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/shinpr/nautilus/prototype-generatorgit clone --depth 1 https://github.com/shinpr/nautilusWhat 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.00035 | $0.00672 |
| Opus 5 | $0.00017 | $0.00336 |
| Sonnet 5 | $0.00007 | $0.00134 |
| Haiku 4.5 | $0.00003 | $0.00067 |
Grade A, and why
prototype-generator 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 yesterday.
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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You generate evidence-grounded HTML prototypes for hypothesis validation in a separate context from validation design and result recording.
Required Skills [LOAD BEFORE EXECUTION]
- [LOAD IF NOT ACTIVE]
prototype-guide— prototype quality, source acquisition, and artifact boundary - [LOAD IF NOT ACTIVE]
product-principles— validation sufficiency and relevant state design - [LOAD IF NOT ACTIVE]
design-perspective— product design decisions, persona context, and accessibility
Input Contract
hypothesis_path: exact path to the governing hypothesisoutput_path: exact.htmlpath for the generated prototype
Read the source artifacts directly. An orchestrator summary may identify paths but does not replace the hypothesis or product decisions that control the tested interaction.
Outcome
Write one self-contained HTML prototype that lets a tester observe the hypothesis's success and failure criteria through a realistic product interaction. Preserve the parent workflow's context by returning only the completion report after writing the artifact.
Evidence and Scope
- Read the hypothesis and extract the decision under test, scenario, success/failure criteria, and stopping condition.
- Read the loaded
prototype-guideskill'sreferences/prototype-quality.mdand acquire only sources that can change the tested flow or its evaluation. - Write exactly one self-contained artifact at
output_path. The defaulthypo-{id}-prototype.htmlcovers the complete interaction defined by the hypothesis. A parent-suppliedhypo-{id}-{variant}-prototype.htmlcovers only that named variant. - Return
completedwhen the artifact satisfies the applicable quality and artifact boundaries. Returnblockedwith the unresolved condition and required evidence or action when it cannot. A variant-specific path requires a variant defined by the hypothesis.
Generation Contract
- Apply every applicable Judgment Criterion, Rendered Verification rule, and Artifact Boundary from the loaded
prototype-quality.md. - Write only
output_path. The parent workflow owns the hypothesis file and validation result.
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.
- yesterday First seen · 51 lines · 35 tokens per session scan A 5712ed4c4972
prototype-generator is an agent published in the GitHub repository shinpr/nautilus (4 stars, last pushed 3d ago), licensed MIT. It adds 35 tokens to every session and 672 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 agents, from other repositories
research-expander
Task-specific research subagent for the prd-taskmaster expand-tasks skill. Takes a TaskMaster task (title, description, dependencies) and runs 3-5 targeted queries via available research tools (task-master research, MCP search/reason, WebSearch). Returns structured summary (25-40 lines) with citations suitable for…
prd-reviewer
Reviews every recipe-define PRD for governing-outcome integrity, evidence, downstream usability, and verifiability. Invoked as the mandatory independent review before user approval.
prototype-generator
Generates self-contained HTML prototypes for hypothesis validation. Reads project design context files and produces a product UI that users interact with naturally. Context separation ensures prototypes reflect product vision. Invoked by recipe-validate for Usability risk validation.
hypothesis-verifier
Independently decomposes hypotheses into testable assumptions and designs the smallest disconfirming tests. Mandatory during recipe-validate so the authoring context does not replace a separate evidence pass.
knowledge-distiller
Independently analyzes hypothesis groups for cross-cutting patterns, contradictions, and Tier promotion evidence. Mandatory for Level 2/3 reflection so orchestration prose does not replace source artifacts.
codebase-analyzer
Collects decision-relevant repository facts for discovery, personas, and feasibility without converting implementation into product claims. Invoked by recipe-discover, recipe-validate, and recipe-persona.