spec

A command for writing a short SPEC, meaning a focused software specification that states what should be built and how completion will be checked. It reviews the specification and closes it after a clean review.

In plain words
What is it for?
Capturing the request, expected behavior, affected files, and completion conditions in a project SPEC.
Why use it?
It keeps implementation tied to the user's original request and prevents a small task from growing into unnecessary documentation.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/ashkaan/contextium/spec
Any agent
npx skills add Ashkaan/contextium --skill spec
Clone the repo
git clone --depth 1 https://github.com/Ashkaan/contextium

Made for: Claude Code, Codex.

Per session 95 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,642 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00095 $0.02642
Opus 5 $0.00048 $0.01321
Sonnet 5 $0.00019 $0.00528
Haiku 4.5 $0.00010 $0.00264

Measured yesterday against content hash 5227dc1a2a02, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

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 yesterday.

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.

templates/claude/skills/spec/SKILL.md · 141 lines

How it starts

The opening of the file, as written. The whole thing — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.

/spec — write the SPEC

/spec is the SPEC-writing half of the Think verb. /project does the thinking — goal-alignment, context-load, explore, design — then hands the design to /spec, which writes the actual SPEC file, audits it, and auto-closes (commits) on a clean pass. Breaking it out means a SPEC can be produced ANY time one is needed: inside a full /project think flow, OR ad-hoc when work-in-progress turns out to need one in the moment.

Critical

  • The SPEC stays lean. Four sections — Ask / Behavior / Files / Done — per .claude/templates/spec-lean.md. Don't pad it with boilerplate that degrades to "N/A"; a heavy project grows its own sections when a real gap bites, per @rule:simplest-solution-default.
  • The Ask section is the user's verbatim ask. Capture it in their words. It's the thing the finished work is checked against — it keeps the implementation from drifting into a fancier interpretation than was wanted.
  • /spec auto-closes; there is no sign-off halt. On a clean audit, /spec auto-invokes /close to commit the SPEC (per ../close/references/auto-close-gate.md). The SPEC lands on the main branch and is revised there — the user reviews it in the fresh /implement tab, not at a pre-commit gate. /spec only HALTS if the audit surfaces a choice the user must make (a @rule:depth-policy decision), or if the reviewer could not run.
  • Fresh-context boundary preserved. /spec's auto-close ENDS the session. The next /implement runs in a fresh tab — /spec does NOT roll into /implement.
  • Don't paper over a gap. If the design left a credential, a file path, or an API unresolved, resolve it now (read the file, find the item) — a SPEC that says "from whatever config X uses" is a guess, not a spec.

step-1-write-spec — write the SPEC file

The SPEC is a committed artifact capturing WHAT this work delivers + HOW + done criteria, using the lean 4-section template. See project/references/spec-schema.md for the section-by-section explainer.

Read the full file on GitHub · 141 lines

Changes

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.

  1. yesterday First seen · 141 lines · 95 tokens per session scan A 5227dc1a2a02

Subscribe to this mod's changes

spec is a skill published in the GitHub repository Ashkaan/contextium (32 stars, last pushed 4d ago), licensed MIT. It adds 95 tokens to every session and 2,642 once invoked, about $0.0005 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.