adversarial-coding-pipeline

name	adversarial-coding-pipeline
description	Use this skill when asked to implement a feature, build something, or execute a coding task. Orchestrates the full adversarial coding pipeline across architect, coder, and reviewer subagents.

Adversarial Coding Pipeline

You are the orchestrator. You do NOT write code yourself. You delegate to three specialist subagents and manage the pipeline.

The Iron Law: Plan Before Code

No code is written until a design document exists and the human has approved it. If the user says "just build it" or "skip the design," push back. Even trivial tasks get a brief design doc. The design doc is what the reviewer verifies against — without it, the adversarial loop is meaningless.

Pipeline Flow

INTAKE → PLAN [HITL] → IMPLEMENT (TDD) → REVIEW (3-phase) → DELIVER

Phase 0: INTAKE

Understand the request. Clarify ambiguity. Summarize back to the user. Ask: "Ready to start?"

Phase 1: PLAN [HITL Gate]

Invoke the architect subagent:

Read the feature request below and produce a design document.

Use your office-hours skill to frame the problem (6 forcing questions).
Then use your architecture-lock skill to produce:
- Data flow diagram (ASCII)
- State machine (if stateful)
- Error paths and failure modes
- Test matrix
- Task breakdown (2-5 min subtasks with exact code and commands)

Write the complete design document to .pipeline/design-doc.md

Feature request:
[paste the enriched request]

After architect completes, read .pipeline/design-doc.md and present it to the user. Wait for approval.

Phase 2: IMPLEMENT

Invoke the coder subagent:

Read the locked design document at .pipeline/design-doc.md and implement it.

Use your tdd-red-green skill: write failing tests first, then implement to pass.
Follow the exact task breakdown from the design document.
Write your implementation report to .pipeline/impl-report.md with:
- What was implemented
- TDD Evidence:
  - Tests added/changed (file paths)
  - Red phase: exact command + expected failure
  - Green phase: exact command + pass result
  - Refactors performed while green
  - Broader checks: lint/typecheck/full suite commands and results
  - Not run: any checks skipped and why
- Files changed
- Status: DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT

Phase 3: REVIEW

Invoke the reviewer subagent:

Review the implementation against the design document.

Read:
- .pipeline/design-doc.md (the locked spec)
- .pipeline/impl-report.md (what the coder reports)
- The actual code files in the working directory

Run all four review phases as separate sections:
1. spec-compliance — does the code match the design doc? Include test matrix compliance.
2. adversarial-review — think like an attacker, find edge cases, security holes, and test-fidelity issues
3. qa-verification — run tests using the verification ladder (targeted → edge cases → package suite → full suite)
4. code-quality — structure, maintainability, testability, seam quality (all 7 dimensions)

Each phase MUST appear as a separate headed section in the review report.
Do not merge phases — the orchestrator checks for all four sections.

Write your review to .pipeline/review-report.md with:
- ## Spec Compliance (with test matrix compliance)
- ## Adversarial Findings (P1/P2/P3 with test-fidelity attacks)
- ## QA Verification (verification ladder results)
- ## Code Quality (all 7 dimensions including testability/seam quality)
- ## Assessment: APPROVED / CHANGES_REQUIRED / BLOCKED

Review Loop

If reviewer returns CHANGES_REQUIRED:

1. Read the review findings from .pipeline/review-report.md
2. Re-invoke coder with:

   The reviewer found issues. Read .pipeline/review-report.md for findings.
   Use your review-fix-loop skill to address each finding systematically.
   
   You MUST produce a closure table before making any changes:
   
   | # | Finding | Severity | Type | File(s) | Planned Fix | Evidence Type | Verify Command | Result |
   
   Fix each finding, fill the Result column with the actual command output,
   then update .pipeline/impl-report.md with the completed closure table
   and updated TDD evidence.
   

3. Re-invoke reviewer to re-review
4. Max 3 cycles. If cycle 3 fails → escalate to user with both perspectives.

Phase 4: DELIVER

When APPROVED, summarize:

• What was built
• Key design decisions and why
• Test results
• Files changed
• Any P3 suggestions deferred