sakura-plan

name	sakura-plan
description	Build the smallest executable implementation plan from the confirmed specification, acceptance contract, project facts, and research conclusions. Use before coding to define milestones, affected scope, and validation; do not redefine the product goal or write implementation code.

Sakura Plan

Role

Convert confirmed goals and technical constraints into an incremental, verifiable, and recoverable engineering plan.

Use When

• Specification, acceptance, and required research are ready.
• The change affects multiple files, modules, or verification steps.
• A repair needs an explicit affected scope and regression strategy.
• Long-running work needs milestones and recovery points.

Do Not Use When

• Product behavior or acceptance remains materially ambiguous.
• Required technical facts have not been researched.
• The request is only review, explanation, or execution of existing checks.

Inputs

• docs/project/PRODUCT_SPEC.md and ACCEPTANCE.md.
• The current project structure, dependencies, verified scripts, and existing user changes.
• Confirmed constraints from the sakura-research handoff.
• Required parity levels, capability contracts, and mandatory gaps from sakura-replicate when replication applies.

Outputs

• An updated docs/project/EXECUTION_PLAN.md.
• The smallest working vertical slice and subsequent milestones.
• An allowed-change scope, dependency list, acceptance mapping, and validation method for every task.
• The first task package for sakura-code.

Workflow

1. Re-check the current project and existing user changes.
2. Map Must requirements to concrete modules and acceptance items.
3. Define the smallest working vertical slice first.
4. Split the remaining work into independently verifiable milestones.
5. Define allowed files or areas, risks, and validation commands for every step.
6. Define recovery without assuming authorization for a branch or commit.
7. For delegated writes, define the fixed Git baseline, dedicated worktree or branch, disjoint write scope, integration order, validation after integration, and safe cleanup condition. Use serial parent execution when any boundary is unavailable.
8. Remove unrelated refactoring, optional enhancements, and duplicate tooling.

For replication work, every milestone maps to capability IDs, capability target minimums, required L1-L4 evidence records, and the bound machine contract. Do not plan a static or surface substitute as complete when the contract requires protocol or runtime consistency.

Read plan-template.md for a full plan. Read planning-checklist.md before handing the plan to implementation.

Quality Gate

• Every task maps to a requirement, acceptance item, or failure record.
• The first task produces a runnable and verifiable result.
• Scope, dependencies, risks, and validation are explicit.
• The plan is grounded in current project and research facts.
• The plan contains no source notes, research narrative, development background, or unrelated metadata.
• Every delegated writer has an isolated workspace, exclusive files or modules, and a parent-owned integration path.
• Replication milestones preserve the required level and include conformance tests for every applicable lower level.

Failure and Fallback

• Return to sakura-spec when a product-behavior gap changes the result.
• Return to sakura-research when a required technical fact is missing.
• Keep unverified commands explicit when the environment cannot establish them.
• Reduce an oversized plan to the first deliverable vertical slice.

Upstream and Downstream

• Upstream: sakura-spec and sakura-research, plus sakura-replicate when replication applies.
• Downstream: sakura-code, or this skill again when execution evidence invalidates the plan.

Handoff

Include the active milestone, allowed-change scope, acceptance items, verification commands, risks, prohibited actions, and the skill to load after implementation.