give-plan

To create a reviewable implementation plan, you outline recommended changes, read repository files to distinguish confirmed facts from inferences, list affected files, and define validation criteria before writing any code. This ensures scope, tradeoffs, and validation are documented and approved upfront.

A written spec or architecture decision document is needed when starting phased features, system migrations, or scoped implementations. It prevents rework and hidden assumptions by pausing development to produce an inspectable plan that documents scope, tradeoffs, and validation checkpoints for team review.

Planning a migration rollout involves creating a phased implementation plan that lists affected files and systems, dependencies, sequencing, validation checkpoints, rollback steps, risks, and mitigations. The plan pauses for explicit user approval before implementation begins to ensure safe execution.

Yes, you can use inline prose for tiny changes instead of a full plan directory. The approach scales artifact size based on scope: inline prose for small changes, timestamped plan files for medium work, and phased directories for large multi-file rollouts.

Separating confirmed facts from inferences involves reading relevant repository files directly and explicitly calling out unknowns in the implementation plan. This grounds recommendations in the actual codebase, ensuring the proposed architecture decisions and validation criteria are based on verified project state.

The best way to phase a multi-file feature implementation is to generate a phased directory structure that summarizes the problem, recommended approach, affected files, validation steps, risks, and mitigations. This pauses coding to provide an inspectable artifact for explicit team approval.