菜单
Generate Architecture Decision Records that capture the reasoning behind technical decisions. Use when the user asks to "create an ADR", "document a decision", "record why we chose X", or discusses architectural trade-offs worth preserving.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Review what agents accomplished, surface loose ends across sessions
Reflect on recent work—capture learnings and surface what to think about next
Post-op check for artifacts, damage, and stale references after agent work
Survey the project and choose what to play next
Create Excalidraw diagrams programmatically. Use when the user wants architecture diagrams, system designs, flowcharts, or any visual diagram with a hand-drawn aesthetic. Outputs editable .excalidraw JSON files. Best for architecture overviews and presentations where the hand-drawn style and drag-and-drop editing add value over Mermaid's text-only approach.
Create diagrams and visualizations using Mermaid.js v11 syntax. Use when generating flowcharts, sequence diagrams, class diagrams, state diagrams, ER diagrams, Gantt charts, user journeys, timelines, or any of 24+ diagram types. Supports CLI rendering to SVG/PNG/PDF, theming, and configuration. Essential for inline documentation diagrams that render natively on GitHub.
| name | adr |
| description | Generate Architecture Decision Records that capture the reasoning behind technical decisions. Use when the user asks to "create an ADR", "document a decision", "record why we chose X", or discusses architectural trade-offs worth preserving. |
Generate an Architecture Decision Record (ADR) based on the conversation context and any architectural decisions discussed.
Create a markdown file with this structure:
# ADR-[NUMBER]: [TITLE]
**Date:** [YYYY-MM-DD]
**Status:** [Proposed | Accepted | Deprecated | Superseded]
**Deciders:** [Who was involved]
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
### Positive
- [Benefit 1]
- [Benefit 2]
### Negative
- [Trade-off 1]
- [Trade-off 2]
### Risks
- [Risk and mitigation]
## Alternatives Considered
### [Alternative 1]
- **Description:** What was this option?
- **Rejected because:** Why didn't we choose it?
### [Alternative 2]
- **Description:** What was this option?
- **Rejected because:** Why didn't we choose it?
## References
- [Related PR, issue, or document]
- [Relevant discussion or prior art]
Extract from context — Use the conversation to identify:
Find the ADR location — Look for existing ADRs:
docs/adr/ or docs/decisions/adr/ at project rootdocs/adr/Number appropriately — Check existing ADRs and use the next number
Write concisely — ADRs should be scannable:
Capture the why — The decision itself ages; the reasoning stays valuable
/research — Research informs the decision; ADR captures it/review — Reviews that surface architectural decisions belong in ADRsskills/FRAMEWORKS.md — Full framework index