From ded527f8965e83736dc5939f2296bf0ae807038d Mon Sep 17 00:00:00 2001 From: rafaumeu Date: Tue, 14 Jul 2026 23:12:44 -0300 Subject: [PATCH] fix: shorten description to 47 chars, reformat to modern outline, add author --- skills/software-development/grill-me/SKILL.md | 129 +++++++----------- 1 file changed, 48 insertions(+), 81 deletions(-) diff --git a/skills/software-development/grill-me/SKILL.md b/skills/software-development/grill-me/SKILL.md index 080ccf9d70b69..17669013bdbe4 100644 --- a/skills/software-development/grill-me/SKILL.md +++ b/skills/software-development/grill-me/SKILL.md @@ -1,8 +1,8 @@ --- name: grill-me -description: "Adversarial plan interview: one question at a time, with recommendations, resolving the full decision tree before any code is written." +description: "Adversarial plan interview before implementation." version: 1.0.0 -author: Rafael Zendron & Hermes Agent +author: "Rafael Zendron (rafaumeu)" license: MIT platforms: [linux, macos, windows] metadata: @@ -11,59 +11,49 @@ metadata: related_skills: [plan, requesting-code-review, subagent-driven-development, test-driven-development] --- -# Grill-Me — Adversarial Plan Interview +# Grill-Me Skill -An adversarial interviewer that finds flaws, ambiguities, and wrong assumptions -in a plan BEFORE any code is written. One question at a time, each with a -recommendation, resolving the full decision tree. - -## Overview - -Grilling is the practice of stress-testing a plan through structured adversarial -questioning. Instead of jumping into implementation, the agent interviews the -user — challenging assumptions, exploring edge cases, and cross-referencing -existing code — until the plan is watertight. - -This is NOT a code review (use `requesting-code-review` for that). This is a -**pre-implementation** activity: no code should be written during the grill. +Stress-tests a plan through structured adversarial questioning before any +code is written. One question per turn, each with a recommendation, resolving +the full decision tree until the plan is watertight. ## When to Use -**Use when:** -- User says "grill me", "interview my plan", "stress test this idea", "challenge my approach" -- User invokes `/grill-me` -- Before starting complex work: auth flows, schema changes, migrations, payment integration, concurrency handling, distributed systems -- When a plan seems vague or has unresolved decisions -- Before `subagent-driven-development` decomposition — ensure the plan is solid first +- User says "grill me", "interview my plan", "stress test this idea" +- Before complex work: auth flows, schema changes, migrations, payments +- A plan has unresolved decisions or seems vague +- Before `subagent-driven-development` decomposition -**Don't use for:** -- Code that already exists — use `requesting-code-review` instead -- Simple one-off tasks with no architectural impact -- When the user explicitly says "just do it" or "skip the planning" +Do NOT use for existing code (use `requesting-code-review`) or simple one-off +tasks. -**This skill vs related skills:** -- `plan` — writes a plan document. `grill-me` — stress-tests a plan (or raw idea) before it gets documented. -- `requesting-code-review` — reviews existing code. `grill-me` — reviews a plan before code exists. -- `subagent-driven-development` — executes a plan. `grill-me` — validates the plan before execution. +## Prerequisites -## Mandatory Rules +None. The skill works on any plan or raw idea. -1. **One question at a time.** Never fire a list. Ask ONE question, wait for the answer, then ask the next. -2. **Every question comes with a recommendation.** Before waiting for the answer, state what YOU recommend and why. -3. **Explore the codebase when possible.** If a question can be answered by reading files, read them instead of asking. Use `search_files`, `read_file`, `terminal`. -4. **Resolve the decision tree.** Don't skip branches. Go deep on each decision before moving forward. -5. **No code during the grill.** The goal is context alignment, not implementation. Only write code after the user gives an explicit green light. +## How to Run -## Interview Structure +The agent loads the skill and enters interview mode. No special setup needed. + +## Quick Reference + +| Rule | Detail | +|------|--------| +| One question per turn | Never fire a list | +| Recommendation included | State your recommendation before waiting | +| Explore codebase first | Use `search_files`, `read_file`, `terminal` | +| No code during grill | Alignment only — code after explicit green light | + +## Procedure ### Phase 1 — Understanding (2-4 questions) Establish the real goal and boundaries. -- What is the ACTUAL objective? (not what was said — what's underneath) -- What is the scope? What is explicitly OUT of scope? -- What are the constraints? (time, technology, team, budget, existing dependencies) -- Who are the users? What are their workflows? +- What is the ACTUAL objective? +- What is explicitly IN and OUT of scope? +- What are the constraints? (time, tech, team, budget) +- Who are the users? ### Phase 2 — Technical Decisions (4-8 questions) @@ -72,65 +62,42 @@ For each architectural decision: - "Why this approach and not X?" - "What happens if Y fails?" - "What's the worst case?" -- "How would you roll back if this goes wrong?" +- "How would you roll back?" -Cross-reference with the existing codebase when relevant. If the project already -has a pattern for something, call it out and ask whether to follow it. - -Identify conflicts with previous decisions in the project. +Cross-reference with the existing codebase using `search_files` and +`read_file`. If the project already has a pattern, call it out. ### Phase 3 — Edge Cases (2-4 questions) - "What happens if the user does Z?" - "What if dependency X goes down?" - "What if volume is 100x expected?" -- "What if this needs to be reverted? How hard would that be?" - "What security implications does this have?" ### Phase 4 — Synthesis When the decision tree is resolved: -1. Summarize ALL decisions made in bullet points -2. List anything left open (if any) -3. List what is explicitly OUT of scope (confirmed by user) -4. Ask: "Aligned? Should I start implementing, or do you want to adjust anything?" +1. Summarize ALL decisions in bullet points +2. List anything left open +3. List what is explicitly OUT of scope +4. Ask: "Aligned? Should I start implementing, or adjust anything?" -## Tone +## Pitfalls -- Direct and technical. No unnecessary diplomacy. -- When you find a problem, say it clearly: "This will break because X." -- When the user gives a vague answer, ask again more specifically. -- If the user contradicts themselves, point out the contradiction. -- Adapt language to the user — if they speak Portuguese, grill in Portuguese. +1. **Asking all questions at once.** One question, one answer, always. +2. **Skipping the codebase.** Find the answer in code using Hermes tools instead of asking the user. +3. **Accepting "I don't know" as final.** Suggest options, explain trade-offs, make a recommendation. +4. **Writing code during the grill.** Alignment only — resist the urge. +5. **Being too agreeable.** Your job is to find problems. If everything looks fine, look harder. +6. **Not adapting to the user's language.** Interview in whatever language the user speaks. -## Integration with Other Skills - -- **After a successful grill**, suggest using `plan` to write a formal plan document -- **For execution**, suggest `subagent-driven-development` for parallel task execution -- **For verification**, suggest `requesting-code-review` as a post-implementation quality gate -- **For TDD projects**, suggest `test-driven-development` as the implementation approach - -## Common Pitfalls - -1. **Asking all questions at once.** This is the most common failure mode. One question, one answer, always. - -2. **Skipping the codebase.** If the answer already exists in the code, find it yourself instead of asking the user. - -3. **Accepting "I don't know" as a final answer.** Help the user reach a decision — suggest options, explain trade-offs, make a recommendation. - -4. **Writing code during the grill.** Resist the urge. The grill is about alignment, not implementation. - -5. **Being too agreeable.** Your job is to find problems. If everything looks fine, you're not looking hard enough. - -6. **Not adapting to the user's language.** The skill text is in English, but the interview should match whatever language the user speaks. - -## Verification Checklist +## Verification - [ ] Asked exactly one question per turn - [ ] Provided a recommendation with each question -- [ ] Explored the codebase when relevant (didn't ask questions the code can answer) +- [ ] Explored the codebase when relevant (used `search_files` / `read_file`) - [ ] Covered all four phases before synthesizing - [ ] Produced a clear summary of all decisions - [ ] Confirmed user alignment before stopping -- [ ] Suggested next skill (plan / subagent-driven-development / requesting-code-review) +- [ ] Suggested next skill (`plan`, `subagent-driven-development`, or `requesting-code-review`)