agentleFS
Sign inStart free
walkcccwalkccc/CLRS/.agents/skills/triage/SKILL.md

triage

Skill5.1k starsChanged todayMITView on GitHub

Handle open issues and pull requests on walkccc/CLRS end to end — read them, fix or improve the solutions, open or update PRs, wait for CI, merge, and reply. Use when asked to go through, reply to, or clean up issues/PRs, or when pasted GitHub notification emails arrive.

  • Commits and pushes

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 179 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 6

    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:

    Wrong or incomplete solution: verify the math yourself. A contributor's PR that is right but incomplete gets a follow-up commit on their …

    line 22
  2. Distinctive:

    Correct PR: keep the contribution unchanged, normalize every commit message as described below, then merge.

    line 23
  3. Very specific:

    Commit subject and PR title are always Update <files>, exactly like the history: Update 33.1.md, Update 5-1.md, 5-2.md.

    line 29
  4. Very specific:

    If updating a published branch, use --force-with-lease with the expected old SHA.

    line 31
  5. Distinctive:

    Follow the conventions in AGENTS.md.

    line 33
  6. Very specific:

    Before landing, run python3 scripts/check_commit_messages.py <base-sha> <head-sha> --title "<PR title>".

    line 45
  7. Very specific:

    When merging is authorized, land the verified PR head with a normal fast-forward push to main.

    line 49
  8. Very specific:

    If the PR needs rebasing, use git rebase --committer-date-is-author-date origin/main, normalize its messages and timestamps, update the PR …

    line 51

“Common” is measured: kept by at least 6 in 10 of the 179 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

Triage issues and pull requests

Work through every item to a finished state: merged, closed, or answered. Do not stop at drafts.

1. Collect

gh issue list --state open --json number,title,author,createdAt
gh pr list --state open --json number,title,author,maintainerCanModify,headRefName

For each item read the body, comments, and diff (gh pr diff N). Check the claim against the source in docs/ and the live page at https://walkccc.me/CLRS/ChapXX/XX.Y/.

2. Decide

  • Rendering report: compare the live site with GitHub's preview. Screenshots of github.com/walkccc/CLRS/blob/... are GitHub's renderer, not the site. Fix the source only if one of them is actually wrong.
  • Wrong or incomplete solution: verify the math yourself. A contributor's PR that is right but incomplete gets a follow-up commit on their branch (when maintainerCanModify), not a replacement, so it merges with their credit.
  • Correct PR: keep the contribution unchanged, normalize every commit message as described below, then merge.
  • Wrong PR or report: reply with the concrete reason and close.

3. Change

  • Branch from origin/main; one branch per item.
  • Commit subject and PR title are always Update <files>, exactly like the history: Update 33.1.md, Update 5-1.md, 5-2.md. The complete commit message is that single subject line, with no body or trailers. This applies to every contributor commit, including fixup commits; editing the PR title alone is insufficient.
  • Before rewording, save the original branch tip in a backup ref. Preserve each commit's tree, author identity/date, and committer identity exactly. Set the committer timestamp to the original author timestamp, including its timezone offset. Never substitute the rewording or merge time. Verify the preserved fields byte-for-byte, verify exact author/committer timestamp equality, and verify an empty tree diff for every old/new pair. Preserve separate commits and contributor credit.
  • If updating a published branch, use --force-with-lease with the expected old SHA. Rewriting main requires a user request to do so; ordinary triage normalizes the PR branch before merging.
  • PR body: Closes #N when it resolves an issue, then what changed and why in a few sentences.
  • Follow the conventions in AGENTS.md.

4. Verify before pushing

npm run format
python3 scripts/check_math.py
mkdocs build --strict

For rendering changes, open the built page (mkdocs serve) and check the affected section.

Before landing, run python3 scripts/check_commit_messages.py <base-sha> <head-sha> --title "<PR title>". Resolve failures on the contributor's branch when maintainer edits are enabled; preserve the metadata above when rewording.

5. Land

When merging is authorized, land the verified PR head with a normal fast-forward push to main. Do not use gh pr merge --rebase or squash merge: GitHub assigns new committer timestamps. Keep the original author timestamps and set committer timestamps to those same values.

If the PR needs rebasing, use git rebase --committer-date-is-author-date origin/main, normalize its messages and timestamps, update the PR branch with an explicit lease, and wait for checks on that exact head again. Recheck the changed content after any conflict resolution.

gh pr checks N --watch
python3 scripts/check_commit_messages.py <base-sha> <verified-head-sha> --title "<PR title>"
git push origin <verified-head-sha>:refs/heads/main

The push must be a fast-forward; if main advances, fetch and rebase rather than forcing it. Verify that the PR is marked merged after the push. Merging to main deploys the site through Actions; confirm the run for the landed SHA passes with gh run list --branch main --limit 1.

6. Reply

Reply on every issue and PR you touched: thank the author, say what changed or why not, and link the PR or live page. Close issues that a merged PR did not close automatically.

Download now (ZIP)

  • Other versions191 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 191

    1. mattpocock/skills★ 309ksame name
    2. withastro/astro★ 64ksame name
    3. vectorize-io/hindsight★ 57ksame name
    4. ogulcancelik/herdr★ 47ksame name
    5. herdrdev/herdr★ 47ksame name
    6. colinhacks/zod★ 44ksame name
    7. QuivrHQ/quivr★ 40ksame name
    8. vercel-labs/skills★ 37ksame name
    9. pnpm/pnpm★ 37ksame name
    10. vercel-labs/add-skill★ 35ksame name

    181 more not listed

    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.

  • Used alongsideProjects with it also use setup-matt-pocock-skills, writing-beats and 10 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.
    • GoogleSkill

      setup-matt-pocock-skills

      Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

      Also in 148 projects that use this

    • LesaniSkill

      writing-beats

      Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

      Also in 58 projects that use this

    • liufeng1976Skill

      setup-ts-deep-modules

      Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

      Also in 33 projects that use this

    • SethGammonSkill

      ascii-diagram

      Generate perfectly aligned ASCII diagrams — architecture, flow, sequence, box-and-arrow. Uses a programmatic character-grid approach so alignment is guaranteed by math, not token prediction. Includes post-render verification.

      Also in 4 projects that use this

    • simo97Skill

      migrate-to-shoehorn

      Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

      Also in 59 projects that use this

    • FabienDehopreSkill

      decision-mapping

      Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.

      Also in 7 projects that use this

  • In this repository2 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.

Check your setup, free