菜单
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/.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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.
基于 SOC 职业分类
| 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.