菜单
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`.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | architecture-decision-records |
| description | 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 repository-local ./ADR.md as the source of truth for user-decided architecture and system design decisions.
Rules:
./ADR.md./ADR.mdAGENTS.md, ensure it tells agents to load ./ADR.md before creating a development planADR.md as repository-local accepted decision authority; keep cross-repository rules in root ARCHITECTURE.md and service-local desired behavior in SPEC.mdGood ADR content:
always SSR or deploy via KargoDo not use ADR.md as a dump for incidental implementation notes.
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 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.
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.