sync-docs
Skill1 starsChanged 4 months agoMITView on GitHub
Regenerates the public skill catalog from `skills/*/SKILL.md` — per-skill MDX pages under `site/src/content/docs/skills/`, the table between `<!-- yoke:skills:start -->` markers in `README.md`, and the bullet list between the same markers in `CLAUDE.md`. Activates when the user writes "sync docs", "regenerate docs", "update the skill catalog", "rebuild docs", "refresh the catalog", or passes `--check` to detect drift. Refuses to write when sentinels are missing or unbalanced.
- Deletes or force-pushes
22 other projects use a version of this.
Adopted by
Most recently taken up by
- richkuo/rk-skillstheir own version, first seen Nov 8, 2026
- Kangentic/kangentictheir own version, first seen Nov 7, 2026
- TanKaizokuO/claude-skillstheir own version, first seen Oct 20, 2026
- blakebauman/memoturn-dbtheir own version, first seen Oct 13, 2026
- kube-hetzner/terraform-hcloud-kube-hetznertheir own version, first seen Oct 8, 2026
- ayutaz/piper-plustheir own version, first seen Oct 8, 2026
Used with
Projects with it also use prepare-release, review-pr and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ShopifySkillprepare-release
Prepare the changeset-release/main branch for release by syncing version.ts files and running pnpm install
Also in 4 projects that use this
DockerSkillreview-pr
Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.
Also in 3 projects that use this
MicrosoftSkillrelease
Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).
Also in 3 projects that use this
Other versions22 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 22
- kube-hetzner/terraform-hcloud-kube-hetzner★ 3.9ksame name
- mysticaltech/terraform-hcloud-kube-hetzner★ 3.9ksame name
- onevcat/Prowl★ 673same name
- ayutaz/piper-plus★ 240same name
- joshzyj/open-scholar-skill★ 177same name
- Kangentic/kangentic★ 140same name
- guess/claude_code★ 96same name
- richkuo/rk-skills★ 50same name
- jiahao-shao1/sjh-skills★ 43same name
- phj128/autoworker★ 18same name
12 more not listed
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.
- CLAUDE.mdCLAUDE.md
- yoke-createSkill
- yoke-releaseSkill
- yoke-validateSkill
- bootstrapSkill
- doSkill
- draftSkill
- gcaSkill
- gpSkill
- grill-docsSkill
- grillSkill
- handoffSkill
- helpSkill
- issuesSkill
- journalSkill
- mergeSkill
- prdSkill
- prSkill
- reviewSkill
The file
We split this skill into the rules it gives an agent
8 rules. 0 are common, 4 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 43
Verify the working tree is the yoke plugin repo:
- Distinctive: line 52
Create the tmp tree:
- Very specific: line 79
Read skills/<name>/SKILL.md.
- Very specific: line 84
Read docs/<name>.md when present.
- Very specific: line 88
Always include the raw SKILL.md body verbatim inside a <details><summary>Full instructions</summary> … </details> block.
- Distinctive: line 91
After every skill is rendered:
- Distinctive: line 199
When the live tree matches the tmp tree byte-for-byte → exit zero.
- Distinctive: line 209
Every other byte must round-trip unchanged.
“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Sync docs
Regenerate the public skill catalog from skills/*/SKILL.md. One source of
truth for the README catalog, the CLAUDE.md catalog, and the per-skill pages
on the docs site.
Input
$ARGUMENTS — empty for write mode (default), or --check for drift
detection.
/sync-docs
/sync-docs --checkPhases
The skill runs through 5 phases. No user interaction.
| Phase | Name | What happens |
| 1 | Preflight | Verify the repo (.claude-plugin/plugin.json exists, skills/ is a directory); parse --check |
| 2 | Enumerate | List every directory under skills/ (15 today); never include .claude/skills/* |
| 3 | Render | Write per-skill MDX, README block, CLAUDE.md block into .yoke/sync-docs-tmp/ |
| 4 | Sentinel check | Verify exactly one start and one end marker in each of README.md and CLAUDE.md; start < end |
| 5 | Write or diff | Write mode → copy tmp tree over live; check mode → diff and exit non-green on drift |
Phase 1 — Preflight
Verify the working tree is the yoke plugin repo:
test -f .claude-plugin/plugin.json && test -d skills/Parse --check from $ARGUMENTS. Set MODE=check when present, MODE=write
otherwise.
Create the tmp tree:
rm -rf .yoke/sync-docs-tmp && mkdir -p .yoke/sync-docs-tmp/skillsPhase 2 — Enumerate
List the shipped skills:
ls -d skills/*/ | xargs -n1 basenameInclude every directory under skills/ that contains a SKILL.md. Never
include anything under .claude/skills/ — yoke-create, yoke-release, and
yoke-validate are local-only tools and must not appear in the public
catalog.
The shipped catalog today is 15 skills:
bootstrap, do, draft, gca, gp, grill, grill-docs, handoff, help, issues,
journal, merge, pr, prd, review.
Phase 3 — Render
For each enumerated skill:
- Read
skills/<name>/SKILL.md. Parse the YAML frontmatter intonameanddescription. - Extract trigger phrases — every quoted substring inside
descriptionthat begins with a lowercase letter or a forward slash (e.g."sync docs","--check"). - Read
docs/<name>.mdwhen present; otherwise extract## Input,## Output, and the first example code block from the SKILL.md body. - Render the MDX page from
reference/mdx-template.md(see that file for the full template) into.yoke/sync-docs-tmp/skills/<name>.mdx. - Always include the raw SKILL.md body verbatim inside a
<details><summary>Full instructions</summary> … </details>block.
After every skill is rendered:
Render the README block to
.yoke/sync-docs-tmp/readme-block.mdas a 3-column markdown table:| Command | What it does | Output | | -------------- | ---------------------- | -------- | | `/yoke:<name>` | <one-line description> | <Output> |The one-line description is the first sentence of the SKILL.md description (everything up to the first
.). The Output column is the value fromdocs/<name>.md's**Output:**line when present, else—.Render the CLAUDE.md block to
.yoke/sync-docs-tmp/claudemd-block.mdas a bullet list matching the current style atCLAUDE.md:62-78:- `/<name>` — <one-line description>
Phase 4 — Sentinel check
For each of README.md and CLAUDE.md, count line-anchored occurrences of each marker:
grep -cE "^<!-- yoke:skills:start -->\$" README.md # must be 1
grep -cE "^<!-- yoke:skills:end -->\$" README.md # must be 1Anchor to line boundaries — the catalog table itself may mention the marker text inside cells (the sync-docs row literally describes the markers). Only standalone-line occurrences count as sentinels.
The standalone start marker line must come before the standalone end marker line.
On any failure:
Markers missing or unbalanced in <file>.
Add exactly one <!-- yoke:skills:start --> and one <!-- yoke:skills:end -->
around the catalog block; re-run.In --check mode → exit non-green. In write mode → abort before any write.
Phase 5 — Write or diff
Write mode
For each per-skill MDX in .yoke/sync-docs-tmp/skills/:
cp .yoke/sync-docs-tmp/skills/*.mdx site/src/content/docs/skills/For README.md: replace the byte range between the two sentinels with the
contents of .yoke/sync-docs-tmp/readme-block.md, surrounded by a single
blank line on each side. Leave every other byte unchanged.
For CLAUDE.md: same procedure with .yoke/sync-docs-tmp/claudemd-block.md.
Then normalize the output through prettier so the round-trip matches what husky's lint-staged hook would produce on commit:
pnpm exec prettier --write \
README.md CLAUDE.md \
site/src/content/docs/skills/*.mdxSend the completion notification:
bash ${CLAUDE_PLUGIN_ROOT}/lib/notify.sh \
--type STAGE_COMPLETE \
--skill sync-docs \
--title "Docs synced" \
--body "<N> MDX pages written; README + CLAUDE.md catalog blocks regenerated"Check mode
Normalize the rendered tree through prettier first (so the comparison is fair against the prettier-formatted live tree):
pnpm exec prettier --write \
.yoke/sync-docs-tmp/skills/*.mdx \
.yoke/sync-docs-tmp/readme-block.md \
.yoke/sync-docs-tmp/claudemd-block.mdThen compare the tmp tree against the live tree:
diff -r .yoke/sync-docs-tmp/skills/ site/src/content/docs/skills/Extract the byte range between sentinels from README.md and CLAUDE.md;
compare against the rendered blocks. List every file with drift.
On any drift:
Docs drift detected in: <files, newline-separated>
Run `/sync-docs` to regenerate, review the diff, commit, and retry.Exit non-green.
When the live tree matches the tmp tree byte-for-byte → exit zero.
Rules
- Catalog membership: every directory under
skills/that contains aSKILL.md(15 today). Never include.claude/skills/*skills (yoke-create,yoke-release,yoke-validate). - Sentinels are required. Refuse to write when they are missing or unbalanced. Never auto-insert.
- Touch only the bytes between the sentinels in
README.mdandCLAUDE.md. Every other byte must round-trip unchanged. - The raw SKILL.md inside
<details>is the source of truth — never edit it during render. - Idempotence: running
/sync-docsthen/sync-docs --checkmust produce no diff. If the check call reports drift after a fresh write, the renderer is non-deterministic — fix the renderer before relying on the release gate. - Render artifacts live in
.yoke/sync-docs-tmp/(gitignored). Never commit them.
Reference
reference/mdx-template.md— the 7-section per-skill MDX template.reference/sync-spec.md— sentinel rules, enumeration rules, check-mode contract, idempotence rule.
Example
/sync-docs→ Writes site/src/content/docs/skills/<name>.mdx for all 15 skills,
regenerates the README and CLAUDE.md catalog blocks.
/sync-docs --check→ Exits zero when everything is in sync; exits non-green and lists the affected files on any drift.
Connections
/yoke-create → /sync-docs (Phase 6b tail; regenerates catalog for the new skill)
/yoke-release → /sync-docs --check (Phase 0f gate; halts release on drift)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.

