Agent skill

Doc-Code Sync Check

by fancyboi999 in fancyboi999/open-tag

Reconciles documentation with code at the end of a change or as a periodic audit, following a repo rule that code changes and doc changes land in one commit.

Apache-2.0Auto-check passedDevelopment

Install Doc-Code Sync Check

skills CLI
$ npx skills add fancyboi999/open-tag --skill doc-sync -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install fancyboi999/open-tag doc-sync --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/fancyboi999/open-tag.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/doc-sync .claude/skills/doc-sync && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
doc-sync
GitHub stars
203
Token cost
~1.7k tokens
SKILL.md length
834 words
Files
1
Skills in repo
1
Repo updated
First seen
Licence
Apache-2.0

At a glance

Reconciles documentation with code at the end of a change or as a periodic audit, following a repo rule that code changes and doc changes land in one commit.

  • Works in 6 steps: Determine the change surface. → Map each changed path against the… → Status single-source rule.… → …
  • Finishing a pull request and confirming every owed doc was updated
  • SKILL.md covers Mode 1 — per-change sync (run… and Mode 2 — periodic full audit…
  • Calls git

What it does

At the end of every change the skill finds the change surface from the git diff against origin/main, then checks each changed path against the doc-sync mapping table kept in AGENTS.md to list the documents the change owes. Examples named in the skill include a database schema snapshot, an architecture codemap, a features checklist, a tech-debt tracker and a changelog entry when the daemon bundle ships.

It also enforces a single-source rule for security and authorization item states, which are meant to live only in docs/authorization.md. A grep command is given to find other documents that mirror those states so they can be removed or pointed at the one source. Documentation that lags behind the code is treated as an unfinished bug.

The skill is written around one repository's layout and file names, so it is most useful there or as a model for similar rules elsewhere. Only the per-change mode is described in detail in the visible text; the periodic drift audit is named in the description.

When your agent uses it

  • Finishing a pull request and confirming every owed doc was updated
  • Auditing a repo for drift between documentation and code
  • Checking whether a schema or route change needs architecture notes
  • Before calling a change done, as the last verification step

Example prompts

  • “Run doc-sync on my branch before I open the PR.”
  • “Audit the docs folder for places where documentation no longer matches the code.”
  • “I changed the database schema. Which docs does this change owe an update to?”

Requirements

  • A git repository with an AGENTS.md doc-sync mapping table
  • Git access to origin/main for the diff

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Determine the change surface.
  2. Map each changed path against the AGENTS.md doc-sync table. Produce the list of
  3. Status single-source rule. Security/authorization item states (F*/C*/IDOR-B*) live
  4. Staleness check on every doc you touched. For each edited doc: file paths it names
  5. Hygiene gates.
  6. Fail loud. In the PR/summary, list: docs updated · docs checked-and-clean ·

What it can do on your machine

Read from SKILL.md and the folder at commit 35d8eee. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Doc-Code Sync Check loads about 1.7k tokens when it runs. Until then it costs about 63 tokens; SKILL.md has 834 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~63
When it runs · the whole SKILL.md, loaded when a task matches
~1.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from fancyboi999/open-tag at commit 35d8eee, republished under its Apache-2.0 licence (© fancyboi999). 834 words, ~1,657 tokens.

Download SKILL.mdSave it as .claude/skills/doc-sync/SKILL.md (or your agent's skills folder).
name
doc-sync
description
Reconcile docs with code after a change (or as a periodic audit). Use before calling any change "done", at the end of every PR, or when asked to audit doc/code drift. Enforces this repo's hard rule: code change = doc change in the same commit.

doc-sync — keep docs and code converged

This repo treats doc lag as an unfinished bug (see AGENTS.md § Doc-sync discipline). This skill is the executable procedure; the canonical mapping table (which change owes which doc) lives in AGENTS.md — read it there, do not copy it here.

This file is canonical at .agents/skills/doc-sync/SKILL.md (.claude/skills/doc-sync is a symlink). The skill itself iterates: when a run shows an instruction here is wrong or misleading, fix it in the same pass, with the run's evidence in the commit message.

Mode 1 — per-change sync (run at the end of every change)

  1. Determine the change surface. git diff --stat origin/main...HEAD (or the staged diff for uncommitted work).

  2. Map each changed path against the AGENTS.md doc-sync table. Produce the list of docs owed by this change. The high-traffic rows:

    • src/db/schema.ts → docs/generated/db-schema.md (hand-maintained snapshot — no generator script exists despite the generated/ dir name; update the table row and any enum lists by hand; prod DB migrates via prod:up → db:push:prod).
    • Routes / CLI subcommands / daemon protocol → ARCHITECTURE.md §II codemap + §IV contracts.
    • Module purpose / boundary / invariant changed → ARCHITECTURE.md §II–IV.
    • Feature completed or modified → FEATURES.md checkbox (checkbox + a short note; long verification narratives belong in the PR, not the checklist).
    • TODO / known drift left behind → docs/tech-debt-tracker.md new entry (next free ID — check the archive too so IDs are never reused).
    • src/daemon/** shipped in the bundle → bump packages/daemon/package.json, cut a GitHub Release, and add the version's CHANGELOG.md entry. Merged ≠ shipped.
  3. Status single-source rule. Security/authorization item states (F*/C*/IDOR-B*) live only in docs/authorization.md §6. Other docs (PLANS, tech-debt I44) may point there but must never mirror per-item states — mirrored lists are how C10 stayed "remaining" for weeks after it was fixed. Detect mechanically, don't trust prose: grep -rnE '\b(C1[0-2]|C[1-9]|B[1-6]|F[0-9]|IDOR)\b' --include='*.md' docs/ *.md | grep -vE 'authorization\.md|docs/exec-plans/|docs/superpowers/' (historical plan/spec records legitimately narrate the states they shipped — the rule polices live docs). A hit naming an item's state (open/fixed/remaining) is a violation; a bare pointer to authorization.md §6 is fine.

  4. Staleness check on every doc you touched. For each edited doc: file paths it names exist; tech-debt I<n> / D<n> references resolve (tracker or archive); counts/enums match code (grep, wc -l — better: drop volatile numbers entirely, per ARCHITECTURE.md's header rule).

  5. Hygiene gates.

    • No personal/machine refs in what this change adds (core belief #9). Grep the added diff lines, not whole files: git diff origin/main -- <files> | grep '^+' | grep -E '~/\.claude|/Users/'. A personal absolute path (/Users/<name>/…) is a violation. Two known non-violations that this grep still surfaces: a generic runtime path that is product behavior (e.g. ~/.claude/skills as Claude CLI's global skills dir), and a tech-debt entry quoting a personal path as the evidence of the debt it records. Judge, don't blind-fail — but never add a new personal path outside those two shapes.
    • Touched src/daemon/prompt.ts? Grep for provider-specific tool names (Read, cat, grep, vision hints) → expect zero hits (code-quality red line).
  6. Fail loud. In the PR/summary, list: docs updated · docs checked-and-clean · drift found but deferred (with its new tech-debt entry ID).

Show full SKILL.md (339 more words)Show less

Mode 2 — periodic full audit (on request / doc-gardening)

Cross-check the status documents against code and each other; they drift fastest:

  1. FEATURES.md — sample every [ ] unchecked line: is the feature actually still missing? (grep the endpoint / CLI verb / component). Unchecked-but-shipped is the most common rot.
  2. docs/PLANS.md — every referenced plan file exists; Active items are still active; completed plans moved to docs/exec-plans/completed/ with their status line updated (a moved plan still saying "merge pending <date>" is half-finished rot).
  3. docs/tech-debt-tracker.md — no duplicate IDs (incl. vs the archive); ⬜/🟡 entries spot-checked against code; newly-✅ entries: move the full row to the archive. The tracker keeps no stub — it holds open items only; cross-references resolve by grepping both files.
  4. docs/authorization.md §6 vs any doc that mentions security items — pointers only, no mirrored states (run the Mode 1 step-3 grep).
  5. ARCHITECTURE.md §II — new substantive modules (>50 lines) present in the codemap. Recipe: git log --since=<last audit> --name-only --diff-filter=A --pretty=format: -- 'src/*' 'web/src/*', then check each surviving non-test file's basename appears in the codemap. Named files exist; CHANGELOG.md's newest version heading (the [Unreleased] section doesn't count) matches packages/daemon/package.json.
  6. Size / density audit — docs must stay maps, not manuals. Line counts hide bloat (long table rows); rank by bytes: git ls-files '*.md' | xargs wc -c | sort -rn | head. For each fat doc, check it against its own stated form rule (FEATURES' "checkbox + short note" header, ARCHITECTURE's "write only what doesn't change often" header) — self-rule violations are the strongest trim mandate. Cut change-history narrative ("the former X was removed…", "before this fix…") and verification evidence — git log and PRs own those. Frozen plan/spec archives of shipped work are deletable (git history retains them); before deleting, grep for inbound references incl. from src/.
  7. README.zh-CN.md parity — diff section structure + bullet counts against README.md; the zh mirror silently misses EN feature edits (drift is one-directional). Small deltas: translate in the same pass. A backlog: open a tech-debt entry.

Report findings with file:line evidence; fix mechanically-safe drift in the same pass, open tech-debt entries for anything needing a decision.

© fancyboi999, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/doc-sync of fancyboi999/open-tag.

Open the folder on GitHubat commit 35d8eee

Compare with similar skills

Doc-Code Sync Check next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Doc-Code Sync Check compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Doc-Code Sync Check this skillfancyboi999/open-tag203—~1.7kAutomated safety check: PassApache-2.0
Sync Docsayutaz/piper-plus220—~1.4kAutomated safety check: PassMIT
Releasejrswab/axe895—~1.4kAutomated safety check: PassApache-2.0
Docs GuardamElnagdy/guard-skills1.3k—~2.1kAutomated safety check: PassMIT
CommitLennartHennigs/Button2565—~562Automated safety check: PassMIT
Qkeymapper Release NotesZalafina/QKeyMapper755—~1.3kAutomated safety check: PassGPL-3.0

Similar skills

  • Sync Docs

    ayutaz/piper-plus

    コミット前にエージェントチームで全ドキュメント (CLAUDE.md / README / CHANGELOG / docs/) を監査し、コード変更に応じて自動更新します。大規模変更時の documentation drift を予防。

    220 GitHub stars~1.4k tokensUpdated today
    DevelopmentAuto-check passed
  • Release

    jrswab/axe

    Prepare code for release (version bumps, changelog, README updates) and create an annotated tag to trigger the GoReleaser workflow.

    895 GitHub stars~1.4k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • Docs Guard

    amElnagdy/guard-skills

    Checks generated or edited documentation against the source code, flagging invented symbols, outdated samples and unverifiable claims before publishing.

    1.3k GitHub stars~2.1k tokensUpdated 3 mo ago
    DevelopmentAuto-check passed
  • Commit

    LennartHennigs/Button2

    Stage and commit current changes for Button2 — checks for needed CHANGELOG/README/CLAUDE.md updates, creates a branch if on master, writes a commit message, and commits

    565 GitHub stars~562 tokensUpdated 4 mo ago
    DevelopmentAuto-check passed
  • Qkeymapper Release Notes

    Zalafina/QKeyMapper

    为 QKeyMapper 编写 README.md 的中文 release note,并默认联动 qkeymapper-readme-en-sync 定向同步更新英文版 READMEen.md。收集最近正式 release tag 之后的已提交更新,先展示中英双语完整草稿供审阅,批准实施后分阶段原子提交两个 README。用于发布说明、更新日志和中英文版本信息维护。

    755 GitHub stars~1.3k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Commit

    LennartHennigs/ESPRotary

    Stage and commit current changes for ESPRotary — checks for needed CHANGELOG/README/CLAUDE.md updates, creates a branch if on master, writes a commit message, and commits

    188 GitHub stars~590 tokensUpdated 2 mo ago
    DevelopmentAuto-check passed

Works with

Questions about Doc-Code Sync Check

What does Doc-Code Sync Check do?

Reconciles documentation with code at the end of a change or as a periodic audit, following a repo rule that code changes and doc changes land in one commit. md to list the documents the change owes. Examples named in the skill include a database schema snapshot, an architecture codemap, a features checklist, a tech-debt tracker and a changelog entry when the daemon bundle ships.

When should I use Doc-Code Sync Check?

Doc-Code Sync Check fits situations like: finishing a pull request and confirming every owed doc was updated; auditing a repo for drift between documentation and code; checking whether a schema or route change needs architecture notes; before calling a change done, as the last verification step.

How do I install Doc-Code Sync Check in Claude Code?

Run `npx skills add fancyboi999/open-tag --skill doc-sync -a claude-code`. Or copy the skill folder (.agents/skills/doc-sync in fancyboi999/open-tag) into .claude/skills/doc-sync in your project. Claude Code loads it when a task matches its description.

How do I install Doc-Code Sync Check in Codex?

Run `npx skills add fancyboi999/open-tag --skill doc-sync -a codex`. Or copy the skill folder (.agents/skills/doc-sync in fancyboi999/open-tag) into .agents/skills/doc-sync in your project. Codex loads it when a task matches its description.

Can I use Doc-Code Sync Check in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add fancyboi999/open-tag --skill doc-sync -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/doc-sync, .gemini/skills/doc-sync, .github/skills/doc-sync and .opencode/skills/doc-sync in your project.

What does Doc-Code Sync Check need to run?

Going by SKILL.md and its folder, Doc-Code Sync Check needs the command-line tools its instructions call (git). Our summary lists: A git repository with an AGENTS.md doc-sync mapping table; Git access to origin/main for the diff.

Does Doc-Code Sync Check access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Doc-Code Sync Check safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Doc-Code Sync Check use?

Doc-Code Sync Check is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Doc-Code Sync Check use?

About 1.7k tokens (SKILL.md is roughly 6.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Doc-Code Sync Check?

Skills that share tags, products or a category with Doc-Code Sync Check: Sync Docs (ayutaz/piper-plus, 220 stars), Release (jrswab/axe, 895 stars), Docs Guard (amElnagdy/guard-skills, 1.3k stars) and Commit (LennartHennigs/Button2, 565 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Doc-Code Sync Check?

fancyboi999 (a GitHub user) maintains it in fancyboi999/open-tag, which has 203 GitHub stars. The repository was last updated on August 22, 2026.

Source: fancyboi999/open-tag on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.