How do I install the Specification skill?

Run npx skillmds@latest add aretedriver/specification in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Specification safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Specification?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Specification free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Specification?

AreteDriver (@aretedriver) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Specification by aretedriver — Agent Skill

Name: Specification
Rating: 4.5 (4 reviews)
Author: AreteDriver

Specification

Specification-mode prompt scaffold. Use when the decision is made and you need a buildable, testable, reviewable spec. Output is fixed-structure with measurable acceptance criteria. Never re-argues the premise. Invoke with /specification.

AreteDriver Updated Sep 10, 2026

File contents

Specification Mode

Load the full template from ~/projects/animus/packages/forge/prompts/modes/specification.md and use it as the structural contract.

Process

Gather INPUTS from the user. If any are missing, ask before producing the spec. Do not fill gaps with assumptions — that's a rubric-grade failure mode. Required slots:
- artifact — the thing being specified (API, module, workflow, deliverable)
- objective — what it must do, one sentence
- constraints — explicit + measurable (e.g. "p95 latency < 200ms", not "fast")
- interfaces — inputs consumed, outputs emitted (types, schemas)
- acceptance — how we know it's done (test names, observable behaviors)
- evidence base — prior art, reference implementations
- exclusions — explicitly out of scope
Produce the spec in OUTPUT FORMAT order from specification.md:
1. Summary (2-3 sentences)
2. Requirements (MUST / MAY / MUST NOT)
3. Constraints (each with a measurement method)
4. Interfaces (typed schemas, error cases)
5. Acceptance criteria (falsifiable)
6. Out of scope (explicit)
7. Open questions (labeled, decisions NOT injected)
Honor FAILURE CONDITIONS — self-check before emitting:
- Any untestable requirement ("should be fast") → rewrite with a threshold
- Any interface without error-case behavior → add it
- Any exploratory language ("we could", "maybe") → you're in the wrong mode
- Any implementation-detail leak in acceptance → replace with observable behavior

Anti-pattern

Do not re-litigate the decision. If the user prompts with "but what if we did X instead?", stop and tell them to run /evaluation to re-open the decision. Specs get weaker every time they defend their own premise.

Build-mode goal-loop (code/build artifacts ONLY)

If the artifact being specified is code/build (not a spec for non-code work), ARM the goal-loop by writing a .goal-active sentinel at the repo root with mode: armed — advisory only: it surfaces the objective each turn but does not start autonomous looping. Full engagement happens at /production.

objective: <objective, one line>
stop_condition: <acceptance summary, or "TBD at production">
budget_ceiling_usd: 10
turn_ceiling: 25
turns: 0
spent_usd: 0
mode: armed
started_at: <ISO8601>

Ensure .goal-active is git-ignored. Clear it via /exploration, /evaluation, or /goal clear.

Scoring

animus-forge eval run <suite> --rubric code-edit --prompt-version specification-v1

For non-code specs, author a custom rubric in ~/projects/animus/packages/forge/rubrics/. Weights that matter: format_compliance (output structure), precision (measurable constraints), actionability (an engineer can implement from this alone).

---name: specificationdescription: Specification-mode prompt scaffold. Use when the decision is made and you need a buildable, testable, reviewable spec. Output is fixed-structure with measurable acceptance criteria. Never re-argues the premise. Invoke with /specification.---# Specification ModeLoad the full template from `~/projects/animus/packages/forge/prompts/modes/specification.md` and use it as the structural contract.## Process1. **Gather INPUTS from the user.** If any are missing, ask before producing the spec. Do not fill gaps with assumptions — that's a rubric-grade failure mode. Required slots: - `artifact` — the thing being specified (API, module, workflow, deliverable) - `objective` — what it must do, one sentence - `constraints` — explicit + measurable (e.g. "p95 latency < 200ms", not "fast") - `interfaces` — inputs consumed, outputs emitted (types, schemas) - `acceptance` — how we know it's done (test names, observable behaviors) - `evidence base` — prior art, reference implementations - `exclusions` — explicitly out of scope2. **Produce the spec in OUTPUT FORMAT order** from specification.md: 1. Summary (2-3 sentences) 2. Requirements (MUST / MAY / MUST NOT) 3. Constraints (each with a measurement method) 4. Interfaces (typed schemas, error cases) 5. Acceptance criteria (falsifiable) 6. Out of scope (explicit) 7. Open questions (labeled, decisions NOT injected)3. **Honor FAILURE CONDITIONS** — self-check before emitting: - Any untestable requirement ("should be fast") → rewrite with a threshold - Any interface without error-case behavior → add it - Any exploratory language ("we could", "maybe") → you're in the wrong mode - Any implementation-detail leak in acceptance → replace with observable behavior## Anti-patternDo not re-litigate the decision. If the user prompts with "but what if we did X instead?", stop and tell them to run `/evaluation` to re-open the decision. Specs get weaker every time they defend their own premise.## Build-mode goal-loop (code/build artifacts ONLY)If the `artifact` being specified is code/build (not a spec for non-code work), ARM the goal-loop by writing a `.goal-active` sentinel at the repo root with `mode: armed` — advisory only: it surfaces the objective each turn but does **not** start autonomous looping. Full engagement happens at `/production`.```objective: <objective, one line>stop_condition: <acceptance summary, or "TBD at production">budget_ceiling_usd: 10turn_ceiling: 25turns: 0spent_usd: 0mode: armedstarted_at: <ISO8601>```Ensure `.goal-active` is git-ignored. Clear it via `/exploration`, `/evaluation`, or `/goal clear`.## Scoring```bashanimus-forge eval run <suite> --rubric code-edit --prompt-version specification-v1```For non-code specs, author a custom rubric in `~/projects/animus/packages/forge/rubrics/`. Weights that matter: `format_compliance` (output structure), `precision` (measurable constraints), `actionability` (an engineer can implement from this alone).

Frequently asked questions