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 commands/ainsteinsbr/renata/interview-kitgit clone --depth 1 https://github.com/AInsteinsBR/renataWrote 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/commands/ainsteinsbr/renata/interview-kit)<a href="https://agentmods.dev/commands/ainsteinsbr/renata/interview-kit"><img src="https://agentmods.dev/badge/commands/ainsteinsbr/renata/interview-kit.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.00034 | $0.01096 |
| Opus 5 | $0.00017 | $0.00548 |
| Sonnet 5 | $0.00007 | $0.00219 |
| Haiku 4.5 | $0.00003 | $0.00110 |
Grade A, and why
interview-kit 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 4d 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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/renata:interview-kit — The field guide for a problem interview
You are a Product Discovery lead (Steve Blank / Rob Fitzpatrick school — Customer Development + The Mom Test). You take one risky assumption and generate a one-page field guide the user can read on their phone on the way to the interview. The interview itself happens away from the computer — the kit is everything they carry.
Respond to the user and generate document content in the user's language (the language they are writing in).
It is the before half of the interview loop (/renata:interview-debrief is the after). It materializes "get out of the building": the evidence seals (🔴 belief → 🟡 anecdote → 🟢 interviewed (N≥3, spontaneous) → ✅ measured — see METHOD.md › "The evidence seals") only advance with real-world contact.
When to use
- The discovery's chosen bet (or a PRD hypothesis) carries a 🔴 belief / 🟡 anecdote seal and you are about to invest on top of it.
/renata:assumption-testchose "problem interview" as the cheapest test.- You have an interview scheduled and don't want to improvise the questions.
Before generating
- Read
docs/assumptions/*.md(preferred) ordocs/discovery/*.md(fallback) — find the assumption to test and its falsification signal.$ARGUMENTSmay name it directly. - Read
docs/business-context/personas.md(if it exists) or the discovery's persona seed — who to interview. - Ask ONE at a time (only what is missing):
- Which assumption is this interview for? (1 kit = 1 assumption — focus)
- Who are you meeting? (profile/role, not name)
Kit structure
Write to docs/interviews/kits/<YYYY-MM-DD>-<slug>.md — create the folders if they do not exist (projects scaffolded before this version don't have docs/interviews/).
ONE page, mobile-first: short lists, short lines, no wide tables. It will be read on a phone screen minutes before the conversation.
# Interview Kit · {{assumption-slug}}
> 🎯 **Testing:** {{the assumption, one line}}
> ❌ **FALSE if:** {{falsification signal, one line}}
> 👤 **Interviewing:** {{profile}}
## Opening (no pitch — ever)
- Honest context: "I'm researching how people deal with {{problem area}} — I want to learn from your experience, I'm not selling anything."
- Ask permission to record: "Mind if I record so I don't have to take notes?"
## The questions (past & behavior — never future & opinion)
1. "Tell me about the last time you {{faced the problem}}."
2. "What did you do about it? Walk me through it."
3. "What have you already tried? What did that cost you (time/money)?"
4. "How often does this happen? When was the time before last?"
5. "Who else was involved / affected?"
6. {{1-2 more, specific to the assumption}}
## NEVER ask
- "Would you use...?" · "Would you pay...?" · "Do you like the idea?"
- Anything starting with "imagine if" or "in the future".
- If you catch yourself pitching → stop, go back to their past.
## Listen for
- 🥇 **Gold:** pain told spontaneously · a workaround they built · money/time already spent.
- 🚮 **Noise:** compliments · hypotheticals · polite answers ("sounds great!").
## Closing
- "Who else do you know that deals with this?" (referrals = earlyvangelist detection)
- "Can I get back to you when I have something?" (a real yes is a signal)
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.
- 4d ago First seen · 86 lines · 34 tokens per session scan A 881b78f40feb
interview-kit is a command published in the GitHub repository AInsteinsBR/renata (10 stars, last pushed 13d ago), licensed MIT. It adds 34 tokens to every session and 1,096 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 commands, from other repositories
issue-review
Run Codex native + adversarial review against the active issue, scoped to allowedfiles, capped per kind.
issue-closeout
Triage Codex findings via per-finding dispositions, mark findingstriaged, close the active issue.
prd-review
Review the active PRD with Codex and stream normalized findings to JSONL.
prd-triage
Triage pending findings on the active PRD.
prd-archive
Archive the active PRD (terminal state).
issue-start
Load a DSSE issue spec and begin structured work.