Initial project scaffold with uv

.opencode/skills/debug/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: debug
+description: Diagnose frozen, slow, or misbehaving sessions by reading debug logs and system state
+compatibility: opencode
+metadata:
+  workflow: diagnostics
+---
+
+## What I do
+
+I diagnose problems with the current session — freezes, slowness, errors, or unexpected behavior — by reading debug logs and checking system state.
+
+## How to use me
+
+1. **Find the debug log.** Check these locations in order:
+   - `~/.local/share/opencode/logs/` (Linux)
+   - `~/Library/Application Support/opencode/logs/` (macOS)
+   - `~/.config/opencode/logs/` (fallback)
+   - Environment variable `OPENCODE_LOG_DIR` if set
+   - Any `.log` files in the project root or `.opencode/` directory
+
+2. **Read the tail of the log** (last 50-100 lines, or last 64KB max). Do not read the entire log file — it can be enormous.
+
+3. **Check system state:**
+   - Is the process still running? (`ps aux | grep opencode`)
+   - Is CPU usage abnormally high?
+   - Is memory usage growing unbounded?
+   - Are there zombie or defunct child processes?
+   - Is the git repo in a weird state (merge conflict, detached HEAD, locked index)?
+
+4. **Identify the problem category:**
+   - **API errors** — rate limits, auth failures, model errors, timeout
+   - **Tool errors** — command failures, permission denials, file not found
+   - **Session freeze** — no output for extended period, hung child process
+   - **Performance** — slow responses, high token usage, context window overflow
+   - **Configuration** — missing API key, wrong model, broken settings
+
+5. **Report findings with evidence.** Quote relevant log lines. Do not speculate without log evidence.
+
+## Investigation rules
+
+- Reproduce before you reason. Never guess at a cause without first confirming the bug.
+- Read logs, don't hallucinate. Quote specific log lines with timestamps.
+- If you cannot reproduce, report what you tried and ask for more information.
+- If the problem is upstream or environmental, say so explicitly.
+
+## Output format
+
+### Symptoms
+What the user reported or what I observed.
+
+### Log Evidence
+Relevant log lines (quoted, with timestamps).
+
+### Diagnosis
+What is wrong and why.
+
+### Recommended Fix
+Specific steps to resolve the issue.
+
+### Escalation
+If the problem is a bug in opencode itself, note the version, reproduction steps, and suggest filing an issue at https://github.com/anomalyco/opencode/issues.
+
+## When to use me
+
+Use this when a session is frozen, slow, throwing errors, or behaving unexpectedly. Do not use for general code debugging — this skill is for diagnosing the tool itself, not the user's code.
+

.opencode/skills/simplify/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: simplify
+description: Review changed code for reuse, quality, and efficiency, then fix issues found
+compatibility: opencode
+metadata:
+  workflow: code-review
+  parallel: true
+---
+
+## What I do
+
+I review your recent changes from three angles in parallel, then fix the issues I find.
+
+## How to use me
+
+1. Identify the changed files using `git diff` (staged or unstaged).
+2. Launch three parallel review agents, each with a different focus:
+   - **Reuse Review**: Look for duplicated logic, copy-paste patterns, or abstractions that already exist in the codebase. Check if the new code reinvents something that's already available as a utility, helper, or library function.
+   - **Quality Review**: Look for hacky patterns, missing error handling, unclear naming, magic numbers, overly complex functions, and violations of existing project conventions.
+   - **Efficiency Review**: Look for unnecessary allocations, N+1 queries, redundant iterations, missing early returns, and opportunities to simplify algorithms.
+3. Wait for all three agents to finish.
+4. Aggregate findings by severity (bugs > correctness > performance > style).
+5. Fix the highest-severity issues directly. For lower-severity items, report them for the user to decide.
+
+## Agent prompt template
+
+For each review agent, use this structure:
+
+```
+You are a code reviewer focused on [REUSE|QUALITY|EFFICIENCY].
+
+Review the following changed files. You are a sub-agent — do NOT modify files, only report findings. The parent skill will apply fixes after aggregating all reviews.
+
+Changed files:
+<list files from git diff>
+
+For each finding, provide:
+- File path and line number
+- What is wrong
+- Why it matters
+- Suggested fix (if applicable)
+
+Order findings by severity: bugs > correctness > performance > style.
+If you find no issues, say so explicitly.
+```
+
+## Output format
+
+### Findings
+Ordered by severity. Each finding includes file, line, issue, and fix.
+
+### Applied Fixes
+List of changes made with rationale.
+
+### Remaining
+Lower-severity items left for the user to decide.
+
+## When to use me
+
+Use this after making a set of changes and before committing. Do not use for exploratory reading — this skill modifies files.
+
+

.opencode/skills/verify/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: verify
+description: Prove a code change works by running real commands and checking output
+compatibility: opencode
+metadata:
+  workflow: testing
+  adversarial: true
+---
+
+## What I do
+
+I verify that a code change actually works by running real commands — not by reading code and guessing.
+
+## How to use me
+
+1. Identify the changed files using `git diff` (staged or unstaged).
+2. Inspect the changed files to understand what behavior should be validated.
+3. Identify the smallest set of commands that can verify that behavior:
+   - Run relevant tests (`npm test`, `go test`, `pytest`, etc.)
+   - Run type checks (`tsc --noEmit`, `mypy`, etc.)
+   - Run linters if they catch correctness issues
+   - Build the project if build errors would indicate problems
+   - For CLI tools, run the tool with test inputs
+   - For APIs, make test requests with `curl`
+4. Execute the checks in order of signal: tests first, then typecheck, then lint, then build.
+5. For failures, investigate root cause — distinguish product bugs from flaky tests from environment issues.
+6. Report results with evidence.
+
+## Verification rules
+
+- Run real commands. Reading code is not verification.
+- Check happy paths and at least one meaningful edge case.
+- Investigate failures instead of dismissing them.
+- Distinguish between product bugs, flaky tests, and environment problems.
+- Do not rubber-stamp. If evidence is weak, say so plainly.
+
+## Anti-patterns to avoid
+
+- "The code looks correct" — not verification
+- "Tests should pass" — run them and prove it
+- Skipping checks because the change "looks simple"
+- Accepting partial test runs as full verification
+
+## Output format
+
+### Checks Run
+List each command or manual flow executed.
+
+### Results
+For each check: PASS or FAIL with the actual output as evidence.
+
+### Confidence
+State one of:
+- **Verified** — all checks passed, edge cases covered
+- **Partially verified** — some checks passed, gaps remain
+- **Not verified** — checks failed or could not be run
+
+### Gaps
+Anything still unproven. Be specific about what was not checked and why.
+
+## When to use me
+
+Use this after implementing a change to prove it works. Use before committing or opening a PR. Do not use for exploratory code reading.
+