Analyze

Investigate a task, idea, ticket, PR, or review-fix backlog and return an evidence-backed memo in chat. Never write to Linear or GitHub.

Read when

• Investigating a touched user flow, visible action, or UX complaint? Open user-experience.md and inspect the current entry point, context, continuation, and existing design before recommending controls. Backend-only work skips this.
• About to research, even when the ask looks like a single file? Open code-quality.md, code-structure.md, doctrine.md, and the execution context. Skip them and the memo recommends a fix the rules reject.
• About to search widely or read large files? Open main-context.md. Skip it and raw search output buries the analysis.
• About to ask the user anything? Open Asking the user. Skip it and you ask what the repo already answers.
• About to post the memo? Open Plain language. Skip it and the memo reads like pack jargon.

Contract

• Rediscover repository, ticket, PR, and diff facts from their live sources.
• Keep user decisions, rules, areas, and promotion state (whether the user approved turning this analysis into a build or ticket, see Apply) visible in the execution context, and take them from the user, not from code.
• Return the analysis memo in chat only, and keep state in the execution context.
• Save a memo only when the user explicitly requests it and approves the destination.

Mechanics or rationale only

If the user only wants how something works (a walkthrough, who owns a layer, how layers fit), stop and follow /how. If they only want why it is this way, stop and follow /why. A bug, an idea, impact, or a build seed stays here.

Process

1. Establish or refresh the relevant execution context and normalize the ask. When a parent already locked Done when and rules that must stay true, reuse them without re-grilling product intent.
2. Investigate the affected flow with the doctrine's research rules. Separate facts, settled decisions, ordinary implementer choices, and unresolved tradeoffs before recommending a design.
   • Meaningful feature or boundary change, or observed architecture friction: apply public boundary investigation. Small changes that keep the contract skip it.
   • An independently uncertain boundary: use a bounded scout.
   • Existing mechanics or history could change the analysis: use /how or /why for that bounded question and carry its conclusions, sources, and uncertainty into the memo. Neither chooses the new design or starts another interview.
   • Under a parent: return facts, conclusions, source pointers, and uncertainty under nested capabilities, with no standard memo.
3. Standalone, post the doctrine memo. Lead with a Mermaid diagram. Include an inline execution seed when the work is buildable.

Review remediation

Use this mode only when the active orchestrator requests analysis of named Fix-now rows under remediation. Return root cause, smallest fix, touch surface, uncertainty, and verification keyed to each stable finding ID. Add no findings, product discovery, or follow-ups. The orchestrator adjudicates and dispatches once; analysis does not promote or launch an implementation lifecycle.

If a parent already owns the next step

Follow nested capabilities. Return bounded evidence and recommendations. The parent owns preparation, promotion, and any next step, including when it already has implementation authorization.

If this is a user one-off

Ask only hard, ambiguous unknowns, then end with the final report. Its Next line offers the hand-off that fits; promote only on the user's reply. Work without a parent brief.

Anti-patterns

• Returning a raw search hit list instead of the memo
• Answering a pure how or why question with this memo
• Creating tickets, implementing code, or writing tests