# Tool Triage > Triage a discovered tool/repo/skill/paper into PORT / ADOPT / WATCH / PASS for a named target, bloat cost counted; proposes first, executes on OK. Use for 'tool-triage X', 'should I adopt/port X', 'evaluate this tool'. ai-radar FINDS; this DECIDES. - Skill: `dylanpulver/tool-triage` (Agent Skill) - Install (CLI): `npx skillmds@latest add dylanpulver/tool-triage` - Raw SKILL.md: https://api.skillmd.com/api/skills/dylanpulver/tool-triage/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dylanpulver (https://skillmd.com/u/dylanpulver) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dylanpulver/tool-triage --- # 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 0. **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. 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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.