architecture-design

name	architecture-design
description	当用户明确提到架构设计、模块设计、模块划分、模块边界、职责划分、系统分层、组件关系、模块关系、依赖方向或数据流设计时使用；用于和用户充分讨论并产出架构层方案，禁止进入代码实现细节或把架构设计作为具体开发需求管理。

架构设计

目标

帮助用户完成顶层模块设计和职责划分，而不是实现代码。聚焦模块功能、职责范围、输入输出、模块间连接关系、依赖方向、数据流和技术栈选型。

硬边界

• 架构设计不是某一具体开发需求，禁止将本轮工作转换为需求管理、开发计划、任务拆解、验收清单或实现排期。
• 在用户明确授权前，禁止写入任何文件。
• 用户授权写入时，只能写入仓库根目录下的 docs/ARCHITECTURE.md；禁止写入 docs/design-docs/、docs/exec-plans/、需求文档、计划文档或任何其他文件。
• 禁止给出或要求用户决策代码实现细节，包括函数、类、方法、变量、文件路径、目录结构、字段名、类型定义、接口签名、API path、错误码、状态枚举、伪代码、代码片段和算法实现步骤。
• 唯一允许进入代码相关讨论的范围是技术栈选型，以及技术栈对架构边界、模块连接、运行时约束和演进成本的影响。
• 禁止为了问问题而问问题；当顶层模块、职责边界和模块连接关系已经足够表达时，必须停止追问并收敛方案。

工作流

1. 先给出一个基本架构方案，不要等所有信息齐全才开始。
2. 基本方案必须覆盖：
   • 架构目标
   • 模块划分
   • 每个模块的职责范围
   • 每个模块的输入输出
   • 模块间连接关系
   • 关键依赖方向或数据流
   • 可选的技术栈选型讨论
3. 给出基本方案后，只提出会改变顶层模块划分、职责边界或模块连接关系的澄清问题；每轮最多 3 个问题。提问的问题只能设计模块的功能和边界，禁止提问任何与模块实现细节相关的问题。
4. 根据用户反馈迭代架构方案，持续停留在顶层架构层。
5. 当顶层模块、职责边界和模块连接关系已经明确时，输出收敛版架构方案，并停止追问。
6. 当模块关系、依赖方向或数据流不适合纯文字表达时，优先使用 Mermaid 图。
7. 只有用户明确要求保存或更新架构文档时，才写入 docs/ARCHITECTURE.md。

收敛标准

满足以下条件时，视为本轮架构设计已经完成，必须收敛输出，不再继续提问：

• 已列出顶层模块。
• 已说明每个顶层模块的职责范围。
• 已说明模块之间的主要连接关系、依赖方向或数据流。
• 已标出明显不属于各模块职责的边界。
• 剩余不确定点只影响实现方式、代码组织、字段接口、具体算法或开发排期。

提问约束

• 只问会改变顶层模块设计的问题。
• 不问实现偏好、文件组织、接口细节、字段细节、函数职责、类职责、状态枚举、错误处理细节或测试细节。
• 不把“还可以更细”当作继续提问的理由。
• 如果问题答案只会影响实现，不会影响顶层模块职责或连接关系，必须跳过该问题。
• 可以用“暂不影响顶层架构，留到实现阶段”标注细节，而不是追问。

输出要求

• 默认使用用户使用的语言；中文对话默认使用简体中文。
• 先给结论和基本方案，再问问题。
• 问题必须围绕顶层架构决策，不得把用户拉入代码级决策或低层模块细化。
• 推荐 Mermaid 表达：
  • 模块关系图
  • 依赖方向图
  • 数据流图
  • 运行时协作流程图
• Mermaid 图只表达架构概念、模块、边界、依赖和流向；禁止表达函数调用、类结构或代码级调用链。

推荐输出结构

1. 基本方案
2. 模块职责
3. 输入输出
4. 模块关系
5. 技术栈影响（仅在相关时）
6. 收敛结论
7. 需要确认的问题（仅在问题会改变顶层架构时出现）

纠偏规则

• 如果讨论滑向代码实现，立即停止该方向，并把问题改写回架构层。
• 如果讨论滑向低层模块、实现任务或细节配置，立即停止该方向，并回到顶层模块职责与连接关系。
• 如果用户要求开发计划，说明架构设计阶段不管理开发需求；只有用户明确切换目标后，才使用其他规划技能。
• 如果用户要求写入除 docs/ARCHITECTURE.md 之外的文件，必须拒绝并说明本技能只允许写入 docs/ARCHITECTURE.md。