Implementation (Subagent-Driven)

Orchestrates implementation using subagents for coding, spec review, paper alignment review, and domain auditing. One component at a time, three-stage review after each.

Overview

The Subagent-Driven Research skill executes approved implementation plans by dispatching specialized subagents for each stage of the process. It enforces a strict one-component-at-a-time discipline with mandatory three-stage review, ensuring that no code ships without spec compliance, paper alignment, and domain audit checks.

3-Stage Review Process

For each task in the approved plan, three review stages run sequentially. All three must pass before moving to the next component.

Stage 1: Implementation

Dispatch the implementer subagent with:

• The specific task from the plan (exact file paths, what to implement, paper reference)
• The full design context (investigation README, paper notes, design doc)
• The implementation constraints (what NOT to change, existing behavior to preserve)

Stage 2: Spec + Paper Review

After implementation, two reviews run:

a) Spec compliance review:

• Does the implementation match the plan's specification?
• Are all verification steps from the plan satisfied?
• Were any deviations from the plan made? (If so, they must be justified)

b) Paper alignment review:

• Dispatch the paper-alignment-auditor on the implemented component
• Provide it with the relevant paper notes from scratch/paper-notes/
• This catches equation/algorithm mismatches before they become training bugs

Stage 3: Domain Audit

Dispatch auditors in parallel based on what was changed:

Gate 3: Per-Component Presentation

After all three stages complete, audit results are presented to the user.

If all auditors pass:

"All auditors passed for [component name].
Spec ✓, Paper alignment ✓, Domain audit ✓.
Moving to next component?"

If any auditor flags an issue:

## Component [N] Audit Results

### Passed
- ✓ Spec compliance: matches plan specification
- ✓ Regression guard: existing configs unchanged

### Issues Found
- ✗ [Auditor]: [specific finding]
  - Evidence: [what the auditor found]
  - Severity: [Critical/Medium/Minor]

### My Assessment
[Whether the issues are real bugs or false
 positives, with reasoning]

### Question
[Specific question about how to handle the finding
 — disjunctive, not yes/no]

Key Constraints

1. One component at a time. Never implement multiple components in parallel — each component's review must complete before the next starts.
2. Never skip reviews. Even if the implementation seems trivial, run all three stages.
3. Complete the review loop. If a review finds an issue and the user requests a fix, implement the fix and re-run the review before moving on.
4. Full context to subagents. Subagents have no conversation history — their prompts must be self-contained. Include all relevant files, design context, and paper references in every dispatch.
5. Track progress. Update the plan with completion status after each component.

Context Management

Multi-component implementations can span long sessions. The skill manages context by:

• Dispatching work to subagents (each gets a fresh context window) rather than accumulating everything in the main conversation
• Offering pause points every 3 components for /clear
• Tracking progress in the plan file so sessions can resume after clearing
• Keeping audit results concise for clean passes (one line) and detailed only when issues are found