<mission_control> <objective>Guide software development from planning through verification with TDD discipline and quality gates</objective> <success_criteria>All phases completed with evidence: plan created, TDD cycle followed, all 6 quality gates pass</success_criteria> </mission_control>

Engineering Lifecycle

Skill Location: This file

Workflow

Plan new feature: /plan:create → Brief → Roadmap → Phases

Continue existing work: /strategy:execute → Executes STRATEGY.md phases with parallel batching

Implement with TDD: RED (write test) → GREEN (minimal code) → REFACTOR (cleanup)

Verify completion: /quality:run-gates (6-phase) or /quality:quick (5-phase)

Why: TDD discipline catches bugs early—80%+ coverage target ensures maintainability.

Batching Strategy

Redline Protocol: When implementing multiple features:

1. •Plan all features → Create single PLAN.md with all features
2. •Execute sequentially → Each feature RED→GREEN→REFACTOR
3. •Verify after each → Run quality gates before next
4. •Batch commits → Single commit for related features

Navigation

System Requirements

• •Plan structure: 2-3 task chunks, <50% context usage
• •TDD cycle: RED (test) → GREEN (code) → REFACTOR (cleanup)
• •Coverage target: 80%+ for new code
• •Quality gates: BUILD → TYPE → LINT → TEST → SECURITY → DIFF

The Path to High-Quality Engineering

1. •

   The TDD Discipline — Test-Driven Development catches bugs early, when they're cheapest to fix. RED→GREEN→REFACTOR creates a rhythm of verification that prevents technical debt.

2. •

   Plan Discipline — Focused plans with 2-3 tasks maintain cognitive clarity. Scope creep destroys plans—new ideas go back to planning, not into current execution.

3. •

   Verification Discipline — Quality gates prevent debt accumulation. Every skipped gate compounds technical debt. Verification is practice, not a checkpoint.

4. •

   Coverage Excellence — 80%+ coverage ensures maintainability and confidence in changes. Tests after = tests that don't catch regression.

Implementation Patterns

Pattern: TDD Cycle

// RED: Write failing test
describe("Calculator", () => {
  it("adds two numbers", () => {
    expect(add(10, 20)).toBe(30);
  });
});
// Result: Fails — add() is not defined

// GREEN: Minimal code to pass
export const add = (a: number, b: number): number => a + b;

// REFACTOR: Clean up while tests stay green
export function add(a: number, b: number): number {
  if (!Number.isFinite(a) || !Number.isFinite(b)) {
    throw new Error("Arguments must be finite numbers");
  }
  return a + b;
}

Pattern: PLAN.md Structure

# Feature: User Authentication

## Overview

Brief description of the feature.

## Tasks

### Task 1: Implement auth service

- [ ] Create auth service with login/logout
- [ ] Add unit tests

### Task 2: Add JWT tokens

- [ ] Implement token generation
- [ ] Add token validation

## Verification

- [ ] All tests pass
- [ ] TypeScript compiles without errors
- [ ] ESLint reports no issues

Pattern: Execution Mode Selection

Troubleshooting

Core Loop

PLANNING → IMPLEMENTATION (TDD) → EXECUTION → VERIFICATION

Workflow Overview

graph TD
    A[Start Feature] --> B{Plan Exists?}
    B -->|No| C[Planning Phase]
    C --> D[Create PLAN.md]
    D --> E{Plan Approved?}
    E -->|No| C
    E -->|Yes| F[Execution Phase]
    B -->|Yes| F
    F --> G{Task Complete?}
    G -->|No| H[TDD Cycle]
    H --> I[RED: Write Test]
    I --> J[GREEN: Minimal Code]
    J --> K[REFACTOR: Clean Up]
    K --> G
    G -->|Yes| L[Verification Phase]
    L --> M[6-Phase Gate]
    M --> N[Complete]

TDD Loop Detail

graph LR
    A[RED: Write Failing Test] --> B[GREEN: Minimal Code]
    B --> C[REFACTOR: Cleanup]
    C --> A
    C --> D[VERIFIED: 80%+ Coverage]

Workflow Patterns

Planning with Funnel

Explore Step

• •Investigate codebase, git history, constraints

Ask Step

• •One focused question with 2-4 recognition-based options

Refine Step

• •Next question if scope still unclear

Write Step

• •Generate PLAN.md with checkpoints and verification criteria

Confirm Step

• •"Plan ready. Invoke /strategy:execute?"

TDD Implementation

Explore Step

• •Identify test cases: happy path, edge cases, error scenarios

Write Step

1. •RED: Write failing test (one behavior, real code)
2. •GREEN: Minimal code to pass (no features)
3. •REFACTOR: Clean up while tests stay green

Confirm Step

• •Verify 80%+ coverage achieved

Execution with Mode Routing

Autonomous Mode

Plan has no checkpoints → Fresh subagent executes all tasks

Segmented Mode

Plan has human-verify checkpoints → Subagent for segments, main for checkpoints

Main Context Mode

Plan has decision/action checkpoints → Sequential main context execution

Reviewed Mode

Quality gates requested → Fresh subagent + 2-stage review

The TDD Pattern

Apply the RED-GREEN-REFACTOR cycle to every behavior:

1. RED (The Specification)

// tests/calculator.spec.ts
describe("Calculator", () => {
  it("adds two numbers", () => {
    expect(add(10, 20)).toBe(30);
  });
});
// Result: Fails — add() is not defined

2. GREEN (The Minimum)

// src/calculator.ts
export const add = (a: number, b: number): number => a + b;

3. REFACTOR (The Cleanup)

Add types, edge cases, and polish without changing behavior:

// src/calculator.ts
export function add(a: number, b: number): number {
  if (!Number.isFinite(a) || !Number.isFinite(b)) {
    throw new Error("Arguments must be finite numbers");
  }
  return a + b;
}

The invariant: Tests define behavior. Code implements it. Refactoring improves structure without changing either.

References

YAGNI Principle

YAGNI ruthlessly - Prevent scope creep during implementation.

Before adding any feature, ask:

• • Is this in the original plan?
• • Does the spec require this?
• • Can the task complete without this?

If you catch yourself thinking "while we're at it, let's add...", stop. That's scope creep, not quality.

Scope discipline: Implement only what's specified. New ideas go back to planning.

Common Rationalizations

If you catch yourself thinking these, STOP. Run the gates.

Few-Shot PLAN.md Examples

Use examples/ for reference when creating plans:

PLAN.md Structure Reference

# Feature: [Name]

## Overview

Brief description of what this feature does.

## Tasks

### Task 1: [First atomic unit]

- [ ] Subtask 1
- [ ] Subtask 2

### Task 2: [Second atomic unit]

- [ ] Subtask 1
- [ ] Subtask 2

## Verification

- [ ] Criterion 1
- [ ] Criterion 2

Key principles:

• •2-3 tasks max (keep context under 50%)
• •Each task is atomic and independently verifiable
• •Tasks follow RED→GREEN→REFACTOR cycle

Operational Patterns

This skill follows these behavioral patterns:

• •Planning: Switch to planning mode for architectural phases
• •Tracking: Maintain a visible task list throughout execution
• •Delegation: Delegate implementation to specialized workers
• •Verification: Verify quality metrics before claiming completion

Use native tools to fulfill these patterns. Trust the System Prompt to select the correct implementation.

The Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven't passed all 6 quality gates, completion cannot be claimed.

The 6-Phase Gate System

Violating the letter of this process is violating the spirit of quality.

Common Mistakes to Avoid

Mistake 1: Skipping the Test Phase

❌ Wrong:

// Write production code first
export function add(a, b) { return a + b; }

✅ Correct:

// RED: Write failing test first
describe("Calculator", () => {
  it("adds two numbers", () => {
    expect(add(10, 20)).toBe(30);
  });
});
// Then implement production code

Mistake 2: Writing Too Much Code in GREEN

❌ Wrong:

// GREEN: Adding validation, edge cases, features
export function add(a, b) {
  if (!Number.isFinite(a) || !Number.isFinite(b)) {
    throw new Error("Arguments must be finite numbers");
  }
  if (a < 0 || b < 0) { /* more logic */ }
  return a + b;
}

✅ Correct:

// GREEN: Minimal code to pass the test
export const add = (a, b) => a + b;

// REFACTOR: Add validation afterward
export function add(a, b) {
  if (!Number.isFinite(a) || !Number.isFinite(b)) {
    throw new Error("Arguments must be finite numbers");
  }
  return a + b;
}

Mistake 3: Skipping Quality Gates

❌ Wrong: "Tests pass, we're done" → Skip BUILD, TYPE, LINT, SECURITY, DIFF

✅ Correct: Run all 6 phases: BUILD → TYPE → LINT → TEST → SECURITY → DIFF

Mistake 4: Large Plans (>3 tasks)

❌ Wrong: "Plan has 10 tasks covering 5 features" → Context overflow, confusion

✅ Correct: "Plan has 2-3 tasks for one feature" → Clear scope, focused execution

Validation Checklist

Before claiming feature completion:

Plan Quality:

• • Plan has 2-3 tasks max
• • Tasks are atomic and independently verifiable
• • Each task has verification criteria

TDD Discipline:

• • RED phase: Failing test written first
• • GREEN phase: Minimal code to pass
• • REFACTOR phase: Cleanup without changing behavior
• • Coverage target: 80%+ achieved

Quality Gates:

• • BUILD: Compilation succeeds
• • TYPE: TypeScript compiles without errors
• • LINT: ESLint reports no issues
• • TEST: All tests pass
• • SECURITY: No vulnerabilities
• • DIFF: Changes are intentional

Best Practices Summary

✅ DO:

• •Write failing tests before production code (RED)
• •Implement minimal code to pass tests (GREEN)
• •Refactor after tests pass
• •Keep plans to 2-3 tasks
• •Run all 6 quality gates
• •Aim for 80%+ test coverage
• •Verify evidence before claiming completion

❌ DON'T:

• •Write production code before tests
• •Add features in GREEN phase
• •Skip quality gates
• •Create plans with >3 tasks
• •Skip TypeScript compilation check
• •Trust "build succeeded" for type safety
• •Push code without running gates

This component carries essential Seed System principles for context fork isolation:

<critical_constraint> System Physics:

1. •Zero external dependencies (portability invariant)
2. •80-95% autonomy target
3. •What-When-Not-Includes format
4. •Progressive disclosure structure </critical_constraint>

Delta Standard: Good Component = Expert Knowledge − What Claude Already Knows

Recognition Questions

Validation Checklist

Before claiming engineering lifecycle complete:

• • TDD phases followed (RED → GREEN → REFACTOR)
• • Execution routing applied
• • Verification strategy executed
• • Quality gates passed

<critical_constraint>