agentleFS
allthriveaiallthriveai/amplify/.claude/skills/lint/SKILL.md

lint

Skill0 starsChanged 3 months agoMITView on GitHub

Health-checks the wiki. Finds orphans, broken links, contradictions, stale claims, missing pages, and index drift, then offers to fix them. Use when the user runs /lint, asks whether the wiki is healthy, or after a batch of ingests.

80 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use query, coverage and 8 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.
  • ArtemXTechSkill

    query

    Query data from this vault. USE WHEN user asks about projects, clients, tasks, daily notes. Use grep to extract frontmatter - do NOT read full files.

    Also in 17 projects that use this

  • PydanticSkill

    coverage

    Fetch coverage diff from Codecov for the current branch or a specific PR. Shows uncovered lines, patch coverage, and overall coverage change.

    Also in 4 projects that use this

  • seongjaeryuSkill

    save

    Complete and save your current thinking to Bindly

    Also in 5 projects that use this

  • BugRogerSkill

    project

    Project lifecycle management. Dispatches to Ada.

    Also in 4 projects that use this

  • AnthropicSkill

    digest

    Generate a daily or weekly digest of activity across all connected sources. Use when catching up after time away, starting the day and wanting a summary of mentions and action items, or reviewing a week's decisions and document updates grouped by project.

    Also in 3 projects that use this

  • AWSSkill

    issue

    Implement a GitHub issue end-to-end — branch, code, test, docs, and commit.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 67 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run this every ten ingests, monthly at minimum, and before leaning on the wiki for anything large.

    line 12
  2. Very specific:

    Read .amplifyrc for paths.wiki and paths.sources, and {vaultPath}/CLAUDE.md for the conventions being checked against.

    line 17
  3. Very specific:

    Read every page under {wiki}/.

    line 22
  4. Distinctive:

    Run the script rather than doing these by hand:

    line 29

“Common” is measured: kept by at least 6 in 10 of the 67 edited versions of this file we could read. “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

Lint the Wiki

Wikis rot quietly. A page nothing links to is a page nobody finds again; an index entry pointing at a deleted file is worse than no entry. None of this announces itself, so it has to be checked on purpose.

Run this every ten ingests, monthly at minimum, and before leaning on the wiki for anything large.

Step 0: Load configuration

Read .amplifyrc for paths.wiki and paths.sources, and {vaultPath}/CLAUDE.md for the conventions being checked against.

Step 1: Build the picture

Read every page under {wiki}/. For each, collect the filename, the # Title, the frontmatter, and every [[link]] in the body. Then compute the inbound links for each page. Do the mechanical parts with a script rather than by reading — this part is bookkeeping, not judgment.

Step 2: The mechanical checks

Run the script rather than doing these by hand:

npm run lint:wiki          # counts, plus every structural failure
npm run lint:wiki -- -v    # also lists orphans and empty-source pages

It covers broken links, index drift in both directions, missing aliases, dangling sources, and orphans. It exits non-zero on structural breakage and treats orphans and empty sources as reportable rather than failing, since a page written a minute ago is legitimately both. What follows is what it checks, for when you need to reason about a finding rather than just see it.

Orphans. Pages with zero inbound links from any other page. The index does not count — being listed is not being connected.

Broken links. [[Targets]] with no page of that title. Usually a rename that did not propagate, or a link written from the filename instead of the title.

Wrapped links. A [[link]] split across a line break does not resolve, and it reads as correct in the source — the only symptom is the target showing up as a broken link whose name contains a newline. Worth checking for explicitly, since hard-wrapped prose produces it constantly.

Index drift. Pages on disk missing from index.md, and index entries naming pages that no longer exist.

Dangling sources. A page whose sources frontmatter names a file that is not in {sources}/. Means the audit trail is broken.

Frontmatter violations. Missing tags, sources, created, updated, or aliases. Extra fields that are not in the schema. An empty sources list on anything but a synthesis page, which means the page is unsupported opinion.

Missing aliases. A page whose aliases does not contain its own # Title. This is the highest-value mechanical check in the list: links are written from the title while filenames are kebab-case, so a page without its alias cannot be linked to at all, and it will read as an orphan for a reason that has nothing to do with how well it is connected.

Naming. Filenames that are not kebab-case, titles that are not Title Case, links written as [[some-file-name]] instead of [[Some File Name]].

Step 3: The judgment checks

These need reading, not scripting.

Contradictions. Two pages asserting incompatible things. Report both, with the sources behind each. Do not resolve it yourself.

Stale claims. A page whose updated predates a source that bears on it. Especially where a newer clipping in {sources}/ was never worked into the pages it touches.

Missing pages. A concept, person, or tool named across three or more pages with no page of its own. That is the wiki asking for a page.

Missing cross-references. Pages that clearly relate and do not link. Common after a batch ingest where each source was filed without looking sideways.

Step 4: Report

Group by severity. Lead with counts so the trend is visible across runs.

Wiki health — [N] pages

Broken     [N] broken links, [N] dangling sources
Index      [N] pages missing, [N] stale entries
Orphans    [N] pages with no inbound links
Schema     [N] frontmatter violations, [N] naming violations
Judgment   [N] contradictions, [N] stale pages, [N] missing pages

Then list each finding with the file it is in and the specific fix. Be concrete — "add a link from [[A]] to [[B]]" beats "improve cross-referencing".

Step 5: Offer to fix

Mechanical fixes can be applied in a batch once the user agrees: index rebuilds, link-casing corrections, frontmatter backfill, kebab-case renames.

Judgment findings need the user. Contradictions in particular are theirs to resolve — picking a side automatically is how a wiki starts quietly lying.

Step 6: Log the pass

Append to {wiki}/log.md:

## [YYYY-MM-DD] lint | [N] pages checked
[N] orphans, [N] broken links, [N] contradictions. Fixed [what]. Left [what] for review.

Log every pass, including a clean one. The value is the trend: orphan count creeping up means ingests are being filed without linking sideways.

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.