一键导入
adr
Use when making significant technical decisions that should be documented — framework choices, architecture patterns, trade-offs, and migration decisions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when making significant technical decisions that should be documented — framework choices, architecture patterns, trade-offs, and migration decisions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when the user wants to free disk space, investigate disk usage, clean caches, remove unused artifacts, or when disk capacity is high. Also use when asked to "clean up", "free space", "disk full", or "what's using disk space". Always uses AskUserQuestion for every deletion decision.
Use at the start of every conversation and for every user message — orchestrates the full engineering skills suite by understanding intent, clarifying requirements interactively, and invoking the right skills
Use when refactoring Go code, cleaning up legacy codebases, optimizing performance, or enforcing clean architecture boundaries in a Go/Fiber backend
Use when refactoring Python code, cleaning up legacy codebases, optimizing performance, enforcing type safety, or improving clean architecture in a FastAPI backend
Use when refactoring React components, cleaning up legacy frontends, optimizing performance, improving component architecture, or reducing bundle size
Use when reviewing changed code before committing or after completing a feature — checks performance, architecture, type safety, and code quality against project standards
基于 SOC 职业分类
| name | adr |
| description | Use when making significant technical decisions that should be documented — framework choices, architecture patterns, trade-offs, and migration decisions |
Document why you chose one approach over another. Future you (and future Claude sessions) need this context.
Core principle: Decisions without documented reasoning get relitigated endlessly. Write it down once.
# ADR-[NNN]: [Decision Title]
**Status:** [Proposed | Accepted | Deprecated | Superseded by ADR-NNN]
**Date:** [YYYY-MM-DD]
**Deciders:** [who was involved]
## Context
[What is the situation? What forces are at play? What problem are we solving?]
## Decision
[What did we decide to do?]
We will use [choice] because [primary reason].
## Alternatives Considered
### Alternative A: [name]
- **Pros:** [list]
- **Cons:** [list]
- **Why not:** [decisive reason]
### Alternative B: [name]
- **Pros:** [list]
- **Cons:** [list]
- **Why not:** [decisive reason]
## Consequences
### Positive
- [benefit 1]
- [benefit 2]
### Negative
- [trade-off 1]
- [trade-off 2]
### Risks
- [risk 1] — mitigated by [how]
## Review Triggers
Revisit this decision when:
- [condition 1, e.g., "team grows beyond 5 engineers"]
- [condition 2, e.g., "traffic exceeds 10k req/sec"]
docs/
adr/
001-use-fiber-over-echo.md
002-clean-architecture.md
003-offset-pagination.md
004-generic-validation.md
005-monolith-first.md
| Decision | Key Trade-offs |
|---|---|
| Framework choice | Ecosystem, performance, learning curve, community |
| Monolith vs microservices | Complexity, deployment, team size, scaling |
| SQL vs NoSQL | Consistency, query flexibility, schema evolution |
| REST vs GraphQL | Client flexibility, caching, complexity |
| Sync vs async processing | Latency, reliability, complexity |
| Build vs buy | Cost, customization, maintenance burden |
| Offset vs cursor pagination | Simplicity vs performance at scale |
claude-md)system-design decisions, data-model schema decisionsgo-refactor / py-refactor to understand original intent