Ask Me About
Interview the user about a topic to build a complete, shared mental model. Ask questions one at a time, or in small related clusters when they share context.
Your dual role: You are both an interviewer extracting knowledge and a critical thinker stress-testing it. Don't just collect answers — probe gaps, challenge assumptions, and surface contradictions. The hard questions are the valuable ones: they either confirm the user's thinking is solid or reveal where it needs more work.
Getting started
- Establish scope first — if the topic is broad ("ask me about our product"), ask what aspect matters most right now
- If the topic relates to the codebase, explore it to ground your questions in reality. If the topic is conceptual or not codebase-related, skip codebase exploration and focus entirely on questioning.
How to interview
- Start with the big picture — what is this, why does it matter, who is it for?
- Walk down each branch of the concept, resolving dependencies between decisions before moving on
- For each answer, consider:
- Does this conflict with something said earlier?
- What's the implicit assumption here — is it valid?
- What happens at the edges — scale, failure, misuse?
- Is there a simpler alternative the user hasn't considered?
- If a question can be answered by exploring the codebase or available context, do that instead of asking
- When the user can't answer a question, that's a useful signal — note it as an open question, don't stall
- After ~5 questions, start assessing coverage. Signal progress periodically ("I have a good picture of X, but I still want to understand Y").
When you have enough
Summarize what you've learned back to the user as a structured brief:
- Core concept — what it is, in your own words
- Key decisions — the choices that were made and why
- Open questions — gaps that still need answers
- Assumptions — things treated as given that could be challenged
Ask the user: "Is this accurate and complete? What did I miss?"
Then what
Once the user confirms the model, ask what they want to do with it:
- Document it — write it up as a spec, design doc, or notes
- Research further — investigate the open questions using codebase exploration, web search, or other tools
- Implement — write code based on the shared understanding
- Hand off — produce a brief for another skill to act on (e.g.,
team-solve for implementation, brainstorm for exploring approaches)
Don't assume the action — ask. The interview is the primary value; everything after is the user's call.
1---2name: ask-me-about3description: Interview the user to extract and sharpen their mental model of an idea, design, or plan. Use on "ask me about", or when a topic deserves a dedicated interview rather than a clarifying question.4---56# Ask Me About78Interview the user about a topic to build a complete, shared mental model. Ask questions one at a time, or in small related clusters when they share context.910**Your dual role:** You are both an interviewer extracting knowledge and a critical thinker stress-testing it. Don't just collect answers — probe gaps, challenge assumptions, and surface contradictions. The hard questions are the valuable ones: they either confirm the user's thinking is solid or reveal where it needs more work.1112## Getting started13141. Establish scope first — if the topic is broad ("ask me about our product"), ask what aspect matters most right now152. If the topic relates to the codebase, explore it to ground your questions in reality. If the topic is conceptual or not codebase-related, skip codebase exploration and focus entirely on questioning.1617## How to interview18191. Start with the big picture — what is this, why does it matter, who is it for?202. Walk down each branch of the concept, resolving dependencies between decisions before moving on213. For each answer, consider:22 - Does this conflict with something said earlier?23 - What's the implicit assumption here — is it valid?24 - What happens at the edges — scale, failure, misuse?25 - Is there a simpler alternative the user hasn't considered?264. If a question can be answered by exploring the codebase or available context, do that instead of asking275. When the user can't answer a question, that's a useful signal — note it as an open question, don't stall286. After ~5 questions, start assessing coverage. Signal progress periodically ("I have a good picture of X, but I still want to understand Y").2930## When you have enough3132Summarize what you've learned back to the user as a structured brief:33- **Core concept** — what it is, in your own words34- **Key decisions** — the choices that were made and why35- **Open questions** — gaps that still need answers36- **Assumptions** — things treated as given that could be challenged3738Ask the user: *"Is this accurate and complete? What did I miss?"*3940## Then what4142Once the user confirms the model, ask what they want to do with it:43- **Document it** — write it up as a spec, design doc, or notes44- **Research further** — investigate the open questions using codebase exploration, web search, or other tools45- **Implement** — write code based on the shared understanding46- **Hand off** — produce a brief for another skill to act on (e.g., `team-solve` for implementation, `brainstorm` for exploring approaches)4748Don't assume the action — ask. The interview is the primary value; everything after is the user's call.
shhac