wiki-sync
Skill4 starsChanged 20 days agoMITView on GitHub
Sync the project wiki with source changes since origin/main, updating docs and the wiki operation log.
7 other projects use a version of this.
Adopted by
Most recently taken up by
- rumi-chan/llm-wikitheir own version, first seen Oct 25, 2026
- nathanaday/almagesttheir own version, first seen Oct 8, 2026
- nathanaday/atlas-obsidiantheir own version, first seen Oct 7, 2026
- nathanaday/claude-atlastheir own version, first seen Oct 7, 2026
- Jawahars07/ballasttheir own version, first seen Sep 11, 2026
- sponge-b0b/Polaristheir own version, first seen Aug 3, 2026
Used with
Projects with it also use almagest, almagest-onboard and 9 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.
nathanadaySkillalmagest
Orient in the Almagest vault, say what waits for the user, do the work a request asks in a linked repository, and route any other request to the skill that owns it. Use for /almagest, what is going on, status, what waits for me, where do I work on X, work on X, fix this, implement, build, note this, remember to, publish my journal, what is in my journals, and any request when the right skill is not clear. Keeping part of this conversation is wiki-save; files to learn from are wiki-ingest.
Also in 3 projects that use this
nathanadaySkillalmagest-onboard
Make a new Almagest vault: ask its name, its folder, and how freely to tag, then link its first repositories. Use for set up almagest, new vault, start a vault here, onboard, make this folder a vault. Linking a repository to a vault that exists is repo-link.
Also in 3 projects that use this
justvinhhereSkillwiki-review
Use when the user runs /review, says "show pending changes", "what's uncommitted", or wants an audit of uncommitted wiki edits before they land in history. Narrates uncommitted changes, flags structural issues scoped to those changes, and commits them with a conventional subject. Fully automatic.
Also in 3 projects that use this
- +8 more from nathanaday
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 7
- richard-kim-79/archora-skills★ 49same name
- sponge-b0b/Polaris★ 4same name
- Jawahars07/ballast★ 1same name
- nathanaday/almagest★ 1same name
- nathanaday/atlas-obsidian★ 1same name
- nathanaday/claude-atlas★ 1same name
- rumi-chan/llm-wiki★ 1same name
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 repository45 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- a11y-auditorSkill
- api-contract-reviewSkill
- backend-releaseSkill
- bug-diagnosisSkill
- client-copy-reviewSkill
- codebase-designSkill
- code-reviewSkill
- create-issueSkill
- create-prSkill
- create-taskSkill
- dependency-upgradeSkill
- deploy-evidenceSkill
- design-expertSkill
- design-system-docsSkill
- design-system-setupSkill
- domain-modelingSkill
- e2e-verifySkill
- evidence-auditSkill
- feature-discoverySkill
- frontend-releaseSkill
- generate-readmeSkill
- handoffSkill
- implement-taskSkill
- incident-responseSkill
- init-projectSkill
- live-docsSkill
- mcp-debuggingSkill
- memory-curatorSkill
- plan-expertSkill
- planning-featuresSkill
- project-memory-initSkill
- project-memory-refreshSkill
- project-profileSkill
- project-releaseSkill
- proof-runnerSkill
- release-checklistSkill
- researchSkill
- security-hardeningSkill
- security-reviewSkill
- tddSkill
- wiki-forgeSkill
- wiki-initSkill
- wiki-querySkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
25 rules. 0 are common, 12 are distinctive, and 13 are very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Every wiki edit must follow those conventions exactly.
- Very specific: line 27
If wiki/sync-config.md doesn't exist, abort:
- Very specific: line 35
If REPOS is empty or "(ninguno)", inform the user:
- Very specific: line 43
Read wiki/sync.md. It contains the last synced commit hash for each repo.
- Very specific: line 54
If wiki/sync.md doesn't exist, treat all repos as first-time syncs.
- Very specific: line 55
Use git -C [path] rev-parse --short origin/main to get the current origin/main as a baseline, then run a full scan of recently modified …
- Distinctive: line 75
If the repo has no entry in sync.md (first sync), use an empty diff and treat the full file list as Added.
- Distinctive: line 80
If all diffs are empty across all repos:
- Distinctive: line 101
Follow conventions loaded in Step 0 for all edits.
- Distinctive: line 105
Read the file from the repo.
- Distinctive: line 107
Update those pages — amplify, do not rewrite.
- Very specific: line 109
If no page covers this file and it introduces a meaningful new concept, create a new wiki page following the format in wiki-conventions.md.
- Very specific: line 111
Update wiki/index.md if a new page was created.
- Very specific: line 118
Remove deleted page from wiki/index.md.
- Very specific: line 125
If a wiki page was named after the old file, rename it and update wiki/index.md and all inbound wikilinks.
- Very specific: line 158
Create wiki/logs/YYYY-MM-DD.md (today's date).
- Distinctive: line 159
If the file already exists (multiple syncs today), append to it.
- Distinctive: line 215
Do not re-read the entire codebase.
- Distinctive: line 216
Do not rewrite wiki pages from scratch — amplify existing content.
- Distinctive: line 217
Do not delete a wiki page just because one of its source files changed.
- Distinctive: line 218
Only delete when the entire concept it documents was removed.
- Very specific: line 219
Do not update wiki/sync.md if the sync failed or was aborted partway.
- Distinctive: line 220
Do not ask for confirmation before applying changes.
- Very specific: line 221
Do not invent conventions.
- Very specific: line 222
Do not hardcode repo paths or file patterns — always read from wiki/sync-config.md.
“Common” is measured: kept by at least 6 in 10 of the 6 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
wiki-sync
Incrementally updates the wiki based on what changed in the source repos since the last sync. Reads only the diff — never re-scans everything.
Output messages to the user in the same language as the wiki (see wiki-conventions.md).
Step 0 — Load conventions and config
Read two files:
.claude/wiki-conventions.md— authoritative source for all wiki standards. Every wiki edit must follow those conventions exactly.wiki/sync-config.md— list of source repos and file impact patterns. This file defines which repos to sync and which file patterns have wiki impact.
If wiki/sync-config.md doesn't exist, abort:
"wiki/sync-config.md not found. Run /wiki-init to configure repos, or create it manually."
Parse wiki/sync-config.md to extract:
REPOS: list of{ name, path }objects from the Repositorios tableIMPACT_PATTERNS: per-repo list of file glob patterns with wiki impactNO_IMPACT_PATTERNS: list of patterns to ignore
If REPOS is empty or "(ninguno)", inform the user:
"No source repos configured in wiki/sync-config.md. Nothing to sync." Then stop.
Step 1 — Read the sync state
Read wiki/sync.md. It contains the last synced commit hash for each repo.
Format expected:
# Wiki Sync State
| Repo | Last synced hash | Date |
|------|-----------------|------|
| repo-name | abc1234 | YYYY-MM-DD |If wiki/sync.md doesn't exist, treat all repos as first-time syncs.
Use git -C [path] rev-parse --short origin/main to get the current origin/main as a baseline,
then run a full scan of recently modified files instead of a diff.
Step 2 — Compute the diff for each repo
For each repo in REPOS, first fetch the latest remote state:
git -C [repo.path] fetch origin main 2>/dev/nullThen compute the diff against origin/main:
git -C [repo.path] log [last-hash]..origin/main --name-status --pretty=format:"" 2>/dev/nullWhere [last-hash] comes from wiki/sync.md for that repo.
If the repo has no entry in sync.md (first sync), use an empty diff and
treat the full file list as Added.
Status letters: A = Added, M = Modified, D = Deleted, R<score> = Renamed.
If all diffs are empty across all repos:
"Everything is up to date. No changes since last sync." Then stop — do not modify anything.
Step 3 — Classify each changed file
For each changed file, check against the patterns in wiki/sync-config.md:
Has wiki impact — matches a pattern in IMPACT_PATTERNS for its repo.
No wiki impact — matches a pattern in NO_IMPACT_PATTERNS, or matches
none of the impact patterns.
Group files by: has-impact vs no-impact. Only process the has-impact group.
Step 4 — Apply changes to the wiki
Follow conventions loaded in Step 0 for all edits.
Added (A) or Modified (M)
- Read the file from the repo.
- Identify which wiki page(s) cover it (
wiki/index.mdas reference). - Update those pages — amplify, do not rewrite. Add or adjust only what the changed file introduces; preserve everything else.
- If no page covers this file and it introduces a meaningful new concept,
create a new wiki page following the format in
wiki-conventions.md. - Update
wiki/index.mdif a new page was created.
Deleted (D)
- Identify wiki page(s) that document this file.
- Whole page is about this file → delete the wiki page.
- File is one part of a larger page → remove only that section.
- Remove deleted page from
wiki/index.md. - Find all
[[wikilinks]]pointing to the deleted page and fix them.
Renamed (R)
- Cosmetic rename (path change only): update path references, no content change.
- Semantic rename (purpose changed): treat as Delete + Add.
- If a wiki page was named after the old file, rename it and update
wiki/index.mdand all inbound wikilinks.
After all changes
Scan modified pages for [[wikilinks]] that don't resolve to an existing
.md file. Fix any ghost links before proceeding.
Step 5 — Update sync state
For each repo, get the current origin/main hash:
git -C [repo.path] rev-parse --short origin/main 2>/dev/null
git -C [repo.path] log -1 origin/main --pretty=format:"%s" 2>/dev/nullOverwrite wiki/sync.md with the new hashes and today's date:
# Wiki Sync State
| Repo | Last synced hash | Date |
|------|-----------------|------|
| [repo.name] | [new-hash] | YYYY-MM-DD |Step 6 — Create sync log file
Create wiki/logs/YYYY-MM-DD.md (today's date).
If the file already exists (multiple syncs today), append to it.
# Sync — YYYY-MM-DD
## Resumen
[For each repo:]
- [repo.name]: `<old-hash>` → `<new-hash>` (<N> commits)
## Cambios en la wiki
### Páginas actualizadas
- `ruta/pagina.md` — descripción breve de qué cambió
### Páginas creadas
- `ruta/pagina.md` — motivo
### Páginas eliminadas
- `ruta/pagina.md` — motivo
## Archivos del diff con impacto wiki (<N> de <total>)
| Archivo | Repo | Estado | Acción tomada |
|---------|------|--------|---------------|
| `path/to/file` | repo-name | M | Actualizado `wiki/pagina.md` |
## Archivos sin impacto wiki (<N> ignorados)
`tests/SomeTest.php`, `composer.lock`, ...Step 7 — Report to the user
Wiki sync complete.
[For each repo:]
[repo.name]: <old-hash> → <new-hash> (<N> files changed)
Wiki changes:
Updated: page-a, page-b
Created: page-c (if any)
Deleted: page-d (if any)
Log: wiki/logs/YYYY-MM-DD.md
Ignored (no wiki impact): tests/SomeTest.php, composer.lock, ...What NOT to do
- Do not re-read the entire codebase. Only read files listed in the diff.
- Do not rewrite wiki pages from scratch — amplify existing content.
- Do not delete a wiki page just because one of its source files changed. Only delete when the entire concept it documents was removed.
- Do not update
wiki/sync.mdif the sync failed or was aborted partway. - Do not ask for confirmation before applying changes.
- Do not invent conventions. All standards come from
.claude/wiki-conventions.md. - Do not hardcode repo paths or file patterns — always read from
wiki/sync-config.md.
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.

