cli-tools/ai-tools/skills/develop/SKILL.md

name, description

name	description
develop	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.