How do I install the Spec Document skill?

Run npx skillmds@latest add ainova-systems/spec-document 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 Spec Document safe to use?

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

Which AI agents work with Spec Document?

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 Spec Document free to use?

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

Who published Spec Document?

ainova-systems (@ainova-systems) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Spec Document by ainova-systems — Agent Skill

Name: Spec Document
Author: ainova-systems

File contents

Write a Docs Artifact

Maintain the knowledge substrate: add or correct a feature baseline, record a numbered business rule, add a glossary term, update the domain model, or refresh the architecture map. Drafts from code, marked confirmed/inferred; the owner approves. This is the engine the spec lifecycle uses to keep docs in sync (spec-create/spec-close/spec-cancel/spec-execute Phase D call into these conventions); it also runs standalone for ad-hoc doc maintenance.

Resolve location and template

Learn from the project (read two sibling docs in the target folder; mimic, don't invent) -> profile (features_dir / rules_dir / decisions_dir / ...) -> ai-first-docs default. The type sets the template (references/doc-types.md):

feature -> features/<feature>.md: what it does TODAY + EARS criteria; business language, no code / types / class-names.
rule -> rules/R-NNN-<slug>.md: one atomic, numbered, testable business rule, paired 1:1 with a contract test.
glossary -> a term in glossary.md: one precise meaning, relations to other terms.
model -> model.md: domain aggregates and invariants.
architecture -> architecture/<...>: condensed arc42 / dependency-map / golden-path, container/component level.

Steps

Search first. A doc for this topic may exist - update it in place, never fork a parallel doc. One concept, one canonical doc.
Read two siblings to match structure and tone.
Draft from code as ground truth; mark each claim confirmed / inferred. Never state intent the code does not show - business rules in config, database rows, or runtime extensions are invisible to static drafting; flag them, don't fabricate.
Naming: kebab-case, R-NNN / NNNN- zero-padded, one concept one name.
Owner gate: present the draft; it stays inferred until the owner confirms.

Verify

One canonical doc per concept; the type template followed; every claim confirmed or marked inferred; cross-references resolve.

Scope / hand-off

A code change (not just docs) - spec-create. Decisions - spec-decision. Drift detection - spec-audit-docs.

Constraints

Never fork a parallel doc - update the canonical one.
Never fabricate a rule or behavior the code does not show; mark inferred and flag config / DB / runtime intent for functional tests.

---name: spec-documentdescription: Writes or updates one documentation artifact - feature, rule, glossary, model, or architecture - from what the code actually does.---# Write a Docs ArtifactMaintain the knowledge substrate: add or correct a feature baseline, record a numbered business rule, add a glossary term, update the domain model, or refresh the architecture map. Drafts from code, marked confirmed/inferred; the owner approves. This is the engine the spec lifecycle uses to keep docs in sync (`spec-create`/`spec-close`/`spec-cancel`/`spec-execute` Phase D call into these conventions); it also runs standalone for ad-hoc doc maintenance.## Resolve location and templateLearn from the project (read two sibling docs in the target folder; mimic, don't invent) -> profile (`features_dir` / `rules_dir` / `decisions_dir` / ...) -> ai-first-docs default. The type sets the template (`references/doc-types.md`):- **feature** -> `features/<feature>.md`: what it does TODAY + EARS criteria; business language, no code / types / class-names.- **rule** -> `rules/R-NNN-<slug>.md`: one atomic, numbered, testable business rule, paired 1:1 with a contract test.- **glossary** -> a term in `glossary.md`: one precise meaning, relations to other terms.- **model** -> `model.md`: domain aggregates and invariants.- **architecture** -> `architecture/<...>`: condensed arc42 / dependency-map / golden-path, container/component level.## Steps1. **Search first.** A doc for this topic may exist - update it in place, never fork a parallel doc. One concept, one canonical doc.2. **Read two siblings** to match structure and tone.3. **Draft from code as ground truth**; mark each claim `confirmed` / `inferred`. Never state intent the code does not show - business rules in config, database rows, or runtime extensions are invisible to static drafting; flag them, don't fabricate.4. **Naming**: kebab-case, `R-NNN` / `NNNN-` zero-padded, one concept one name.5. **Owner gate**: present the draft; it stays `inferred` until the owner confirms.## Verify- One canonical doc per concept; the type template followed; every claim confirmed or marked inferred; cross-references resolve.## Scope / hand-off- A code change (not just docs) - `spec-create`. Decisions - `spec-decision`. Drift detection - `spec-audit-docs`.## Constraints- Never fork a parallel doc - update the canonical one.- Never fabricate a rule or behavior the code does not show; mark `inferred` and flag config / DB / runtime intent for functional tests.

Frequently asked questions

Spec Document