should-i-uselisted

# should-i-use Evaluate a candidate — a tool, library, repo, URL, article, pasted text, or image — for adoption in the **current project**. Produce one structured verdict. Be a critical advisor, not a hype amplifier: most candidates do not belong. ## Input The candidate arrives in any form. Normalise it first: - **Repo / tool** — resolve the default branch first (`gh api repos/<owner>/<repo> --jq .default_branch`), then fetch the README from it. Never assume `main`: a repo whose default branch is a working branch will serve you a stale `main`, and you will assess a version nobody installs. Record the HEAD SHA; every later claim is about that commit. Note language, runtime, dependencies, licence. If the tool is already installed locally, diff the install against that SHA before assessing. They drift. - **URL / article** — fetch it. Extract what the thing *is*, not the author's enthusiasm. - **Pasted text** — read it as given. - **Image** — read it visually; identify the tool, architecture, or screenshot shown. If the candidate is ambiguous, ask one clarifying question before assessing — never guess what it is. **Check for a missing half.** If the candidate delegates part of its job to a companion ("apply the X skill", "requires Y"), you were handed a system and shown one piece. Ask for the rest before judging: a verdict on half a system is a verdict on the wrong thing. ## Does this project have the problem? Answer this before anything else. If the project