Architecture Skill

为软件架构设计提供方法论指导。

Rules

核心原则：权衡优先

架构的本质是 Trade-offs（权衡），不是画框图。每个决策都要回答：

• 为什么选 A 而不是 B？
• 这个决策在什么条件下会失效？

约束优先

开始任何设计前，先明确约束：

1. 时间与资源: 有多少时间？有多少人？
2. 技术债务: 必须用什么栈？有什么遗留包袱？
3. 运行环境: 读多写少？高并发？离线优先？

演进式设计

• MVP: 最小可行性产品，先跑起来再说
• YAGNI: You Aren’t Gonna Need It，不预设用不到的功能
• Gall’s Law: 复杂系统从简单系统演化而来，不要一开始就设计复杂架构

重构原则：Strangler Fig Pattern

禁止大爆炸式重写，使用渐进式替换：

1. 识别边界 (Identify Seams)
2. 建立测试 (Add Tests)
3. 最小修改 (Small Refactor)
4. 验证提交 (Verify & Commit)

Phases

Phase: Plan (新项目规划)

1. 需求解构: 将模糊需求拆解为核心实体和交互流程
2. 约束识别: 填写 ADR 模板的 Context 部分
3. 技术选型: 根据约束推荐技术栈，记录 ADR Decision
4. 蓝图绘制: 设计目录结构、模块划分、数据流向
5. 立即执行: 用 write_to_file 创建核心骨架

Phase: Design (方案设计)

1. 明确问题边界: 这个问题的范围是什么？
2. 分析当前状态: 现状是什么？痛点在哪？（先 find_code 定位）
3. 定义目标状态: 理想状态是什么？
4. 设计转换路径: 怎么从 A 到 B？
5. 记录 Trade-offs: 必须写 ADR！
6. 立即执行第一步: 不要等确认

Phase: Refactor (重构规划)

1. 使用 find_code(mode='impact') 分析修改影响范围
2. 评估 DICE 复杂度（Manager 已提供）
3. 按复杂度排序，优先处理高风险文件
4. 每次只改一个点，验证后再继续

ADR Template

当做出重要技术决策时，必须记录 ADR：

# ADR: [决策标题]

## Context (背景)
为什么需要做这个决策？当前痛点是什么？

## Decision (决策)
我们选择了什么？

## Rationale (理由)
为什么选择这个而不是其他？
- **Pros**: ...
- **Cons**: ...

## Consequences (后果)
这个决策带来什么影响？

## Alternatives (备选方案)
考虑过但放弃的方案及原因。

Anti-Patterns

• ❌ 画了框图但不解释为什么这么设计
• ❌ 选了技术栈但不记录理由
• ❌ 大爆炸式重写，不做渐进式迁移
• ❌ 预设复杂架构，违反 YAGNI