Jev Kuznetsov
89 lines
3.9 KiB
Markdown
89 lines
3.9 KiB
Markdown
---
|
|
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.
|