implementing-tasks

# Implementing Tasks ## Overview Takes an in-memory batch of TDD-sized tasks and executes each through: implementer subagent (TDD) → PAR spec-compliance review → fix loop → PAR code-quality review with boxing-in check → fix loop → mark complete. This is a fork of `superpowers:subagent-driven-development` with the plan-file reading phase stripped and the final end-of-plan reviewer removed. ## When to Use Invoked by `running-an-iteration` with a list of tasks. Tasks are passed in memory, not via a file. ## Per-Task Cycle For each task in the provided list: ### 1. Dispatch implementer Using the template in `implementer-subagent-prompt.md`, dispatch a single implementer subagent with: - The full task description and context - The proof obligations for each observable AC in the task's stories - The list of existing scenarios that may be impacted The implementer MUST complete a pre-flight mapping (AC → proof seam → scenario) before writing code. If the implementer skips the pre-flight, re-dispatch with explicit instructions to complete it first. ### 2. Handle implementer status - **DONE:** proceed to spec-compliance review (step 3). Verify the implementer's report includes pre-flight mapping and scenario updates. - **DONE_WITH_CONCERNS:** read the concerns. If about correctness/scope, address before review. If observations, note and proceed. - **NEEDS_CONTEXT:** provide the missing context and re-dispatch - **BLOCKED:** assess: context problem → re-dispatch with context; too hard → re-dispatch with more capable model; task too large → break into smaller pieces; plan wrong → escalate to caller ### 3. PAR spec-compliance review (Stage 1) Following `skills/shared/parallel-adversarial-review.md`: 1. Build spec-compliance prompt using `spec-compliance-reviewer-prompt.md` - Include the proof obligations and the implementer's evidence claims 2. Wrap in PAR competitive framing from `skills/shared/par-reviewer-wrapper.md` 3. Dispatch TWO spec-compliance reviewers in parallel 4. Aggregate findings (PAR rules: union of findings, severity = take worst) 5. If ❌ issues found: - Send aggregated issues back to the implementer subagent (same subagent, via continuation message) - Implementer fixes - Re-dispatch fresh PAR spec-compliance pair - Repeat until ✅ spec compliant with adequate evidence 6. Only proceed to Stage 2 after Stage 1 is ✅ ### 4. PAR code-quality review (Stage 2) Following `skills/shared/parallel-adversarial-review.md`: 1. Build code-quality prompt using `code-quality-reviewer-prompt.md` - Include the next 3 pending roadmap iterations for the boxing-in check - Include the implementer's corpus contribution for quality review 2. Wrap in PAR competitive framing 3. Dispatch TWO code-quality reviewers in parallel 4. Aggregate findings 5. If ❌ changes needed: - Send aggregated issues back to the implementer - Implementer fixes - Re-dispatch fresh PAR code-quality pair - Repeat until ✅ approved ### 5. Mark task complete Record the task as done. Move to the next task. After all tasks complete, return a per-task result list to the caller, including: - Per-task status - Scenarios added or updated per task - Evidence commands per task ## Model Selection Use the least powerful model that can handle each role: | Role | Signal → Model | |---|---| | Implementer (mechanical: 1-2 files, clear spec) | Cheap/fast model | | Implementer (integration: multi-file, judgment) | Standard model | | Spec-compliance reviewer | Standard model | | Code-quality reviewer | Most capable model | ## Quick Reference | Per task | Subagents dispatched | |---|---| | Implementer | 1 (sequential, TDD) | | Spec-compliance review (PAR) | 2 in parallel | | Code-quality review (PAR) | 2 in parallel | | **Minimum per task** | **5** (before re-review loops) | ## Red Flags - **Never** start code-quality review before spec compliance is ✅ - **Never** skip the re-review after fixes (reviewer found issues = implementer fixes = review again) - **Never** dispatch multiple implementers in parallel (conflicts) - **Never** accept "close enough" on spec compliance - **Never** let implementer self-review replace the two-stage review ## References - `implementer-subagent-prompt.md` — implementer dispatch template - `spec-compliance-reviewer-prompt.md` — Stage 1 review template - `code-quality-reviewer-prompt.md` — Stage 2 review template (includes boxing-in) - `skills/shared/parallel-adversarial-review.md` — PAR methodology - `skills/shared/par-reviewer-wrapper.md` — competitive framing wrapper