Plan

Workflow: Plan

Create an implementation plan for a ticket before coding begins.

When to Use

• Ticket is in todo and has no plan yet
• Non-trivial work that needs scoping before implementation
• Skip for bug fixes with obvious root cause or single-file changes

Inputs

• Issue identifier, title, and description
• Any linked PRD or design doc
• The target repo’s codebase

Steps

1. Read the ticket — understand what’s being asked, acceptance criteria, and delivery layers
2. Read existing context — check for PRDs at .ai/projects/cascadeguard/prds/, designs at designs/, and ADRs at adr/ (all relative to workspace root)
3. Explore the codebase — read relevant source files in the repo to understand current state
4. Identify approach — determine the minimal set of changes needed
5. Write the plan — create a markdown file at .ai/projects/cascadeguard/plans/<identifier>-<slug>.md containing:
   • Summary: One paragraph on what and why
   • Approach: Numbered steps with file paths
   • Layers: Which delivery layers are touched (backend, frontend, api, infra, docs)
   • Risks: Anything that could go wrong
   • Open questions: Anything that needs clarification before building
6. Commit the plan

Quality Checks

• Plan is concise (one page max — if longer, requirements belong in a PRD)
• Plan lives in the filesystem (.ai/projects/cascadeguard/plans/), not in the issue body
• All affected delivery layers are identified
• No implementation detail that belongs in code

References

• See “Artefact Storage”, “When a Ticket Goes Into Backlog”, and “When a Ticket Is Ready to Build” in .ai/projects/cascadeguard/sdlc.md