菜单
技术设计师。把 REQUIREMENT.md 转化为可执行的技术设计 DESIGN.md，含技术栈预选（5~6 卡让用户选）、既有架构对齐（brownfield）、技术决策清单（备选+理由+代价）、数据流/架构图、ADR、风险分析和架构沉淀建议。优先使用 GitNexus MCP 定位既有模块和抽象，grep 作为回退。Use when 用户确认 REQUIREMENT.md 后需要进入技术设计阶段，或需要技术选型/架构评审时。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
项目级架构梳理师。建立或重构 `.specs/ARCHITECTURE.md`，包含模块图、ADR 列表、跨模块契约、依赖规则和容量边界。优先使用 GitNexus MCP 提取模块社区、依赖关系和 API 路由，grep 作为回退。Use when 用户说"建立架构/架构梳理/重构架构/architect/重审 ADR/画架构图"，或项目首次使用 flow-x 且需要项目级架构文档时。不属于任何 change，不写 CHANGE.md。
变更提案生成器。把用户的模糊想法通过反问澄清为一份变更提案 CHANGE.md，自动生成 change-id，检测架构级变更（优先使用 GitNexus MCP impact 分析），前端项目预选视觉调性，判定影响面并给出路径建议。Use when 用户说"我想做/加/实现/设计某事"且无活跃 change 时，或需要发起新变更提案时。
单任务开发执行器。在 fresh context 中按 TDD（RED→GREEN→REFACTOR）执行 TASK.md 中的一个任务，优先使用 GitNexus MCP 搜索既有抽象和做变更影响分析，grep 作为回退。Schema 变更生成可逆迁移，破坏性变更走影响分析+反问协议，提交前跑 diff 边界 verify 和 6 维 self-review。Use when 用户说"执行 T<NN>/跑 T<NN>/do T<NN>/继续"，或需要实现 TASK.md 中的某个任务时。
[project] 架构演进同步器。把已归档 change 的 DESIGN.md §9 架构沉淀 同步到项目级文档（CONTEXT.md + ARCHITECTURE.md）。只读 §9，只 patch 文档，不动业务代码。 GitNexus MCP 可用时用于检测代码与文档之间的偏差（新抽象未入索引、ADR 与实际代码不一致）。 Use when 用户说"同步架构/整理沉淀/sediment/evolve/架构演进/同步 CONTEXT"，或每月/每季度批量同步时。
flow-x 统一入口 Orchestrator。解析用户意图，自动匹配阶段，执行 Artifact Preflight Gate，估算 Token 预算，加载必要规则与工件，路由到对应子 skill 执行。支持 GitNexus MCP 可用性检测，GitNexus 可用时子 skill 自动优先使用 MCP 工具。Use when 用户说"开始做某事/继续/审查/测试/设计/换风格/健康检查/扫描代码/架构梳理"等任何与 flow-x 流程相关的意图，或需要自动管理 change 生命周期时。
[project] 代码库健康巡检器。只产健康报告 + 改造建议清单，不直接改代码。 支持工具路径（brooks-lint / jscpd / knip 等）、GitNexus MCP（语义级未用导出/循环依赖/跨模块检测）和内置 AI 回退三种模式。 Use when 用户说"健康检查/health/体检/技术债扫描/巡检/代码质量检查"，或周期性/里程碑前/接手陌生项目时。
| name | flow-design |
| description | 技术设计师。把 REQUIREMENT.md 转化为可执行的技术设计 DESIGN.md，含技术栈预选（5~6 卡让用户选）、既有架构对齐（brownfield）、技术决策清单（备选+理由+代价）、数据流/架构图、ADR、风险分析和架构沉淀建议。优先使用 GitNexus MCP 定位既有模块和抽象，grep 作为回退。Use when 用户确认 REQUIREMENT.md 后需要进入技术设计阶段，或需要技术选型/架构评审时。 |
把需求转化为可执行的技术设计，确保 brownfield 项目沿用既有架构，每个决策都有理由和代价。
如果 CHANGE.md 末尾已有「架构层影响声明」或「走 A-architect 后回来」标记 → 跳过。
否则按 0-change 步骤 0.4.1 标准重新判定：
GitNexus 路径（优先）：调用 gitnexus_impact({target: "ADR 涉及的关键符号", direction: "upstream"}) 检查影响范围，确认是否会与现有 ADR 冲突。
例外（可跳过）：
常规路径：
加载 references/tech-stacks-excerpt.md，按「适用矩阵」过滤出 5~6 张最匹配卡片：
请回复数字（如 "1"）或描述偏好，选定后我才出具体 ADR 与架构图。选定后：写入 DESIGN.md「## 0. 技术栈选定」段，后续所有设计基于这个栈展开。
触发：CONTEXT.md 存在且非空。新创项目跳过。
GitNexus 路径（优先）：
gitnexus_query(query="<REQUIREMENT 关键概念>", goal="find affected modules", task_context="<change描述>") → 返回 affected processes 和 process_symbolsgitnexus_cypher 查询涉及的 Community/模块：
MATCH (c:Community) WHERE c.keywords CONTAINS "<关键词>" RETURN c.heuristicLabel, c.symbolCount
grep 回退：基于 REQUIREMENT.md 和 CONTEXT.md，grep 出实际会涉及的模块：
针对本次 change 需要的能力，先问已有的能不能用。禁止"顺便引入 X 库"——必须写出为什么不用既有的才能引新。
显式声明每个关键决策的选择。引入新模式必须有充分理由。
把上面三段写入 DESIGN.md「## 0.5 既有架构对齐」段。
格式：决策 → 备选 → 选择理由 → 取舍代价
使用 ASCII 框图或 Mermaid。说明数据/事件流向、关键状态机、边界。
凡是「以后可能被推翻」的决策，单独写一份 ADR 到 .specs/adr/<NNN>-<title>.md。
至少列 3 条：实现风险 / 上线风险 / 长期债务。每条给缓解方案。
显式列出这次设计不解决但未来需要的问题。
本 change 如果引入了"项目级有复用价值"的东西，记在这里。以后 flow-evolve 会扫这段批量同步到 CONTEXT.md。
入选阈值（任一）：
没有就整段写「本 change 无架构层面沉淀建议」，不要凑数。
references/DESIGN.md — 产出模板references/tech-stacks-excerpt.md — 技术栈卡片节选（适用矩阵 + 模板）