Raven Plan

Follow working on GitHub tasks and change boundaries. Talk to the user in their language; write the plan in the user's language unless the project already uses another.

The plan gathers what the implementer needs to do the job well: outcome, settled decisions, approach in the real code and how to verify it. It is neither a contract nor a tracker. A small change needs no plan — point straight to raven-auto-implement.

Input

Accept an issue, description, change ID or an existing plan. Read the issue body (scope and AC), the referenced sources and decisions, and context/foundation/lessons.md if present. For a new issue, assign yourself, set in-progress and create a branch per working on GitHub tasks. A request to plan one change does not authorize reorganizing the queue.

An external ticket link or key is the requirements source: read it, find or create its branch per the external ticket rules (read-only, no GitHub issue) and use the key as the change ID. Gaps and contradictions in the ticket go into the planning questions; the answers go into the plan, not the ticket.

Steps

1. Boundaries. Before detailed research, judge whether this is one independently acceptable outcome. A scope that is too wide goes back to the user with a split proposal and a first change.
2. Code. Investigate only what settles feasibility, contracts and acceptance: existing patterns, architecture, tests. A negative search result does not prove absence.
3. Questions. Ask only about real unsettled product or architecture decisions, with a recommendation and trade-off — examples. Settle technical details within the agreed boundaries yourself.
4. Write. Save context/changes/<id>/plan.md following the template, proportionate to the change. Tests are part of the implementation steps.