---
name: grill-me
description: Pre-task alignment protocol. Ask sharp clarifying questions before starting any complex task — coding, writing, research, or planning. Use when Bo says "grill me", "let's align", "before you start ask me", or when a task is ambiguous enough that misalignment would waste significant work. Also use proactively before large coding tasks or any task where the wrong interpretation means starting over.
---

# /grill-me — Pre-Task Alignment

Before writing a line of code or prose, stop and interrogate the request. The goal: surface assumptions, constraints, and preferences that Bo hasn't stated but definitely has.

## When to trigger

- Bo says "grill me" or "grill me first" explicitly
- Task is large enough that misalignment = significant rework (>30 min of work)
- The request has ambiguous scope ("make it better", "build a dashboard", "write a post about X")
- You're about to make architectural choices that are hard to reverse
- Conflicting interpretations are plausible

## How to grill

Ask **5–8 pointed questions**. Not yes/no. Not open-ended fluff. Questions that reveal constraint and preference:

### For coding tasks
- What's the entry point / how will this be used? (CLI? API? UI component?)
- What already exists that this needs to integrate with?
- What's the output format / schema?
- Any tech constraints? (language, framework, file size, browser-only, no deps)
- What does "done" look like — is there a test case or example output?
- What's the most likely thing I'll get wrong if I just start?

### For writing tasks (X post, article, email)
- What's the audience? (technical peers, general public, specific person?)
- What's the one thing you want them to walk away believing?
- Tone? (sharp/skeptical, authoritative, casual, provocative)
- Any angle or framing you already have in mind?
- Length / format constraints?
- What would make this version bad?

### For research / analysis tasks
- What's the actual decision this informs? (not just "I'm curious")
- What do you already know or suspect?
- What format is useful — bullet summary, deep dive, comparison table?
- Any sources to prioritize or avoid?

### For planning tasks
- What's the constraint that matters most? (time, cost, reversibility)
- Who else is involved / needs to sign off?
- What does failure look like?

## After grilling

Once Bo answers:
1. Restate your understanding in 2–3 sentences ("So you want X, with Y constraint, and the success condition is Z")
2. Flag any remaining ambiguities or tradeoffs
3. Then start

## What not to do

- Don't ask obvious questions answerable from context
- Don't ask more than 8 questions — pick the highest-leverage ones
- Don't list questions as a wall of text — number them cleanly
- Don't grill for simple, low-stakes requests
- Don't ask about things already answered in CONTEXT.md or MEMORY.md

## Example

**Bad:** "Can you tell me more about what you want?"

**Good:**
> Before I start — a few things I need to nail down:
>
> 1. Is this going into the wiki or a standalone file?
> 2. Who's the reader — you reviewing it later, or passing it to someone else?
> 3. Do you want the technical depth of the original paper, or a distilled take?
> 4. Any existing structure I should match?
> 5. What would make this version a waste of time?