From grill-all
Use when stress-testing a coding plan or design and the right answers may come from the human, project docs, codebase, or the web.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grill-all:grill-allThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
`grill-all` is a source-aware extension of `grill-me` for Codex, Claude Code, Hermes, and other vibe-coding agents.
grill-all is a source-aware extension of grill-me for Codex, Claude Code, Hermes, and other vibe-coding agents.
Its job is not to ask more questions. Its job is to ask the right source: the human, project docs, the codebase, or the web. If a question can be answered confidently from authoritative context, answer it there instead of interrupting the human.
Use it when a plan, architecture, feature, refactor, or implementation direction needs to be stress-tested before or during coding.
Every unresolved question should be routed to the most authoritative available source.
CONTEXT.md, README.md, design docs, tickets, specs, project rules.Do not ask the human questions that docs or code can answer. Do not let web results override local project authority. Do not silently decide matters of human intent.
Infer the desired level of human interruption from the user's prompt.
Do you want me to grill you with confirmation questions, or should I proceed autonomously by checking docs/code/web and only ask when a human decision is required? I recommend autonomous unless this is a high-stakes design.
After this one preference question, follow the chosen mode.
For every open question, classify it before asking anyone.
1. Is this answered by explicit user instruction in the current prompt?
-> Use that. Do not ask again.
2. Is this a project fact or requirement?
-> Check project docs first: OpenSpec, ADRs, CONTEXT.md, README, tickets, specs.
3. Is this an implementation fact?
-> Inspect the codebase, tests, types, call sites, and existing patterns.
4. Is this a human preference or product trade-off?
-> Ask the human one question, with a recommended answer.
5. Is this about current external facts or third-party behavior?
-> Search the web, prioritizing official docs and primary sources.
6. Do sources conflict?
-> Use the conflict rules below. Ask the human only if the conflict changes product intent, risk, or scope.
Use the highest-authority source for the kind of question being answered.
When conflict matters, summarize the conflict and ask one question:
I found a conflict: docs say X, code currently does Y. I recommend following X and updating the code because Z. Should I proceed with that?
When asking the human:
README.md, CONTEXT.md, issue notes, or another repo-appropriate docs file. Treat the recorded answer as project documentation in future source routing. Do not record secrets, private credentials, or throwaway one-off preferences.Good pattern:
I checked
openspec/changes/auth/design.mdand the current auth middleware. The remaining decision is product policy: should expired sessions redirect to login or show an inline re-auth modal? I recommend redirecting to login for v1 because it is simpler and matches the current flow. Which should we use?
Bad pattern:
What auth middleware does this project use?
If the codebase can answer it, inspect the codebase instead.
Use when the user wants deep questioning or says things like "grill me", "challenge this", "stress-test this", or "ask until clear".
Behavior:
The goal is shared understanding, not speed.
Use when the user wants vibe coding, autonomous execution, or minimal interruptions.
Behavior:
Good autonomous update:
Docs and code both indicate that settings are stored in
UserPreferences. I will use that path and note the assumption that no migration is needed.
Use web research only when local context cannot answer the question or the question depends on current external facts.
When searching:
For coding projects, consider these before asking the human:
AGENTS.md, CLAUDE.md, GEMINI.md, .cursorrulesREADME.md, docs/**, wiki/**CONTEXT.md, ARCHITECTURE.md, DESIGN.mdopenspec/project.md, openspec/specs/**, openspec/changes/**adr/**, docs/adr/**, architecture/decisions/**When proceeding without asking:
I checked [sources]. They indicate [answer]. I will proceed with [decision].
When asking:
I checked [sources]. The unresolved human decision is [decision]. I recommend [option] because [reason]. Choose: A, B, or C?
When using web:
Local context did not answer this, so I checked external sources. Official docs say [claim] ([URL]). I will use that unless local project docs conflict.
When blocked:
I cannot resolve this from docs, code, or web because [reason]. This is a human decision about [intent/risk/trade-off]. I recommend [option]. Should I proceed?
Prompt: "Grill me on this caching design."
Use grill-heavy mode. Ask one decision-tree question at a time, but inspect docs/code for factual answers first.
Prompt: "Vibe code this settings page; don't ask unless needed."
Use autonomous mode. Inspect existing settings patterns, make reversible assumptions, and ask only for product choices or risky scope changes.
Prompt: "Implement OAuth with the current SDK."
Check project auth docs and existing code first. Use web research for current SDK docs if the local version or API behavior is unclear.
Prompt: "Should we use modal re-auth or redirect?"
This is a human/product decision. Check existing UX patterns, then ask one question with a recommendation.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub zhjai/grill-all --plugin grill-all