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/yaalalabs/agent-kernel/ak-dev-write-specnpx skills add yaalalabs/agent-kernel --skill ak-dev-write-specgit clone --depth 1 https://github.com/yaalalabs/agent-kernelWhat 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.00143 | $0.05145 |
| Opus 5 | $0.00072 | $0.02573 |
| Sonnet 5 | $0.00029 | $0.01029 |
| Haiku 4.5 | $0.00014 | $0.00515 |
Grade A, and why
ak-dev-write-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 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 — 316 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write a Spec for a Planned Change
Use this skill when asked to produce spec documents for Agent Kernel work before (or instead of) implementing it. A change is specified in three documents, written in strict order, all under docs/specs/<issue-number>-<short-title>/:
| Stage | File | What it is | Written when |
|---|---|---|---|
| 1 | design.md |
Concise, point-form, hierarchical requirements — what changes and why | First, before anything else |
| 2 | spec.md |
Detailed design and implementation components, following the approved design | Only after design.md has been reviewed and optimized through review cycles |
| 3 | plan.md |
Concise breakdown of the implementation into iterations/steps | Only after both design.md and spec.md are done |
Do not skip ahead. design.md is the document humans review — it must exist and survive its review cycles before effort goes into spec.md. Writing a detailed spec against an unreviewed design wastes the detail work when the design changes.
The same directory may optionally hold a research/ subfolder — the supporting investigation that informed the design (provider surveys, prior-art comparisons, benchmarks, spike notes). It is not a fourth stage and not required; see Optional: research/.
This skill is for writing these documents, not for implementing the change they describe.
Which Stage Are You In?
Route from what the requester asked for and what already exists in docs/specs/<issue-number>-<short-title>/:
- No
design.mdyet, or the request is "write a spec/design for X" → Stage 1: writedesign.mdand stop there. design.mdexists and the requester says it is reviewed/approved (or asks for the implementation spec) → Stage 2: writespec.md.design.mdandspec.mdboth exist and the requester asks for the plan/breakdown → Stage 3: writeplan.md.- Asked to update an existing document → update that document; if the update changes requirements in
design.md, flag that downstreamspec.md/plan.mdneed re-alignment. - Asked to capture or record research — a provider survey, a prior-art comparison, a benchmark, a spike — → write it under
research/(optional; see Optional:research/). This can happen beforedesign.mdexists and does not, on its own, start Stage 1.
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 · 316 lines · 143 tokens per session scan A 483dadb3ddc1
ak-dev-write-spec is a skill published in the GitHub repository yaalalabs/agent-kernel (145 stars, last pushed 5d ago), licensed Apache-2.0. It adds 143 tokens to every session and 5,145 once invoked, about $0.0007 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
notion
Notion workspace integration for searching pages, managing databases, creating postmortems, and exporting RCA findings.
datadog
Datadog monitoring integration for querying logs, metrics, monitors, events, traces, hosts, and incidents during RCA investigations.
ovh
OVHcloud infrastructure integration for managing instances, Kubernetes clusters, networks, and object storage via CLI and Terraform.
scaleway
Scaleway cloud integration for managing instances, Kapsule Kubernetes clusters, object storage, and managed databases via CLI and Terraform.
postmortem
Postmortem generation and management tools for writing, reading, and versioning incident postmortems.
drawio-aws
Use when the user asks for an AWS architecture diagram — VPC/networking, event-driven, landing zone, multi-AZ, serverless pipeline, or any diagram built with AWS service icons. Builds with the declarative layout engine using ground-truth mxgraph.aws4 stencils, validates (stencils/colors/nesting/geometry), runs a…