用途
Architecting Solutions 是一个架构设计能力技能，目标是在任何实现开始之前，深入分析问题并产出清晰的规格说明。它适用于用户提出“我应该怎么做”“最好的方式是什么”这类设计问题、讨论系统架构、将复杂功能拆解为组件、在多种实现方案之间做选择、规划新功能或重构，以及涉及模块化、结构或模式的问题。
核心哲学
- 奥卡姆剃刀：方案应尽可能简单，但不能过于简单。
- 信任涌现：复杂系统最好由简单组件构成。
- 分析优先：始终先分析再实现。
- 设计先于代码：清晰的规格指导成功的实现。
主要能力
该技能按以下流程工作：
- 问题分析：以“让我分析这个问题并设计解决方案”开始，提供问题分解、核心需求、约束（技术、性能、可维护性）以及成功标准。
- 方案选项：给出 2-3 种方法，并说明描述、优点、缺点、复杂度与可维护性。
- 推荐：给出明确选择，包含所选方案及理由、风险评估与缓解、以及何时考虑其他选项。
- 模块规格：为每个组件按模板创建规格，包括用途（一句话单一职责）、契约（输入、输出、副作用）、依赖、实现说明与测试要求。
决策框架
按顺序提出以下问题：是否真的需要它、是否有更简单的替代方案、能否用现有组件解决、能否更模块化、是否易于重新生成、复杂度是否带来价值。
模块设计原则
- 单一职责：每个模块一个清晰目的，能用一句话描述，只因一个原因变化。
- 清晰契约：显式输入输出，记录副作用，定义错误条件，说明性能特征。
- 自包含：所有模块代码在一个目录中，隐藏内部实现细节，依赖最小化，可独立理解。
- 可重新生成：规格即事实来源，可从零重建，无隐藏的团队知识，决策有清晰文档。
使用方式
该技能会调用 Architect Agent（核心架构推理来自 ~/.amplihack/.claude/agents/architect.md），参考 Templates/ModuleSpec.md 获取详细规格格式，参考 Specs/DesignPatterns.md 获取常见解决方案。在极其复杂的架构决策时可升级到 /ultrathink；当存在多个有效方案且需要团队输入时升级到 /consensus；设计完成后将规格交接给 Builder Agent 进行实现。
适用场景
- 用户提出设计或架构问题。
- 将复杂功能拆解为组件。
- 在多种实现方案之间做选择。
- 规划新功能或重构。
- 涉及模块化、结构或模式的问题。
常见模式与不适用场景
适用模式包括：分层架构（UI、业务逻辑、数据清晰分离）、管道模式（顺序数据转换步骤）、插件架构（未来需求未知的可扩展系统）、观察者模式（多个组件需要对事件做出反应）、仓储模式（将数据访问从业务逻辑中抽象）。
不适用场景包括：微服务（除非有团队或扩展问题，应先从单体开始）、事件溯源（除非审计追踪是核心需求）、复杂抽象（除非模式重复出现 3 次以上）、过早优化（除非性能分析显示瓶颈）。
输出格式
始终按以下结构组织架构分析：问题陈述（2-3 句）、需求与约束（项目符号列表）、方案选项（2-3 种方法及权衡）、推荐（明确选择及理由）、模块规格（详细契约）、下一步（交接给构建者或迭代设计）。
应避免的反模式
架构宇航员（对简单问题过度工程）、金锤（对所有问题使用同一模式）、过早优化（在性能分析前优化）、简历驱动开发（无理由使用时髦技术）、非我发明（重建已有解决方案）、分析瘫痪（无休止争论而不做决定）。
成功标准
好的架构设计应能用简单术语解释、明确权衡、提供清晰实现路径、预见常见变化、最小化偶然复杂度、聚焦本质复杂度。
限制
该技能的具体安装方式、运行环境要求、收费与价格、平台支持等信息在提供的资料中暂未提供。