docs-drift
/docs-drift
Wykrywa nieaktualną dokumentację: osobna sesja wyciąga sprawdzalne twierdzenia (pola API, flagi CLI, klucze konfiguracji, ścieżki, wersje) i weryfikuje każde z kodem, oceniając ważność rozbieżności.
- Autor
- amirfish1 ↗
- Repozytorium
- claude-command-center ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 27.10.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 2
Brak sygnałów. Repozytorium zmienione 27.10.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Wykrywa nieaktualną dokumentację: osobna sesja wyciąga sprawdzalne twierdzenia (pola API, flagi CLI, klucze konfiguracji, ścieżki, wersje) i weryfikuje każde z kodem, oceniając ważność rozbieżności.
Oryginalny opis (EN)
Use to catch documentation that has silently gone stale — it spawns ONE fresh sibling session via CCC that extracts every checkable factual claim from a doc (API fields, endpoint names, CLI flags, config keys, file paths, version numbers, example commands) and verifies each one against the actual code, reporting each mismatch as a drift with severity. A claim-by-claim audit, not a read-through.
Jak działa
- Cost
- Setup
- Preconditions — decide these BEFORE spawning
- Spawning the auditor
- Waiting for the report
- When the report arrives
- Dry run
- When CCC is down
- What this is not
Podgląd SKILL.md
---
name: docs-drift
description: Use to catch documentation that has silently gone stale — it spawns ONE fresh sibling session via CCC that extracts every checkable factual claim from a doc (API fields, endpoint names, CLI flags, config keys, file paths, version numbers, example commands) and verifies each one against the actual code, reporting each mismatch as a drift with severity. A claim-by-claim audit, not a read-through.
allowed-tools: Bash
---
Docs-drift spawns a single fresh CCC session that treats a doc as a list of
**factual assertions about the code** and checks each one against the source. It
does not follow the docs as a user would — it enumerates the claims (this
endpoint exists, this flag is `--foo`, this response has field `bar`, this
default is `127.0.0.1`, this version is `X.Y.Z`) and greps/reads the code to
confirm or refute each. The output is a drift ledger. It builds on the
spawn/report_to mechanics in the `ccc-orchestration` skill — read that first for
the full Spawn/Inject/Ask API.
## Cost
**1 spawned session.** Each spawn is a real billed session on the user's
kanban — tell the user the count before spawning. Point it at a **bounded** set
of docs (one file, or a section) — "audit all the docs" is a fleet job
(`fleet-lane-dispatch` with a per-doc brief), not one session.
## Setup
```bash
CCC_URL="$(cat ~/.claude/command-center/port.txt 2>/dev/null || echo "${CCC_URL:-http://127.0.0.1:8090}")"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_URL="http://127.0.0.1:8090"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_DOWN=1
```
- (a) Run every CCC curl with the **network sandbox disabled** — the Bash
sandbox blocks loopback and fails spuriously even when CCC is up.
- (b) **URL-encode `repo_path`** in query strings (`+` → `%2B`, space → `%20`).
- (c) Resolve your own session id: `$CLAUDE_SESSION_ID`, else the newest
`*.jsonl` under `~/.claude/projects/<slugified-cwd>/` (see `ccc-orchestration`).
## Preconditions — decide these BEFORE spawning
- **(a) The exact doc(s)** to audit — file paths or a named section. One file or
one section per run; the more bounded, the sharper the ledger.
- **(b) The source of truth** — which code the claims should match (a module, a
set of endpoints, a config schema). If you don't tell it where the truth
lives, it wastes the run hunting.
- **(c) The claim types that matter** for this doc — API response fields, CLI
flags, endpoint paths, config keys/defaults, file paths, version strings,
copy-paste example commands. Naming them focuses the extraction.
## Spawning the auditor
```bash
curl -s -X POST "$CCC_URL/api/sessions/spawn" -H "Content-Type: application/json" -d @- <<'JSON'
{
"prompt": "Audit this doc for drift against the code. DOC: <path or section>. SOURCE OF TRUTH: <module / endpoints / config to check against>. Method: 1) Extract EVERY checkable factual claim the doc makes about the code — endpoint paths, request/response field names, CLI flags, config keys and their stated defaults, file paths, version strings, and any copy-paste example command. Ignore prose, motivation, and opinion; only claims a reader could act on and be wrong. 2) For EACH claim, verify it against the actual code (grep / read the source — do NOT trust the doc). 3) Classify each: MATCH (doc agrees with code), DRIFT (doc contradicts code — wrong field name, renamed flag, changed default, dead endpoint, stale version), or UNVERIFIABLE (could not locate the truth — say why). Report ONLY the DRIFT and UNVERIFIABLE rows as a ledger; give a MATCH count as one summary number. Each drift row: the exact doc quote + line, what the code actually says (with file:line evidence), severity (BROKEN = a reader following this will fail, e.g. dead endpoint or wrong flag / MISLEADING = works but the doc is wrong, e.g. stale default / COSMETIC = typo-level), and the one-line doc patch. Finish with a verdict: is this doc safe to trust as-is, yes or no?",
"repo_path": "/abs/path/to/repo",
"report_to": "<your-session-id>"
}
JSON
```
Omit `"model"` and `"reasoning_effort"`: the server spawn defaults (Settings →
Spawn defaults) apply. Pass either explicitly to keep cost down, with
`"engine"` alongside it, since both are validated per engine (see
`ccc-orchestration` § 2 for the per-engine effort ladders). CCC appends the
return-address footer (`report_to`), so the auditor injects its ledger back to
you when it finishes.
## Waiting for the report
After spawning, **end your turn.** Tell the user an auditor is checking the doc
against the code and give its session id. The ledger arrives by injection
(`report_to`) — do **not** poll or sleep-loop. If it never arrives, check
`GET /api/sessions/spawned` for whether the child is still alive.
## When the report arrives
Turn the ledger into doc fixes:
- **BROKEN** drift is a doc bug that will actively mislead — fix before the next
reader hits it (a dead `/api/*` endpoint, a renamed flag, a wrong required
field). For a public repo these ship the moment you push, so treat them like
code bugs.
- **MISLEADING** — the reader gets through but on wrong information (a stale
default, an old version string); correct the wording.
- **COSMETIC** — polish when convenient.
- **UNVERIFIABLE** rows are their own signal — either the doc is describing
something that no longer exists, or the truth moved; investigate each.
## Dry run
If the arguments contain `dry-run`, print the exact payload — session count (1),
the full auditor prompt with the doc path and source-of-truth filled in, and the
target repo — and POST nothing.
## When CCC is down
If `CCC_DOWN=1` or the spawn curl returns connection refused (exit 7), fall back
to the built-in `Task` tool subagent with the same claim-extraction prompt —
fresh context matters less here than for `dogfood`, because the value is the
systematic cross-check, not naïve eyes. You lose only kanban visibility. Never
pretend the CCC spawn ran.
## What this is not
- Not `dogfood` — that follows the getting-started path as a user and reports
where it stumbles; it only catches drift on the exact steps it walks.
Docs-drift ignores the experience and checks every claim in the doc against the
code, including claims off the happy path. Run `dogfood` to prove the
quickstart works; run `docs-drift` to prove a reference doc is not lying.
- Not `/code-review` — that judges whether the code is right. This assumes the
code is the truth and judges whether the **doc** still matches it.
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · amirfish1/claude-command-center | 100 | MIT |
| gtapps/hermitd | 100 | MIT |
| gtapps/hermitd | 100 | MIT |
Migawka bazy z 28.10.2026 · wersja paczki b8af0e5b8fe2 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 84audit
Audytuje bazę kodu pod kątem rozjazdu między dokumentacją, konfiguracją, kodem i architekturą: weryfikuje każde twierdzenie równoległymi subagentami, ocenia wagę ustaleń i raportuje bez zmian, a naprawę przekazuje dalej. - 100documentation-audit
Audytuje jakość dokumentacji: komentarze w kodzie, dokumentację API, kompletność README i zgodność dokumentów z kodem, oceniając, czy dokumentacja jest dobra i pełna. - 100spec-drift-check
Audytuje brief WP pod kątem rozjazdu z aktualnym kodem: wyciąga twierdzenia, weryfikuje każde i wydaje werdykt PROCEED lub STOP. - 90doc-drift
Sprawdza całą dokumentację względem kodu i wskazuje twierdzenia, które przestały być prawdziwe. - 100docs-sync-audit
Przeprowadza audyt rozjazdu dokumentacji tylko do odczytu dla funkcji, PR, gałęzi, wydania, API, konfiguracji lub CLI, sprawdzając README, przewodniki, dokumentację API, changelogi i przykłady. - 100doc-freshness
Wykrywa rozjazd dokumentacji z kodem, sprzeczne informacje między dokumentami i nieaktualne odwołania, takie jak zepsute linki, usunięte pliki i stare wersje.