doc-drift
Skill13 starsChanged 7 months agoMITView on GitHub
Detects documentation drift after structural changes. Dispatches parallel specialist reviewers and auto-fixes. Triggers on "check my docs", "audit docs", "doc drift", "check doc drift", or auto from post-implementation when tracked categories change.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- gr219/OpenBA-Kittheir own version, first seen Oct 25, 2026
- spmtitsolution/OpenBA-Kittheir own version, first seen Oct 20, 2026
- AlexZio00/sovereign-skillstheir own version, first seen Oct 9, 2026
- Kyungjong-kim/claude-code-harnesstheir own version, first seen Jun 17, 2026
- tykisgod/quick-questiontheir own version, first seen Mar 28, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- AlexZio00/sovereign-skills★ 157same name
- spmtitsolution/OpenBA-Kit★ 38same name
- tykisgod/quick-question★ 12same name
- gr219/OpenBA-Kit★ 0same name
- Kyungjong-kim/claude-code-harness★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
- agent-auditSkill
- codebase-auditSkill
- commitSkill
- design-and-specSkill
- dispatching-parallel-agentsSkill
- execution-planningSkill
- explain-codeSkill
- post-implementationSkill
- pushSkill
- python-auditSkill
- receiving-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- terraform-auditSkill
- test-driven-developmentSkill
- trace-codeSkill
- typescript-auditSkill
- verification-before-completionSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 12 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
When triggered from post-implementation Step 3:
- Distinctive: line 16
Run git status --porcelain to get changed files
- Very specific: line 17
Read docs-structure.md (location: ${CWD}/.kiro/steering/docs-structure.md)
- Very specific: line 18
If no docs-structure.md found → SKIP auto mode.
- Distinctive: line 19
Check if any changed files are in tracked categories (from docs-structure.md)
- Distinctive: line 20
If no tracked-category changes → SKIP.
- Distinctive: line 21
If tracked-category changes found → proceed to Detection phase
- Distinctive: line 25
When triggered manually ("check my docs", "audit docs", "doc drift"):
- Distinctive: line 29
If found → proceed to Detection phase with targeted + discovery passes
- Distinctive: line 30
If NOT found → proceed to Detection phase with full heuristic scan (use filesystem state as ground truth)
- Very specific: line 31
After completing, if no docs-structure.md exists, offer: "For more precise doc-drift detection in this project, I can generate a …
- Very specific: line 82
If docs-structure.md exists, scan remaining *.md files not in the enumeration table:
- Distinctive: line 92
If no new enumeration docs were discovered, report: "Discovery pass: no new enumeration docs found outside docs-structure.md."
- Distinctive: line 93
Never auto-update docs-structure.md — suggest only
- Distinctive: line 97
After all 3 specialists return:
- Distinctive: line 110
In auto mode (post-implementation): do NOT run a separate sanity check — post-implementation Step 4 (auto-review) handles verification
- Very specific: line 111
In on-demand mode: after fixes are applied, run bash ~/.kiro/hooks/doc-consistency.sh as a quick sanity check.
- Very specific: line 121
After execution completes, create ~/.kiro/logs/ if it doesn't exist (mkdir -p ~/.kiro/logs), then append to ~/.kiro/logs/doc-drift.md:
≈ “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.
Files
Doc Drift
Detect and fix documentation that has drifted from the current state of the codebase.
Announce at start: "Running doc-drift detection."
Trigger Gate (auto mode)
When triggered from post-implementation Step 3:
- Run
git status --porcelainto get changed files - Read
docs-structure.md(location:${CWD}/.kiro/steering/docs-structure.md) - If no
docs-structure.mdfound → SKIP auto mode. Log: "No docs-structure.md found — auto-trigger disabled. Run doc-drift on-demand to generate one." - Check if any changed files are in tracked categories (from docs-structure.md)
- If no tracked-category changes → SKIP. Log: "No tracked-category changes detected."
- If tracked-category changes found → proceed to Detection phase
On-Demand Mode
When triggered manually ("check my docs", "audit docs", "doc drift"):
- Skip the git status gate — always proceed regardless of whether files have changed. The user explicitly asked for a check.
- Read
docs-structure.md(location:${CWD}/.kiro/steering/docs-structure.md) - If found → proceed to Detection phase with targeted + discovery passes
- If NOT found → proceed to Detection phase with full heuristic scan (use filesystem state as ground truth)
- After completing, if no
docs-structure.mdexists, offer: "For more precise doc-drift detection in this project, I can generate a.kiro/steering/docs-structure.mdbased on what I found. Want me to create it?"
Detection Phase — 3 Parallel Specialists
Dispatch 3 devops-reviewer instances in parallel. This is not optional — do not collapse into a single pass. Each specialist has a distinct cognitive focus that prevents context fatigue on large doc sets. Label each specialist's findings clearly in the output (e.g., "### Structural Findings", "### Prose Findings", "### Numeric Findings").
Specialist 1: Structural/Tabular
Briefing: "Review these docs for structural completeness. Focus ONLY on: ASCII architecture diagrams, assignment matrices, policy tables, directory/structure trees. For each, verify all current artifacts from [tracked categories] are represented. Report missing entries."
Receives:
- List of changed files (added/removed)
- Docs assigned: those with enumeration types matching structural patterns
- Current filesystem listing of tracked category directories
Specialist 2: Prose/Content
Briefing: "Review these docs for prose accuracy. Focus ONLY on: category headings that should list new items, deny-list mentions that should include new agents, agent/skill enumerations in running text, version/migration notes. Report stale prose."
Receives:
- List of changed files (added/removed)
- Docs assigned: those with enumeration types matching prose patterns
- Names and descriptions of new/removed artifacts
Specialist 3: Metadata/Numeric
Briefing: "Review these docs for numeric accuracy. Focus ONLY on: artifact counts and totals, CHANGELOG completeness (cross-reference delivered artifacts against version entry), skill/agent baseline counts, version references. Also run bash ~/.kiro/hooks/doc-consistency.sh and include its output."
Receives:
- List of changed files (added/removed)
- Docs assigned: those with enumeration types matching numeric patterns
- Output of
doc-consistency.sh - Current actual counts from filesystem
Specialist Output Format
Each specialist returns structured findings, clearly labeled by specialist name:
### Structural Findings (or Prose Findings, or Numeric Findings)
- file: <path>
- line: <number or range>
- category: <structural|prose|numeric>
- what's stale: <description>
- suggested fix: <concrete change>
- confidence: <high|medium|low>This labeling is required for the run stats log — per-specialist finding counts must be accurate.
Discovery Pass (runs after targeted pass — MANDATORY)
If docs-structure.md exists, scan remaining *.md files not in the enumeration table:
- Flag any that reference 3+ items from a tracked category
- Always include a dedicated "Steering File Updates" section at the end of the report with:
## docs-structure.md Updates Suggested The following docs were found to enumerate tracked-category items but are NOT in your docs-structure.md: - <path> — enumerates: <what it lists> - <path> — enumerates: <what it lists> Add these to `.kiro/steering/docs-structure.md` for future targeted detection. - If no new enumeration docs were discovered, report: "Discovery pass: no new enumeration docs found outside docs-structure.md."
- Never auto-update docs-structure.md — suggest only
Consolidation Phase
After all 3 specialists return:
- Merge findings, deduplicate (same file + same line = keep highest confidence)
- Group findings by file
- Classify each finding:
- Auto-fix: numeric count updates, matrix row/column additions, tree node additions, table row additions
- Present for approval: prose rewrites, architecture diagram overhauls, CHANGELOG narrative
Remediation Phase
For auto-fix findings:
- Dispatch devops-docs instances in parallel — one per file (prevents merge conflicts)
- Each devops-docs instance receives: the file path + all findings for that file + suggested fixes
- In auto mode (post-implementation): do NOT run a separate sanity check — post-implementation Step 4 (auto-review) handles verification
- In on-demand mode: after fixes are applied, run
bash ~/.kiro/hooks/doc-consistency.shas a quick sanity check. If it reports drift, flag for user.
For present-for-approval findings:
- Show to user with file, line, what's stale, and suggested fix
- User approves/dismisses each
- Approved items → dispatch devops-docs (same parallel-by-file pattern)
- Dismissed items → count as false positives in log
Run Stats Logging
After execution completes, create ~/.kiro/logs/ if it doesn't exist (mkdir -p ~/.kiro/logs), then append to ~/.kiro/logs/doc-drift.md:
## YYYY-MM-DD — <project path>
- Trigger: <post-implementation | on-demand>
- Steering: <path to docs-structure.md used | heuristic mode>
- Docs checked: N (list file names)
- Changed files: <list>
- Structural specialist: N findings (brief list)
- Prose specialist: N findings (brief list)
- Numeric specialist: N findings (brief list)
- Auto-fixed: N/total
- Flagged for user: N (reasons)
- False positives: N (user-dismissed + reviewer-rejected)
- Discovery pass: <N new enumeration docs suggested | none>
- Drift age: <when drift was likely introduced, if detectable from git log or CHANGELOG>Self-Audit Checkpoint
At 1-3 months after deployment, review ~/.kiro/logs/doc-drift.md:
- Specialist consistently finding 0 issues → consider removing
- Specialist with high false-positive rate → refine prompt or remove
- Two specialists finding same things → merge them
Reduce specialist count only with evidence from the log.
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
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.

