AB Method Workflow

Description

The AB Method is a specification-first workflow optimized for Claude Code's subagent capabilities. Instead of tackling a large feature sequentially, you write a detailed spec, decompose it into independent missions, and dispatch subagents to execute them in parallel. This dramatically reduces implementation time for multi-file features.

Instructions

Follow the A-B sequence strictly: A (Specification) defines WHAT, B (Missions) defines HOW and executes.

Workflow

Phase A: Specification

Create a detailed specification document before any code is written.

Spec Template:

Copy
# Feature: [Name]

## Goal
One sentence describing the desired outcome.

## Requirements
- [ ] Functional requirement 1
- [ ] Functional requirement 2
- [ ] Non-functional: performance, security, etc.

## Interfaces
- Input: What data/events trigger this feature
- Output: What the feature produces
- Dependencies: What existing code it interacts with

## Constraints
- Must use existing [patterns/libraries]
- Must not break [existing functionality]
- Performance budget: [metrics]

## Acceptance Criteria
- [ ] Criterion 1 (testable)
- [ ] Criterion 2 (testable)

Phase B: Mission Decomposition & Execution

Break the spec into independent, parallelizable missions.

Mission Rules:

1. Each mission modifies a non-overlapping set of files
2. Each mission has a single, clear objective
3. Each mission can be tested independently
4. Missions are ordered by dependency (independent first)

Mission Template:

Copy
## Mission B1: [Name]
- **Objective**: [One sentence]
- **Files**: [List of files to create/modify]
- **Dependencies**: [Other missions this depends on, or "none"]
- **Tests**: [How to verify this mission succeeded]
- **Estimated changes**: [Small/Medium/Large]

Execution Strategy

Spec (A)
  |
  +-- Mission B1 (independent) -----> Subagent 1
  +-- Mission B2 (independent) -----> Subagent 2
  +-- Mission B3 (depends on B1) ---> Subagent 3 (waits)
  +-- Mission B4 (independent) -----> Subagent 4
  |
  v
Integration: Verify all missions work together
Acceptance: Run criteria from spec

Rules

1. Never skip the spec - vague specs produce wrong code
2. No overlapping files between parallel missions
3. User approves spec before mission decomposition begins
4. User approves missions before execution begins
5. Integration testing after all missions complete
6. Max 6 parallel missions to maintain quality
7. Each mission must be atomic - it either fully succeeds or fully reverts

Examples

Feature: User Notification System

Phase A (Spec):

• Send email/push/in-app notifications
• User preferences control which channels
• Rate limiting to prevent spam

Phase B (Missions):

B1: Create notification data model and types     [models/notification.ts]
B2: Build notification service with queue         [services/notification.ts]
B3: Add user preference API endpoints             [routes/preferences.ts]
B4: Create email sender integration               [integrations/email.ts]
B5: Add push notification integration             [integrations/push.ts]
B6: Write notification component UI               [components/Notification.tsx]

B1 runs first (others depend on types). B3, B4, B5, B6 run in parallel. B2 integrates all channels.