doc-standards Skill
SkillDocs & knowledgeDocumentation standards workflow for Citum specs, policies, architecture snapshots, guides, and references. Use this skill when creating or updating project documentation and choosing the correct docs directory/template.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the doc-standards Skill skill
What this skill tells your AI
The instructions your AI receives, as published by citum/citum-core in .claude/skills/doc-standards/SKILL.md and read by ahel’s review.
Trigger phrases: "create a spec", "write a design doc", "add a policy", "document this decision", "new architecture doc", "write a spec for", "spec this out", "design doc for", "I need a policy for"
Directory Selection
| Intent | Directory | Template source |
|---|---|---|
| Feature/design specification | docs/specs/ | docs/specs/README.md |
| Active behavioral rule | docs/policies/ | docs/policies/README.md |
| Execution plan or snapshot | docs/architecture/ | date-stamp filename |
| Operational how-to | docs/guides/ | — |
| Reference lookup table | docs/reference/ | — |
Spec Template
# [Feature Name] Specification
**Status:** Draft | Active | Superseded
**Version:** 1.0
**Date:** YYYY-MM-DD
**Supersedes:** (path, if any)
**Related:** (policy, bean, or issue)
## Purpose
One paragraph: what feature this specifies and why.
## Scope
In scope. Explicitly out of scope.
## Design
(Core content — decisions, data models, examples.)
## Implementation Notes
(Non-normative hints, known constraints.)
## Acceptance Criteria
- [ ] Verifiable condition 1
- [ ] Verifiable condition 2
## Changelog
- v1.0 (DATE): Initial version.
Policy Template
# [Policy Name]
**Status:** Active | Superseded
**Version:** 1.0
**Date:** YYYY-MM-DD
**Superseded by:** (path, if Superseded)
**Related:** (spec or CLAUDE.md section)
## Rule
The binding rule in 1–2 sentences. Agents must be able to apply this
without reading further.
## Rationale
Why this rule exists.
## Application
Decision table or flowchart for common scenarios.
## Exceptions
When the rule may be bypassed, and the approval process.
## Changelog
- v1.0 (DATE): Established.
Pre-Commit Validation Checklist
- Correct directory (see table above)
- Frontmatter complete: Status, Version, Date, Related
- Spec: Acceptance Criteria section populated with at least one item
- Policy: Rule section is self-contained (≤2 sentences, agent-readable)
- No broken relative links
- Run
/humanizerif the document is user-facing prose
Feature Design Workflow (Spec-First)
- Create
docs/specs/FEATURE_NAME.mdwith StatusDraftbefore writing code. - Commit the spec. Get it merged/pushed.
- Set Status to
Activein the same commit as the first implementation commit. - Add the spec path to the bean description (
beans update <id> -d "..."). - After the feature ships, update Acceptance Criteria checkboxes.
Registering a New Active Policy
- Create
docs/policies/POLICY_NAME.mdusing the policy template. - Add an entry to
docs/policies/README.mdtable. - If the policy must be loaded by agents on every session, add a reference to CLAUDE.md (Prior Art & Design Documents section or Autonomous Operations).
Signals
- GitHub stars
- 33
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
doc-standards- Source
- github.com/citum/citum-core