dylanpulver Tool-triage — decide how a discovered thing enters the stack
Discovery skills (ai-radar, creative-hunt, sparks, daydream) FIND candidates. This one DECIDES what to do with one: port it, plug it in, watch it, or pass — for a named target, with the standing cost counted. Run it on any repo / tool / skill / paper / idea. Every verdict lands in a ledger so the setup compounds and never re-litigates. Sibling of ai-radar's Trial protocol; reuses its adopt/mine/skip vocabulary as ADOPT / PORT / WATCH / PASS.
Two phases — PROPOSE (default), then EXECUTE (only on the user's OK)
This skill does NOT auto-integrate. By default it runs Phase 1 only: assess, decide, design the smallest proving experiment, write the proposed ledger entry, and stop with a review summary — nothing built, nothing installed, nothing committed to a real repo. The user reviews the disposition + plan and says go (or redirects). Only then does Phase 2 run: execute the approved plan and report back. The gate is deliberate — adding tooling is easy to do and hard to undo, so the call gets human eyes before any code or dependency lands. (If the user explicitly says "just do it" / "port it now," run both phases in one pass.)
The core bias: PORT beats plug-in
There is such a thing as too much tooling, and it's the default failure mode, not a rare one. Every tool you ADOPT is a standing tax: a dep to update, maybe an MCP server loaded every session, tokens per turn, an auth secret, a supply-chain + prompt-injection surface, one more thing that breaks at 3am and that you don't control. So the default disposition is PORT — extract the mechanism into code you own: no dep, removable, and you actually learn the idea. Plug in only when rebuilding is genuinely expensive AND upstream is healthy AND the standing cost clears the bloat gate.
Don't over-correct into not-invented-here either: a mature, well-scoped, hard-to-rebuild tool (a real DB, a solver, a battle-tested SDK) is worth adopting. The gate is judgment, not a ban. But when it's a technique or a few-hundred-line idea — port it.
Run it (one candidate) — work the ladder, stop when a rung decides
- YAGNI gate. Does this capability need to exist in the setup at all? Already have it / a plain-English or already-owned equivalent does the job / the need is speculative → PASS with a one-line why. Most things stop here. That's a healthy run, not a failed one.
- Name the mechanism. Strip the implementation to the ONE transferable idea, in a sentence. Can't? Read the source (README / SKILL.md / the actual code) until you can. You're deciding on the mechanism, not the repo.
- PORT vs ADOPT.
- PORT (default) — reimplement the mechanism in your own code/skill. Prefer for techniques, small ideas, or anything you want to control and keep removable.
- ADOPT — install the external tool / dep / MCP / plugin. Only when rebuild is genuinely costly, upstream is healthy (maintained, real users, not one-author-abandoned), and it clears rung 4.
- Target. Name it — one of your active repos OR general setup (
~/.claude, your skills repo). Recurs across repos → build once as a shared util/skill. One-repo need → keep it local; don't globalize a single-use thing. - Bloat & reversibility gate (hard for ADOPT, light for PORT). Count the standing cost: new deps? always-loaded MCP / tokens-per-session? auth/secrets? injection or supply-chain surface? ongoing maintenance? And: can you rip it out in 5 minutes later? Low reversibility + high standing cost = strong mark against → downgrade ADOPT to PORT or WATCH. Sanity check: is the setup's total external-tool count still one you could explain to a new hire in a breath? If not, the bar to add another rises.
- Smallest proving experiment + leverage. The cheapest test that yields a REAL verdict (not the README's claim). Score leverage-if-it-works (1-5) and effort-to-test (1-5); high-leverage + low-effort jumps the queue.
- Record to the ledger. WATCH items get a concrete revisit trigger ("next time I touch the queue code", "if upstream crosses 1k stars / gets a second maintainer").
Batch mode
Given a list (or the ai-radar backlog / creative archive / a set of URLs): run rungs 0-1 FAST on everything, then rungs 2-6 only on survivors. Output ranked dispositions. Don't deep-eval anything that PASSed the YAGNI gate.
Ledger (the compounding memory)
Append one JSON line per decision to a ledger you keep (e.g. ~/.claude/integrations.jsonl):
{ "id","name","url","mechanism","disposition":"port|adopt|watch|pass","target","effort":1-5,"leverage":1-5,"bloat_risk":"low|med|high","reversible":true|false,"experiment","revisit","note","ts" }
Never re-litigate a logged decision without new evidence (a WATCH trigger fired; upstream changed materially). Past PASSes stop you re-evaluating; past PORTs record what you built and why. This ledger is why the setup gets smarter over time instead of just bigger.
End of Phase 1 — present for review, then STOP
Write the proposed ledger line, then hand the user a short review summary: the disposition, the target, the one-line mechanism, the standing cost you counted, and the smallest proving experiment. Stop there. Do not build, install, or commit to a real repo yet. Ask for a go / redirect. (WATCH and PASS are terminal — the ledger line IS the whole result; no Phase 2.)
Phase 2 — execute (ONLY after the user approves the disposition + plan)
- PORT → build the smallest version in the target, with one runnable check; update the ledger line with where
it lives +
done. - ADOPT → install in a scratch/target project first (never global on the first try), run the proving
experiment, THEN commit to the setup; if it came from ai-radar, set that item's status to
adopted. - Report what you did and the experiment's result (not the README's claim).
Don'ts
- Don't adopt on the README's word — run the experiment or mark WATCH.
- Don't globalize a single-repo need, or localize a cross-repo one.
- Don't let the external-tool count grow unexamined — the bloat gate is the point of this skill, not a formality.
- Don't re-decide a logged item without new evidence. Trust the ledger.