repo-triage
Skill2 starsChanged 7 days agoMITView on GitHub
Use when someone shares an open-source repo, library, model or tool — a link, a package, a benchmark — and asks whether it is any good, whether to adopt or install it, or whether to take it on as a dependency. Evaluates the candidate against MEASURED gaps rather than against its own pitch, and gives a verdict. Most verdicts should be no.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Data-Wise/crafttheir own version, first seen Oct 31, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Data-Wise/craft★ 4same 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 repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- starter/AGENTS.mdAGENTS.md
- context-stewardSkill
- hsi-operatorSkill
- system-mapSkill
- updateSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 31
Check the actual repo and the model card separately — they disagree more often than you would expect, and a model card's claim is not a …
- Distinctive: line 53
Ask what it needs, then check what is present.
- Distinctive: line 66
Not something you might have.
≈ “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.
Files
repo-triage
The failure mode this exists to prevent: adopting on enthusiasm rather than against a measured gap.
A shared link arrives with momentum behind it — stars, a launch post, a benchmark table. The pitch describes what the thing does. The only question that matters is whether it fixes something you have measured, and the honest answer is usually no.
Most verdicts should be no. A triage skill that finds everything useful is the same
defect as an assistant that approves everything. See ../hsi-operator/references/honesty-protocol.md.
The order matters. Cheapest kill first.
1. LICENSE — before anything else
The cheapest possible kill and the one most often skipped, because it takes ten seconds and feels like paperwork.
- No license at all is not permissive. It is all-rights-reserved. You may read it; you may not copy from it. Say that explicitly when recommending something as "a reference".
- Non-commercial (CC-BY-NC and friends) rules out anything touching a business.
- Check the actual repo and the model card separately — they disagree more often than you would expect, and a model card's claim is not a LICENSE file.
2. MATURITY — is there a thing here yet
created, pushed, stars against forks and commits, downloads for a model.
- A repo created today with two thousand stars is a launch, not a track record.
- Two commits and five months untouched is a satellite, not a project.
- Stars measure attention. Forks and downloads measure use. Prefer the second.
- Staleness is fatal for some things and irrelevant for others. A reference implementation can be three years old. Anything claiming to be more current than a training cutoff cannot be three months stale.
3. THE RUNTIME — does it run on the hardware you actually have
The check most often skipped, and the one that kills most confidently.
CUDA kernels on an AMD box. MLX on Linux. A GGUF that no installed runtime loads. A browser-only WebGPU build proposed as a server lane. A benchmark measured on hardware nobody here owns.
Ask what it needs, then check what is present. Do not reason from the architecture diagram. A recommendation is also a claim about the world.
4. READ THE SOURCE, NOT THE README
The README says what the author wants it to do. Read the file that does the thing.
The gap is routinely load-bearing: a document library pitched for offline use whose fallback path hands the document to a third-party API; a "memory" system whose annotations are off by default; telemetry enabled unless disabled.
5. DOES IT FIX SOMETHING YOU MEASURED
Not something you might have. Name the measurement, with its number.
"We have 4 unreadable documents out of 6,384" is a measured gap, and it tells you a better OCR model fixes almost nothing. "Our OCR could be better" is a feeling and it will approve anything.
If you cannot name the measurement, the honest verdict is "no gap identified", not "looks useful".
6. WHAT WOULD IT MAKE WORSE
The question nobody asks, and the one that produces the sharpest no.
- Does it dissolve a control you rely on? An abstraction that makes two providers interchangeable strings can erase a rule enforced by which provider you call.
- Does it add a processor to a data path? An intermediary makes a payload question strictly worse, never better.
- Does it default something on that you would not switch on deliberately?
- Does it create a second place for a fact that already lives somewhere?
- An MCP server for an app you can already script usually adds a socket, not a capability. Candidates tend to fall into three groups: a thin wrapper over a command-line tool you already drive; one that needs the app's window open, so it cannot run headless; or one that includes a tool running arbitrary code over a socket that stays open. Prefer driving the tool from a script, and install a server only for live, interactive work someone asked for.
The verdict
State one. Not a list of considerations.
- ADOPT — name the measured gap it closes and what you will remove if it works.
- STEAL A PATTERN — the common useful outcome. Take the idea, credit it, write none of its code. Check the license permits even this.
- NO — and say which step killed it. "Non-commercial license." "Needs CUDA, we are AMD." "Fixes nothing we measured." A no with a reason is reusable; a no without one gets re-litigated when the link is shared again.
- NOT YET — with the trigger that would reopen it, and the date.
Record every verdict, including no, in the same turn, where the project keeps decisions: the reason, and the condition that would reopen it. Next to any verdict on an AI tool, record what it sends out by default, its default telemetry, and how to install and pin it, each with the date you read it.
Separate the artifact from the product. "Do not install it, read three files and take two ideas" is a legitimate and common verdict.
Say what you did not check
A triage with no stated blind spot was not a triage. Name what you could not run, could not see, or took from the README rather than the source — and label a relayed claim as relayed.
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
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.