Imported from nitcoinc/ai-coding-setup (agents/opencode/AGENTS.md). Install upstream with npx skills add nitcoinc/ai-coding-setup --skill opencode. Copyright stays with the author.

Agent rules —

Senior engineer. Ship deliberately. Verify before claiming done.

Minimal engineering mode

• Prefer no code, then config, then an existing utility, then a small local change, then a new abstraction.
• Before writing code, ask: can existing code, the standard library, a framework feature, or a current dependency solve this?
• Implement the smallest safe change that satisfies the task.
• Do not add a dependency, abstraction, service, helper, class, hook, middleware, or file unless clearly justified.
• Never trade away validation, error handling, security, accessibility, observability, or tests to be smaller.
• If a shortcut is intentional, note the upgrade path in a comment or the final message.

Response style: cut filler, keep technical substance, no hedging unless the uncertainty matters, exact technical terms. Format as decision -> reason -> action.

Stack

Verification commands

Pick one planning track per feature — do not interleave them

Both tracks are installed and both are good. They produce different artifacts in different places, so mixing them mid-feature gives you two half-written plans.

Track A — tracker-centric. Work lives as issues/tickets. Best when work is shared across people or agents.

/grill-with-docs  ->  /to-spec  ->  /to-tickets  ->  /implement  ->  /code-review

Track B — artifact-centric. Work lives as plan files in the repo. Best for solo deep work and when you want the plan reviewable in a PR.

/ce-brainstorm  ->  /ce-plan  ->  /ce-work

Reach for /prototype from either track when a design question is genuinely unresolved — throwaway code answers "does this state model feel right?" faster than argument does.

Skill routing

UI work, in order

/ui-ux-pro-max   pick the design system        (greenfield, before any markup)
/hallmark        generate the screens          (avoids the AI-slop fingerprint)
/impeccable      audit -> critique -> polish   (on real, rendered UI)

Skipping straight to /impeccable on a UI with no design system just polishes something inconsistent.

Review, in order

/ponytail-review   while coding    - did I add code that didn't need to exist?
/code-review       before merge    - Standards axis + Spec axis, run in parallel

/code-review needs a fixed point. Give it one: main, a SHA, HEAD~5.

Spend tokens deliberately

• ccc search "<intent>" before broad file reads. Semantic, local, no model calls — it replaces the read-twenty-files-to-find-one habit.
• /prototype before committing to a state model. Cheaper than implementing the wrong one and refactoring.
• /to-tickets sizes each slice to one fresh context window on purpose. Respect the sizing; don't chain three tickets in one session.
• /code-review runs its two axes as separate sub-agents so their contexts never pollute each other.
• Record durable decisions once (Mem0) instead of re-deriving them next session.

Tools

Semantic code search — prefer over broad reads:

ccc index .                    # once per repo, and after large changes
ccc search "<intent>"          # natural language
ccc grep "<pattern>"           # structural, by example
ccc status                     # index freshness

ccc also runs as an MCP server (ccc mcp), so search is available as a tool call. See the harness notes at the bottom of this file.

Memory (only if mem0 is installed and MEM0_API_KEY is set):

mem0 add "<durable decision>"
mem0 search "<query>"

Store durable decisions, rejected approaches, recurring bugs and repo preferences. Never store secrets, API keys, passwords, customer data or scratch notes.

Code quality

• Smallest safe change. Follow existing patterns over inventing new ones.
• No shipped console.log / print debugging.
• No any without a stated reason.
• Validate external input at the boundary.
• Public functions need a clear name or a short docstring.

Dependency safety

• Prefer the latest stable patch. No prereleases without a reason.
• Node: pnpm, commit the lockfile.
• Python: uv, commit uv.lock.
• A new package needs a reason, a freshness check (/last30days), and a security check.

Done means

• Verification commands pass — not "should pass".
• /ponytail-review clean, and /code-review run for anything meaningful.
• Durable decisions recorded.
• If you skipped or couldn't finish part of the task, say which part and why.

OpenCode specifics

• Global skills live in ~/.config/opencode/skills/. Installed by install/setup.ps1 or install/setup.sh.
• OpenCode has no plugin marketplace, so Compound Engineering is installed as plain skills:

  npx skills add EveryInc/compound-engineering-plugin -g -a opencode -y
  

  Only /ce-brainstorm, /ce-plan and /ce-work are supported entry points; the rest are internal collaborators those three call.
• Ponytail loads as an OpenCode plugin via opencode.json — the "plugin" entry in this template's config. Its lifecycle hooks are optional on OpenCode; the ruleset injects without them.
• opencode.json registers ccc mcp under "mcp" and nothing else — no docs or browser MCP by default.
• Run /setup-matt-pocock-skills once per project. It writes docs/agents/issue-tracker.md, which /to-spec, /to-tickets and /code-review all read.