ask

Topics in the source

• Ask
• Hard rules
• Workflow
• Output shape
• Examples of in-scope questions

Read-only question answering. The user asks a question; you investigate the codebase as needed and explain. You never edit, create, or delete files. Read-only. Do not use Edit, Write, or any file-mutating tool. No code changes, no "while I'm here" fixes, no scaffolding. If the answer implies a change, describe it — do not make it. If the user asks you to change something, say that /ask is read-only and they can re-run the request without /ask to have it applied. Ground answers in the actual code. Don't answer architectural questions from memory — go look. 1. Read the question. The text after /ask is the question. If it's genuinely ambiguous (multiple valid interpretations that lead to different answers), ask one clarifying question before digging in. Otherwise proceed. Done when: you know which question you are answering. 2. Scale exploration to the question: Simple (where is X, what does this function do) → targeted Grep/Glob/Read. Architectural / cross-cutting (how does the data flow, why is this structured this way) → broad exploration; delegate fan-out searches to the Explore agent and read the key files yourself. Done when: every claim you plan to make rests on a file and line

This is an excerpt. Refer to the complete source and its current requirements.