"/feature-loop Add cursor-based pagination to the /api/posts endpoint"
The orchestrator agent assesses complexity, then delegates to three separate sub-agents: one writes the code, another writes tests from the spec (without seeing the implementation), and a blind reviewer evaluates the result. Before any LLM review, an objective gate checks the build, lint, typecheck, tests, and verifies that tests can actually fail. The loop runs until every quality axis hits 8/10, producing a final report and keeping the best version.
What it does
A mother agent sizes the difficulty, then delegates to SEPARATE subagents: the one writing the code is neither the one writing the tests (from the spec) nor the blind reviewer. An objective gate (build, lint, typecheck, tests, plus a check that the tests can actually fail) runs BEFORE any LLM review. Any runnable feature gets a mandatory live smoke test before the word "tested" is allowed.
When to use it
For a real feature where quality matters more than raw speed. The loop runs until every quality axis hits 8/10 with no critical (max 3 iterations), keeps the best version, and emits a report. Not for a quick edit (just do it) nor a plain review (use senior-review).
The stance: an agent that writes code can't judge it objectively. Hence the strict separation (writer, test-writer and reviewer are three different agents) and the objective gate BEFORE any LLM review. Tests must prove they can fail, otherwise an always-green test passes for a guarantee.
Install this skill
$ /plugin marketplace add ohugonnot/claude-skills
$ /plugin install feature-loop@web-developpeur-skills
Frequently asked questions
When should I use /feature-loop instead of just coding directly?
When quality matters more than speed: non-trivial feature, critical logic, code that needs to hold up over time. For a quick fix or a rename, just do it directly.
How is this different from /senior-review?
/feature-loop builds the feature in an iterative loop with an objective gate and separate sub-agents. /senior-review reviews already-written code before a merge. They're complementary, not interchangeable.
Why do tests need to know how to fail before the LLM review?
A test that always passes proves nothing. The gate explicitly verifies that breaking the implementation turns tests red, otherwise they're rejected before any review happens.
Feedback & discussion · 0
No feedback yet. Tried it? Tell us what you think.