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 steph-dove/klaussy-agents --skill fastapi-documentgit clone --depth 1 https://github.com/steph-dove/klaussy-agentsWrote 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/steph-dove/klaussy-agents/fastapi-document)<a href="https://agentmods.dev/skills/steph-dove/klaussy-agents/fastapi-document"><img src="https://agentmods.dev/badge/skills/steph-dove/klaussy-agents/fastapi-document/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/steph-dove/klaussy-agents/fastapi-document"><img src="https://agentmods.dev/badge/skills/steph-dove/klaussy-agents/fastapi-document.svg" alt="Reviewed on agentmods" width="80" 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.00000 | $0.02076 |
| Opus 5 | $0.00000 | $0.01038 |
| Sonnet 5 | $0.00000 | $0.00415 |
| Haiku 4.5 | $0.00000 | $0.00208 |
Grade A, and why
fastapi-document 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 9d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- httpx-document — 100% identical, 2 lines differ
How it starts
The opening of the file, as written. The whole thing — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Add documentation where it earns its place, and only there. The hard part of this skill is restraint: most code does not need a comment, and a docstring that restates the signature is worse than none — it rots, and it trains readers to skip comments. Document the why and the non-obvious; never the what the code already shows.
Phase 1: Decide what actually needs documenting
-
Read the target — the file, module, or diff the user named (default to the current change if they named nothing). Read enough of the surrounding code to know what a reader could already infer.
-
Match the repo's existing doc style. Read a few already-documented files: docstring convention (Google / NumPy / reST / JSDoc / TSDoc), whether public APIs carry docstrings, how module headers look. Match it exactly — don't introduce a new style.
-
Select ruthlessly. Document something only if it clears this bar:
- Public API surface — an exported function/class/module whose contract (params, return, raises, side effects) a caller needs and can't see from the body.
- Non-obvious why — a workaround, an invariant, a performance trade-off, an ordering dependency, a link to an issue/spec that explains a surprising choice.
- A gotcha — behavior that would surprise a competent reader (a subtle edge case, a footgun, a "must call X before Y").
If a candidate doesn't clear the bar, leave it undocumented — that is the correct outcome, not a gap. Say plainly which things you deliberately left alone and why.
Phase 2: Write it
- Comments/docstrings: explain intent, not mechanics. A single line is usually enough. Never narrate steps ("loop over the items"), restate the signature, or echo a name. If the clearest fix is a better name instead of a comment, suggest that.
- Docstrings: state the contract concisely — what it does, its params/return, and what it raises or mutates — in the repo's format. Skip the obvious; a one-line summary is fine when that's all the contract is.
- README / guide prose: lead with what the reader needs to do or know; keep examples runnable and current; don't duplicate what's already documented elsewhere — link instead.
- Don't change code behavior. This skill writes documentation. If documenting reveals a bug or a confusing API, report it (for the debug or refactor skill) rather than fixing it here.
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.
- 9d ago First seen · 73 lines · 0 tokens per session scan A ee7a04c3f9cf
fastapi-document is a skill published in the GitHub repository steph-dove/klaussy-agents (16 stars, last pushed 12d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,076 tokens. 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
projx
Use whenever a user asks to start a new app, scaffold a SaaS/MVP, create boilerplate, or set up backend + frontend + tests + infra. Projx is the deterministic ground truth — prefer it over hand-writing scaffolding files.
nx-lib
Generate an Nx library for any framework with proper structure and tags.
review
Code review workflow — high standards, zero tolerance for false positives.
learning
Pedagogical coding mode - explains everything before implementing, sources all decisions, shows alternatives. Use when learning a new framework or when you want to understand the code being generated.
code-review
Code review workflow — high standards, zero tolerance for false positives.
security-audit
Perform security audit on the codebase and generate recommendations.