菜单
Builds in small, verified increments instead of one big batch. Use when implementing any feature or change — slice vertically, prove each step works, commit at green, then move to the next.
用 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."
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.
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.
| name | incremental-delivery |
| description | Builds in small, verified increments instead of one big batch. Use when implementing any feature or change — slice vertically, prove each step works, commit at green, then move to the next. |
Ship work as a series of small, working steps. Each increment compiles, runs, passes its tests, and could in principle be merged. Big-bang changes hide bugs until the end — when ten moving parts fail together and [[fault-recovery]] becomes a archaeology project.
Incremental delivery is how you keep reviewable diffs, known-good checkpoints, and fast feedback on risky ideas. It's not "move slower" — it's fail fast on small surfaces instead of slow at the finish line.
Default build skill: pair with [[test-first]] to prove each slice, [[work-planning]] to order slices, [[git-flow]] to commit at green, [[browser-checks]] for UI slices, and [[migration-path]] when each slice must stay backward-compatible.
Skip heavy slicing for truly trivial, isolated fixes (typo, single constant) — still run checks before push.
Start from [[spec-first]] or [[work-planning]]. List increments — each independently demonstrable.
Vertical slice (prefer): thin path through all layers that does one real thing end-to-end.
Slice 1: POST /orders with one hardcoded SKU → persists row → returns id (no payment)
Slice 2: Validate cart payload + real SKUs from DB
Slice 3: Payment redirect on success
Horizontal slice (avoid as first increments): whole layer with no user-visible outcome.
Bad first slices: "all models", "all API routes", "all CSS" — nothing works until the end
Walking skeleton / steel thread: smallest end-to-end path — even ugly — then harden and expand.
| Feature type | First slice example |
|---|---|
| API | One endpoint, happy path, real persistence |
| UI page | One section, real data, one state |
| Background job | Process one message type, log success |
| Migration | Expand schema nullable; deploy before backfill ([[migration-path]]) |
| Refactor | One module moved; all tests green; behavior unchanged |
Each slice should answer: "What can I demo or test after this?" If nothing — slice smaller.
Target increments that:
| Too big | Right size |
|---|---|
| Entire checkout flow | Guest can submit email on checkout step 1 |
| All admin CRUD | List view with pagination |
| "Implement auth" | Login form posts; session cookie set; protected route redirects |
If a slice feels large, split: data path then polish; read path then write path; happy path then error states ([[ui-craft]]).
For each slice, repeat until the spec is satisfied:
1. Define slice outcome — one sentence + how you'll verify
2. Implement minimum to reach outcome (pair with [[test-first]] when logic-heavy)
3. Verify immediately — tests, run app, browser if UI ([[browser-checks]])
4. Commit at green ([[git-flow]]) — one logical change
5. Integrate often — rebase/merge main; don't drift for days
6. Next slice
Verify before the next slice starts. A failure you ignore compounds — you won't know which slice introduced it.
Stop rule: If you've written a lot without running anything — stop, run tests, get back to green, commit or stash. Never stack unverified work.
Verification matches the slice — not always full suite theater:
| Slice type | Verify with |
|---|---|
| Logic / service | Unit/integration test ([[test-first]]) |
| API | Contract test + curl/httpie; check response body |
| UI component | Story or render test + [[browser-checks]] on wired page |
| Migration | Migration up on staging DB; row counts; app still boots |
| Config/deploy | CI green; smoke in staging ([[pipeline-ops]]) |
Demo the slice when possible — 30-second screen share beats "tests pass" for alignment.
For UI, don't wait until the whole page is pretty — prove the wiring early (data shows up, button does something).
Each green increment is:
One logical change per commit — not refactor + feature + lint fix in one blob.
WIP on private branch is fine; before PR, history should tell a story or squash per team convention.
Push slices regularly — laptop loss and silent drift are real risks.
Mixed diffs are unreviewable and unbisectable:
Commit A: extract OrderService (tests green, no behavior change)
Commit B: add tax calculation (tests new behavior)
Never "while I'm here" refactor across the feature unless refactor is its own slice first ([[simplify]] can guide cleanup passes).
Use temporary bridges to keep slices vertical without building everything:
Mark stubs clearly — ticket or comment linking to the slice that removes them. Permanent stubs become debt.
Expand-contract migrations: each expand/contract step is its own shippable increment ([[migration-path]]).
Long-lived branches are incremental delivery failure:
main daily (or more) — conflicts grow with timeIf integration hurts, slices may be too wide or branch lived too long — fix process, not blame git.
git log, CI historyTwo broken slices ahead = go back to last green, not forward faster.
New API feature
Slice: schema/migration expand → model + one endpoint happy path → validation/errors → authz → remaining endpoints → contract cleanup.
New UI page ([[design-handoff]])
Slice: route + skeleton layout → one section with real data → remaining sections → states (loading/ empty/error) → responsive/a11y polish → browser-check proof.
Replace legacy module
Slice: adapter calls legacy → move one caller → move next caller → delete legacy when zero callers ([[migration-path]]).
Performance fix ([[perf-budget]])
Measure → one bottleneck fix → measure again → commit. Don't bundle five optimizations.
Bug fix
Repro test ([[test-first]]) → minimal fix green → commit. Not bundled with nearby feature.
Spike / prototype
Time-box; throwaway or harden — if spike code ships, first slice after spike is "make it real" with tests, not more spike on spike.
AI-generated implementation
Treat output as untrusted: slice by slice, run tests each slice, reject 500-line dumps — regenerate in smaller chunks.