PM + Dev Subagents: Spec-to-Code Loop with Quality Gates

The problem

Single-agent coding tasks often suffer from "self-review blindness" where the agent decides a task is done simply because it stopped typing. Developers frequently find themselves in a "ping-pong" loop with agents that claim success while ignoring acceptance criteria or moving the goalposts by editing the spec.

What it does

• Enforces a strict separation of authority by spawning two subagents: a PM to write the spec and a Developer to write the code.
• Implements a file-based protocol (SPEC.md, BUILD.md, REVIEW.md) that persists across agent crashes or restarts.
• Automates quality gates by detecting and running project-specific tests, linters, and build commands.
• Prevents infinite loops through built-in thrash detection and hard round budgets.
• Ensures the PM agent has no write access to source code, preventing it from reviewing its own fixes.

Why this beats prompting it yourself

Writing "please review your work" in a single prompt rarely works because the agent shares the same context and bias as its mistakes. This skill provides a structured framework with specialized roles, dedicated artifacts, and bash-backed verification that forces objective accountability. It replaces vague conversational feedback with a citation-based rubric that links every code change to a specific acceptance criterion.

Use cases

• Executing complex feature requests where self-correction typically fails.
• Managing long-running refactors that require strict adherence to a multi-point checklist.
• Automating internal PR reviews before a human ever touches the code.
• Ensuring legacy code changes pass a rigorous, multi-stage quality gate without manual oversight.

Known limitations

This skill requires a repository with executable tests or build signals to populate the quality gate. It consumes 3x to 5x more tokens than a single-agent execution, making it unsuitable for trivial fixes.