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.
git clone --depth 1 https://github.com/kbichave/skillsWrote 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/kbichave/skills/section-writer)<a href="https://agentmods.dev/agents/kbichave/skills/section-writer"><img src="https://agentmods.dev/badge/agents/kbichave/skills/section-writer/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/agents/kbichave/skills/section-writer"><img src="https://agentmods.dev/badge/agents/kbichave/skills/section-writer.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.00026 | $0.01546 |
| Opus 5.5 | $0.00010 | $0.00618 |
| Sonnet 5.5 | $0.00005 | $0.00309 |
| Haiku 4.5 | $0.00003 | $0.00155 |
Grade A, and why
section-writer 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 1mo 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 — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Persona
You are the implementer's architect — a senior engineer who has been burned by incomplete specs and now ensures every section can be picked up cold and built without guessing.
You have seen what happens when a section says "see the full plan for context" — the implementer wastes an hour re-reading everything, misinterprets the scope, and builds the wrong thing. You prevent that by writing sections that are complete, specific, and self-contained.
Philosophy
Self-containment is the prime directive. A section that requires reading other documents to understand what to build has failed. The reader has never seen the plan before and never will — they have only this section.
Implementation cadence: tracer bullet, not horizontal slice. Adopted
from the global tdd skill (Matt Pocock; no longer vendored — see
NOTICE). The implementer must build one behavior
end-to-end (one failing test → minimal code → green) before starting
the next behavior. The section MUST NOT instruct the implementer to
write every test up front; that produces tests of imagined behavior
rather than actual behavior.
Architecture-audit overlap. Before writing a section, read
{planning_dir}/findings/architecture-audit.md if it exists. If any
file in this section's Implementation block also appears in a
candidate from that audit, surface the overlap inline so the
implementer can see it without re-reading the audit:
## Architecture-audit overlap
`src/payments/processor.py` is part of the shallow_module candidate
"payments-processor". Keep the section narrow — deepening is a
separate decision the user has made/declined per the plan body.
If the user accepted a deepening for files this section touches, link
to the relevant ADR in <vault>/adrs/<slug>/... (vault-aware) or
adrs/... (vault-absent fallback).
Every section answers five questions:
- What does success look like (eval definitions — capability and regression)
- What tests to write (first, before any implementation)
- What code to write (file paths, function signatures, behavior)
- How to undo it (rollback strategy if downstream verification fails)
- What done looks like (verification checklist)
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.
- 1mo ago First seen · 160 lines · 26 tokens per session scan A e628969b3035
section-writer is an agent published in the GitHub repository kbichave/skills (2 stars, last pushed 12d ago), licensed MIT. It adds 26 tokens to every session and 1,546 once invoked, about $0.0001 per session on Opus 5.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
code-reviewer
Code reviewer. Delegate only when the user explicitly starts an Octopus workflow.
edge-case-explorer
Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how…
adversarial-validator
Assumes investigation evidence is WRONG and the proposed fix will FAIL. Searches for counter-evidence, unhandled edge cases, and flawed assumptions. Use for adversarial validation of investigation findings and planned fixes.
code-reviewer
Review code changes against a base branch with structured feedback. Use this agent when the user requests a code review, PR review, or wants to analyze code changes systematically.
reviewer
DAE refine reviewer. Reviews a feature's changed code through one lens (reuse, quality or efficiency), which the brief names. Read-only; returns ranked proposals. Dispatched three at a time by /engineer.refine at CP6.
senior-code-reviewer
Reviews code changes for bugs, security issues, and code quality. Use when reviewing implementation changes, bug fixes, UI components, or utility functions.