# Bite-Sized Implementation Planning

> The "Plan" phase: breaking approved designs into 2-5 minute tasks, each with explicit file paths, code changes, and verification steps to ensure predictable progress.

- Repository: obra/superpowers
- GitHub: https://github.com/obra/superpowers
- Human wiki: https://grok-wiki.com/public/wiki/obra-superpowers-8ae12eb67e85
- Complete Markdown: https://grok-wiki.com/public/wiki/obra-superpowers-8ae12eb67e85/llms-full.txt

## Source Files

- `skills/writing-plans/SKILL.md`
- `skills/writing-plans/plan-document-reviewer-prompt.md`
- `skills/executing-plans/SKILL.md`

---

<details>
<summary>Relevant source files</summary>
The following files were used as context for generating this wiki page:
- [skills/writing-plans/SKILL.md](skills/writing-plans/SKILL.md)
- [skills/writing-plans/plan-document-reviewer-prompt.md](skills/writing-plans/plan-document-reviewer-prompt.md)
- [skills/executing-plans/SKILL.md](skills/executing-plans/SKILL.md)
- [skills/subagent-driven-development/SKILL.md](skills/subagent-driven-development/SKILL.md)
- [skills/verification-before-completion/SKILL.md](skills/verification-before-completion/SKILL.md)
</details>

# Bite-Sized Implementation Planning

Bite-Sized Implementation Planning is the process of decomposing approved technical designs into atomic, 2-5 minute tasks. This approach ensures that progress remains predictable, verifiable, and resilient to context drift. By shifting the focus from broad feature goals to specific, actionable steps, developers and AI agents can maintain high velocity while adhering to strict quality standards.

The core of this philosophy is that any task that cannot be completed and verified within a few minutes is too large and must be further decomposed. This "bite-sized" granularity allows for continuous integration, rapid feedback loops, and a clear audit trail of verification evidence for every single change.

## The Anatomy of a Bite-Sized Task

A well-defined task is not just a description of work; it is a self-contained unit of execution. Every task in an implementation plan must satisfy specific criteria to be considered "bite-sized" and ready for execution.

### Task Requirements
*   **Time-Boxed:** Each task should ideally take between 2 and 5 minutes to complete.
*   **Explicit Context:** Must name specific file paths and line ranges targeted for modification.
*   **Target Content:** Includes the exact character sequence or logic being replaced.
*   **Verification Steps:** Explicit commands (tests, builds, or linting) that prove the task was successful.

Sources: [skills/writing-plans/SKILL.md:45-60](), [skills/executing-plans/SKILL.md:17-48]()

## The Planning Workflow

The transition from a design specification to a bite-sized plan involves a rigorous extraction and review process. This phase ensures that the plan is not only logically sound but also technically grounded in the current state of the repository.

### Extraction and Review Cycle
1.  **Requirement Extraction:** Breaking the high-level spec into functional blocks.
2.  **Decomposition:** Splitting blocks into 2-5 minute tasks with explicit file citations.
3.  **QA Review:** A dedicated review phase to catch "hallucinated" file paths, missing verification steps, or overloaded task scopes.
4.  **Final Approval:** Ensuring the plan provides a clear, risk-mitigated path to the goal.

Sources: [skills/writing-plans/plan-document-reviewer-prompt.md:7-22](), [skills/writing-plans/plan-document-reviewer-prompt.md:84-118]()

### Task Execution Flow
```mermaid
sequenceDiagram
    participant Controller
    participant Implementer
    participant Reviewer
    
    Controller->>Implementer: Dispatch Task (Context + Spec)
    Note over Implementer: 2-5 Minute Implementation
    Implementer->>Implementer: TDD / Verification
    Implementer->>Controller: Self-Review & Completion Claim
    Controller->>Reviewer: Dispatch for QA (Spec Compliance)
    Reviewer->>Implementer: Request Fixes (if gaps found)
    Reviewer->>Controller: ✅ Approved
    Controller->>Controller: Mark Task Complete
```

## The Iron Law of Verification

A completion claim is considered a "hallucination" unless it is accompanied by fresh verification evidence. This is the "Iron Law" that governs the transition between bite-sized tasks.

### The Gate Function
Before claiming any status or moving to the next task, the agent must follow the Gate Function:
1.  **Identify:** Determine which command proves the claim (e.g., `npm test`).
2.  **Run:** Execute the full, fresh command.
3.  **Read:** Analyze the output for errors or exit codes.
4.  **Verify:** Confirm the output matches the expected result.
5.  **Claim:** Only then state that the task is complete.

Sources: [skills/verification-before-completion/SKILL.md:16-35](), [skills/subagent-driven-development/SKILL.md:36-41]()

## Quality Gates and Subagent Roles

In complex environments, Bite-Sized Implementation Planning is supported by specialized subagent roles that provide automated quality gates.

| Role | Responsibility | Key Output |
| :--- | :--- | :--- |
| **Implementer** | Executing the 2-5 minute task. | Diff + Verification Evidence |
| **Spec Reviewer** | Ensuring code matches the original plan/spec. | Compliance Report |
| **Code Quality Reviewer** | Checking for patterns, style, and regressions. | Approval / Fix Requests |

Sources: [skills/subagent-driven-development/SKILL.md:125-180](), [skills/subagent-driven-development/SKILL.md:36-41]()

Bite-sized planning transforms unpredictable "coding sessions" into a series of small, guaranteed wins. By enforcing 2-5 minute task boundaries and mandatory verification evidence, it eliminates the ambiguity that often leads to regressions and failed implementations.

Sources: [skills/verification-before-completion/SKILL.md:110-118]()