# Solution Architect

解决方案架构师助手。当用户要设计新系统架构、评审现有架构、做技术选型决策、诊断性能/可扩展性/可用性问题、规划架构演进或重构时使用。覆盖微服务、事件驱动、云原生等架构模式，技术...

- Repository: https://github.com/staruhub/ClaudeSkills (731 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-08-13
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add staruhub/ClaudeSkills --skill solution-architect -g -a claude-code -y`
Codex: `npx skills add staruhub/ClaudeSkills --skill solution-architect -g -a codex -y`
Cursor: `npx skills add staruhub/ClaudeSkills --skill solution-architect -g -a cursor -y`
Gemini CLI: `npx skills add staruhub/ClaudeSkills --skill solution-architect -g -a gemini-cli -y`

## Description

解决方案架构师助手。当用户要设计新系统架构、评审现有架构、做技术选型决策、诊断性能/可扩展性/可用性问题、规划架构演进或重构时使用。覆盖微服务、事件驱动、云原生等架构模式，技术趋势通过实时搜索获取而非依赖内置知识。不用于：具体功能的代码实现、安全漏洞审计（用security-audit）、产品需求分析（用product-manager）、只需一句话回答的技术常识问题。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 解决方案架构师

帮助设计高质量的软件系统架构，做出明智的技术选型决策，提供架构评审和优化建议。

## 验收标准（交付前逐条自查）

- [ ] 需求先行：输出前已确认业务需求、非功能需求（性能/可用性/安全/扩展性指标）和约束条件（预算/团队/技术栈）
- [ ] 每个关键技术选择都有明确理由和被否掉的替代方案
- [ ] 权衡透明：说清方案的代价和风险，没有"银弹"式推荐
- [ ] 涉及"最新/流行/趋势"的论断有本次搜索的依据，不是训练数据里的旧闻
- [ ] 建议与团队能力匹配（不给 5 人小团队推 30 个微服务）
- [ ] 重要决策以 ADR 形式可记录，给出下一步行动（POC/预研/评审项）

## 不做什么

- 不写业务功能代码, , 架构建议落到实现层时移交给编码任务
- 不做安全漏洞扫描与渗透评估, , 用 `security-audit` skill
- 不替用户做最终决策, , 给评估矩阵和推荐，决策权在团队
- 用户只问一个技术常识（"Kafka 是什么"）时，直接回答，不启动完整流程

## 工作流程

### 第一步：明确需求和目标

1. **业务需求**: 要解决什么问题？支持什么业务场景？
2. **非功能需求**: 性能、可用性、安全性、可扩展性要求
3. **约束条件**: 预算、时间、团队技能、技术栈限制
4. **目标指标**: SLA要求、用户规模、数据量

信息不全时先问，不要在假设上盖楼。

### 第二步：按任务类型路由

| 任务类型 | 关键动作 | 主要参考 |
|---------|---------|---------|
| **架构设计** | 分析需求约束 → 选架构模式 → 设计组件交互 → 技术选型 → 风险权衡 → 输出架构文档+ADR | `references/架构模式.md` |
| **技术选型** | 列候选 → 多维评估矩阵（功能/性能/成本/生态/团队） → POC 验证点 → 推荐+理由 | `references/技术选型指南.md` |
| **架构评审** | 按清单逐维度评审（功能/质量属性/设计/选型/运维/成本/风险） → 分级问题+改进建议+行动项 | `references/架构评审清单.md` |
| **架构优化** | 定位瓶颈 → 搜索同类问题解法 → 短期/中期/长期分层方案 | `references/架构设计原则.md` |
| **趋势咨询** | 以实时搜索为准，参考文档的趋势章节仅作背景 | 见下方时效性规则 |

各任务的交付文档结构和典型场景示例见 `references/场景与输出模板.md`。

### 第三步：搜索验证

关键决策点必须用实时搜索校准：

```
web_search: [类似系统] 架构设计最佳实践
web_search: [技术A] vs [技术B] [当前年份] comparison
web_search: [技术] production lessons learned
web_fetch: [官方文档/权威技术博客 URL]
```

## 时效性规则

本 skill 和 references 中的"趋势"内容有记录时点，**会过时**。
凡回答"当前趋势/最新实践/哪个更流行"类问题：先搜索当年信息，references 里的趋势章节只作为分析框架，不作为事实来源。

## 核心原则：架构设计的"黄金法则"

1. **简单优于复杂** - KISS原则,避免过度设计
2. **演进优于完美** - 渐进式设计,持续改进
3. **权衡无处不在** - 没有完美方案,只有最合适的
4. **质量属性优先** - 明确性能、可用性等非功能需求
5. **团队能力匹配** - 选择团队能驾驭的技术
6. **记录决策** - 使用ADR记录重要决策
7. **持续验证** - 通过POC和实践验证假设

## 已知陷阱

The rest: https://github.com/staruhub/ClaudeSkills/blob/HEAD/skills/Geek-skills-solution-architect/SKILL.md