doc-style-trace

Audits closed tasks against documentation by tracing code-only branches for missing text updates.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill doc-style-trace-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doc-style-trace
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/doc-style-trace
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill doc-style-trace-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing documentation from the text side only finds stale statements, not missing ones. This Skill runs a reverse pass over closed tasks to detect work that shipped code without ever updating the documentation that should describe it. ## Core Features & Use Cases - Machine-Computed Selection Sign: Uses git merge history and diff commands to select branches that added code but touched no Markdown files, avoiding error-prone hand-written path lists. - Sample Partitioning and Cross-Checks: Splits the selected sample into parts by the narrowest task area label, with comm-based recount commands to find tasks nobody reviewed or that were reviewed twice. - Three-Outcome Classification: Judges each task as needing no trace, having a trace in a rule/pattern/spec, or having no trace (the finding), and routes findings into the correct documentation layer. - Use Case: After a documentation review wave yields few findings, run this reverse pass over recently merged task branches to uncover techniques that were applied in code but never written down anywhere. ## Quick Start Run a reverse documentation-completeness pass over the tasks closed since the last release and report which ones left no trace in the docs.

Frequently Asked Questions about doc-style-trace

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find tasks that changed code but never updated documentation?

List merge commits with git log --merges and grep for task branch names, then run git diff --name-only between the merge parents. Code is everything that is not .md; text is any .md outside archives and task folders. Branches with code but no text form the audit sample.

Why does reviewing documentation text miss undocumented work?

A text-side review only judges statements that exist; a statement that was never written is invisible to it. Reviewing from the work side finds far more issues because most findings land where there is no text at all, not where text is stale.

How should a large audit sample be split into review parts?

Assign each task to a part by its narrowest area label, fixing one narrowing order for the whole pass. Tasks with no area label fall into no part and must be assigned by hand, with the decision recorded so recounts do not flag them as unread.

What counts as a finding in a documentation trace audit?

Each task has three outcomes: needs no trace (one-off technique), has a trace (a statement exists in a rule, pattern, or spec, even if added by a later task), or has no trace, which is the finding. Findings are routed to the layer they belong to.

When should code be edited during a documentation audit?

Code is not edited during the pass; if wrong code is found, a separate task is filed and the pass continues. The only exception is what describes the audited rule itself, such as a check header comment or a test title carrying a scenario identifier.