---
name: Implementing Tasks
slug: implementing-tasks
category: AI Engineering
description: Implementing Tasks executes an in-memory batch of TDD-sized tasks through an implementer subagent, then spec-compliance and code-quality review loops. Use it during a running iteration when tasks need to be completed one by one with per-task status reported back.
github: "https://github.com/prime-radiant-inc/iterative-development/tree/main/skills/implementing-tasks"
language: Python
stars: 179
forks: 17
install: "npx degit https://github.com/prime-radiant-inc/iterative-development/tree/main/skills/implementing-tasks ~/.claude/skills/implementing-tasks"
installs_to: ~/.claude/skills/implementing-tasks
source_path: skills/implementing-tasks/SKILL.md
collection_size: 6
category_size: 3475
collection_url: "https://dirskills.com/collections/prime-radiant-inc/iterative-development"
added: 2026-09-07T05:20:44.289Z
last_synced: 2026-09-07T05:20:44.289Z
canonical_url: "https://dirskills.com/skills/implementing-tasks"
---

# Implementing Tasks

Implementing Tasks executes an in-memory batch of TDD-sized tasks through an implementer subagent, then spec-compliance and code-quality review loops. Use it during a running iteration when tasks need to be completed one by one with per-task status reported back.

**Install:**

```bash
npx degit https://github.com/prime-radiant-inc/iterative-development/tree/main/skills/implementing-tasks ~/.claude/skills/implementing-tasks
```

## README

# 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