/doc-updates

name: doc-updates
description: Updates documentation after code changes with quality gates, slop detection, and accuracy checks. Use when code changes require corresponding doc updates.
alwaysApply: false
category: artifact-generation
tags:
- documentation
- readme
- adr
- docstrings
- writing
- consolidation
- debloat
tools: []
complexity: medium
model_hint: standard
estimated_tokens: 1200
progressive_loading: true
modules:
- modules/adr-patterns.md
- modules/directory-style-rules.md
- modules/accuracy-scanning.md
- modules/consolidation-integration.md
- modules/capabilities-sync.md
dependencies:
- sanctum:git-workspace-review
- imbue:proof-of-work
- scribe:slop-detector
- scribe:doc-generator
optional_dependencies:
- elements-of-style:writing-clearly-and-concisely

Table of Contents

• [When to Use](#when-to-use)
• [Required TodoWrite Items](#required-todowrite-items)
• [Step 1: Collect Context](#step-1-collect-context-context-collected)
• [Step 2: Identify Targets](#step-2-identify-targets-targets-identified)
• [Step 2.5: Check for Consolidation](#step-25-check-for-consolidation-consolidation-checked)
• [Step 3: Apply Edits](#step-3-apply-edits-edits-applied)
• [Step 4: Enforce Guidelines](#step-4-enforce-guidelines-guidelines-verified)
• [Step 4.25: AI Slop Detection](#step-425-ai-slop-detection-slop-scanned)
• [Step 4.75: Sync Capabilities Documentation](#step-475-sync-capabilities-documentation-capabilities-synced)
• [Step 5: Verify Accuracy](#step-5-verify-accuracy-accuracy-verified)
• [Step 6: Preview Changes](#step-6-preview-changes-preview)
• [Exit Criteria](#exit-criteria)
• [Flags](#flags)

Documentation Update Workflow

When To Use

Use this skill when code changes require updates to the README, plans, wikis, or docstrings. Run `Skill(sanctum:git-workspace-review)` first to capture the change context.

System Capabilities

The documentation update workflow includes several specialized functions. It identifies redundancy through consolidation detection and enforces directory-specific style rules, with strict limits for `docs/` and more lenient ones for the `book/` directory. The system also verifies the accuracy of version numbers and component counts and integrates with the LSP for semantic documentation verification in supported versions of Claude Code.

When NOT To Use

• README-specific updates - use update-readme instead
• Complex multi-file consolidation - use doc-consolidation

Required TodoWrite Items

1. `doc-updates:context-collected` - Git context + CHANGELOG review 2. `doc-updates:targets-identified` 3. `doc-updates:consolidation-checked` (skippable) 4. `doc-updates:edits-applied` 5. `doc-updates:guidelines-verified` 6. `doc-updates:slop-scanned` - AI marker detection via scribe 7. `doc-updates:plugins-synced` - plugin.json ↔ disk audit 8. `doc-updates:capabilities-synced` - plugin.json ↔ documentation sync 9. `doc-updates:accuracy-verified` 10. `doc-updates:preview`

Step 1: Collect Context (`context-collected`)

• Validate `Skill(sanctum:git-workspace-review)` has been run.
• Use its notes to understand the delta.
• Identify the features or bug fixes that need documentation updates.

**CHANGELOG Reference** (critical for version sync):

# Check recent CHANGELOG entries for undocumented features
head -100 CHANGELOG.md

# Compare documented version vs plugin versions
grep -E "^\[.*\]" CHANGELOG.md | head -3
for p in plugins/*/.claude-plugin/plugin.json; do
    jq -r '"\(.name): \(.version)"' "$p"
done | head -5

Cross-reference CHANGELOG entries against:

• `book/src/reference/capabilities-reference.md` - All skills/commands/agents
• Plugin documentation in `book/src/plugins/` - Per-plugin docs
• Plugin READMEs - Quick reference docs

Step 2: Identify Targets (`targets-identified`)

• List the relevant files from the scope across all documentation locations:
• `docs/` - Reference documentation (strict style)
• `book/` - Technical book content (lenient style)
• `README.md` files at project and plugin roots
• `wiki/` entries if present
• Docstrings in code files
• Prioritize user-facing documentation first, then supporting plans and specifications.
• When architectural work is planned, confirm whether an Architecture Decision Record (ADR) already exists in `wiki/architecture/` (or wherever ADRs are located).
• Add missing ADRs to the target list before any implementation begins.

Step 2.5: Check for Consolidation (`consolidation-checked`)

Load: `@modules/consolidation-integration.md`

**Purpose**: Detect redundancy and bloat before making edits.

**Scan for:**

• Untracked reports (ALL_CAPS *_REPORT.md, *_ANALYSIS.md files)
• Bloated committed docs (files exceeding 500 lines in docs/, 1000 in book/)
• Stale files (outdated content that should be deleted)

**User approval required before:**

• Merging content from one file to another
• Deleting stale or redundant files
• Splitting bloated files

**Skip options:**

• Use `--skip-consolidation` flag to bypass this phase
• Select specific items instead of processing all

**Exit criteria**: User has approved/skipped all consolidation opportunities.

Step 3: Apply Edits (`edits-applied`)

• Update each file with grounded language: explain what changed and why.
• Reference specific commands, filenames, or configuration options where possible.
• For docstrings, use the imperative mood and keep them concise.
• For ADRs, see `modules/adr-patterns.md` for complete template structure, status flow, immutability rules, and best practices.

Step 4: Enforce Guidelines (`guidelines-verified`)

Load: `@modules/directory-style-rules.md`

Style Enforcement

Maintain consistent documentation by applying directory-specific rules. The system checks for and removes filler phrases such as "in order to" or "it should be noted" and ensures that no emojis are present in the body text of technical documents. Use grounded language with specific references rather than vague claims, an