sakura-plan

Start from an accepted outcome and current project facts, then decompose the work into items each having an identity, concrete result, owning area, prerequisites, and acceptance reference. Order items by dependencies and user value, then select one ready item to implement first.

Plan when work spans multiple meaningful changes, dependencies, integration points, or recovery checkpoints. Do not use planning merely to restate a simple edit; independent small modifications should stay short and direct.

Identify the applicable frontend, contract, backend, database, integration, and end-to-end work for the feature. Define the owning module, entrypoint, dependency direction, public contract, and data owner before implementation, and only explain omissions when they could change the accepted result.

Yes. When revising, preserve completed items and failed approaches, and update the same accepted workstream for added requests unless they change the milestone. Correct any plan assumptions that conflict with repository or runtime evidence.

A plan should only cover enough to make the next result executable, verifiable, and recoverable; expanding it beyond that adds no value. It also must not include unauthorized commits, pushes, deployments, credential use, or other external mutations.