RomanNum3ral
/
hermes-agent
mirror of https://github.com/NousResearch/hermes-agent.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix: shorten description to 47 chars, reformat to modern outline, add author

This commit is contained in:
rafaumeu 2026-07-14 23:12:44 -03:00 committed by teknium1
parent c7b3abd1f0
commit ded527f896
1 changed files with 48 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

129
skills/software-development/grill-me/SKILL.md
View File

@ -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`)