---
name: develop
description: "Autopilot feature delivery: spec, implement, commit, review — stops for manual testing before merge."
---

# Develop

Deliver a feature end-to-end with minimal human intervention.

## Input

`/develop <description>` — a plain-English feature description or slug name.

If no description is provided:
1. Read `docs/feature_backlog.md` if it exists.
2. Pick the first `## NNN — title` item (lowest `NNN`).
3. Announce: "Next up: **NNN — title** — description. Starting now." then proceed.
4. If no backlog exists, ask: "What should I build?" and wait.

## Resuming an interrupted run

1. Run `git log --oneline` to see commits on the branch.
2. Check `Status` in `docs/features/<NNN-slug>.md`.
3. Skip completed phases, continue from the next one.

## Phase 0 — Setup

1. Derive a slug from the description (e.g. `user-auth`, `csv-export`).
2. Determine the numeric prefix: list files in `docs/features/` matching `[0-9][0-9][0-9]-*.md`, find the highest number, and use one higher. If no files exist, start at `001`. Format: `NNN-<slug>` (e.g. `001-user-auth`, `042-csv-export`).
3. Use the full prefixed slug everywhere: branch name (`feat/NNN-<slug>`), spec file (`docs/features/NNN-<slug>.md`), and commit messages.
4. Run `git checkout -b feat/<NNN-slug>` to create the feature branch. If it already exists, switch to it.
5. If the working tree is dirty, stash changes first with `git stash`, then pop after switching.

## Phase 1 — Spec

1. Read `docs/architecture.md` if it exists (not required).
2. Write a lightweight feature spec to `docs/features/<NNN-slug>.md` using the template in `assets/spec-template.md`.
3. Make reasonable assumptions — flag each with `[ASSUMPTION]` in the spec.
4. Ask only if a missing answer would materially change the result and cannot be inferred. Otherwise choose the simpler option and flag it.
5. Commit the spec: `docs(<NNN-slug>): add feature spec`

## Phase 2 — Implement + Commit

Delegate to the **implementer** subagent (Sonnet). Provide it with:
- The feature spec path
- The architecture doc path (if it exists)
- Instruction to write tests first, then production code
- Instruction to commit atomically as it goes (conventional commits)
- Instruction to run tests after each logical step
- Instruction to read only the minimum files needed

If the implementer reports `[BLOCKED]`, stop and report the blocker to the user.

**Copilot / single-thread mode:** run implementation directly — read the spec, write tests, implement, commit, run tests.

## Phase 3 — Review

1. Run the test suite (`inv test` or project-appropriate test command).
2. Run `git diff main...HEAD` to see all changes on the feature branch.
3. Compare against the feature spec:
   - Are all acceptance criteria addressed?
   - Do tests pass?
   - Any obvious issues (broken imports, missing files, dead code)?
4. Decision:
   - **PASS** → update spec status to `approved`. Stop and tell the user: "Feature branch `feat/<NNN-slug>` is ready. Test it, then run `/merge <NNN-slug>` to merge."
   - **FIXABLE** → loop back to Phase 2 with specific fix instructions. Maximum **1 retry**.
   - **BLOCKED** → update spec status to `blocked`, stop and report to user.

## When to stop

Stop and report to the user ONLY for:
- Contradictions between the feature description and existing architecture
- Test failures that can't be resolved after 3 attempts
- Merge conflicts that can't be auto-resolved
- Missing critical information that genuinely cannot be assumed

Do NOT stop for:
- Choosing between implementation approaches (pick the simpler one, flag with `[ASSUMPTION]`)
- Creating new files or modules (just do it)
- Commit message wording (use conventional commits)

## Rules

- No approval gates.
- Make assumptions and flag them.
- Atomic conventional commits throughout.
- Feature branches are temporary — created and merged automatically.
- If the project has no test infrastructure, skip test-related steps and note it in the review.