القائمة
Architecture design skill: ADR records, system design checklists, scalability assessment, architecture patterns. Use for complex system design and architecture decisions.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Frontend patterns: component design, state management, performance, accessibility. Use when building web frontends, components, or client-side apps.
Git version control best practices: branching, commits, merging, conflict resolution, PR workflows. Use when managing branches, creating commits, merging code, or resolving conflicts.
Model selection strategy and routing. Use when choosing between models for different task types, subagent configurations, or optimizing token cost vs quality tradeoffs.
Security review skill: comprehensive security checklist and patterns. Use when adding authentication, handling user input, working with secrets, or creating API endpoints.
Extracts reusable patterns from sessions. Use at session end to capture debugging insights and project-specific knowledge.
Strategic compaction skill: suggests context compression at logical breakpoints. Use to suggest compaction at logical intervals during development sessions.
| name | architecture |
| description | Architecture design skill: ADR records, system design checklists, scalability assessment, architecture patterns. Use for complex system design and architecture decisions. |
| allowed-tools | Read, Write, Edit, Grep, Glob |
本技能提供架构设计的完整指南，包括 ADR 记录、设计检查清单、可扩展性评估、架构模式速查等最佳实践。
对于重要的架构决策，创建 ADR 记录：
docs/decisions/ADR-XXX.md)# ADR-XXX: [决策标题]
## 状态
Proposed | Accepted | Deprecated | Superseded by ADR-YYY
## 上下文
[描述导致这个决策的背景、问题或需求]
## 决策
[明确说明做出的决策]
## 理由
[解释为什么选择这个方案]
## 备选方案
### 方案 A: [名称]
- 优点: ...
- 缺点: ...
### 方案 B: [名称]
- 优点: ...
- 缺点: ...
## 后果
### 正面
- [好处1]
- [好处2]
### 负面
- [代价1]
- [代价2]
### 风险
- [风险1] → 缓解: [措施]
## 相关决策
- ADR-XXX: [相关决策]
## 日期
YYYY-MM-DD
| 场景 | 是否需要 ADR |
|---|---|
| 选择主要技术栈（框架、数据库） | ✅ 必须 |
| 定义核心架构模式 | ✅ 必须 |
| 引入新的外部依赖 | ⚠️ 视影响范围 |
| API 设计重大变更 | ✅ 必须 |
| 简单的实现细节 | ❌ 不需要 |
设计方案前，检查以下维度：
| 阶段 | 用户量 | 架构要求 |
|---|---|---|
| MVP | <1K | 单体应用足够 |
| 成长期 | 1K-10K | 优化数据库查询，添加缓存 |
| 扩展期 | 10K-100K | 服务拆分，读写分离 |
| 规模化 | >100K | 微服务，分布式缓存，多区域 |
| 瓶颈 | 解决方案 |
|---|---|
| 数据库读取慢 | 索引优化 → 读写分离 → 缓存层 |
| API 响应慢 | 异步处理 → 消息队列 → CDN |
| 内存不足 | 分页加载 → 流式处理 → 扩容 |
| 并发冲突 | 乐观锁 → 分布式锁 → 事件溯源 |
| 模式 | 适用场景 | 复杂度 |
|---|---|---|
| 分层架构 | 大多数 CRUD 应用 | 低 |
| 六边形架构 | 需要高可测试性 | 中 |
| CQRS | 读写负载差异大 | 高 |
| 事件溯源 | 需要完整审计轨迹 | 高 |
| 微服务 | 团队多、规模大 | 高 |
| 模式 | 适用场景 |
|---|---|
| 组件组合 | 构建复杂 UI |
| 状态提升 | 组件间共享状态 |
| Context + Reducer | 全局状态管理 |
| 自定义 Hooks | 复用有状态逻辑 |
| 渲染属性 | 灵活的组件复用 |
| 模式 | 说明 |
|---|---|
| Repository | 抽象数据访问层 |
| Unit of Work | 事务管理 |
| DAO | 数据访问对象 |
| Active Record | 模型直接操作数据库 |
在提交设计方案前：
/cc-best:lead 技术设计
↓
需要架构决策？
├─ 是 → 创建 ADR 记录
└─ 否 → 继续设计
↓
设计检查清单
↓
任务分解
↓
/cc-best:dev 开始实现
记住: 架构决策要记录理由——ADR 不是文档负担，而是未来自己和团队的决策参考。