agentleFS
smkg75smkg75/wikidoc/skills/tidy/SKILL.md

tidy

Skill2 starsChanged 18 days agoMITView on GitHub

The regular clean of the wiki - examines it, cleans what the wiki or its sources settle, and reports what changed and what stays open. Runs alone, from a routine or on request. Use when the user asks to tidy or clean up the wiki, or asks whether it is healthy, stale, bloated or contradicting itself.

24 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use map, architect and 4 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.
  • AWSSkill

    map

    Map verified service capabilities against customer-provided control framework and threat model. Produces mapping-results.json, controls-catalog.md, and framework-mapping.md. Supports pluggable frameworks: CCMv4, NIST 800-53, CIS Benchmarks, ISO 27001, etc. Split into 4 focused sub-skills for better accuracy; this skill orchestrates them.

    Also in 3 projects that use this

  • Harut8Skill

    architect

    Also in 3 projects that use this

  • AWSSkill

    retro

    Conduct a retrospective on a coding session.

    Also in 4 projects that use this

  • AWSSkill

    ship

    Finalize dev work on an issue branch — update docs, push, and open a PR.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    verify

    End-to-end app testing pipeline for browser-based web apps on cloud browsers via Azure Playwright Workspaces: verify the live app, author tests for working flows, heal failing tests, then re-run with video and produce one consolidated report. Three phases (app verification, test authoring, test healing) plus a scoped final sanity run; each phase emits a sub-report. Use when asked to "verify my app", "make sure my app works and has good test coverage", "do a full QA pass", "add tests where I'm missing coverage", "fix failing tests and add new ones", "smoke test before deploy", "QA my deployment", or any combined verify-and-test ask. Requires Azure CLI (`az login`) and a Playwright Workspace resource ID — bootstraps configs on first invocation. Browser-based web apps with Playwright only — not for unit/API tests, native mobile/desktop, load/perf, or full accessibility audits.

    Also in 3 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 3 projects that use this

The file

Files
SKILL.md

Tidy

The upkeep of the wiki, done alone: examine, clean, report. The user reads what changed afterwards; nothing waits on them. Three things make that safe. The workspace is a local git repository, so every clean is one commit the user can read and revert. The examination is finished before the first edit, so each finding is checked against the state it was found in. And a fact is only ever settled by the wiki's own dated replacement or by its source document, never by a guess: what neither settles stays, as an open question.

The audit of a filing rule is another thing: route.py --audit, in skills/tri/SKILL.md.

Step 0 — Load

Resolve the workspace: $WIKIDOC_HOME, default ~/.wikidoc. No wiki/index.md: stop on "Run /wikidoc:setup first". Read skills/wiki/SKILL.md: its write rules bind every edit below.

The workspace is a git repository, local, with no remote: config.yaml, the ledger and wiki/ are versioned together. No .git at the workspace root: git init it there, .gitignore logs/, cache/, bench/, .trash/, .DS_Store, *.bak*. Commit whatever is uncommitted as before tidy <date>: that commit holds everything sessions wrote since the last one.

The scope: $ARGUMENTS is full, or no tidy <date> commit exists yet, and the whole wiki is read. Otherwise the scope is the diff of wiki/ since the last tidy commit: the changed hunks, and for each fact they carry, the other places in the wiki that speak of the same subject, found by search. List every file under wiki/, recursively, with its line count.

Done when: the before commit exists, the scope is a list of files and hunks, and the write rules are read.

Step 1 — Examine

Families 1, 2, 5 and 6 are mechanical: run them here. Families 3 and 4 read long text: dispatch one sub-agent per family, in parallel, so that text stays out of this conversation. Each sub-agent is told it is read-only, receives the wiki path, the scope and its family, and returns per finding: file, section, line number, what was observed, the line quoted word for word, what would settle it. A finding that spans state.md and another file belongs to State. Re-read every quoted line at its number before using it: a proof that is not where it was said to be is dropped.

  1. Index — a wiki file with no index line; an index line whose target is gone, or that points at no file; a line past ~150 characters, or one that carries the fact instead of naming the question.
  2. Pointers — a [[link]], or an absolute or ~/ path, that resolves to nothing. A path whose own line records it as binned, moved or deleted is a correct trace. A path fragment is resolved against the workspace and against root, and skipped when neither holds it. The anchor is the instructions file (anchors: in config.yaml, default ~/.claude/CLAUDE.md): its pointers are checked the same way.
  3. Facts — two lines that contradict each other; a replaced fact still standing beside its replacement; the same fact with its detail in two files; one name under two spellings. A dated arbitration in decisions.md and the current rule in the file that owns it are two layers of one fact, by design.
  4. State — a dossier marked closed still listed as in flight; an open question the wiki answers elsewhere; a current-state line the disk contradicts; history settled in state.md or any file of current rules, which belongs in log.md: reports of past passes, closed questions, the event-by-event journal of a dossier.
  5. Ledger — a path whose last memory.jsonl line leaves the file in place (none, tag, keep, or no decision) and whose file is gone; an unanswered or refused line older than 30 days; a bench/ holding a routing.json, which is an interrupted pass, or an empty one, which is debris.
  6. Workshop — .bak copies beside config.yaml and memory.jsonl, which the repository has made redundant, and the weight of logs/ by subfolder, each with size and date. A chronicle or a report a session left at the workspace root: the chronicle belongs in log.md, the report in logs/.

And one family that is reported, never cleaned — Deadlines: every date in state.md by which someone must act, passed or within 14 days, with the last event recorded on it.

Done when: every family has returned or the one that broke is named, and every proof kept was re-read at its line.

Step 2 — Clean

Each finding gets one of four fates.

Cleaned, when the wiki or a source settles it:

  • A replaced fact whose replacement is dated in the wiki: the old line is deleted where it lived.
  • A contradiction: find the source document (memory.py find, then read it) and keep what it proves; the arbitration goes to decisions.md with the source named. When the source shows both lines true of two different things, both stay and one sentence says what each of them names. A wrong fact the source reveals in passing is corrected the same way, and counted.
  • A duplicated fact: it stays in the file that owns that kind of fact, the other place points at it.
  • History: it moves whole to log.md, word for word under dated headings in date order, and the state keeps one current line per dossier. A dated entry that is the evidence of a rule stays with its rule: only history with no rule attached leaves. No log.md yet: create it, with its index line. Count the lines taken out against the lines laid down.
  • The index: one pointing line per file.
  • A pointer to a moved target: re-pointed once the target is found on disk.
  • A current-state line the disk contradicts: rewritten from the disk.
  • .bak copies, unless the wiki cites them, and an empty bench/: to the OS bin. The repository is the backup.

Left as it is, by rule: decisions.md, log.md and every dated archive are append-only, a dead link inside a dated entry is history. Anything outside the workspace belongs to the corpus and to tri. A file the wiki cites stays where it is cited. logs/ of past passes are archives. memory.jsonl is the pass's to write: Ledger findings are reported, like the deadlines.

Open, when neither the wiki nor a source settles it, or the decision is the user's: the contradiction is recorded at the fact's place with what would settle it, and the question goes to state.md, one line, under the one heading that holds tidy's questions. Each tidy rewrites that heading: the answered leave, the rest carry over.

Dropped, when the proof does not hold on re-reading, or when a dated arbitration in decisions.md already settles the matter — search it before raising anything the user may have ruled on: named in the report with the reason, so the next examination does not raise it again.

Edit file by file, surgically, and re-read each edit at its place.

Done when: every finding has its fate, and git diff shows only edits a finding accounts for.

Step 3 — Report and record

Write logs/tidy-<date>.md in the wiki's language, under a hundred lines: the deadlines first; then what was cleaned, one line each; what stays open, one line each with what would settle it; the count per family against the previous tidy, or "first run". Append one line to wiki/log.md: the date, tidy, cleaned, open, the report's path. The previous counts are read from the previous report.

Then commit as tidy <date>. With the user present, close on the deadlines and the open questions, and on how to read the change: git -C <workspace> show.

Done when: the report is written, the log line points at it, and the tidy <date> commit holds both.

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.