wiki-merge
Skill150 starsChanged 12 days agoMITView on GitHub
Merge an overlap cluster of Vault concepts into one canonical concept, rewrite wikilinks, and preserve a dry-run/apply boundary. Use when $wiki-curate has identified a winner and fold-in slugs. Not for general wiki auditing or automatic article promotion.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- kfchou/wiki-skillstheir own version, first seen Jul 3, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- kfchou/wiki-skills★ 189same 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 repository89 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- beamer-deckSkill
- bib-coverageSkill
- bib-filterSkill
- bib-parseSkill
- brief-compliance-checkSkill
- camera-readySkill
- causal-designSkill
- checkpointSkill
- code-archaeologySkill
- compile-knowledgeSkill
- computational-experimentsSkill
- cross-language-checkSkill
- data-analysisSkill
- devils-advocateSkill
- docs-consistencySkill
- docxSkill
- experiment-designSkill
- grill-meSkill
- handoffSkill
- ideasSkill
- init-project-courseSkill
- init-project-lightSkill
- init-project-orchestrationSkill
- init-projectSkill
- insights-deckSkill
- interview-meSkill
- knowledge-lintSkill
- latex-diffSkill
- latex-health-checkSkill
- latex-polishSkill
- latex-postersSkill
- latex-scaffoldSkill
- latexSkill
- latex-templateSkill
- lean-checkSkill
- math-proofSkill
- mcp-builderSkill
- method-auditSkill
- multi-perspectiveSkill
- numerical-checkSkill
- pdfSkill
- pipeline-manifestSkill
- playwright-cliSkill
- postmortemSkill
- pre-commit-auditSkill
- pre-submission-reportSkill
- project-deckSkill
- project-safetySkill
- proof-readabilitySkill
- proofreadSkill
- python-envSkill
- quarto-deckSkill
- reorgSkill
- replication-auditSkill
- replication-packageSkill
- retarget-journalSkill
- review-clusterSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 26
When the "overlap" turns out to be a genuine sub-concept relation — keep both, add a [[wikilink]] reference between them instead.
- Very specific: line 67
Default invocation (no --apply) prints a plan:
- Very specific: line 99
All atlas/books/concepts/project-knowledge files that wikilinked to the loser slugs now wikilink to the winner with the original display …
- Distinctive: line 125
Don't merge a curated concept INTO an auto-generated one: If you must, swap winner/loser.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Wiki Merge — Collapse an Overlap Cluster
Folds one or more concept slugs into a single canonical entry. Preserves provenance, rewrites incoming wikilinks across atlas / books / concepts / project knowledge folders, deletes the losers, and denylists them so the Saturday
wiki-growcron doesn't re-promote.
When to Use
- Right after
wiki-curateflags an overlap cluster in Section A and you've decided which slug should be canonical. - Manual cleanup when you notice two concepts that should be one.
When NOT to Use
- For trivial renames — keep both files and add an alias.
- For tag normalisation — that's edit-in-place, not a merge.
- When the "overlap" turns out to be a genuine sub-concept relation
— keep both, add a
[[wikilink]]reference between them instead.
What it does
uv run python scripts/wiki-merge.py <winner> <loser1> [<loser2> ...]
uv run python scripts/wiki-merge.py --apply <winner> <loser1> [<loser2> ...]Steps performed (in order, only on --apply):
- Read winner + every loser concept file under
~/vault/concepts/. - Build merged body — winner's body verbatim, then each loser's
body under a
## From <loser-slug>section. Each section includes a small admonition naming the source project + promotion date for traceability. Sub-headings in loser bodies are demoted by one level (##→###) so they don't compete with the new section delimiter. - Build merged frontmatter — winner's fields preserved; tags
becomes the union of winner ∪ loser tags; a new
fold_in_sources:block records each loser's slug + source_project + promoted_on date;last_merged:is set to today. - Write merged content back to the winner's file.
- Rewrite wikilinks — every
[[<loser-slug>]](with or without alias suffix) across atlas topics, book chapters, other concepts, and project knowledge folders gets rewritten to[[<winner-slug>|<original-display-text>]]. The alias keeps the original display label visible so the change isn't jarring on pages that referenced the loser by name. - Delete loser files from
~/vault/concepts/. - Append to denylist — each loser slug is added to
~/vault/concepts/.denylistwith a comment noting the merge date. This stops the Saturdaywiki-growcron from re-promoting the loser slug if a project knowledge article with that slug still exists.
Dry-run output
Default invocation (no --apply) prints a plan:
Merge plan (dry-run):
Winner: goodharts-law (concepts/goodharts-law.md)
Fold in: goodhart-taxonomy, goodhart-resistance
Merged file size: 11666 chars (winner was 3516)
Wikilink rewrites: 12 file(s)
concepts/strategic-classification.md: 1 occurrence(s)
.../knowledge/goodhart-resistance.md: 1 occurrence(s)
...
Denylist additions: goodhart-taxonomy, goodhart-resistance
Files to delete: concepts/goodhart-taxonomy.md, concepts/goodhart-resistance.md
(dry-run — pass --apply to perform the merge)Inspect the file count and the rewrite targets. If anything looks wrong (e.g. a loser slug is wildly overrepresented across the corpus suggesting it's actually a distinct concept), abort and reconsider.
Apply
uv run python scripts/wiki-merge.py --apply goodharts-law goodhart-taxonomy goodhart-resistancePerforms all six steps. After the run:
~/vault/concepts/goodharts-law.mdcontains the merged content with fold-in provenance in frontmatter.goodhart-taxonomy.mdandgoodhart-resistance.mdare deleted.- All atlas/books/concepts/project-knowledge files that wikilinked to the loser slugs now wikilink to the winner with the original display label preserved as the alias.
~/vault/concepts/.denylisthas two new lines.
Verify with wiki-curate — the goodhart cluster should be gone
on the next run.
Safety properties
- Dry-run is default. Forgetting
--applypreviews only. - Loser frontmatter preserved in
fold_in_sources:— even though the loser file is deleted, the merged file records source_project + promoted_on for each fold-in, so the provenance is recoverable. - Wikilinks preserve display labels — rewrite produces
[[winner|Original Display]]form, so a topic page that wrote[[Goodhart Taxonomy]]will still render "Goodhart Taxonomy" after the merge, just pointing atgoodharts-lawnow. - Denylist prevents re-promotion — if a project still has
<loser-slug>.mdin its knowledge folder, the next Saturday cron won't re-promote it.
Anti-patterns
- Don't merge a curated concept INTO an auto-generated one. If you must, swap winner/loser. Curated content should be the canonical surface.
- Don't merge concepts from different domains just because slugs
share a token (e.g.
modeltoken inlanguage-modelandlinear-model). Use judgement. - Don't merge without dry-running first. The dry-run output is the only confirmation step.
Cross-References
| Skill | Relationship |
wiki-curate | Identifies the clusters this skill collapses. |
wiki-grow | Writer of auto-promoted concepts; denylist entries from wiki-merge prevent it from re-promoting losers. |
compile-knowledge | Source of project knowledge articles that get promoted to concepts. |
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.

