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. Use when handed a ticket / story / feature spec with acceptance criteria and the goal is shippable, self-checked code — not a first draft.
Pack dev-teamTier standardJob Build and review softwarev0.1.0
In Claude Code, with the dev-team plugin installed, invoke it as:
/dev-team:feature-implement-loop
Try it
A realistic prompt from the skill's acceptance evals:
Implement this story in our Python/FastAPI service (pytest, ruff, mypy already set up):
As an admin, I can export the audit log for a date range as CSV.
Acceptance criteria:
1. GET /admin/audit/export?from=YYYY-MM-DD&to=YYYY-MM-DD returns text/csv.
2. Non-admins get 403.
3. from after to returns 400 with a clear message.
4. Ranges over 90 days return 400.
5. The CSV opens cleanly in Excel.
Build it and check your own work.
What a good result looks like
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.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 68% of its checks, against 44% without it, and a blind judge preferred it. How skills are checked
21 assertions across 3 acceptance evals, and 7 trigger queries. Every skill's checks
What the output must do
Restates the five acceptance criteria as a numbered checklist before writing code
Plans a named test per criterion up front and flags criterion 5 (opens cleanly in Excel) as manual-verify
Runs the project's tests plus ruff and mypy, and does not report VERIFIED while any command is red
Review findings are tagged blocker/major/minor/nit with file:line and a concrete fix, covering edge cases, security (e.g. authz on the admin route, CSV formula injection), and craft
Tests assert the criterion's expected output (status codes, content type, messages), not just that the call didn't throw
Stops at or before 3 rounds, and later rounds patch only the named gaps rather than regenerating the whole feature
Final report has a status (VERIFIED, VERIFIED WITH OPEN ITEMS, or BLOCKED), an acceptance-criteria table mapping each criterion to a test, manual-verify, or open item, an honest round log, and open items
Does not add criteria the user did not give without echoing them back first
Implements the fee calculation with tests, runs python3 -m unittest discover -s tests, and reports the real result; it does not claim tests pass without having run them
Flags that the ticket's worked example is wrong: 8 March is a Sunday and 9 March is a closure day, so 3 chargeable days and $0.75, not $1.25; no test expects $1.25
Notices that the existing MAX_FEE of $15.00 in fees.py conflicts with the ticket's $10.00 cap and says which one it applied
Has tests with specific expected amounts for the junior-card rule, the cap at the lower of replacement cost and $10.00, and the Sunday and closure exclusions
Does not invent a daily rate for magazines; a magazine is rejected or raised as a decision for the user
Uses only the standard library, and the existing tests and desk.checkin still work
The closing summary is short (a few lines plus any decisions needed)
After the change, running rota.py puts nobody on a date when away.txt says they are away, even though away.txt uses different capitalisation and extra spaces
Handles or clearly points out that Edith Marsh is back for 5 Dec, rather than silently leaving her off every date or treating '(back for the 5 dec one)' as part of her name
The header line and the name that is not a member (Ruth Ng) cause no error and do not appear in the rota
The script is actually run and the output keeps the same 'date: name & name' format
The reply to the user is a couple of plain-language lines without programming jargon
Does not add features that were not asked for (no new options, dependencies or file formats)
When it should and shouldn't activate
Should activate:
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
Should leave to another skill:
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
Hands off to
pre-merge-review — when the code exists and the question is whether it can merge. Judge the diff that now exists against a mechanical gate.