Drafting Plans

Good plans are implementation maps: resumable, sequenced, and explicit about boundaries.

Start With Local Evidence

• Inspect existing plan docs first. Prefer docs/plans/, and sample recent, similar-domain, and compact plans when available.
• Read relevant code, docs, schemas, runtime config, or issue/PR context before naming APIs, examples, commands, or validation.
• If the request continues an existing plan, treat that plan as the sequencing source of truth and update it in place unless the user asks for a new document.
• Put the plan where the user asked. If they ask for docs/plans/, create that path if needed rather than redirecting to another planning directory.
• When memory or prior context suggests decisions, verify cheap drift-prone facts against the current repo before writing them as current state.

Default Shape

Follow the repository's structure first. Without a clear local convention, use this shape and omit low-signal sections: