Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/terva-sh/terva/grillingnpx skills add terva-sh/terva --skill grillinggit clone --depth 1 https://github.com/terva-sh/tervaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/terva-sh/terva/grilling)<a href="https://agentmods.dev/skills/terva-sh/terva/grilling"><img src="https://agentmods.dev/badge/skills/terva-sh/terva/grilling.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00037 | $0.00895 |
| Opus 5 | $0.00018 | $0.00447 |
| Sonnet 5 | $0.00007 | $0.00179 |
| Haiku 4.5 | $0.00004 | $0.00089 |
Grade A, and why
grilling scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Grilling
Run this when the user asks to be interviewed before you build. It prevents the expensive failure: building the wrong thing confidently, from a goal you and the user each read differently.
The trigger is the ask, not your own read of whether a request is vague. You are poor at noticing that you are about to invent a decision, so do not wait to feel uncertain. When you do spot unstated decisions and the user has not asked for an interview, name the two or three that matter and offer to run this, rather than starting an interview nobody requested.
Leave it alone when the shape is already clear: a one-line fix, a rename, a question with one obvious answer. An interview over a settled task spends the user's attention for nothing.
The design tree and the frontier
Every decision branches into the decisions that hang off it. Picking a storage engine opens questions about migration and backup; it settles none of the questions about the interface above it.
The frontier is every decision whose prerequisites are already settled: the questions answerable now, without guessing at an answer you have not heard yet. A question whose answer depends on another question still open belongs to a later round, not this one.
Working the frontier is what keeps an interview short. Asking a downstream question early forces the user to invent a premise, and you then build on it.
The loop
- Map the frontier. From what the user has said, list every decision that is open and answerable now. Park the rest as later branches.
- Send every fact question to a sub-agent. Anything answerable from the
environment goes to
swarm_spawnrather than to the user: what the config says, whether a symbol exists, how a test behaves today. Only the questions downstream of that exploration wait for it; ask the rest of the frontier now. - Ask the whole frontier in one round, using a single
ask_user_questioncall. See the format below. - Recompute the frontier from the answers. New answers settle prerequisites and usually open new branches.
- Repeat from step 2 until the frontier is empty.
- State the shared understanding back and wait for confirmation.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 80 lines · 37 tokens per session scan A 18a20398aab7
grilling is a skill published in the GitHub repository terva-sh/terva (2 stars, last pushed 3d ago), licensed MIT. It adds 37 tokens to every session and 895 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
pi-sync
Daily upstream-sync job for the pi Go port — fetch upstream pi, triage every change since the recorded pin, port what's in scope, verify idiomatic + parity via independent reviews, update the ledger, and push. Use for "sync with upstream", "porting job", or as the scheduled daily run.
pi-go-review
Review ported Go code for idiomatic quality — that the port maximizes Go rather than transliterating TypeScript. Use after porting upstream pi changes, or standalone on any diff in this repo.
use-modern-go
Use the Modern Go Guidelines CLI whenever writing, modifying, fixing, or refactoring Go code. Apply its version-specific guidance to generated changes.
modern-go
Modernize Go code by applying version-appropriate idioms and APIs (gofix-style transformations). Scans go.mod for the Go version, then transforms Go source files to use modern patterns—from Go 1.0 through 1.26+. Use when the user says "现代化","现代Go语言", "地道的", "idiomatic", "modernize", "modern-go", "update Go code"…
go-127
What changed in Go 1.27 (released August 2026) and how it changes the way Go is written in pi-go. Use this skill when writing or reviewing Go that could use a 1.27 feature, when bumping the go directive in go.mod, when a build or test behaves differently after a toolchain upgrade, or when code-guidelines-go points…
code-guidelines-go
Go 1.24–1.27 coding guidelines for the dimetron/pi-go AI agent runtime. Use this skill whenever writing, reviewing, or refactoring ANY Go code in pi-go. This covers idiomatic style, error handling, concurrency, project layout, testing (table-driven, fuzz, benchmarks, synctest), new stdlib usage, golangci-lint v2…