菜单
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.
Stops an AI agent from declaring "done" on work it hasn't actually finished, by separating generation from evaluation and refusing self-graded completion. Use whenever an agent reports a task complete — especially in autonomous or long-running runs — to catch early termination, self-grading bias, and gamed tests before the work is trusted or merged.
| name | feature-flags |
| description | Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt. |
Deploying code and releasing a feature are different events, and conflating them is why launches are scary. A feature flag separates them: merge and deploy the code dark, then turn it on for 1%, a cohort, or everyone — and turn it off in seconds if it misbehaves, with no rollback deploy. The power comes with a cost: every flag is a branch in your runtime and a line of debt. This skill is how to get the control without drowning in permanent conditional spaghetti.
It's the delivery mechanism the rest of the lifecycle leans on: [[incremental-delivery]] merges work behind a flag, [[experimentation]] uses flags to split variants, and [[launch-readiness]] uses them for gradual rollout and instant kill. Pair with [[observability]] (watch the metric as you ramp) and [[simplify]] (remove the flag when done).
Skip when a change is trivial and safe to ship directly — a flag adds a code path to test and remove; don't flag a typo fix. Don't use flags to avoid ever finishing the work either (see debt below).
Not a substitute for [[launch-readiness]] (the full release gate) or [[migration-path]] (data/contract migration) — flags control exposure; those govern readiness and schema change.
Knowing the type up front tells you when (or whether) it dies. Most pain comes from release flags that never got removed.
Name for intent and direction (enable_new_checkout, not flag2). Default to off / the safe path —
a missing or failed flag lookup must fall back to current behavior, never to the half-built new one.
Both states ship in the binary, so both must work. Test flag-on and flag-off paths ([[test-first]]); CI should exercise both. Don't let the off-path rot — it's your rollback.
Ramp deliberately — internal → 1% → 10% → 50% → 100% — watching the primary and guardrail metrics at each step ([[observability]]). Define the kill condition before ramping (error rate, latency, a business metric) and confirm the off-switch actually works. A kill switch you've never tested is a hope, not a control.
Maintain a registry: each flag's owner, type, default, created date, and expected removal. A flag with no owner is a future incident. Stale release flags are tech debt with a security and correctness cost (dead code paths, surprising states).
Once a release flag is at 100% and stable, delete it and the losing code path ([[simplify]]). The task isn't done at full rollout; it's done when the flag is gone. Schedule removal when you create the flag, not "someday." Permanent flags (entitlement, kill switches) are the only ones that stay.
