메뉴
集成验证与归档执行器。跑全套自动化测试，引导人工 UAT，失败诊断并产 fix-plan（最多 3 轮自动重试），提名 LESSONS 到知识库，归档 change 到 archive/ 目录并更新 CHANGELOG.md 和 STATE.md。提交前用 GitNexus MCP 检测变更影响范围。Use when 用户确认 REVIEW.md 通过后需要进入集成验收阶段，或需要 UAT/归档/发布时。
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 时，或需要发起新变更提案时。
技术设计师。把 REQUIREMENT.md 转化为可执行的技术设计 DESIGN.md，含技术栈预选（5~6 卡让用户选）、既有架构对齐（brownfield）、技术决策清单（备选+理由+代价）、数据流/架构图、ADR、风险分析和架构沉淀建议。优先使用 GitNexus MCP 定位既有模块和抽象，grep 作为回退。Use when 用户确认 REQUIREMENT.md 后需要进入技术设计阶段，或需要技术选型/架构评审时。
单任务开发执行器。在 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 生命周期时。
| name | flow-integration |
| description | 集成验证与归档执行器。跑全套自动化测试，引导人工 UAT，失败诊断并产 fix-plan（最多 3 轮自动重试），提名 LESSONS 到知识库，归档 change 到 archive/ 目录并更新 CHANGELOG.md 和 STATE.md。提交前用 GitNexus MCP 检测变更影响范围。Use when 用户确认 REVIEW.md 通过后需要进入集成验收阶段，或需要 UAT/归档/发布时。 |
作为 Verifier + Release，完成集成验证、人工 UAT、失败诊断与修复、LESSONS 提名、归档。
提交前检测：归档前必须调用 gitnexus_detect_changes(scope="all") 验证本次 change 只影响预期符号和执行流。返回 HIGH/CRITICAL risk → 必须回 flow-review 重新审查。
npm test（或等价）npm run e2e（如有）tsc --noEmit / lint 等npm run build贴出每条命令的真实输出。任何失败立即进入「失败诊断」。
逐条读 TEST.md 的 UAT 脚本，向用户提问：
UAT-1：<场景>
前置：...
步骤：1. ... 2. ... 3. ...
通过 / 失败 / 描述问题：
记录每条 UAT 结果到 .specs/<id>/UAT.md。
任何失败（自动测试或 UAT）：
T-FIX-XX，含完整 verifyR2.6：自动重试 <= 3 轮。第 3 轮仍失败必须停下来要求人工决策。
扫本次 change 的所有 *-SUMMARY.md「决策与偏离」段，以及任何遗留的 *-PROGRESS.md「已排除方案」段。
按提名条件筛选：
把入选的失败按 LESSONS.md 条目格式追加到 .specs/LESSONS.md，编号续上 L-NNN。
复核现有 active 条目，看是否有本次 change 让它们 superseded 或 deprecated。
全部通过后：
.specs/<change-id>/ 移动到 .specs/archive/<YYYY-MM-DD>-<change-id>/.specs/CHANGELOG.md 追加一行（日期/change-id/摘要/PR 链接/新增 LESSONS 条目编号）STATE.md.specs/LESSONS.md——项目级常驻文件本 change 的 DESIGN.md §9 不在归档时立即合并到 CONTEXT.md。原因：单个 change 视角窄，容易把临时决策错升项目级。
正确做法：
.specs/CONTEXT.md如果用户用 git 流水线：
.specs/ 内文件归类到 PR 描述references/LESSONS.md — 提名条件与条目格式