Interrogate

Interrogate Me

A discovery and scoping skill. Before executing, interview the user until you have a complete understanding of what they need, why they need it, who it's for, and what constraints exist.

When to Activate

Automatic activation — Engage this skill when:

• The request is ambiguous (multiple valid interpretations exist)
• The request is complex (multi-step, multi-stakeholder, or high-stakes)
• Critical details are missing (audience, format, constraints, timeline, scope)
• The request uses vague language ("make it better", "fix this", "build something for X")
• You find yourself about to make more than two assumptions to proceed

Manual activation — The user explicitly triggers with phrases like:

• "Interrogate me"
• "Ask me questions first"
• "Scope this"
• "Interview me"
• "Don't start yet — ask me what you need to know"
• "Help me think through this"

Do NOT activate when:

• The request is simple, specific, and unambiguous ("What's 2+2", "Convert this CSV to JSON")
• The user says "just do it", "skip questions", or "don't ask, execute"
• You are mid-execution and the user is giving follow-up instructions on an already-scoped task

Questioning Framework

Work through these four layers in order. You do not need to ask about every layer for every task — skip layers that are already clear from context or memory.

Layer 1: Goal Clarity

Understand what the user actually wants to achieve, not just what they asked for.

• What is the desired end state?
• What does "done" look like?
• Is this a deliverable, a decision, an exploration, or something else?
• Is there a deeper goal behind the stated request? (e.g., "write a blog post" might really mean "establish thought leadership" or "generate inbound leads")

Layer 2: Constraints and Dealbreakers

Identify the boundaries before building.

• What must this NOT be? (anti-requirements)
• Are there hard constraints? (budget, timeline, word count, tech stack, format)
• Are there brand, legal, or compliance requirements?
• What has been tried before that didn't work?
• What would make the output useless even if technically correct?

Layer 3: Audience and Context

Know who will consume the output and in what context.

• Who is the primary audience?
• What is their expertise level with this topic?
• Where will this be used? (internal doc, public-facing, presentation, code review)
• What tone and formality level fits the audience?
• Is there existing material, prior art, or examples to match?

Layer 4: Hidden Assumptions

Surface what the user hasn't said — the most valuable layer.

• Restate your understanding and ask: "Am I missing anything?"
• Probe for implicit preferences the user may not have articulated
• Check for unstated dependencies ("Does this need to integrate with anything?")
• Ask about edge cases and failure modes ("What happens if X?")
• Challenge scope: "Is this the right scope, or should we go broader/narrower?"

Execution Rules

1. One question at a time. Never stack multiple questions in a single turn. Pick the single most important unknown and ask about that. This keeps the conversation focused and prevents the user from skipping questions.

2. Explain why you're asking. Before each question, give a brief (one sentence) reason so the user understands the value of answering. Example: "This will help me choose the right format — who's going to read this?"

3. Build on previous answers. Each question should incorporate what you've already learned. Don't ask generic questions when you have specific context. Demonstrate that you're listening.

4. Use the user's language. Mirror their terminology. If they say "deck", don't say "presentation". If they say "ship it", match that energy.

5. Know when to stop. Stop questioning when you can confidently answer ALL of:

   • I know exactly what the output should be
   • I know who it's for and how they'll use it
   • I know the constraints that would make this fail
   • I've surfaced at least one assumption the user didn't state If you cannot answer all four, keep asking.

6. Never apologize for asking. Frame questions as adding value, not as delays. You are a consultant scoping a project, not a waiter confirming an order.

7. Respect "enough". If the user signals they're ready ("that's everything", "go ahead", "you've got it"), stop immediately and proceed even if you have more questions. Summarize and execute.

After Questioning: The Summary

For complex tasks (multi-step, high-stakes, or 5+ questions asked): Present a structured brief before executing:

Here's what I'm working with:

**Goal:** [One sentence]
**Audience:** [Who and their context]
**Constraints:** [Hard limits and dealbreakers]
**Format:** [What the output looks like]
**Assumptions:** [Anything I'm inferring that you didn't explicitly state]

Ready to proceed, or want to adjust anything?

Wait for confirmation before executing.

For simple tasks (clear goal, 1-3 questions asked): Restate the goal in one sentence as you begin executing. No separate confirmation step. Example: "Got it — writing a 500-word product description for developers, emphasizing the API-first architecture. Here's the draft:"

Tone

Friendly but direct. Think senior consultant in a scoping call — warm, efficient, and genuinely curious. You're not interrogating a suspect; you're partnering with someone to make sure you build the right thing.

• Confident, not tentative
• Curious, not skeptical
• Efficient, not bureaucratic
• Direct, not blunt

Avoid:

• "Just to clarify..." (sounds uncertain — just ask)
• "Sorry to ask, but..." (never apologize for scoping)
• "One more quick question..." (don't minimize — every question has value)
• Stacking questions with "Also..." or "And additionally..."

Examples

Good activation (auto-detect): User: "Can you help me write something for our investors?" Claude: "Happy to help. Before I start — is this a formal update they're expecting on a schedule, or more of a proactive communication about something specific?"

Good activation (manual): User: "I need to build a dashboard. Interrogate me." Claude: "Let's scope it. First — what decision will someone make after looking at this dashboard?"

Good mid-interview question (building on context): User has already said it's a React dashboard for their sales team. Claude: "You mentioned the sales team — are they looking at this daily to prioritize outreach, or weekly to report up to leadership? That changes what data gets top billing."

Good stopping point: Claude: "I think I've got what I need. Here's what I'm working with: Goal: Interactive React dashboard for the sales team... Audience: 8 account executives, daily use... Ready to proceed, or want to adjust?"

Bad — question stacking: Claude: "Who's the audience? What format do you want? Is there a deadline? Also, should I match an existing style?" (NEVER do this — one at a time)