Keep a short and clear trade-off record for a small number of high-impact design decisions.
How to Use
/cx:cx-adr {决策标题}
/cx:cx-adr
Trigger Boundaries
Writing an ADR is recommended only in the following cases:
- L-scale feature
- Introduction of new technology or new infrastructure
- Obvious trade-offs exist in storage, communication, caching, or synchronization options
- Architectural decisions with high rollback cost and broad impact
Do not overuse ADRs for ordinary implementation details. When writing an ADR on the Claude Code side, it is still only supplementing documentation on the shared core, and does not change the lease of other runners. After the user explicitly confirms that an ADR is needed, the workflow is allowed to automatically connect to this skill.
Core Steps
Step 0: Locate the document directory
PROJECT_ROOT=$(git rev-parse --show-toplevel)
CX_DIR="$PROJECT_ROOT/开发文档/CX工作流"
FEATURE_TITLE="{功能标题}"
FEATURE_DIR="$CX_DIR/功能/$FEATURE_TITLE"
ADR_FILE="$FEATURE_DIR/架构决策.md"
Step 1: Collect decision context
- What problem needs to be solved
- What candidate options exist
- The benefits, costs, risks, and rollback difficulty of each option
Step 2: Associate PRD / Design
By default, associate existing documents in the same directory:
需求.md设计.md
Step 3: Generate a short decision record
The ADR keeps only these core contents:
- Background
- Candidate options
- Chosen result
- Scope of impact
- Rollback strategy
Step 4: Update feature document associations
In the feature's 状态.json , add:
{
"docs": {
"prd": "需求.md",
"design": "设计.md",
"adr": "架构决策.md"
}
}
If there is no clear architectural decision, do not force-write an ADR just for process completeness.