菜单
Use when deciding whether a behavior change belongs in centralized policy, a shared abstraction, or a local call site. Prefer narrow high-leverage shared fixes for cross-cutting behavior.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | centralized-fix-selection |
| description | Use when deciding whether a behavior change belongs in centralized policy, a shared abstraction, or a local call site. Prefer narrow high-leverage shared fixes for cross-cutting behavior. |
When a bug or behavior spans multiple routes, handlers, pages, or integrations, look for the narrowest shared control point first.
Before deleting, renaming, or simplifying shared code, identify touched behavioral surfaces such as routes, DTOs, storage rows, events, commands, manifests, pages, packages, and tests. Do not use "forward-only" as permission to drop desired functionality. Preserve current external behavior unless the active request or authoritative docs require a desired-state change.
Evaluate the fix in this order:
Prefer centralized fixes when the behavior is governed by shared concerns such as:
Choose a local patch only when a centralized change would be unsafe, would violate an explicit spec, or the behavior is intentionally route-specific.
When proposing or implementing the fix:
Use when investigating root cause with the Five Whys method: gather evidence across the full problem space, ask five explicit why questions in sequence, and answer each why with a Because line that connects each cause to the prior answer.
Use when adding or repairing GitHub Actions release automation that builds multi-arch container images on semver tags, pushes them to GitHub Container Registry, updates example healthcheck manifests, creates GitHub releases, and documents the tag-only release process in RELEASE.md.
Use for complex, multi-factor incidents. Recursively split causes into binary branches, pursue one path to a single concrete fix, then backtrack through sibling branches and implement fixes one at a time until the issue-level check passes.
Use when you need to convert session history into reusable, repo-specific workflow skills from repeated service-specific discovery.
Use when adding, updating, or consulting repository-local `ADR.md` architecture decisions. Keep ADR authority user-owned and ensure planning flows load `./ADR.md` via `AGENTS.md`.
Use only at workspace root in a multi-service repo with authoritative `ARCHITECTURE.md` when deciding cross-repo ownership, compatibility, or service-to-service contracts. Do not use for service-local `SPEC.md` work.
