grill-me
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.
IMPORTANT — Do NOT end the interrogation early:
- Do not stop because you think you have "enough" information.
- Do not stop based on turn count or a feeling that the conversation has gone on long enough.
- Continue asking questions for as long as there are unresolved branches, ambiguities, or decisions that haven't been stress-tested.
- The interrogation ends ONLY when the user explicitly confirms they are satisfied with the clarified requirements.
When you believe all branches have been explored, ask the user explicitly:
"I believe we've covered all the major decision branches. Are you satisfied with the clarified requirements, or is there anything else you'd like me to dig into?"
Only after the user confirms they are satisfied, emit the structured summary block followed by the completion marker, in this exact format:
Problem statement:
Proposed solution:
Key decisions:
Open questions:
- <any unresolved questions, or "None" if all were resolved>
More from tahajemmali/skills
prd-to-plan
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./docs/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
76write-a-prd
Create a PRD through user interview, codebase exploration, and module design, then save to docs/<feature>/PRD.md. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
74reality-check
Activate a brutally honest, skeptical architectural partner that stress-tests ideas, architectures, and assumptions. Use when the user says "reality check", wants their design challenged, asks if their idea is sound, wants a devil's advocate review, or wants architectural critique without hand-holding.
73ship-check
Run the standard post-change validation flow after a fix, refactor, or new feature. Use when implementation work is done and you should validate the latest changes by invoking the repo's review skills, starting with review-changes and then repo-doc-maintainer, before giving the final close-out.
70review-changes
Review the latest changes and check whether they comply with the project's documented guidelines (AGENTS.md, CLAUDE.md, or equivalent). Use when reviewing local diffs, recent commits, or feature work and you need a findings-first assessment of architecture, reuse, testing, and repo-specific rules.
70repo-doc-maintainer
Review recent repository changes and decide whether AGENTS.md or other project-level documentation needs a high-level update. Use when finishing a feature, fix, refactor, or architectural change and you need to preserve repo-shaping guidance such as new patterns, constraints, workflows, validation rules, or onboarding-relevant gotchas without adding low-level implementation detail.
69