원클릭으로
no-new-abstraction
Enforces the Rule of Three — a new abstraction requires three existing, real call sites before it is created.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Enforces the Rule of Three — a new abstraction requires three existing, real call sites before it is created.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Detects files that always change together, exposing hidden coupling that inflates Lead Time for Change and makes every PR bigger than it needs to be.
Generates a deployment-specific checklist before any code ships, covering rollout, monitoring, communication, and rollback. Directly reduces Change Failure Rate and Mean Time to Restore.
Requires a feature flag for any user-facing change, giving teams an instant kill switch without a deployment.
Identifies flaky tests in the affected test suite before shipping, because flaky tests kill Deployment Frequency by making CI untrustworthy.
Blocks shipping code where test coverage for changed files drops below threshold, and flags untested paths that directly raise Change Failure Rate.
Detects breaking changes to public APIs, interfaces, and exported symbols, and blocks shipping without a migration path.
| name | no-new-abstraction |
| description | Enforces the Rule of Three — a new abstraction requires three existing, real call sites before it is created. |
| when_to_use | Apply automatically whenever new interfaces, base classes, shared utilities, hooks, composables, or generic wrappers are proposed. |
Premature abstraction is the most common form of technical debt in AI-generated code. A model that sees two similar things immediately wants to extract a shared interface. That instinct is wrong more often than it is right, and the cost compounds every time a future engineer has to understand the abstraction before they can make their change.
This skill enforces a single rule: a new abstraction requires three real, existing call sites.
Before creating any of the following, you must demonstrate three existing call sites that would concretely benefit from the abstraction:
"Call sites" means code that exists right now in the codebase. Not code you are about to write. Not hypothetical future use cases. Not "the next engineer will probably need this."
When a new abstraction is proposed, run this check and output the result:
## Abstraction Gate: [proposed abstraction name]
### Existing Call Sites Found
1. [file:line] — [one sentence describing how this site would use the abstraction]
2. [file:line] — [one sentence describing how this site would use the abstraction]
3. [file:line] — [one sentence describing how this site would use the abstraction]
### Verdict
[APPROVED — 3 real call sites confirmed]
[BLOCKED — only N call sites found]
If fewer than three call sites exist, output this instead:
## Abstraction Gate: BLOCKED
Only [N] real call site(s) found for [proposed abstraction].
The Rule of Three is not met. Proceed with inline implementation.
When a third real call site emerges naturally, revisit the extraction.
The right time to abstract is after the third duplication, not before the second.
When the rule blocks an abstraction, implement the logic inline at the call site. Do not create a "temporary" version of the abstraction to work around the gate. Temporary abstractions become permanent ones.
Leave a comment at the inline implementation:
// NOTE: inline by design — extract when 3 real call sites exist (Rule of Three)
One valid exception: abstractions required by the framework or language idiom (e.g., React context for global state, an interface required to satisfy a third-party type contract). These must be documented as framework-required, not design-driven. They still require a written justification in the ADR.
Every abstraction is a contract. Contracts constrain the future. A well-timed abstraction (three proven use cases) is knowledge crystallized into code. A premature abstraction (one use case with guesses about the future) is speculation crystallized into a maintenance burden.
An AI that abstracts eagerly is building a maze for the next human engineer.