Teknium
c49fa88b80
* refactor(skills): shipped-set slim — 15 skills to optional, github six-way merge, pdf absorbs OCR+nano-pdf, channel-gated teams pipeline
Maintainer-directed shipped-skills curation (skills index 1,900 -> ~1,400
tok/call on desktop; every session pays the index, so this is a per-call
diet on all installs):
- optional-skills moves (installable via skills hub, history preserved):
creative comfyui/ascii-art/excalidraw/pretext/sketch/touchdesigner-mcp;
ALL of mlops (huggingface-hub, llama-cpp, serving-llms-vllm,
weights-and-biases, evaluating-llms-harness — subcategory structure
kept); research-paper-writing (55 supporting files, 17.3K-tok load);
openhue; blogwatcher (first taught the cronjob monitor-field watch
pattern + web_extract instead of pre-cron manual workflows)
- DELETED session-librarian (Aug-12 'inspired by Perplexity Computer'
port, never maintainer-intended; session_search covers discovery)
- github: six skills (auth, issues, pr-workflow, issue-to-pr,
code-review, repo-management) merged into ONE software-development/
github skill — routing body + complete per-workflow references;
benbarclay authorship credited; codebase-inspection rides along;
discipline pins from test_github_issue_to_pr_skill.py preserved
against the reference body in the new test_github_skill.py
- pdf absorbs ocr-and-documents + nano-pdf as references/ + scripts
(extract_pymupdf, extract_marker converted to the argparse house
standard its contract test enforces)
- NEW session_platforms frontmatter gate (metadata.hermes): hides a
skill from the index on gateway channels it is not for; fail-open on
unknown platform; teams-meeting-pipeline gated to [teams, cron]
- blocked-page-recovery: research -> new web category; trigger-first
description ('Use when a fetch fails: 403/429, paywall, WAF, bot
wall.') so the model actually reaches for it on blocked fetches
- docs regenerated via generate-skill-docs.py (195 pages); related_skills
swept repo-wide; tests: 1672 passed (2 openclaw failures pre-existing
on clean main, Windows-local)
* chore: ignore .skills_prompt_snapshot.json (local index cache, accidentally committed)
5.6 KiB
title, sidebar_label, description
| title | sidebar_label | description |
|---|---|---|
| Grill Me — Adversarial plan interview before implementation | Grill Me | Adversarial plan interview before implementation |
{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}
Grill Me
Adversarial plan interview before implementation.
Skill metadata
| Source | Optional — install with hermes skills install official/software-development/grill-me |
| Path | optional-skills/software-development\grill-me |
| Version | 2.0.0 |
| Author | Rafael Zendron (rafaumeu) + Matt Pocock (mattpocock/skills, grilling) + Hermes Agent |
| License | MIT |
| Platforms | linux, macos, windows |
| Tags | planning, adversarial, interview, decision-tree, pre-implementation, review, alignment |
| Related skills | requesting-code-review, subagent-driven-development, test-driven-development |
Reference: full SKILL.md
:::info The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active. :::
Grill Me
Stress-tests a plan through structured adversarial questioning before any code is written. Models the plan as a design tree — every decision branches into the decisions that hang off it — and interviews the user in rounds until every branch is resolved and nothing is silently assumed.
Combines the phase discipline of the original with the frontier-rounds
mechanic from mattpocock/skills' grilling.
When to Use
- 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-developmentdecomposition
Do NOT use for existing code (use requesting-code-review) or simple one-off
tasks.
Prerequisites
None. The skill works on any plan or raw idea.
Core Mechanic: Frontier Rounds
Map the plan as a design tree. The frontier is every decision whose prerequisites are already settled — the questions you can ask NOW without guessing at answers you haven't heard yet.
Work in rounds: ask the whole current frontier in one message, numbered, each question carrying your recommended answer. Then wait. A question whose answer depends on another question still open in this round belongs to a LATER round, not this one.
Format each round like so:
❓ Q1 — <question title>: <question body, options if relevant>
➡️ Recommendation: <your recommended answer + one-line why>
❓ Q2 — <question title>: <question body>
➡️ Recommendation: <...>
Each answer reshapes the tree: settled decisions push the frontier outward and unblock dependent questions. Recompute the frontier and ask the next round.
Facts are your job; decisions are the user's. When a frontier question
needs a fact from the environment (codebase, filesystem, config, docs), find
it yourself with search_files / read_file / terminal — or dispatch a
subagent via delegate_task for a heavy exploration. Never ask the user for
anything you could look up. Don't block on an exploration: only the questions
downstream of it wait; ask the rest of the frontier now.
Question Coverage (work these branches into the tree)
Understanding — the real goal and boundaries:
- 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?
Technical decisions — for each architectural choice:
- "Why this approach and not X?" / "What happens if Y fails?"
- "What's the worst case?" / "How would you roll back?"
- Cross-reference the existing codebase; if the project already has a pattern for this, call it out.
Edge cases:
- "What happens if the user does Z?" / "What if dependency X goes down?"
- "What if volume is 100x expected?" / "What are the security implications?"
Synthesis (when the frontier is empty)
- Summarize ALL decisions in bullet points
- List anything left open, and what is explicitly OUT of scope
- Ask: "Aligned? Should I start implementing, or adjust anything?"
Do not act on the plan until the user confirms shared understanding.
Pitfalls
- Asking questions out of dependency order. A question that depends on an unanswered question is a guess wearing a question mark. Keep it for a later round.
- Skipping the codebase. Find facts in code with Hermes tools instead of asking the user.
- Accepting "I don't know" as final. Suggest options, explain trade-offs, make a recommendation.
- Writing code during the interrogation. Alignment only — code after the explicit green light.
- Being too agreeable. Your job is to find problems. If everything looks fine, look harder.
- Not adapting to the user's language. Interview in whatever language the user speaks.
Verification
- Every question in a round had all its prerequisites already settled
- Provided a recommendation with each question
- Explored the codebase for facts instead of asking the user
- Frontier empty (no branch silently assumed) before synthesizing
- Produced a clear summary of all decisions and open items
- Confirmed user alignment before stopping