/feature

name: feature
description: >
  Runs the full feature workflow: plan, critique, implement, review, QA. Use
  this when starting a new feature. Guides you through each phase with explicit
  gates between steps.

/feature — AI-Assisted Development Lifecycle

Activate this skill for non-trivial features or changes to run the full structured development workflow: plan → critique → implement → test → code-review → QA → PR.

---

Workflow

Step 1 — Draft, critique, and approve the plan

**Preconditions — check the branch first.** The workflow assumes the human started this session on a fresh feature branch: the code review (Step 4) diffs against the default branch (named in `AGENTS.md` → *Commands*) and Step 9 opens a PR targeting it, neither of which works from the default branch itself. If the session is on the default branch, STOP and ask the user to create a feature branch — you may not create or switch branches yourself (Rule 3 in `AGENTS.md`).

**Enter plan mode now**, before drafting. Plan mode is a structural commitment: while in plan mode the harness blocks edit tools, so the workflow cannot skip the approval gate even if the agent is tempted to inline the plan and proceed. Stay in plan mode through steps 1a, 1b, and 1c. Exit plan mode only in step 1c, after the user approves.

Step 1a — Draft the plan

Invoke the `planner` sub-agent to draft an implementation plan. Pass the user's prompt verbatim — including any reference to docs or links. The planner will fetch all external specs with its own tools (it has `WebFetch` for URLs) and return the plan as markdown text.

Do not use tools directly — always delegate to the planner sub-agent, regardless of which platform you are running on.

Step 1b — Critique the plan

Invoke the `plan-critic` sub-agent with the draft plan as input. The critic will apply pre-mortem, inversion, load-bearing assumption analysis, and consistency checks against ADRs and product docs, and return the critique as markdown text.

Skip this step ONLY if the change qualifies as trivial under ALL of:

• diff is plausibly under ~50 lines of non-test code,
• touches none of the project's sensitive areas (the *Sensitive Areas*

section in `AGENTS.md` is the canonical list),

• introduces no new public endpoints, no new persisted fields, no new

external dependencies,

• AND the user explicitly said "skip the critic" (or equivalent) in

this session.

If any condition fails, run the critic. When in doubt, run it. Do not infer "trivial" from your own read of the plan — the user has to ask.

Step 1c — Present plan and critique for approval

Present BOTH the plan and the critique to the user for approval, using whatever mechanism the harness provides for exiting plan mode.

**Lead with the approval screen**: the plan's **Approval Summary** first, immediately followed by the critique's **Confidence** verdict and its top findings (any suggested amendments the user is likely to want). This is what the user reads on a phone. The full plan and the full critique follow below, clearly separated — make clear which sections are the plan and which are the critique; do not interleave them. The user reads the approval screen (and drills into the detail only where needed) and decides whether to approve as-is, amend the plan based on critique findings, or request a re-plan.

Do not proceed until the plan is approved. On a substantive change (new scope, a different approach, or reworked requirements), re-enter plan mode and re-invoke the `planner` sub-agent to revise the plan — do not re-plan yourself — then re-run the `plan-critic` and re-present for approval. When re-presenting a revised plan, lead with a short **delta** section — what changed relative to the previously presented version — so the user re-reads only the changes, not the whole plan again.

If the user approves the plan conditional on adopting specific critique amendments ("approved, but also address point 2"), you may fold those specific amendments into the plan text yourself before implementing — that is transcribing an accepted decision, not fresh planning, so it does not need another planner round. The `code-critic` and `adversarial-qa` sub-agents receive only the plan text — an amendment that lives only in the conversation is invisible to them.

After approval, retain the plan text — you will pass it to the `code-critic` and `adversarial-qa` sub-agents later.

Step 2 — Implement

**Acceptance tests first.** Before implementing, write the end-to-end tests from the plan's Test Strategy — at minimum the `[AC-<slug>-n]`-tagged ones. They encode the approved contract, so drift from the plan surfaces as a failing test during implementation instead of a surprise at review. Tests derived from the plan may not be weakened, loosened, or rewritten to make them pass — if one turns out to be wrong, treat it as a plan deviation (below): flag it, don't silently adjust it.

Then implement the approved plan in small logical steps until the suite is green. Run the test suite once a coherent unit of work is complete (e.g., after finishing a module or a meaningful set of related changes) — not after every individual step.

**Look up current library/API docs instead of relying on training-time memory for version-sensitive details.** Before writing code against an external library or framework — especially anything that could have changed since training (recent APIs, config shape, breaking changes) — use the bundled `context7` MCP server — resolve the library ID, then query its docs — to pull current docs rather than guessing. Skip it for stdlib/language-core usage you're already confident about. This is a quality aid, not a gate like the canonical commands in Rule 1 — if the lookup errors or the library isn't found, note it in your summary and proceed on your best existing knowledge rather than stopping the implementation step over it.

If you discover something during implementation that changes what nee