Grilling autoresearch
SkillMonitoring & opsCoach the user through a rigorous, repository-grounded interview to create or improve program.md. Use when a target repository lacks program.md, its goals, metrics, data, or guardrails are unclear, or the user asks to be grilled about an autoresearch setup.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Grilling autoresearch skill
What this skill tells your AI
The instructions your AI receives, as published by wandb/senpai in .agents/skills/grilling-autoresearch/SKILL.md and read by ahel’s review.
Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
Before asking questions, inspect the repository's documentation, data loaders,
training and evaluation code, configuration, and any existing program.md.
Finding facts is your job, never the user's. Ask the user only for decisions
and intent.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers you have not heard yet. Ask the whole frontier in one round. Number each question, give your recommended answer, and then wait for the user's answers before the next round.
Format each question like this:
❓ **Q1** - **<question title>**: <question body, including choices when useful>
➡️ <your recommended answer>
Each round reshapes the tree. Settled decisions push the frontier outward and unblock dependent questions. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round.
When a frontier question needs a fact from the environment, dispatch a subagent to find it. Do not ask the user for anything you could look up yourself, and do not block the independent questions: a running investigation is only an unsettled prerequisite for its downstream branch. The decisions are the user's; put each to them and wait.
For program.md, keep the design tree centered on:
- the objective, exact primary metric names and definitions, optimization direction, evaluation split, and any secondary gates;
- data paths, shapes, sizes, splits, exclusions, leakage risks, and footguns;
- commands, budgets, result artifacts, editable boundaries, and benchmark integrity constraints; and
- useful research avenues, papers, models, or libraries without unnecessarily narrowing the search space. Narrow it only when that is the user's explicit intent.
The session is done when the frontier is empty: every branch of the design tree has been visited and nothing material remains silently assumed. Do not act on it until the user confirms that you have reached a shared understanding.
Then draft a program.md that is concise, plain-language, and high-signal
because Senpai appends it to every model's system prompt. Make it specific
enough to run and evaluate the research correctly, while leaving implementation
choices and exploration to the research agents. Prefer high-level goals and
guardrails over step-by-step micromanagement, and verify every repository path,
command, data claim, and metric definition against the repository.
Useful examples:
Adapted from Matt Pocock's grilling skill, used under the MIT License.
Signals
- GitHub stars
- 34
- Forks
- 5
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
grilling-autoresearch- Source
- github.com/wandb/senpai