Prompt grill
Interrogates the user about a vague plan, feature, or prompt until reaching complete understanding, resolving every branch of the decision tree before any implementation. Use ALWAYS when the user requests a new feature, describes an ambiguous task, says "grill me", "interview me", "refine this prompt", or when a request has more than one possible interpretation — even if they don't ask for it explicitly.From its SKILL.md
npx -y skills add murilobauck/specsmith --skill prompt-grillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.3 KB, as published. Nobody here has run it
Prompt Grill
Goal: turn vague requests into assertive specifications BEFORE writing any code.
Interview rules
- Ask ONE question at a time via the AskUserQuestion tool. Never dump a questionnaire.
- Each question offers 2-3 options; the recommended one comes first with "(Recommended)"
in the label, and each option's
descriptionstates the trade-off in one line. - Walk the decision tree in order, advancing only once the current branch is resolved:
- (a) problem and target user
- (b) measurable success criteria
- (c) explicit IN / OUT scope
- (d) data and contracts (inputs, outputs, schemas)
- (e) edge cases and failure modes
- (f) constraints (performance, cost, deadline, privacy/compliance)
- (g) technical decisions
- When an answer opens a new branch, pursue it before moving on.
- Stop when you can write the spec without any "probably" or "assuming that".
Required output
At the end, write specs/<feature>/spec.md in the user's project (create the
directory if needed). Use the section structure below directly — do not depend
on a template file existing in the project. If the project already has
specs/_template/spec.md (e.g. after running specsmith-init), follow that
template's structure instead.
- Context and problem (2-3 sentences)
- Verifiable acceptance criteria (checklist)
- Out of scope (explicit)
- Data contracts (inputs, outputs, schemas)
- Edge cases mapped
- Decisions taken + rejected alternatives and why
- Open questions (if any remain, flag them as risks)
Once the spec is approved, follow the flow in specs/README.md:
spec.md approved → plan.md approved (declares the branch) → tasks.md → lifecycle kickoff (branch) → code (1 commit per task, checkpoint phase) → lifecycle close (tests/CI → push → PR draft, pause) — git mechanics per the dev-lifecycle skill.