Menu
Start implementing a feature with user story validation, phased execution, and quality gates. Use after planning is complete.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Audit Ansible playbooks, roles, collections, and inventories for production readiness. Use when reviewing an Ansible repo, before merging IaC PRs, before promoting a role to a collection, or when the user mentions ansible-lint, idempotency, vault, or molecule.
Enter planning mode — interview the user, design a phased approach, and produce an implementation plan before writing code.
Execute an approved /plan unattended — phases, agents, commits — stopping only on hard safety failures (hook exit 2, sandbox/network deny, repeated test failures). Use after /plan when the user wants hands-off execution.
Run a full read-only audit of the current project — code review, security analysis, and documentation freshness check. Use to assess project health without making changes.
Take a project from "it works" to "it's shippable." Runs audit, fixes findings, walks the Definition of Done checklist, and generates a release readiness score. Use before releasing, after feature-complete, or when quality feels prototype-y.
Run the Goldfish Protocol — test a design doc's completeness by verifying a fresh session can reconstruct the plan from it alone. Use after /plan, before /implement, on any complex feature.
| name | implement |
| description | Start implementing a feature with user story validation, phased execution, and quality gates. Use after planning is complete. |
| model | opus |
| argument-hint | [--phase N] [plan slug or feature description] |
Execute a planned feature with quality gates at each step.
Ask via dialog: When this skill needs a decision, preference, or clarification, call
AskUserQuestion(ToolSearch select:AskUserQuestionif the schema isn't loaded). Don't embed questions in prose. See~/.claude/CLAUDE.md§ "Asking the User Questions" for the full rule.
Before writing code, verify:
If any are missing, ask the user before proceeding.
Check if docs/cujs/ exists and is not opted out. If CUJs exist:
"This feature introduces a new user flow that isn't documented as a CUJ. Want me to scaffold one with
/cuj?"
Check if docs/decisions/ exists and is not opted out. If ADs exist:
"This implementation would use [X], but AD [number] chose [Y] because [reason]. Should we proceed anyway or create a new AD to supersede it?"
For each phase:
While writing code, hold to two rules from rules/karpathy-principles.md:
If the plan's phase steps weren't already in step → verify: check format, restate them that way before executing — it makes "phase done" objective instead of vibes.
After each phase, check:
After passing the quality gate, set review markers so the pre-commit gate allows the commit:
~/.claude/hooks/mark-reviewed.sh --tests
~/.claude/hooks/mark-reviewed.sh --coverage <percentage>
After passing the quality gate:
--phase N)When invoked as /implement --phase N <plan-slug> (e.g. by /autopilot), behave as follows:
~/.claude/plans/<slug>.mdstep → verify block exactly as writtentests-passed and coverage-checked markers, even for phases with no test surface (docs-only, config-only, scaffolding). For non-test phases, set coverage-checked 100 since there is no executable code to leave uncovered. This prevents the 5-gate hook from blocking autopilot's per-phase commitcode-reviewed — the caller (/autopilot) invokes code-reviewer separately as part of its review-agent stepPhase N complete: <files touched> · tests <pass/fail> · coverage <pct>This mode is harmless for manual users — without --phase N, behavior is unchanged.
After implementation:
Phase [N] complete:
- [summary of changes]
- Tests: [pass/fail count]
- Coverage: [percentage]
- Next: [what comes next or "ready for review"]