菜单
Record an architecture decision by creating, updating, or superseding an ADR after a significant, costly-to-reverse technical choice is approved.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Draft an academic paper or thesis in phases that survive peer review, from fitting the venue through shaping the contribution, storyboarding the skeleton, and writing the prose.
Pressure-test a paper at any phase, whether shape, skeleton, draft, or final, by reviewing it three ways at once, four when citations need checking against sources, then synthesize a mock notification with a phased revision list.
Build a single-file HTML slide deck in three light passes, content and mechanics first, then a unique visual identity, then the assembled deck, so revising the sequence never means regenerating the whole file.
Use after implementation is committed on a branch to open or update a PR, write the PR body, link work items, monitor checks, and handle CI feedback. Works for a feature or a standalone fix/perf/refactor.
Define how approved requirements will be implemented (service boundaries, APIs, data model, integrations, failure modes, technical contracts) before coding.
Explore how something should work before building it (product philosophy, component design, or feature behavior) and converge on an approved design.
| name | adr |
| description | Record an architecture decision by creating, updating, or superseding an ADR after a significant, costly-to-reverse technical choice is approved. |
| model | sonnet |
| effort | low |
Record a committed decision that is costly to reverse or that materially shapes system boundaries, data ownership, public APIs, infrastructure, auth or security posture, or migration strategy. An ADR captures a decision, not a discussion, so routine implementation details and tentative ideas stay out.
On the user's request, or proactively when architecture-design or grill-me approves a decision affecting:
Follow the repo's existing ADR convention. Absent one, use docs/adr/NNNN-short-title.md with the next four-digit sequence; existing ADRs keep their numbers.
# NNNN: Decision title
- Status: Proposed | Accepted | Superseded by [NNNN](#link)
- Date: YYYY-MM-DD
## Context
Why the decision is needed: the forces at play, constraints, and what happens without it.
## Decision
What was chosen, in one direct paragraph.
## Alternatives Considered
Required. Each viable alternative and why it lost. If only one option existed, why no other was viable.
## Consequences
Positive outcomes, costs, risks, and the follow-up work this creates.
## Traceability
- Requirements: [RF-XXX.N links from docs/srs.md, or "none"]
- Tracker: [work item reference, or "none"]
Proposed: recommended, not yet approved.Accepted: approved and in effect.Superseded: replaced by a newer ADR. Set this record's status to Superseded by [NNNN](link), mark the new one Accepted, and keep both.