AgentSkillsCN

documentation-quality-assurance

开展系统的文档审计、漂移检测、事前验证,以及多轮次的质量管控流程。

SKILL.md
--- frontmatter
name: "documentation-quality-assurance"
description: "Systematic documentation audit, drift detection, preflight validation, and multi-pass quality pipelines"
metadata:
  inheritance: inheritable

Documentation Quality Assurance

Prevent documentation rot through systematic audits, automated validation, and pipeline-enforced quality gates.

Scope: Inheritable skill. Covers drift detection, preflight validation, count elimination, link integrity, 5-pass quality pipeline, staleness detection, and large-project organization.

Complements: The Documentarian agent uses this skill as its knowledge foundation. This skill is the "what" — the agent is the "who".

The Count Problem

Hardcoded counts in documentation drift silently:

Document SaysRealityImpact
"109 skills"116 skills (6 added)Undermines credibility
"7 agents"8 agents (1 added)Users miss new capability
"28 instructions"30 instructionsStale architecture picture

Count Elimination Rules

Instead ofWriteWhy
"Alex has 109 skills""Alex has N skills" (computed)Auto-correct
"We support 7 agents""See Agent Catalog for current list"Delegate to source
Inline numberCross-reference to canonical sourceSingle source of truth

Canonical Count Sources

When a count is needed, always derive it from the file system:

MetricSourceMethod
Skill count.github/skills/Count subdirectories
Agent count.github/agents/Count *.agent.md files
Instruction count.github/instructions/Count *.instructions.md files
Prompt count.github/prompts/Count *.prompt.md files
Muscle count.github/muscles/Count script files

Docs-as-Architecture

Documentation is a load-bearing part of the system, not a separate artifact:

PrincipleMeaning
Docs are codeSame review rigor as source code
Docs have testsPreflight validation catches errors
Docs have dependenciesCross-references create a dependency graph
Docs can breakStale docs actively mislead users
Docs need maintenanceSchedule regular audits like code refactoring

Document Header Pattern

Comprehensive Metadata Headers

Operational documentation (regression checklists, deployment guides, QA procedures, release workflows) should include comprehensive headers that provide complete context at-a-glance.

Minimal Header (4 lines) — Insufficient:

markdown
**Date**: 2026-02-14
**Status**: In Progress
**Purpose**: Verify v5.7.1 UI features
**Method**: Install and test

Enhanced Header (10+ lines) — Comprehensive:

markdown
**Version**: 5.7.1
**Date**: 2026-02-14
**Status**: ⚠️ PENDING UI VERIFICATION — WebP avatars regenerated, awaiting restart + testing
**Testing Mode**: CP2 Contingency (Local Install)
**VSIX Size**: 9.44 MB (426 files)
**Key Changes**: Enterprise auth removed, WebP avatars optimized (144×144, 92% reduction)

**Purpose**: Local install verification of all v5.7.1 visual identity + UI features
**Method**: Install VSIX locally, restart VS Code, test in current workspace (CP2 contingency)
**Expected Outcome**: All 9 test sections pass → DoD criterion #4 complete → Ready to publish

Header Field Guidelines

FieldUse ForExample
VersionSoftware version being documented5.7.1, v3.2.0-beta
DateISO format date of creation/update2026-02-14
StatusCurrent state with emoji for scanning⚠️ PENDING, ✅ COMPLETE, 🚧 IN PROGRESS
Testing ModeValidation approach or environmentCP2 Contingency (Local Install), F5 Extension Host, Production
Size/ScopePackage size, file count, or metrics9.44 MB (426 files), 3 breaking changes, 86 tests
Key ChangesWhat's different in this versionEnterprise auth removed, WebP optimized
PurposeWhy this document existsOne sentence explaining the goal
MethodHow the task will be performedStep-by-step approach or workflow
Expected OutcomeSuccess criteriaWhat "done" looks like

Rule: Include enough metadata that anyone can understand the document's context without reading the body. Operational docs reviewed during incidents need at-a-glance clarity.

5-Pass Quality Pipeline

Run these passes in sequence on any document suite:

PassFocusCatches
1. BrandVoice, tone, naming consistency"Copilot" vs "Alex", passive voice, jargon
2. ArchitectureStructural accuracy, counts, versionsStale numbers, outdated diagrams
3. Cross-ReferenceLink integrity, orphan filesBroken links, unreferenced docs
4. LintFormatting, markdown validityBad tables, broken code blocks
5. ConsolidationRedundancy, overlap, merge candidatesTwo docs covering same topic

Rule: Don't merge passes — each pass has a single focus. Multi-focus reviews miss more than single-focus reviews applied sequentially.

Preflight Validation

Automated Checks

Run before every release or documentation change:

powershell
# Example preflight validation script
function Test-DocQuality {
    $errors = @()
    
    # Check 1: All markdown links resolve
    Get-ChildItem -Recurse -Filter "*.md" | ForEach-Object {
        $content = Get-Content $_.FullName -Raw
        $links = [regex]::Matches($content, '\[([^\]]+)\]\(([^)]+)\)')
        foreach ($link in $links) {
            $target = $link.Groups[2].Value
            if ($target -notmatch '^https?://' -and $target -notmatch '^#') {
                $resolved = Join-Path (Split-Path $_.FullName) $target
                if (-not (Test-Path $resolved)) {
                    $errors += "Broken link in $($_.Name): $target"
                }
            }
        }
    }
    
    # Check 2: No orphan files in docs folder
    # Check 3: Required sections present in each doc type
    # Check 4: Version strings match package.json
    
    return $errors
}

Pre-Implementation Cross-Reference Sweep

Before adding any new file, check what already references the concept:

  1. Grep for the concept name across all docs
  2. Identify which files will need updating
  3. Create the new file AND update all references in a single commit

Anti-pattern: Creating a new skill/agent and updating only one reference document. Every catalog, index, and count needs updating simultaneously.

Link Integrity

Link Audit Protocol

CheckHowFrequency
Internal links resolvePath validation against file systemEvery commit
Anchor links work#heading matches actual heading slugsEvery commit
External links aliveHTTP HEAD request (batch, rate-limited)Weekly/monthly
Orphan file detectionFiles not referenced by any other fileEvery release
Circular referencesGraph traversal (A→B→C→A)Quarterly

Orphan Detection

powershell
# Find markdown files not referenced by any other markdown file
$allMd = Get-ChildItem -Recurse -Filter "*.md" | Select-Object -ExpandProperty Name
$referenced = @()
Get-ChildItem -Recurse -Filter "*.md" | ForEach-Object {
    $content = Get-Content $_.FullName -Raw
    $links = [regex]::Matches($content, '\]\(([^)]+\.md)')
    foreach ($link in $links) {
        $referenced += Split-Path $link.Groups[1].Value -Leaf
    }
}
$orphans = $allMd | Where-Object { $_ -notin $referenced }

Staleness Detection

Last Validated Dates

Add validation dates to critical documents:

markdown
<!-- Last Validated: 2026-02-12 by Documentarian audit -->

Staleness Tiers

TierThresholdAction
Fresh< 30 days since validationNone
Aging30-90 daysFlag for review
Stale90-180 daysMandatory review before next release
Expired> 180 daysConsider archival or major rewrite

Drift Detection During Maintenance

During regular maintenance cycles (meditation, dream, release prep):

  1. Compare document claims against current reality
  2. Flag any numeric drift (counts, versions, dates)
  3. Check if referenced files still exist
  4. Verify code examples still compile/execute
  5. Update Last Validated timestamp after review

Large Project Organization

15+ File Threshold

When a documentation folder exceeds 15 files, introduce numbered chapter folders:

code
docs/
├── 01-getting-started/
│   ├── installation.md
│   ├── quick-start.md
│   └── configuration.md
├── 02-architecture/
│   ├── overview.md
│   ├── components.md
│   └── data-flow.md
├── 03-operations/
│   ├── deployment.md
│   ├── monitoring.md
│   └── troubleshooting.md
└── README.md              # Index/TOC

Rules:

  • Numbered prefixes ensure consistent ordering across all tools
  • Each chapter folder has 3-7 files (not 1, not 20)
  • Root README.md serves as table of contents with links to all sections
  • Flat structure is fine for < 15 files

Multi-Audience Documentation

Audience Matrix

Every doc suite serves multiple readers:

AudienceNeedsFormat Preference
New usersQuick start, screenshots, examplesTutorial (step-by-step)
Experienced usersReference, API, configurationReference (lookup)
ContributorsArchitecture, conventions, review processHow-to guides
AI agentsStructured data, clear rules, no ambiguityJSON > prose, tables > paragraphs

Rule: Each document should declare its audience. A document trying to serve all audiences well serves none of them well.

Ship First, Document After (Threshold)

Document TypeWhen to Write
User-facing READMEBefore release
API referenceWith the API code
Architecture docsWhen design stabilizes
Internal notesAfter shipping (retrospective)

Anti-pattern: Blocking a release to write perfect docs. Ship with minimal docs (README + quick start), then iterate.

Doc Audit Checklist

Run this 7-item checklist for any documentation review:

#CheckMethod
1All links resolveAutomated link checker
2No hardcoded countsGrep for common count patterns
3Version strings currentCompare against package.json/CHANGELOG
4Code examples executeCopy-paste test critical examples
5File references existVerify every referenced file path
6No orphan filesCross-reference scan
7Consistent terminologySearch for variant spellings/names

CHANGELOG Best Practices

PracticeWhy
One entry per user-visible changeUsers scan, not read
Link to relevant docs/issuesTraceability
Group by: Added, Changed, Fixed, RemovedConsistent scan pattern
Version header matches package.jsonNo version drift
Date in ISO format (YYYY-MM-DD)Unambiguous globally
Most recent version at topUsers want latest first