grill-me
- Repo stars 0
- Author updated Live
- Author repo claude-code-expert
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @reedmayhew18 · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Docker
- Runtime requirements
- Docker
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: grill-me
description: Deep interview to reach shared understanding before building. Use when starting a complex featur…
category: engineering
runtime: Docker
---
# grill-me output preview
## PART A: Task fit
- Use case: Deep interview to reach shared understanding before building. Use when starting a complex feature, when requirements are unclear, or when the user says "grill me", "interview me", "ask me questions", "let's figure this out", or "grill me lightly" for a quick version..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Goal / Dependencies / Context” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Deep interview to reach shared understanding before building. Use when starting a complex feature, when requirements are unclear, or when the user says "grill me", "interview me", "ask me questions", "let's figure this out", or "grill me lightly" for a quick version.”.
- **02** When the source has headings, the agent prioritizes “Goal / Dependencies / Context” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source mentions slash commands such as `/grill-me`, `/wizard`, `/plan-and-spec`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Goal / Dependencies / Context”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: grill-me
description: Deep interview to reach shared understanding before building. Use when starting a complex featur…
category: engineering
source: reedmayhew18/claude-code-expert
---
# grill-me
## When to use
- Deep interview to reach shared understanding before building. Use when starting a complex feature, when requirements a…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Goal / Dependencies / Context” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "grill-me" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Goal / Dependencies / Context
rules -> SKILL.md triggers / order / output contract
runtime -> Docker | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Grill Me - Design Tree Exploration
Goal
Reach a shared, unambiguous understanding of what the user wants to build before any implementation begins. Success = a concrete implementation plan the user has approved, with all blocking decisions resolved.
Dependencies
- Tools: Read, Grep, Glob (read-only — this skill gathers information, never modifies files)
- No external services or MCP servers required
Context
This skill reads the existing project (CLAUDE.md, README, config files) to pre-fill known answers before asking any questions. The less the user has to repeat themselves, the better. Reference reference/02-best-practices.md if uncertain about Claude Code patterns.
Interview the user about their plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.
Modes
Full Mode (default): /grill-me [topic]
Relentless, thorough interview. Explores every branch of the design tree until zero ambiguity remains. Use for complex features, architecture decisions, or anything where getting it wrong is expensive.
Light Mode: /grill-me lightly [topic]
Quick, focused interview — 5-8 questions max. Gets the essential decisions made without deep-diving every branch. Use for quick setups, small features, or when the user just needs to fill in a few gaps. Skip edge cases and failure modes unless they're critical. Aim for "good enough to start" not "perfectly specified."
Pre-Fill: Check the Codebase First
Before asking ANY questions, check if you're in an existing project:
- Look for: CLAUDE.md, README.md, package.json, pyproject.toml, Cargo.toml, go.mod, Makefile, Dockerfile, src/, tests/
- If an existing project is found:
- Read CLAUDE.md, README, and config files to understand the project
- Identify: tech stack, architecture, conventions, existing patterns
- Note what you already know and what's still unclear
- Only ask about the gaps — don't ask questions the codebase already answers
- Start by saying: "I've looked at your project. Here's what I understand: [summary]. Let me ask about what I'm less sure about..."
- If no project exists (empty directory or new project):
- Start from scratch with the full interview
Rules
- If a question can be answered by exploring the codebase, explore the codebase instead of asking
- Ask one focused question at a time, not batches
- When a decision opens new branches (e.g., "advanced search" → filters, sorting, pagination), explore each branch (full mode) or note it for later (light mode)
- Don't accept vague answers — ask follow-ups until the answer is specific and implementable
- Track decisions made so far to avoid re-asking
Process (Full Mode)
Phase 1: Big Picture
- What is the user trying to build?
- Who is it for?
- What does success look like?
Phase 2: Design Tree
For each major component:
- What are the options?
- What are the tradeoffs?
- Which option fits the constraints?
- What does this decision imply for other decisions?
Phase 3: Edge Cases & Failure Modes
- What happens when things go wrong?
- What are the performance constraints?
- What are the security considerations?
- What data validation is needed?
Phase 4: Synthesis
After all questions are answered:
- Summarize all decisions made
- Highlight any tensions or tradeoffs
- Propose a concrete implementation plan
- Ask if anything was missed
CHECKPOINT: Present the full synthesis to the user. Do NOT recommend next steps until they confirm. Ask: "Does this capture everything accurately? Anything missing or wrong before we move to implementation?"
Process (Light Mode)
Phase 1: Quick Context
- What are you building? (one sentence)
- What's the most important thing it needs to do?
- Any hard constraints? (tech stack, timeline, platform)
Phase 2: Key Decisions Only
- Ask about the 3-5 biggest decisions that would block progress
- Skip theoretical edge cases — focus on "what do I need to know to start building?"
Phase 3: Quick Summary
- Summarize decisions in bullet points
- Note anything deferred for later
- Recommend next step (usually
/wizardor/plan-and-spec)
CHECKPOINT: Present the summary to the user before recommending next steps. Ask: "Does this look right? Ready to move forward, or anything to adjust?"
Output
- Format: Inline chat — a structured summary presented in the conversation, not saved to a file
- Full mode deliverable: Decisions list + tensions/tradeoffs + concrete implementation plan
- Light mode deliverable: Bullet-point decisions + deferred items + recommended next step
- Save location: None by default. If the user wants it persisted, write to
PLAN.mdorPROGRESS.mdin the project root and note it survives context compaction.
Key Principle
The goal is NOT to ask a fixed list of questions. The goal is to dynamically explore the design tree until the level of clarity matches the mode: Full mode = zero ambiguity. Light mode = enough to start.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review