agentleFS
flonatflonat/flonat-research/skills/wiki-merge/SKILL.md

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

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
  1. Very specific:

    When the "overlap" turns out to be a genuine sub-concept relation — keep both, add a [[wikilink]] reference between them instead.

    line 26
  2. Very specific:

    Default invocation (no --apply) prints a plan:

    line 67
  3. Very specific:

    All atlas/books/concepts/project-knowledge files that wikilinked to the loser slugs now wikilink to the winner with the original display …

    line 99
  4. Distinctive:

    Don't merge a curated concept INTO an auto-generated one: If you must, swap winner/loser.

    line 125

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-grow cron doesn't re-promote.

When to Use

  • Right after wiki-curate flags 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):

  1. Read winner + every loser concept file under ~/vault/concepts/.
  2. 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.
  3. 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.
  4. Write merged content back to the winner's file.
  5. 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.
  6. Delete loser files from ~/vault/concepts/.
  7. Append to denylist — each loser slug is added to ~/vault/concepts/.denylist with a comment noting the merge date. This stops the Saturday wiki-grow cron 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-resistance

Performs all six steps. After the run:

  • ~/vault/concepts/goodharts-law.md contains the merged content with fold-in provenance in frontmatter.
  • goodhart-taxonomy.md and goodhart-resistance.md are 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/.denylist has two new lines.

Verify with wiki-curate — the goodhart cluster should be gone on the next run.


Safety properties

  • Dry-run is default. Forgetting --apply previews 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 at goodharts-law now.
  • Denylist prevents re-promotion — if a project still has <loser-slug>.md in 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. model token in language-model and linear-model). Use judgement.
  • Don't merge without dry-running first. The dry-run output is the only confirmation step.

Cross-References

SkillRelationship
wiki-curateIdentifies the clusters this skill collapses.
wiki-growWriter of auto-promoted concepts; denylist entries from wiki-merge prevent it from re-promoting losers.
compile-knowledgeSource of project knowledge articles that get promoted to concepts.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.