skills/mine.grill/SKILL.md
Use when the user says: "grill me on this", "poke holes in my idea", "help me think this through", "what am I not thinking about", or wants multi-angle questioning before committing to building something. Pre-pipeline exploration that sharpens thinking.
npx skillsauth add NodeJSmith/Claudefiles mine.grillInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Multi-angle interrogation of a raw idea. Attacks the idea from product, design, engineering, and adversarial perspectives to surface what you haven't thought about. Produces a structured brief that /mine.define can ingest.
Not a spec. Not a design doc. A thinking tool.
$ARGUMENTS — the idea, issue, or problem to explore. Can be a description, a GitHub issue reference, or a path to an existing document.
If $ARGUMENTS is provided, paraphrase it back in one sentence to confirm understanding. If empty, ask:
AskUserQuestion:
question: "What's the idea or problem you want to think through?"
header: "Grill"
Before exploring, confirm the pain point:
Understood pain point: <the underlying problem or frustration driving this idea>
If the user gave a solution ("I want to add X") but not the problem, ask: "What's not working well?" before proceeding.
Explore the codebase for relevant context (existing patterns, related features, prior art). Present a brief summary of what you found — this grounds the entire conversation.
Work through these lenses one at a time. For each lens, ask 1-3 questions — only the ones that surface something the user likely hasn't considered. Skip questions where the codebase already provides the answer. One question per AskUserQuestion call.
You do not need to ask every question. Skip any that are obvious, already answered, or where the codebase provides the answer. The goal is to find the 5-8 questions the user hasn't thought about, not to run a checklist.
After each answer, walk down any decision branches it opens — same pattern as adaptive follow-up in /mine.define. If an answer reveals something the codebase can inform, check the code before asking the next question.
After the interrogation, write a brief to the feature directory. If no feature directory exists yet, create one:
spec-helper init <slug> --json
Record the returned feature_dir — you will write the brief there.
Write to <feature_dir>/brief.md:
# Brief: <Title>
**Date:** YYYY-MM-DD
**Status:** explored
## Idea
<One-paragraph summary of what was explored>
## Key Decisions Made
<Bullet list of decisions reached during the grill — things that were ambiguous and are now pinned down>
## Open Questions
<Anything that came up but couldn't be resolved — these feed directly into /mine.define>
## Scope Boundaries
<What's in, what's explicitly out, what's deferred>
## Risks and Concerns
<Things that surfaced during adversarial questioning — assumptions, failure modes, maintenance burden>
## Codebase Context
<Relevant findings from code exploration — existing patterns, integration points, constraints>
AskUserQuestion:
question: "Brief saved. What next?"
header: "Handoff"
multiSelect: false
options:
- label: "Challenge this brief first"
description: "Run /mine.challenge — the brief shapes everything downstream, catch issues now"
- label: "Specify this feature"
description: "Run /mine.define with this brief as input"
- label: "Build it directly"
description: "Run /mine.build — routes based on complexity"
- label: "Done for now"
description: "Brief saved; pick it up later"
Invoke /mine.challenge --target-type=brief <feature_dir>/brief.md. After challenge completes, loop back to this handoff gate.
Invoke /mine.define <feature_dir>
Invoke /mine.build <feature_dir>
Confirm: "Brief saved at <feature_dir>/brief.md. Resume with /mine.define <feature_dir> later."
development
Use when the user says: 'create an issue', 'file an issue', 'open an issue', 'write an issue', 'new issue for this'. Codebase-aware issue creation — investigates the code to produce well-structured issues with acceptance criteria, affected areas, and enough detail for automated triage.
development
Use when the user says: 'triage issues', 'classify issues by complexity', 'assess issue complexity', 'find quick wins', 'which issues are small', 'batch issue assessment'. Batch codebase-aware issue triage — parallel Haiku subagents assess actual complexity and effort by reading the code, not just titles.
development
Use when the user says: "review my changes", "run the reviewers", "code and integration review", "readability review", "maintainability review", "sniff test this", "WTF check", "code smells", "is this code any good", "fresh eyes on this branch", "review this directory", "check this module". Dispatches three parallel reviewers — code, integration, and a readability pass — and consolidates findings into one prioritized report.
development
Use when the user says: "clean code check", "style review", "LLM smell check", "code hygiene", "nitpick this", "style check", "find style sins", "nitpicker review", "anal retentive review", "exhaustive style review", "no-filter style report". Dispatches three parallel stylistic checkers — llm-checker (training-bias patterns), lazy-checker (deferred debt), and nitpicker (style hygiene) — and consolidates findings into a report organized by checker with a Summary section for orchestration consumption.