Analyze — Read-Only Deep Analysis
Use $analyze to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.
Shared operating, delegation, state, hook, team, cancellation, and verification invariants live in templates/AGENTS.md. Follow that source instead of duplicating its rules here.
Use when
- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.
- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.
- The user needs confidence and concrete evidence before changing anything.
Do not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.
Inputs and method
- Restate the question and define the evidence-backed scope.
- Identify the smallest files, tests, configs, and docs likely to answer it.
- Read direct code paths and contracts first; trace boundaries only as far as needed.
- Compare competing explanations, rank them by support, and mark unresolved points.
- Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.
Evidence discipline
Label every material claim as one of:
- Evidence — directly shown by code, tests, generated artifacts, configuration, or docs.
- Inference — a reasoned conclusion drawn from cited evidence.
- Unknown — not settled by the repository evidence.
Prefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.
Output contract
Answer the asked question first and use this shape:
Question
Restated question, briefly.
Ranked synthesis
| Rank |
Explanation |
Confidence |
Basis |
| 1 |
... |
High / Medium / Low |
strongest supporting evidence |
| 2 |
... |
High / Medium / Low |
why it trails |
| 3 |
... |
High / Medium / Low |
why it remains possible |
Evidence
path/to/file:line-line — direct observation.path/to/file:line-line — corroborating observation.
Inference
- What the evidence most strongly implies.
- Why weaker alternatives were down-ranked.
Unknowns / limits
- What the repository does not establish.
- The next discriminating read-only probe, when useful.
Stop conditions
- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.
- Do not continue searching after the answer and confidence boundary are grounded.
- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.
Task: {{ARGUMENTS}}
1---2name: analyze3description: Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.4---56# Analyze — Read-Only Deep Analysis78Use `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.910Shared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.1112## Use when1314- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.15- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.16- The user needs confidence and concrete evidence before changing anything.1718Do not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.1920## Inputs and method21221. Restate the question and define the evidence-backed scope.232. Identify the smallest files, tests, configs, and docs likely to answer it.243. Read direct code paths and contracts first; trace boundaries only as far as needed.254. Compare competing explanations, rank them by support, and mark unresolved points.265. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.2728## Evidence discipline2930Label every material claim as one of:3132- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.33- **Inference** — a reasoned conclusion drawn from cited evidence.34- **Unknown** — not settled by the repository evidence.3536Prefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.3738## Output contract3940Answer the asked question first and use this shape:4142### Question43Restated question, briefly.4445### Ranked synthesis46| Rank | Explanation | Confidence | Basis |47|------|-------------|------------|-------|48| 1 | ... | High / Medium / Low | strongest supporting evidence |49| 2 | ... | High / Medium / Low | why it trails |50| 3 | ... | High / Medium / Low | why it remains possible |5152### Evidence53- `path/to/file:line-line` — direct observation.54- `path/to/file:line-line` — corroborating observation.5556### Inference57- What the evidence most strongly implies.58- Why weaker alternatives were down-ranked.5960### Unknowns / limits61- What the repository does not establish.62- The next discriminating read-only probe, when useful.6364## Stop conditions6566- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.67- Do not continue searching after the answer and confidence boundary are grounded.68- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.6970Task: {{ARGUMENTS}}
Yeachan-Heo