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 skills/stacklok/toolhive/implement-storynpx skills add stacklok/toolhive --skill implement-storygit clone --depth 1 https://github.com/stacklok/toolhiveWhat 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.00027 | $0.02083 |
| Opus 5 | $0.00014 | $0.01042 |
| Sonnet 5 | $0.00005 | $0.00417 |
| Haiku 4.5 | $0.00003 | $0.00208 |
Grade A, and why
implement-story 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 2d 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 — 235 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implement User Story
Takes a GitHub user story issue and produces well-organized PR(s) that reliably meet the acceptance criteria.
Arguments
The user provides a GitHub issue number or URL. Example:
/implement-story #4550
/implement-story https://github.com/stacklok/toolhive/issues/4550
Phase 1: Gather Context
1.1 Read the Issue
Fetch the issue body using GitHub tools. Extract:
- User story: The "As a / I want / so that" statement
- Acceptance criteria: The checkbox list — this is the contract
- Context links: RFC links, related issues, dependencies
- Out of scope: What NOT to do
1.2 Fetch RFC Context
If the issue links to an RFC (look for THV-XXXX references or links to toolhive-rfcs):
- Clone or locate the RFC repo locally (check
../toolhive-rfcs/first) - Read the full RFC document
- Extract design decisions relevant to this story — config shapes, algorithm details, error formats, key schemas, etc.
If no RFC is linked, skip this step.
1.3 Find Related Stories
Search for sibling stories that share context with this one. These inform how to factor the code for extensibility:
# Search by keywords from the issue title
gh search issues "<keywords>" --repo stacklok/toolhive --state open --limit 10
# Search for issues linking to the same RFC
gh search issues "THV-XXXX" --repo stacklok/toolhive --limit 10
For each related story, read its acceptance criteria. Ask:
- Will a future story need to extend a type, interface, or package I'm creating?
- Should I define an interface now that a sibling story will implement later?
- Are there naming conventions or patterns I should establish that siblings will follow?
Do not implement sibling stories. Design internal interfaces so they can be extended without refactoring, but do not add config fields, CRD types, or user-facing API surface for functionality that isn't implemented in this PR. Unused config confuses users and reviewers.
1.4 Research the Codebase
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.
- 2d ago First seen · 235 lines · 27 tokens per session scan A 043ceec2634a
implement-story is a skill published in the GitHub repository stacklok/toolhive (2,065 stars, last pushed today), licensed Apache-2.0. It adds 27 tokens to every session and 2,083 once invoked, about $0.0001 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-30.
Other skills, from other repositories
testing-mcp-server-security
Testing Model Context Protocol (MCP) servers and the clients that consume them for tool poisoning, prompt injection via tool descriptions/outputs, over-permissioned and local-credential-stealing tools, config/trust bypasses, and unauthenticated RCE during authorized penetration tests of AI agent infrastructure.
mcp-redteam
Security audit of MCP servers. Safe mode (default) = source analysis + read-only probing. Active mode = controlled payload testing.
brin-check
Scan packages, repositories, MCP servers, domains, web pages, and agent skills for security threats using the brin API. Use this skill before installing dependencies, visiting URLs, or integrating external resources.
browser-control
Requires BROWSERAPIKEY in .env.
browser-skill
Imported from OpenClaw migration.
bugcrowd-reporting
Bugcrowd-specific reporting tactics complementing report-writing: VRT category search-and-fallback strategy when no exact match exists, manual severity override when VRT defaults underrate impact, severity-request paragraph as first body section, OOS-clause rebuttal templates (rate limiting on auth-flow endpoints…