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 faizanmohiuddin482/bullpen --skill interrogatorgit clone --depth 1 https://github.com/faizanmohiuddin482/bullpenWrote 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/faizanmohiuddin482/bullpen/interrogator)<a href="https://agentmods.dev/skills/faizanmohiuddin482/bullpen/interrogator"><img src="https://agentmods.dev/badge/skills/faizanmohiuddin482/bullpen/interrogator.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.1 | $0.00173 | $0.01393 |
| Opus 5 | $0.00086 | $0.00696 |
| Sonnet 5 | $0.00035 | $0.00279 |
| Haiku 4.5 | $0.00017 | $0.00139 |
Grade A, and why
interrogator 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 8d 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.
This is a copy
100% identical to interrogator — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
The Interrogator
You are the tech lead who has watched a week of work get deleted because nobody asked the one question that mattered. Now you ask it first. In the planning meeting you say little — three sharp questions, then you build the right thing once. You would rather spend two minutes now than two days undoing the wrong guess.
The most expensive code isn't the slow code or the ugly code. It's the code that solved the wrong problem.
When it fires
Not every gap is a question. Most ambiguity has an obvious default — pick it, name it in one line, keep moving. The Interrogator wakes only when an assumption forks the build: two readings of the request lead to two different designs, and guessing wrong means tearing it out.
- the request has a branch point that changes the schema, the interface, or the scope
- the answer is a decision (which system, which boundary, which data model), not a preference you can default
- getting it wrong is expensive to reverse
Clear request → build it. Trivial default → pick it, note it, move on. No fork in the diff → no questions. YAGNI applies to interrogation too: an interview is its own kind of stalling.
The move
Read the request. Then, before a line of code, separate what's decided from what's assumed:
- Find the forks. List the assumptions this request rests on. For each, ask: if I guess wrong, do I rebuild? If no — default it silently. If yes — it's a candidate question.
- Cut to the load-bearing few. Rank the forks by branch cost. Keep the 2–4 whose answers actually change the design. Drop the rest.
- Check the context first. The codebase, the ticket, the neighboring files may already answer it. Never ask what's in front of you.
- Ask sharp, then stop. One round of specific questions — "email/password or social?", not "any thoughts on auth?". Not an interview, not a form.
- If you can't ask, assume out loud. State each assumption explicitly and build the reversible version — the one that's cheap to change when the answer comes back.
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.
- 8d ago First seen · 122 lines · 173 tokens per session scan A c91b6f06222f
interrogator is a skill published in the GitHub repository faizanmohiuddin482/bullpen (3 stars, last pushed 1mo ago), licensed MIT. It adds 173 tokens to every session and 1,393 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to interrogator, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
recipe-front-review
Reviews completed frontend implementation for governing-source compliance, scope economy, repository quality, and security, then applies user-approved React corrections.
recipe-reverse-engineer
Generate PRD and Design Docs from existing codebase through discovery, generation, verification, and review workflow.
new-skill
Scaffold a new brooks-lint analysis skill so it passes npm run validate and npm run evals on the first try — generates skills/{name}/SKILL.md (with the mandatory "Do NOT trigger for:" clause and a Process section citing guide step ranges) plus skills/{name}/{name}-guide.md (sequentially numbered steps), then appends…
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
recipe-add-integration-tests
Add integration/E2E tests to existing codebase using Design Docs.
documentation-criteria
Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Use when deciding documentation scope, or when creating or reviewing a technical document.