# Grill Me

> ---

- Skill: `together2329/grill-me` (Agent Skill)
- Install (CLI): `npx skillmds@latest add together2329/grill-me`
- Raw SKILL.md: https://api.skillmd.com/api/skills/together2329/grill-me/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: together2329 (https://skillmd.com/u/together2329)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/together2329/grill-me

---

---

## name: grill-me

description: Sweep the SSOT for every TBD / unknown / null / missing-required field and capture each human decision through ATLAS QA tools. Use ask_user for immediate blockers and record_ssot_qa for deferred Review cards, so both paths appear as pending/approved in QA Review.

# Grill Me — SSOT-Gen Edition (TBD-driven QA Review)

Adapted from [https://github.com/mattpocock/skills](https://github.com/mattpocock/skills) (`productivity/grill-me`,
MIT). The original interviews the user about a plan; this version is
tuned for the ssot-gen workflow: **find every TBD field in the SSOT and
capture it through ATLAS QA tools**, never via plain prose. Use
`record_ssot_qa` for deferred Review items and `ask_user` only when the
answer blocks the next SSOT write/import pass.

## Iron rules

1. **Use QA tools for every question.** Plain-text "what should I set X to?"
  is forbidden in this skill. Use `record_ssot_qa` when the decision can
   stay pending in QA Review while drafting continues. Use `ask_user` when
   the answer is an immediate blocker. Both paths must create QA Review
   records: pending first, approved after the user answers.
2. **Never invent values.** If a field's correct value can't be derived
  from (a) the canonical template `workflow/ssot-gen/rules/ssot-template.yaml`,
   (b) an existing IP's `*.ssot.yaml`, (c) an explicit user message in the
   conversation, you MUST create a QA Review item. Default values from the
   template are acceptable, but only after the user confirms via
   `ask_user` or answers a `record_ssot_qa` pending card.
3. **Status is part of the contract.** `record_ssot_qa` creates pending
  cards. `ask_user` creates pending cards while open and flips them to
   approved when the user submits. Do not leave an `ask_user` answer only in
   chat history when it belongs to SSOT.
4. **Auto-select is explicit pipeline behavior.** If the current mode is
  `auto-select`, `ask_user` may return an automatically chosen answer based on
   the `Suggest:` hint, recommended/default option, or first safe option. Treat
   that as approved QA evidence for smoke testing, but keep the generated QA
   card reviewable with `field_path`, `criteria`, `source_refs`, and a clear
   recommendation. Do not silently fill a value outside QA.

## Process

### 1. Locate the work-in-progress SSOT

- If the user named an IP, look for `<ip>/yaml/<ip>.ssot.yaml` (and
`<ip>/<ip>.ssot.yaml` as legacy fallback) via `read_file` /
`find_files`.
- If no draft exists, start from the canonical template at
`workflow/ssot-gen/rules/ssot-template.yaml` and treat the entire file
as TBD.
- If no IP name yet, the FIRST `ask_user` is:
  ```
  ask_user(
    question="What's the IP name?",
    kind="input",
    subtitle="Used as top_module.name and the directory prefix.",
  )
  ```

### 2. Sweep for TBD markers

Walk the YAML and collect a list of unresolved fields. A field is TBD if
ANY of these are true:

- value is `null`, `~`, empty string, or missing entirely
- value is `"<…>"` placeholder (template style), `"TBD"`, `"TODO"`,
`"unknown"`, `"???"`
- there is a `# TODO`, `# TBD`, or `# confirm` comment on the line
- a required-by-schema field is absent (top_module.name, top_module.type,
sub_modules[*].name, function_model.transactions[*].outputs,
cycle_model.handshake_rules[*].rule, timing.target_clocks[*],
quality_gates.signoff.evidence, register_map[*].address, etc.)

For each gap, record: `{section, path, current_value, allowed_values?, why_required}`.

### 3. Walk the gaps in canonical SSOT order

§0 → §1 → … through the canonical SSOT sections. Within a section, parents before children
(e.g. `top_module.type` before `top_module.target.clock_freq_mhz`).
For each gap, emit one QA item. Keep the question *narrow* — one decision
per card. Prefer `record_ssot_qa(questions=[...])` for non-blocking gaps
so the user can answer them from QA Review. Use `ask_user(questions=[...])`
only for immediate blockers.

#### Question shape

For each TBD field, pick the right `kind`:


| Field type                                                            | `kind`     | Options source                              |
| --------------------------------------------------------------------- | ---------- | ------------------------------------------- |
| Enum (e.g. `top_module.type`, `interface.protocol`, `reset.polarity`) | `"single"` | template's allowed values; surface verbatim |
| Boolean (`ssot_gen: true/false`)                                      | `"single"` | `["yes","no"]`                              |
| Multi-pick (interface list, irq sources, power domains)               | `"multi"`  | template enumerated values                  |
| Numeric (clock_freq_mhz, register address, bit width)                 | `"input"`  | (no options)                                |
| Identifier / free name (sub-module name, signal name)                 | `"input"`  | (no options)                                |
| Description text                                                      | `"input"`  | (no options)                                |


Mandatory fields in each `record_ssot_qa` or `ask_user` question object:

- `question` — short, single-decision
- `subtitle` — cite §section + field path so the user sees where the
answer lands, e.g. `"§3 register_map[2].access — RW lets firmware modify; RO is hardware-set; W1C clears on write of 1"`
- `options` — for `single`/`multi`, surface 2–6 *real* options; never
include "Other" (the GUI auto-adds a custom note field)
- `kind` — see table above

#### Recommendation in the subtitle

Always include your *recommended* answer at the end of the subtitle,
prefixed with `Suggest: …`. The user can override via the custom-note
field. Recommendations follow these defaults:

- pick the simplest option that doesn't paint the design into a corner
- match adjacent IPs' style when one exists in the project
- prefer template defaults over inventing new values

### 4. Apply each answer

After `ask_user` returns or the user answers a pending QA card:

- Parse the result string (it comes back as `"selected: <label>"` or
`"selected: …  ·  note: <free-form>"`).
- Apply the value to the in-memory SSOT model.
- Re-sweep for TBDs (a single answer may unlock or invalidate other
fields, e.g. picking `top_module.type=memory` changes which sub-module
templates apply).
- If the answer references something checkable in the codebase (a file
path, an existing module name), verify with `read_file` /
`find_files` before trusting it.

### 5. Stop conditions

- Every TBD resolved or recorded as a pending QA Review card → propose the
next review/write step.
- User says "stop", "done", "skip the rest" → write the YAML with the
remaining gaps left as `# TODO: confirm` comments.
- A single `ask_user` returns empty (no selection, no note) → treat as
"use suggested default" and continue.

### 6. Report

When done, summarize:

- which sections are now fully filled
- which still have `# TODO: confirm`
- the next workflow step (typically `/gen-rtl` or another `/grill-me`)

## Anti-patterns (do not do)

- Asking "what do you want for §3?" without the field path or options.
- Presenting more than one decision per QA card.
- Using plain prose to elicit values when ATLAS QA tools are available.
- Filling a value yourself and noting it as "(needs confirm)" without
asking the user — the whole point of this skill is to NOT silently
default.
- Asking about fields that are already concretely set in the conversation
or in `<ip>.ssot.yaml`.