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 skills add retz8/pastiche --skill grill-to-specgit clone --depth 1 https://github.com/retz8/pasticheWrote 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/retz8/pastiche/grill-to-spec)<a href="https://agentmods.dev/skills/retz8/pastiche/grill-to-spec"><img src="https://agentmods.dev/badge/skills/retz8/pastiche/grill-to-spec/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/retz8/pastiche/grill-to-spec"><img src="https://agentmods.dev/badge/skills/retz8/pastiche/grill-to-spec.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00061 | $0.00662 |
| Opus 5.5 | $0.00024 | $0.00265 |
| Sonnet 5.5 | $0.00012 | $0.00132 |
| Haiku 4.5 | $0.00006 | $0.00066 |
Grade A, and why
grill-to-spec 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 2mo 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 — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Grill to Spec
Convert a just-completed grill-me session into a spec file under _dev/docs/spec/.
File naming
Number first. Filename comes from the TODO number when available, otherwise name only. Do not ask the user about the path — derive it and proceed.
- Task (
**N.M**in TODO):_dev/docs/spec/task-<N.M>-<short-name>.md - Phase:
_dev/docs/spec/phase-<N>-<short-name>.md - No task number available:
_dev/docs/spec/<short-name>.md
Hard rules
- Spec, not plan. Capture what was decided, not how to implement it. No task breakdown, no step-by-step, no file-by-file instructions.
- Only what was locked in the grill. If a decision did not come up explicitly in the grilling conversation, do not include it. Do not infer, do not extend, do not add "for completeness."
- No invented decisions. If the user did not state a preference on something, it is not in the spec. Surface it as an open item only if the user flagged it as open during grilling.
- No implementation details. No code, no command lines, no file syntax, no per-step procedure. The spec is a high-level overview of the locked task scope and decisions.
Required structure
# <Task title>
<One- or two-sentence statement of what this spec covers. Reference the parent TODO item, phase, or OSS_SPEC section.>
## Scope
<Bulleted or short-prose statement of what is in scope for this task. Drawn from the grill, not invented.>
## Locked decisions
### 1. <Decision title>
<One short paragraph stating the decision as locked in the grill.>
### 2. <Decision title>
<...>
## Invariants
<Optional. Constraints the grill surfaced that apply throughout the task. Skip if none were raised.>
## Open items
<Optional. Only items the user explicitly flagged as deferred or unresolved during the grill. Skip if none.>
Process
- Re-read the grilling conversation in context. Identify every decision the user explicitly accepted, rejected, or modified.
- Derive the target path per the File naming rules above. Do not ask, do not confirm.
- Write the spec directly to that path using the required structure. Do not display the draft to the user beforehand — just write it.
- Report the written path in one line. The user will redirect if revisions are needed.
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.
- 2mo ago First seen · 69 lines · 61 tokens per session scan A 4da842a0a8c8
grill-to-spec is a skill published in the GitHub repository retz8/pastiche (4 stars, last pushed 4mo ago), licensed MIT. It adds 61 tokens to every session and 662 once invoked, about $0.0002 per session on Opus 5.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
designlang-tokens
Use when styling UI for cal.com — references the extracted design system tokens instead of inventing colors, spacing, or typography.
cicd-integration
Generate CI pipeline files and check scripts (GitHub Actions, GitLab, CircleCI, Bitbucket) that automate design system checks: token validation, hardcoded values, a11y scans, visual regression, bundle size. Trigger: set up CI, quality gates, automate these checks. Not for running an audit.
figma-variable-audit
Audit Figma variable collections: tier mapping, naming, alias chains, modes, orphans; can fix in place with Figma Console MCP. Triggers: audit my Figma variables, review variable collections, Figma variable health. For token files in code use token-audit.
token-audit
Audit how design tokens are defined: tiers, naming, alias chains, raw values, orphans, DTCG readiness. Triggers: audit my tokens, token architecture review, token health check. Not for code consuming tokens (token-compliance), theme parity (theme-audit) or Figma variables (figma-variable-audit).
codebase-index
Generate machine-readable index files in .ai/index/ (component inventory, uses/usedBy graph, stats) for AI agents. Triggers: index my codebase, build a relationship graph, what depends on what. Not an assessment; for library health use component-audit.
token-documentation
Write reference docs for existing design tokens: semantic intent, use/do-not-use, references, used-by, theming contract, misuse list. Triggers: document our tokens, token reference, what is this token for. Token structure/architecture audit: use token-audit; file validation: schema-validator.