evaluate-techlisted

<!-- Generated from https://github.com/nielsmadan/agentic-coding — edits here are overwritten. --> # Evaluate Tech Adopting a library, tool, or service is a decision you live with, not a lookup. This skill enforces the two things ad-hoc evaluation reliably skips: 1. **Maintenance health is checked for every candidate, upfront** — never discovered later because someone thought to ask. A recommendation that flips the moment "is it maintained?" comes up was never a recommendation. 2. **Your current implementation is not a constraint on the search.** Requirements get triaged into hard (eliminates) and soft (costs money). Anchoring on how the code happens to be written today is the main way good options get silently dropped. Applies to code dependencies, CLI/dev tools, and hosted services. The process is identical; only the criteria block differs. Not for learning how to use something already decided on, or open-ended research — that is `research-tech`. ## Workflow ### Step 1: State the job, without naming anything One sentence: *"We need something that ⟨capability⟩ so that ⟨outcome⟩."* No product names, no API shapes, no "like X but". If the request arrived as "should we use Zod?", reverse-engineer the job first — the answer changes when the job turns out to be "validate API responses at the boundary" rather than "validate everything everywhere". Then check what is already there: grep the manifest (`package.json`, `pubspec.yaml`, `pyproject.toml`, `Cargo.toml`, `go.mod`