Przejdź do treści
Biblioteka skilli
Programowanie · Przegląd i audyt

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.

Licencja
MIT
Ostatnia zmiana repozytorium
27.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
2
Przestarzałość

Brak sygnałów. Repozytorium zmienione 27.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

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

  1. Cost
  2. Setup
  3. Preconditions — decide these BEFORE spawning
  4. Spawning the auditor
  5. Waiting for the report
  6. When the report arrives
  7. Dry run
  8. When CCC is down
  9. What this is not
Sekcje z nagłówków SKILL.md, w oryginale · 106 linii, 982 słów
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

RepozytoriumWynikLicencja
Ta strona · amirfish1/claude-command-center100MIT
gtapps/hermitd100MIT
gtapps/hermitd100MIT

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.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.