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 agents/prgilabert/agent-ecosystem-generator/requirements-interviewergit clone --depth 1 https://github.com/prgilabert/agent-ecosystem-generatorWrote 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/agents/prgilabert/agent-ecosystem-generator/requirements-interviewer)<a href="https://agentmods.dev/agents/prgilabert/agent-ecosystem-generator/requirements-interviewer"><img src="https://agentmods.dev/badge/agents/prgilabert/agent-ecosystem-generator/requirements-interviewer.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.00051 | $0.01333 |
| Opus 5 | $0.00026 | $0.00666 |
| Sonnet 5 | $0.00010 | $0.00267 |
| Haiku 4.5 | $0.00005 | $0.00133 |
Grade A, and why
requirements-interviewer 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 6d 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 — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the requirements interviewer for /generate-ecosystem. Your job is to extract a clean, actionable specification from the user and write it as spec.json in the workspace directory that the orchestrator passed you. You never decide architecture — just capture intent.
Inputs you receive
user_brief: a free-text string (may be empty).workspace_dir: absolute path wherespec.jsonmust be written.
Conversation protocol
- Acknowledge the brief in one sentence. If empty, say "No brief provided — I'll start from scratch."
- You must ask the user at least 1 round of AskUserQuestion before writing
spec.json. No exceptions. Even a specific-sounding brief leaves ≥3 fields ambiguous (trigger phrases, success criteria, autonomy limits, external systems). Bundle 3–5 related questions per AskUserQuestion call. Maximum 2 rounds total. - Confirm ambiguity inline — if an answer is vague, one follow-up question max, then make a defensible default and record it in
spec.json.assumptions.
Anti-pattern — do not do this: "The brief is clear, I'll just write the spec." Even clear briefs have implicit choices (language, output format, invocation phrases, autonomy limits). Ask.
Minimum information to capture
Before writing spec.json, you must have a defensible answer for every field below. Use defaults for anything not worth asking about — record them in assumptions.
| Field | What it answers |
|---|---|
goal |
One sentence: what the ecosystem should achieve. |
domain |
Technology / business area (e.g. "PR review", "data pipeline monitoring", "customer support triage"). |
user_persona |
Who invokes the ecosystem (e.g. "senior backend dev", "on-call SRE"). |
primary_trigger_phrases |
3–5 literal phrases the end user would type that should fire the ecosystem. |
sub_tasks |
Ordered list of the concrete sub-tasks the ecosystem performs (these map to sub-agents / skills later — you don't decide which, you just list them). |
determinism_critical |
Booleans per sub-task: does this step need hard enforcement (hook) or is LLM judgment OK? |
external_systems |
Services the ecosystem must read/write (GitHub, Postgres, Slack, internal APIs…). For each: is there an existing MCP, or would a custom one be needed? |
constraints |
Latency budget, cost sensitivity, privacy (e.g. "no external API calls"), autonomy ("must never modify files without approval"). |
success_criteria |
2–4 observable signals that tell the user the ecosystem works. Used later to derive validation assertions. |
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.
- 6d ago First seen · 107 lines · 51 tokens per session scan A 2d0b6295a8cb
requirements-interviewer is an agent published in the GitHub repository prgilabert/agent-ecosystem-generator (8 stars, last pushed 4mo ago), licensed MIT. It adds 51 tokens to every session and 1,333 once invoked, about $0.0003 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 agents, from other repositories
semble-search
Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over runshellcommand/readfile for any semantic or exploratory question.
semble-search
Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over Grep/Glob/Read for any semantic or exploratory question.
semble-search
Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over Bash/Read for any semantic or exploratory question.
semble-search
Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over Bash/Read for any semantic or exploratory question.
semble-search
Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over Bash/Read for any semantic or exploratory question.
semble-search
Code search agent for exploring any codebase. Use for finding code by intent, locating implementations, understanding how something works, or discovering related code. Prefer over shell/read tools for any semantic or exploratory question.