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/inkeep/open-knowledge-skills/write-a-specnpx skills add inkeep/open-knowledge-skills --skill write-a-specgit clone --depth 1 https://github.com/inkeep/open-knowledge-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/skills/inkeep/open-knowledge-skills/write-a-spec)<a href="https://agentmods.dev/skills/inkeep/open-knowledge-skills/write-a-spec"><img src="https://agentmods.dev/badge/skills/inkeep/open-knowledge-skills/write-a-spec.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 | $0.00176 | $0.04717 |
| Opus 5 | $0.00088 | $0.02358 |
| Sonnet 5 | $0.00035 | $0.00943 |
| Haiku 4.5 | $0.00018 | $0.00472 |
Grade A, and why
write-a-spec 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 3d 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 — 299 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write a spec — scope a feature and commit an implementation spec
This skill is pack guidance. The platform
/open-knowledgeskill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers spec-writing craft on top.
A spec is the contract between "we decided to build this" and "here is how it gets built." It is derived from an ACCEPTED proposal, maps the system that exists TODAY before proposing a change, and records its one-way-door choices in a Decision Log so the reasoning survives the author leaving. A spec that skips the current-system mapping, or resolves its open questions silently, is a liability — it reads authoritative while being unfounded.
specs/ uses a folder-per-spec shape: specs/NNN-name/ holding spec.md, and (when the work is actually going to be built) plan.md + tasks.md. The pack ships all three templates. status on spec.md flows draft → ... → shipped.
Autonomy mode
| Mode | Behavior | How entered |
|---|---|---|
| Supervised (default) | STOP at the Step 2 scoping gate for user confirmation of Goals / Non-goals / change shape. Route open decisions interactively. | Default when a user drives the session. |
| Headless | Auto-confirm the scoping proposal after presenting it; auto-select routing decisions. All other gates (parent-proposal check, current-system mapping, Decision Log, validation, grounding) still enforced. | Explicit "don't wait for me", "just proceed", "run headless" — or non-interactive container environments. |
In headless mode, propose the scope AND proceed immediately; record in the Decision Log that scope was auto-confirmed without user sign-off.
Mandatory execution order
Hard gates — do NOT skip ahead. If you find yourself about to write ## Design before you have read the actual code the change touches, STOP — you skipped Step 1.
- Find the parent proposal. No accepted proposal behind a spec is a smell.
- Map the CURRENT system. Read real code + prior specs + guides. Write what exists today, with pointers.
- Scoping STOP gate. Propose Goals / Non-goals / change shape. In Supervised mode, WAIT.
- Create the spec folder +
spec.mdfrom thespectemplate; allocateNNNby listing, not guessing. - Fill Goals / Non-goals — non-goals temporal, each with a reason.
- Design — options considered, one chosen, why; one-way doors flow to the Decision Log.
- Decision Log — append the section; each entry survives the author.
- Open Questions — a live backlog, each with its closing evidence and decider.
- Migration + Test plan — real states, real tiers, explicit gaps.
plan.md+tasks.md— only when the spec is going to be built.- Link + validate — backlinks, dead-links clean, frontmatter complete.
- Recap — and what would move it out of
draft.
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.
- 3d ago First seen · 299 lines · 176 tokens per session scan A 1e1e2fdc5335
write-a-spec is a skill published in the GitHub repository inkeep/open-knowledge-skills (6 stars, last pushed yesterday), licensed MIT. It adds 176 tokens to every session and 4,717 once invoked, about $0.0009 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 skills, from other repositories
syndic
Gère un parc de copropriétés en France avec vue portfolio consolidée. Couvre administration, comptabilité (décret 2005, plan comptable copro, 5 annexes), assemblées générales (convocation, PV, notification), appels de fonds, travaux, fournisseurs, recouvrement d'impayés et transition de syndic. Maîtrise les majorités…
decision-map
Maps the unresolved architecture, policy, and scope decisions that must be answered before planning can start: one durable decision ticket per question on the issue tracker, typed and blocker-linked under a parent map, with fog-of-war, out-of-scope, a computed frontier, and one decision resolved per invocation.…
to-issues
Decompose a PRD and/or SPEC into implementable, vertically-sliced Issues with real blocking edges, then create them in your chosen platform (GitHub or Local). Use after /prd (and optionally /prd-to-spec) to turn requirements into agent-ready tickets. Triggers on: create issues, to-issues, 创建issue, 拆解issue, 生成卡片, 创建卡片…
produck-feedback
Use when acting on real user feedback — you have a Produck feedback ticket or URL, or the user wants to fix something users complained about or build a feature users asked for. Pulls full feedback context through the Produck MCP and drives a feedback → aligned PRD → build loop. Triggers on "fix what users reported", a…
setup-matt-pocock-skills
为本仓库配置工程技能——设置其 issue tracker、分诊标签词汇表和领域文档布局。首次使用其他工程技能前运行一次。.
gh-issues
Use when creating, searching, updating, or managing GitHub issues via CLI. Triggers: "issue", "create issue", "gh issue", "task tracking", "context", "handoff", "resume task", "session context", "save progress", "active tasks", "in-progress", "my tasks", "open issues". Covers: gh commands, bulk operations, JSON/jq…