// Use when evaluating a library, framework, or external service for adoption. Walks evaluation axes (fit, maintenance, license, footprint, integration cost) and produces a recommendation with explicit trade-offs. Output goes under docs/research/.
Use to decide when to invoke the Claude Code CLI and how. Claude specializes in deep reasoning — plans, hypercritical reviews, multi-file impact analysis, and pipe-fed log analysis. Includes invocation patterns and cross-check usage with Codex.
Use when an architectural decision has been made or is about to be made. Decides whether the decision belongs in docs/DESIGN.md, what level of detail to record, and what NOT to record. Operates as a judgment skill, not a fixed procedure — for the procedure see the update-design workflow.
Use when reviewing a diff, a PR, or a series of recent commits. Produces a severity-graded report covering correctness, security, performance, concurrency, maintainability, and Definition of Done compliance. Pairs well with pipe input and with Codex cross-checks.
Use when a bug is reported, a test is failing, or production is misbehaving. Provides observation patterns and diagnostic moves rather than a fixed sequence — every bug has its own shape. Pairs naturally with pipe-fed log analysis.
Use to decide when to invoke the Codex CLI and how. Codex specializes in tight iterate-loops, small refactors, lint cycles, and test additions. Includes invocation patterns and anti-patterns.
Use before writing any non-trivial code. Produces a written plan that names every file to touch, the order of work, the test strategy, the rollback path, and the open questions. Code is not written during this skill.
| name | research-lib |
| description | Use when evaluating a library, framework, or external service for adoption. Walks evaluation axes (fit, maintenance, license, footprint, integration cost) and produces a recommendation with explicit trade-offs. Output goes under docs/research/. |
A library is a dependency you can't easily uninstall. Evaluate it as such.
For each candidate, score on these axes. "Score" is a one-line verdict, not a number.
Write to docs/research/<YYYY-MM-DD>-<lib-name>.md:
# <library> evaluation
Problem: <one sentence — what we'd use it for>
Candidates considered: A / B / C
Scores
- Fit: ...
- Maintenance: ...
- License: ...
- Footprint: ...
- Integration cost: ...
- Exit cost: ...
Recommendation: adopt | reject | revisit in <N months>
Trade-offs accepted: <bullet list>
Trade-offs rejected: <bullet list>
update-design workflow.