菜单
Use when a non-obvious buy-vs-build decision was just made and should be recorded durably, or when a project keeps a docs/decisions/ log of Architecture Decision Records (ADRs) for build/buy/reuse and dependency choices.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when evaluating whether to adopt a specific open-source or commercial dependency (npm/PyPI/etc. package or library) — to research its fit, maintenance and health, security and supply-chain risk, license, and footprint before taking it on.
Use when reviewing a code diff, pull request, or local changes for buy-vs-build mistakes, avoidable custom code, unnecessary dependencies, missed built-ins, missed platform features, or weak decision notes.
Use when choosing between options at the same ownership rung — a transport, API style, data store, job/async mechanism, integration pattern, or cache — and you want the one that fits the requirement's real shape (directionality, volume, latency, consistency, failure mode) rather than the most powerful, popular, or familiar default.
Use when coding, designing an implementation, choosing dependencies, adding features, reviewing diffs for custom code, evaluating whether to use built-ins, standard libraries, native platform features, installed packages, open source libraries, commercial services, or an in-house implementation.
Use when choosing between built-ins, standard libraries, native platform features, installed packages, open source libraries, commercial products, or in-house implementation for a feature or technical design.
Use when coding, designing implementations, choosing dependencies, or reviewing whether a task should use built-ins, platform features, installed packages, open source, commercial services, or in-house code.
| name | buy-vs-build-adr |
| description | Use when a non-obvious buy-vs-build decision was just made and should be recorded durably, or when a project keeps a docs/decisions/ log of Architecture Decision Records (ADRs) for build/buy/reuse and dependency choices. |
Capture non-obvious buy-vs-build decisions as Architecture Decision Records so the reasoning — and the trigger to revisit it — survives the pull request.
Record an ADR when a decision is non-obvious or hard to reverse:
Skip it for obvious, trivial, easily reversible choices. An ADR is a few sentences, not an essay — it mirrors the one-line decision note the rule already produces, just durable and reviewable.
ADRs live in docs/decisions/, numbered sequentially as NNNN-title.md. Use the next free number. Either run the helper:
node scripts/record-decision.js \
--title "Use Server-Sent Events for the live feed" \
--rung native-platform \
--decision "Stream updates with SSE over HTTP." \
--rejected "WebSockets, because the feed is one-way and full-duplex is unused." \
--revisit "the feed needs bidirectional messaging."
…or, if no helper is available, create docs/decisions/NNNN-title.md by hand with this shape:
# NNNN. <title>
- Status: Accepted
- Date: <YYYY-MM-DD>
- Rung: <do-nothing|built-in|native-platform|installed-dependency|open-source|commercial|in-house>
## Context
<requirement and constraints>
## Decision
<the option chosen>
**Tradeoff:** <why it wins>
**Rejected:** <next-best option> because <constraint>
## Consequences
Revisit if <specific trigger>.