Use feature-implement-loop

Implement a feature or story so it ends up *verified*, not just generated

Implement a feature or story so it ends up verified, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs an adversarial review pass that hunts for gaps (broken edge cases, baked-in assumptions, uncovered acceptance criteria), and re-generates to close them — looping until the review is clean or a 3-round cap is hit.

Reach for it when handed a ticket / story / feature spec with acceptance criteria and the goal is shippable, self-checked code — not a first draft.

Install it

npx skilldrop-cli install feature-implement-loop                 # Claude Code, your user folder
npx skilldrop-cli install feature-implement-loop --project       # Claude Code, this repo
npx skilldrop-cli install feature-implement-loop --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Implement this ticket and make sure every acceptance criterion actually has a test"
• "Build this story, review your own code adversarially, and fix the gaps"
• "Here's a feature spec with acceptance criteria — give me shippable, self-checked code"
• "Implement the password-reset flow per these criteria and loop until the review is clean"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Review this PR I wrote for edge cases and broken assumptions"
• "Should we use Postgres or DynamoDB for the new service? Write it up for review"
• "Run the pre-merge gate on my branch before I open the PR"

If another skill answers instead, ask for this one by name: "use feature-implement-loop".

Check what you get

A good result:

• Every acceptance criterion maps to a test by the final report. A criterion with no asserting test is an ❌ open item — not a pass. This is the rule that makes the skill more than codegen.
• The review challenges the code; it doesn't rubber-stamp it. A round-1 review that finds nothing on a non-trivial feature is a smell — re-run it adversarially, assuming the first pass missed something (it usually did).
• Tests assert behavior, not just execution. ❌ a test that calls the function and checks it didn't throw. ✅ a test that asserts the criterion's expected output. Catch assertion theater in the review.
• Regeneration is targeted. Each round fixes the named gaps and leaves passing code alone. Don't rewrite the whole feature every round — that loses ground and never converges.
• The cap is real. 3 rounds, then stop and report. A loop that "just one more round"s past 3 is a bug. If it can't converge in 3, a human needs to see why.
• The round log is honest. If round 2 found nothing new, say so. If a gap was downgraded rather than fixed, say why. The log is the audit trail.

Use something else when

• One-line fixes / trivial changes — the loop is overhead; just make the change.
• Greenfield spikes / throwaway prototypes — verifying code you'll delete wastes rounds.
• Specs with no acceptance criteria and none inferable — there's no gate to close. Get criteria first.
• Pure code review of code you didn't generate — that's devils-advocate standalone.
• Open-ended design questions ("should we use Postgres or Dynamo?") — that's design-doc + doc-critique.

Where a loop runs it

• Stage implement of the build loop
• Stage rebuild of the modernize loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: design-doc, devils-advocate, doc-critique, pre-merge-review

Edit this page on GitHub · View source