wiki-merge
Skill189 starsChanged 4 months agoMITView on GitHub
Use when two wiki pages turn out to be the same concept under different slugs (merge), or one page overloads several distinct senses of a term and should be separated into qualified slugs (split). Often run on a wiki-lint "merge candidate" or "colliding slug" finding.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- flonat/flonat-researchtheir own version, first seen Nov 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
- flonat/flonat-research★ 150same 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 repository6 other files it gives its agents.
- wiki-auditSkill
- wiki-ingestSkill
- wiki-initSkill
- wiki-lintSkill
- wiki-querySkill
- wiki-updateSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 2 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
If unsure which, describe both pages to the user and confirm before proceeding.
- Distinctive: line 47
Read both pages in full. Merge the loser's content into the survivor:
- Very specific: line 53
Keep the earlier created date of the two.
- Very specific: line 69
Remove wiki/pages/<loser-slug>.md.
- Very specific: line 82
If the merge changes the synthesis (e.g.
- Very specific: line 121
Write each new page with the content for its sense only, with full frontmatter (title, category, a distinct one-line summary, tags, …
- Very specific: line 139
If retiring the bare slug, delete wiki/pages/<original-slug>.md.
- Very specific: line 146
If the bare slug was retired, grep the whole wiki for [[<original-slug>]] — zero matches must remain.
- Very specific: line 151
Update wiki/overview.md if the split changes the synthesis.
≈ “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
Consolidate two pages into one (merge), or separate one overloaded page into qualified pages (split). Both operations rewrite the link graph, so they are deliberate, confirmed, and verified — never automatic.
The slug is the concept's identity (see the Concept Identity section of SCHEMA.md).
Merge and split are how identity changes safely: every inbound [[slug]] is rewritten so
no link is left resolving to nothing.
Pre-condition
Find SCHEMA.md (search from cwd upward, or ~/wikis/). If not found, tell the user to
run wiki-init first. Read it to get the wiki root path and the Concept Identity
convention.
Choose the operation
- Merge — two slugs name the same concept. Goal: one surviving page, the other gone, all links pointing at the survivor.
- Split — one slug overloads distinct senses (a homonym, or a page that grew two unrelated subjects). Goal: two qualified pages, each inbound link repointed to the correct sense.
If unsure which, describe both pages to the user and confirm before proceeding.
Merge
1. Identify survivor and loser
Present both pages and recommend which slug survives. Prefer the slug that is: more specific and correct, more linked-to, or already the better-developed page. Confirm the choice with the user before writing anything.
Survivor:
[[<survivor-slug>]]—<why>Loser:[[<loser-slug>]]— folded in, then deleted
2. Fold content into the survivor
Read both pages in full. Merge the loser's content into the survivor:
- Combine sections; do not duplicate facts already present.
- Preserve every citation. Carry footnotes over, renumbering sequentially. Never drop a footnote during the fold — a merged claim keeps its provenance.
- Union the frontmatter
sourceslists; keep the broader/more-correcttitle,category,summary, andtags. - Keep the earlier
createddate of the two; bump the survivor'supdateddate.
Show the proposed survivor page as a diff and confirm before writing.
3. Rewrite all inbound links
Grep every page in wiki/pages/ and overview.md for [[<loser-slug>]] (skip
index.md — it is generated and will be rebuilt). Rewrite each to [[<survivor-slug>]].
Watch for:
- A page that linked to both — collapse to a single link, fix surrounding prose.
- Link text/aliases that named the loser — update the wording to read naturally.
Show the list of affected pages and the edits; confirm before writing.
4. Delete the loser page and regenerate the index
Remove wiki/pages/<loser-slug>.md. Do not touch index.md by hand — regenerate it so
the loser's entry disappears and the survivor's reflects its merged frontmatter:
python bin/generate-index.py.
5. Link-resolution sweep
Grep the whole wiki for [[<loser-slug>]] — there must be zero matches left. Then
confirm every [[slug]] on the survivor page resolves to a real page. Fix any stragglers
before finishing. (This is the same inline check wiki-ingest runs; a merge that leaves a
dangling link defeats its own purpose.)
6. Update overview and record the operation
If the merge changes the synthesis (e.g. a duplicated "Key Concept" becomes one), update
wiki/overview.md. Then record the operation per SCHEMA's Operation Log & Commit
Convention:
- Git wiki: suggest a commit (default
refactor:for a merge, plus the trailer) and commit on confirmation.refactor: merge <loser-slug> into <survivor-slug> Wiki-Op: merge - Non-git wiki: append to
wiki/log.md:## [<today>] merge | <loser-slug> → <survivor-slug> Inbound links rewritten: <N> across <list of pages>
Split
1. Define the senses and slugs
Identify each distinct sense the overloaded page conflates. Propose a qualified slug per
sense, following the disambiguation convention in SCHEMA.md (narrowest discriminator
that disambiguates):
[[transformer]]overloads two senses →
[[transformer-ml]]— the neural network architecture[[transformer-electrical]]— the power-grid device
Decide what happens to the original bare slug:
- Retire it (most common): both senses move to qualified slugs; the bare slug is deleted and every inbound link repointed.
- Keep it as the primary sense: one sense stays on the bare slug, the other moves out.
Confirm the slug plan with the user before writing.
2. Create the qualified pages
Write each new page with the content for its sense only, with full frontmatter
(title, category, a distinct one-line summary, tags, created: <today>,
updated: <today>). Split the frontmatter sources so each page lists only the sources
that actually support it. Carry the relevant footnotes to each page, renumbering
sequentially. Show each new page and confirm before writing.
3. Repoint inbound links per sense
Grep every page in wiki/pages/ and overview.md for [[<original-slug>]] (skip the
generated index.md). For each occurrence, decide which sense it meant from its
context and rewrite it to the correct qualified slug. This is the judgment-heavy step —
do not blanket-replace. When a single page referenced both senses, split it into two links.
Show each repointing decision (link, surrounding context, chosen target) and confirm before writing.
4. Remove or repurpose the original
If retiring the bare slug, delete wiki/pages/<original-slug>.md. If keeping it as the
primary sense, trim it to that sense only and bump its updated date. Then regenerate the
index so the removed/added pages are reflected — do not hand-edit index.md:
python bin/generate-index.py.
5. Link-resolution sweep
If the bare slug was retired, grep the whole wiki for [[<original-slug>]] — zero matches
must remain. Confirm every [[slug]] on the new pages resolves. Fix any stragglers.
6. Update overview and record the operation
Update wiki/overview.md if the split changes the synthesis. Then record the operation
per SCHEMA's Operation Log & Commit Convention:
- Git wiki: suggest a commit (default
refactor:for a split, plus the trailer) and commit on confirmation.refactor: split <original-slug> into <slug-a>, <slug-b> Wiki-Op: split - Non-git wiki: append to
wiki/log.md:## [<today>] split | <original-slug> → <slug-a>, <slug-b> Inbound links repointed: <N> across <list of pages>
Common Mistakes
- Leaving dangling links — The whole point is a trustworthy graph. After any merge or split, grep for the removed slug; zero matches is the only acceptable result.
- Dropping citations during a fold — Every claim keeps its footnote. Renumber, don't delete. A merge that loses provenance is a regression.
- Blanket-replacing on a split — Each inbound link must be repointed by meaning, not by find-and-replace. That per-link judgment is the reason split is a deliberate skill.
- Merging without confirmation — Merge deletes a page and rewrites links across the wiki. Always show the plan and the diffs, and write only after the user confirms.
- Skipping the log — Record the operation so the slug change is traceable: a git wiki
commits it (with the
Wiki-Op:trailer); a non-git wiki appends tolog.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.

