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** — fetch the README (`raw.githubusercontent.com/<owner>/<repo>/<branch>/README.md`); fall back to the repo page. Note language, runtime, dependencies, license. - **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. ## Project context Assess against *this* project, not in the abstract. Before judging: - Read the repo — stack, size, brownfield vs greenfield, and what tooling already exists (`package.json`, configs, `AGENTS.md` / `CLAUDE.md`, installed skills). - A candidate that fits a 300-file brownfield repo can be pure noise in a 5-file greenfield one. ## The six-part verdict Produce exactly these, as a compact structured block — tables over prose: 1. **What it is** — one paragraph. Problem it solves, runtime / dependencies, license. 2. **Status** — already present in this project? Overlaps with something already installed? Name the overlap explicitly. 3. **Added value** — con