메뉴
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | additive-default-off-feature-flags |
| description | Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior. |
When you introduce a new capability to a system that already works, gate it behind a switch whose default reproduces the existing behavior exactly. The proven path stays untouched; the new path is opt-in, reversible, and carries no standing cost until someone deliberately turns it on.
Apply this whenever you add a feature to code, infrastructure, or a pipeline that real users or other systems already depend on:
Red-flag thoughts that mean STOP and apply this skill:
cache=None, verify=False, RAG_ENABLED=false, TELEMETRY_ENABLED=false, enable_cloud_sql=false. If the default changes any observable behavior, it is not default-off.A working system is an asset you've already paid for in testing, debugging, and user trust. A new feature is a hypothesis. Coupling the hypothesis to the asset means a flaw in the new code becomes an outage in the proven code — and the only way back is a revert under pressure. A default-off seam decouples the two: you can merge, deploy, and even ship the new path to a fraction of traffic while the baseline keeps serving everyone else. Reversal is flipping a switch, not a rollback. The cost of skipping this is paid exactly when you can least afford it — in production, on the path everyone relied on.
On the project this was distilled from — a hexagonal, human-in-the-loop AI agent deployed to a cloud platform — a cost-tracking cache was added to the core use case as an optional collaborator. The design note stated plainly: "Default None preserves current behaviour and tests" (cost-cache design spec, §3). With cache=None, the use case ran exactly as before and its entire existing test suite passed unmodified; only the cache-enabled path got new tests.
The same team applied the second condition on a retrieval-augmented feature, documenting that "the feature is purely additive and off by default" (retrieval doc, §Wiring) and gating it on both RAG_ENABLED being true and the index file existing — so an unconfigured or half-provisioned environment silently fell back to the baseline rather than failing.
The discipline also caught a regression: an evaluation harness showed that a "skeptic verify" pass regressed quality (eval calibration record, §judge-calibration: skeptic pass REGRESSES → SHIPPED OFF; temperature 0.2 shipped as the measured win). Because it had been built as a default-off seam, shipping it OFF cost nothing, and the measured win (a low-temperature setting) was shipped in its place. Had verify been on by default "because it was the plan," the baseline would have shipped worse. You do not need to know any of this project's specifics to apply the pattern: optional collaborator, default = prior behavior, old tests green, double-gate the risky bit.
What a machine can check: that off is really off. A golden-default regression test pinned before the feature lands — with every new flag unset, observable behavior equals the prior release's; a config lint requiring every new knob to declare an explicit default; the default asserted off in one test line that a flipped default turns red. Whether the capability should be additive is design judgment; whether the default path changed is not.
Related skills:
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
Use when a value (project id, model, threshold, rubric) would be duplicated across Makefile, scripts, docs, and code — collapse to one source.