agentleFS
dexio-wikidexio-wiki/llm-wiki-skills/skills/wiki-refactor/SKILL.md

wiki-refactor

Skill1 starsChanged 46 days agoMITView on GitHub

Restructure an LLM wiki without breaking it: split oversized pages into focused linked pages, merge duplicate pages, rename or move pages, and archive superseded ones, rewriting every inbound link and confirming zero broken links afterwards. Use when a page passes about 200 lines, when two pages cover the same topic, when the folder layout changes, or when a page is superseded.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. bordenet/superpowers-plus★ 8same 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 repository11 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When a page passes about 200 lines, or covers several things a reader wants separately:

    line 27
  2. Distinctive:

    Read the whole page and list its distinct subtopics.

    line 29
  3. Distinctive:

    Leave the original as the overview: a short section per subtopic with a one- or two-sentence summary and a link to the new page.

    line 32
  4. Distinctive:

    When two pages cover one topic:

    line 41
  5. Very specific:

    Delete the duplicate or move it to _archive/.

    line 48
  6. Distinctive:

    Update the page's own relative links if it changed folder.

    line 57
  7. Distinctive:

    When a page is fully superseded but its history matters:

    line 61
  8. Distinctive:

    Add one line at the top: what replaced it and when.

    line 64

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

Refactor a wiki

Agent-kept wikis grow by accretion. Without periodic restructuring, one page absorbs a whole subject, near-duplicates multiply under slightly different names, and superseded pages keep getting cited. Refactoring fixes that; done carelessly it is also the fastest way to break a hundred links at once.

Rule for every operation below: find inbound links first, change them in the same change, and run wiki-lint afterwards. Zero broken links, or the refactor is not done.

Finding inbound links. Folder wiki: python3 <wiki-lint skill>/scripts/wiki_lint.py <wiki> --links-to <path>, or search for the page name in [[...]] and (...md) links. Hosted wiki: the page's links-in list from read_page; on Dexio, move_page rewrites inbound links itself.

Split a long page

When a page passes about 200 lines, or covers several things a reader wants separately:

  1. Read the whole page and list its distinct subtopics.
  2. Move each self-contained subtopic to its own page in the right folder, with full frontmatter and the relevant sources. Keep the text; do not summarize it away.
  3. Leave the original as the overview: a short section per subtopic with a one- or two-sentence summary and a link to the new page. Keep the path, so existing links still land on the right topic.
  4. Retarget inbound links that were clearly about one subtopic (for example [[vendor#Pricing]]) to the new page.
  5. One change for the split, with a note listing the new pages.

Merge duplicates

When two pages cover one topic:

  1. Choose the survivor: the one with more inbound links, the better path, or the better sources.
  2. Merge the other's unique content into it, with sources. Where they disagree, follow wiki-conflicts rather than picking silently.
  3. Retarget every inbound link to the survivor.
  4. Delete the duplicate or move it to _archive/. If other tools or people may still use the old path, leave a one-line redirect page instead ("Moved to [[survivor]]").

Rename or move

  1. Choose the new path by the schema's naming rule (lowercase, hyphenated, folder by kind).
  2. Move the file (git mv in a git-backed wiki, so history follows) or call the host's move tool.
  3. Rewrite inbound links, including relative markdown links whose ../ depth changed.
  4. Update the page's own relative links if it changed folder.

Archive

When a page is fully superseded but its history matters:

  1. Move it to _archive/ with its links rewritten.
  2. Add one line at the top: what replaced it and when.
  3. Retarget links that should now point at the replacement; leave links in historical records (old decisions, old query pages) pointing at the archive.

Pitfalls

  • Refactoring and editing content in one change. Move first, then edit, so a reviewer can see that nothing was lost in the move.
  • Relative links. Moving a page one folder deeper breaks every ../ link on it and every relative link to it. Wikilinks by path or unique name survive moves better.
  • Splitting by date ("2026 notes", "2025 notes") instead of by subject. Readers look things up by subject.
  • Renaming a page other agents are editing right now. Check recent changes first (wiki-orient) and do structural work when the wiki is quiet.

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.