tech-evaluation

Tech Evaluation

Investigate a candidate library, dependency, or file format against a fixed question set, and end with exactly one verifiable recommendation -- never "it depends." A production decision recorded without cited evidence is a guess, not a finding; this skill exists to close that gap. Produces a schema-validated structured record plus a human-readable write-up in the project's dated findings directory (see Finding Record Layout for the exact path and shape).

Prerequisites

• A concrete technology to evaluate (an npm package, a file format, a spec) and, ideally, the alternatives already ruled out or being compared against.
• This skill REQUIRES the create-context-file skill to persist the human-readable finding, and the context-index skill to regenerate the index afterwards -- do not run this evaluation if neither is available in the current environment.
• A subagent capable of both web research and reading this repository's own source (to check integration/bundling fit against real code, not just documentation).

Mindset

A verdict without a cited source is a guess, not a finding -- the schema enforces at least one piece of evidence per question for exactly this reason. needs_more_research is a legitimate recommendation when the evidence is genuinely inconclusive, but it MUST NEVER be used to avoid picking a side when the evidence already points one way. One recommendation, not a comparison table with no conclusion: the point of this skill is to convert "it depends" into a decision someone can act on in production.

When to Use

• Choosing between candidate crates/dependencies for a specific integration point (e.g. a CLI-parser decision such as usage/usage-rs vs. clap, recorded in a dated plan under .context/plans/).
• A plan or ADR decision hinges on a factual claim about a library that keeps getting revisited because nobody wrote the answer down with evidence.
• The user explicitly asks to "investigate," "research," or "properly evaluate" a technology option mid-decision.