메뉴
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.
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 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.
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.
| name | buy-vs-build |
| description | 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. |
Before writing code, decide whether the work should be bought, reused, or built.
First classify it: core (differentiation) or context, and commodity (stable) or novel. Reuse context and commodity work; build in-house only where core meets novel. Scale scrutiny to reversibility.
Stop at the first rung that satisfies the requirement:
For non-obvious decisions, compare fit, ownership, cost, security, licensing, maintenance, integration, maturity, and exit risk. Preserve validation, security, privacy, accessibility, observability, and explicit requirements.
