agentleFS
martincjarvismartincjarvis/development-skills/skills/documentation-as-code/SKILL.md

documentation-as-code

Skill4 starsChanged 10 months agoMITView on GitHub

Use when user creates/modifies/reviews documentation (Markdown, ADRs, plans, READMEs). Applies same rigor as code with lint, spell, format validation, review processes, and CI automation.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    P1 Quality & Correctness: - Treat documentation with same rigor as source code.

    line 13
  2. Distinctive:

    Add CI validation (fail PR if validation fails)

    line 33
  3. Distinctive:

    Run all validation before completion

    line 35
  4. Distinctive:

    When documenting doc-only verification, post evidence like:

    line 84
  5. Distinctive:

    Create incremental cleanup plan

    line 120

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Documentation as Code

Overview

P1 Quality & Correctness - Treat documentation with same rigor as source code.

REQUIRED: superpowers:verification-before-completion

Cross-references: automated-standards-enforcement, ci-cd-conformance

When to Use

  • Creating/modifying Markdown, ADRs, plans, READMEs
  • Adding API documentation, architecture decisions
  • PR includes documentation changes

Core Workflow

  1. Announce skill and scope
  2. Configure validation:
    • markdownlint (Markdown Linting)
    • cSpell (Spell Checking)
    • link-check for broken links
  3. Enforce templates (Templates)
  4. Add CI validation (fail PR if validation fails)
  5. Define review expectations
  6. Run all validation before completion

Quick Reference

CheckToolEnforcement
FormattingmarkdownlintPre-commit, CI
SpellingcSpellPre-commit, CI
Linksmarkdown-link-checkCI
StructureTemplate validationReview

See Validation Configuration for setup.

Verification Commands for Doc-Only Changes

For documentation-only changes, use these commands to verify quality before completion:

Local Verification

# Markdown formatting check
npm run lint:md

# Spell check
npm run spell

# Both checks (combined command)
npm run validate:docs

Specific File Validation

# Check single file
npx markdownlint-cli2 docs/README.md

# Check documentation directory
npx markdownlint-cli2 "docs/**/*.md"

# Spell check specific files
npx cspell "docs/**/*.md" --no-progress

# Link validation (requires configuration)
npx markdown-link-check docs/README.md

Evidence Capture for Issue Comments

When documenting doc-only verification, post evidence like:

## Verification

- [x] `npm run lint:md` passed
- [x] `npm run spell` passed
- [x] All links verified (no broken references)
- Link validation output: [CI check details](link-to-workflow-run)

Brownfield Baseline Verification

For existing docs without validation:

# Capture baseline violations for documentation
npm run lint:md > lint-baseline.txt 2>&1
npm run spell > spell-baseline.txt 2>&1

# Document findings in baseline file
echo "## Baseline Issues Identified
- Markdown formatting issues: $(wc -l < lint-baseline.txt)
- Spelling issues: $(wc -l < spell-baseline.txt)
" > docs/validation-baseline.md

Key Point: For doc-only changes, verification evidence is process-only (analytical). Link to CI output or command results, not commit SHAs.

Brownfield Approach

  1. Run baseline validation
  2. Document existing issues
  3. Suppress existing violations (Baseline Strategy)
  4. Enforce strict validation on new/modified docs only
  5. Create incremental cleanup plan

Red Flags - STOP

  • "Content matters, not formatting"
  • "Can fix typos later"
  • "Template is optional"
  • "Existing docs aren't validated"

All mean: Apply skill, document exceptions in baseline.

Rationalizations Table

ExcuseReality
"Content matters, not formatting"Poor formatting reduces readability
"Can fix typos later"Spell check takes seconds, prevents embarrassment
"Template is a guideline"Templates ensure consistency and completeness
"Better than no documentation"Low-quality docs can mislead worse than none

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.