Phase 1 — Analyze

Start every task here, no matter how it arrived: issue link, PR number, verbal idea, bug report — with two exceptions that use a sharper deliverable instead: a bare "look at/triage issue #n" with no implementation asked for goes to issue-triage.md, and "handle the review comments on PR #n" goes to pr-review-comments.md. If the request already asks for a fix ("fix issue #n", "issue #n: users can't log in"), analysis and an implicit go are both present — use this file directly, not issue-triage.md. No code gets written or edited during this phase.

Gather the full context

• Issues and PRs: gh issue view <n> --comments / gh pr view <n> --comments, plus linked issues, referenced discussions, and any code the report points at.
• Ideas and verbal requests: restate the goal and constraints in your own words. If the request is ambiguous, resolve the ambiguity now — not halfway through implementation.
• Check for prior art: existing helpers, similar segments/modules, and past commits that touched the same area (git log -- <path>).

Reproduce before theorizing

Reproduce the problem when possible. A reproduction turns the analysis from a hypothesis into a fact and gives Phase 5 its verification case for free. When reproduction is impossible (platform, hardware, credentials), say so explicitly in the report and mark the fix as unverified-by-repro.

Find the root cause in the code

• Read the actual implementation. Never reason from the issue text, a review comment, or a stack trace alone — reports and bot reviewers are frequently wrong.
• Distinguish the root cause from the symptom. Fixing where it crashes is not the same as fixing why it crashes.
• State what the change should be, which files it touches, and what it deliberately leaves alone.

When to escalate

If root cause can't be pinned with confidence, or the fix looks architectural, security-sensitive, or irreversible, hand the specific question to the strongest available model instead of guessing — see escalate.md. Resume ownership of the phase once the question is answered.

Output of this phase

A short analysis report to the user containing:

1. What is actually happening and why (root cause, with file references).
2. The proposed change and its scope.
3. What is intentionally out of scope.
4. Open questions, if any remain.

This is the root_cause / proposed_change / out_of_scope / repro_status / open_questions artifact defined in artifacts.md — Plan reads it in that shape regardless of which entry point produced it.

Stop gate

Report the analysis and wait for a go before implementing. This applies every time this phase is entered — including a return trip from Verify (see verify.md) — not only the first time. Skip the gate only when the user already gave the go in the request itself ("do it", "fix it and commit", "implement with Sonnet"). A go given for analysis is not a go for implementation, and a go given for the first pass does not carry forward to a re-diagnosis after a Verify failure.