Analyze

Analyze — Read-Only Deep Analysis

Use this skill to answer the user’s question through read-only repository analysis. The goal is to explain what the codebase most likely says about the question, not to drift into implementation, debugging theater, or generic fix planning.

Use $analyze when

• the user wants a grounded explanation, not code changes
• the answer requires reading multiple files or tracing behavior across boundaries
• there are several plausible explanations and they need to be ranked
• confidence should reflect the strength of the available evidence
• the user wants to understand architecture, behavior, causality, impact, or tradeoffs before changing anything

Examples:

• why a workflow behaves a certain way
• how a feature is wired across modules
• what likely explains a failure, regression, or mismatch
• what would be impacted by changing a dependency or contract
• which interpretation of the current codebase is best supported

Do not use $analyze when

• the user explicitly wants code edits, a fix, or execution — use the appropriate implementation lane instead
• the user wants a new product plan or acceptance criteria — use $plan / $ralplan
• the request is a simple one-file fact lookup — read the file and answer directly
• the request is purely about running the OMX tmux team runtime — use $team only when OMX runtime is active

Non-negotiable contract

Analyze is read-only by contract.

• Do not edit files.
• Do not turn the answer into an implementation plan.
• Do not recommend fixes as the primary output.
• Do not silently switch into execution work.
• Do not overclaim certainty.
• Do not invent facts that are not supported by repository evidence.
• Do not use judgmental, normative, or speculative language that outruns the evidence.

If a next step is helpful, keep it to a discriminating read-only probe that would reduce uncertainty.

Question-aligned synthesis

Answer the user’s actual question first.

• Start from the asked question, not a generic debugger template.
• Keep the synthesis scoped to what the user needs to know.
• Scale the depth to the request: for simple or obvious questions, reduce swarm intensity and answer directly after enough reading.
• For broader questions, expand the search surface but keep the final answer tightly synthesized.

Evidence rules

Maintain an explicit evidence-vs-inference distinction. Every material claim must be labeled as one of:

1. Evidence — directly supported by concrete repository artifacts
2. Inference — a reasoned conclusion drawn from evidence
3. Unknown — a question the current repository evidence does not resolve

Never present an inference as if it were direct evidence. Never present a guess as if it were an inference. Call out uncertainty explicitly when the codebase does not settle the question.

Acceptable evidence

Prefer stronger evidence over weaker evidence:

1. direct code paths, contracts, tests, generated artifacts, configs, or docs with concrete file references
2. multiple independent files pointing to the same conclusion
3. localized behavioral inference from well-supported code structure
4. weaker contextual clues that remain explicitly marked as tentative

Unsupported speculation is not evidence.