@archsight/aios 1.0.0 → 1.0.1

package/runtime/skill-routing.md

@@ -1,63 +1,65 @@
-# Skill Routing
-
-## 定位
-
-本文件定义 ArchSight AIOS 中任务到 Skill、Agent 和 Workflow 的路由关系。
-
-基本关系：
-
-| 类型 | 含义 |
-| --- | --- |
-| Agent | 谁来做 |
-| Skill | 怎么做 |
-| Workflow | 什么时候做、按什么顺序做 |
-| Runtime | 在哪里运行 |
-
-## 默认路由表
-
-| 任务类型 | 推荐 Skill | 主 Agent | 推荐 Workflow |
-| --- | --- | --- | --- |
-| 项目立项、产品定位、商业目标、范围取舍 | `aios-ceo` | Janus | `review` |
-| 建筑行业平台界面方案、工作台体验、复核追溯和前端实现交接 | `aios-design` | Janus | `design-review` |
-| 架构评审、技术选型、服务边界 | `aios-arch` | Atlas | `architecture-review` |
-| Feature 拆解、交付计划、任务依赖 | `aios-plan` | Mason | `feature-development` |
-| PR / diff / AI 生成代码审查 | `aios-review` | Argus | `code-review` |
-| Bug 修复、测试失败、构建失败 | `aios-exec` | Hephaestus | `bug-fixing` |
-| BIM / IFC / 建筑规范 / 审图规则 | `aios-knowledge` | Vitruvius | `rag-pipeline` |
-| Prompt / Context / Memory / MCP / Tool | `aios-runtime` | Daedalus | `architecture-review` |
-| RAG / GraphRAG Pipeline | `aios-runtime` | Daedalus | `rag-pipeline` |
-| 受控代码修改、文档、脚本、测试 | `aios-exec` | Hephaestus | `feature-development` |
-
-## 路由原则
-
-- 优先按任务类型选择 Skill，而不是按 Agent 名称选择。
-- Skill 使用 `aios-*` 前缀，避免与通用技能包混淆。
-- 所有 `aios-*` Skill 都服务建筑行业平台研发；差异在任务分工，而不是行业归属。
-- `aios-ceo` 用于一把手视角的立项、定位、商业目标和范围取舍，不替代 `aios-arch` 的架构评审。
-- `aios-design` 用于实现前判断界面方案是否支撑建筑行业审查、定位、复核、追溯和交付；不替代 `frontend-generation` 的 UI 实现、布局验证和交互验证，也不替代通用 `frontend-design` 的视觉风格和前端代码美化评审。
-- `aios-arch` 应补足通用架构评审缺失的建筑行业平台视角，包括 BIM / IFC、规范知识链路、审图证据链、RAG / GraphRAG、任务编排、审计和后端运行可靠性。
-- Agent 可以调用多个 Skill；Skill 也可以被多个 Agent 复用。
-- 项目工作目录中的事实优先于 AIOS 的通用模板。
-- Hermes / 飞书只是可选入口和调度适配器，不替代本地验证，也不是 AIOS 的必要前提。
-
-## 升级规则
-
-- 涉及服务边界、数据模型、长期架构：升级给 Atlas。
-- 涉及立项、定位、商业目标和范围取舍：升级给 Janus。
-- 涉及页面方案、工作台体验、证据定位、复核追溯、交互状态和前端实现交接：升级给 Janus，并使用 `aios-design`。
-- 涉及任务依赖、交付顺序、CI/CD：升级给 Mason。
-- 涉及安全、权限、Prompt 注入、生产发布：升级给 Argus。
-- 涉及 BIM、IFC、规范条文和审图语义：升级给 Vitruvius。
-- 涉及 RAG、GraphRAG、MCP、Tool Calling、Memory：升级给 Daedalus。
-- 涉及具体代码、脚本、测试、文档执行：交给 Hephaestus。
-
-## 项目接入
-
-业务项目接入时，应复制 `templates/project-ai/`，并在 `.ai/skills.md` 中按项目实际情况启用 Skills。
-
-## 维护规则
-
-- 新增 Skill 时必须更新本文件。
-- 新增 Workflow 时必须更新对应路由。
-- 不允许将 Agent 定义直接改造成 Skill。
-- 不允许让 Runtime 配置直接承载复杂角色资产。
+# Skill Routing
+
+## 定位
+
+本文件定义 ArchSight AIOS 中任务到 Skill、Agent 和 Workflow 的路由关系。
+
+基本关系：
+
+| 类型 | 含义 |
+| --- | --- |
+| Agent | 谁来做 |
+| Skill | 怎么做 |
+| Workflow | 什么时候做、按什么顺序做 |
+| Runtime | 在哪里运行 |
+
+## 默认路由表
+
+| 任务类型 | 推荐 Skill | 主 Agent | 推荐 Workflow |
+| --- | --- | --- | --- |
+| 建筑行业软件 / 系统深度评价、项目立项、产品定位、商业目标、范围取舍 | `aios-ceo` | Janus | `review` |
+| 建筑行业平台界面方案、工作台体验、复核追溯和前端实现交接 | `aios-design` | Janus | `design-review` |
+| 建筑行业项目中的架构评审、技术选型、服务边界 | `aios-arch` | Atlas | `architecture-review` |
+| 建筑行业项目中的 Feature 拆解、交付计划、任务依赖 | `aios-plan` | Mason | `feature-development` |
+| 建筑行业项目中的 PR / diff / AI 生成代码审查 | `aios-review` | Argus | `code-review` |
+| 建筑行业项目中的 Bug 修复、测试失败、构建失败 | `aios-exec` | Hephaestus | `bug-fixing` |
+| BIM / IFC / 建筑规范 / 审图规则 | `aios-knowledge` | Vitruvius | `rag-pipeline` |
+| 建筑行业项目中的 Prompt / Context / Memory / MCP / Tool | `aios-runtime` | Daedalus | `architecture-review` |
+| 建筑行业知识库 / 工程知识 RAG / GraphRAG Pipeline | `aios-runtime` | Daedalus | `rag-pipeline` |
+| 建筑行业项目中的受控代码修改、文档、脚本、测试 | `aios-exec` | Hephaestus | `feature-development` |
+
+## 路由原则
+
+- 优先按任务类型选择 Skill，而不是按 Agent 名称选择。
+- Skill 使用 `aios-*` 前缀，避免与通用技能包混淆。
+- 所有 `aios-*` Skill 都服务建筑行业平台研发；差异在任务分工，而不是行业归属。
+- AIOS 是建筑行业增强层，不是通用任务替代器；普通非建筑任务优先使用宿主工具的通用能力，不强行套用 BIM、IFC、规范、审图或工程证据链假设。
+- 是否启用行业增强，先看项目 profile、`.ai/project-context.md`、README 和当前任务；不确定时先核验上下文，不凭 Skill 名称硬套。
+- `aios-ceo` 用于一把手视角的建筑行业软件 / 系统深度评价，把产品定位、行业专业性、工程可信度、证据链、商业验证和范围取舍放到同一决策框架里；它可以引用架构和行业语义事实作为 CEO 判断依据，但不替代 `aios-arch` 或 `aios-knowledge` 的专项设计与专业结论。
+- `aios-design` 用于实现前判断界面方案是否支撑建筑行业审查、定位、复核、追溯和交付；不替代 `frontend-generation` 的 UI 实现、布局验证和交互验证，也不替代通用 `frontend-design` 的视觉风格和前端代码美化评审。
+- `aios-arch` 应补足通用架构评审缺失的建筑行业平台视角，包括 BIM / IFC、规范知识链路、审图证据链、RAG / GraphRAG、任务编排、审计和后端运行可靠性。
+- Agent 可以调用多个 Skill；Skill 也可以被多个 Agent 复用。
+- 项目工作目录中的事实优先于 AIOS 的通用模板。
+- Hermes / 飞书只是可选入口和调度适配器，不替代本地验证，也不是 AIOS 的必要前提。
+
+## 升级规则
+
+- 涉及服务边界、数据模型、长期架构：升级给 Atlas。
+- 涉及建筑行业软件 / 系统深度评价、立项、定位、商业目标和范围取舍：升级给 Janus，并优先使用 `aios-ceo`。
+- 涉及页面方案、工作台体验、证据定位、复核追溯、交互状态和前端实现交接：升级给 Janus，并使用 `aios-design`。
+- 涉及任务依赖、交付顺序、CI/CD：升级给 Mason。
+- 涉及安全、权限、Prompt 注入、生产发布：升级给 Argus。
+- 涉及 BIM、IFC、规范条文和审图语义：升级给 Vitruvius。
+- 涉及 RAG、GraphRAG、MCP、Tool Calling、Memory：升级给 Daedalus。
+- 涉及具体代码、脚本、测试、文档执行：交给 Hephaestus。
+
+## 项目接入
+
+业务项目接入时，应复制 `templates/project-ai/`，并在 `.ai/skills.md` 中按项目实际情况启用 Skills。
+
+## 维护规则
+
+- 新增 Skill 时必须更新本文件。
+- 新增 Workflow 时必须更新对应路由。
+- 不允许将 Agent 定义直接改造成 Skill。
+- 不允许让 Runtime 配置直接承载复杂角色资产。

package/skills/README.md

@@ -1,38 +1,59 @@
-# Skills
-
-`skills/` 保存可复用能力插件。
-
-每个 skill 应沉淀为可重复执行、可验证、可治理的工作单元，而不是一句 prompt。Skill 是项目工作目录中的实际作业方法，Agent 是角色身份和职责边界。
-
-AIOS Skill 的差异化目标是让通用 AI Coding 工具在建筑行业平台研发中获得更专业的默认判断。所有 `aios-*` Skill 都继承这个行业取向；Skill 名称只表示任务分工，不表示只有某一个 Skill 才面向建筑行业。
-
-当项目涉及 BIM / IFC、建筑规范、智能审图、图纸 / 模型处理、RAG / GraphRAG、任务编排、审计证据链或长期平台演进时，`aios-ceo`、`aios-design`、`aios-plan`、`aios-exec`、`aios-review`、`aios-arch`、`aios-knowledge` 和 `aios-runtime` 都应把这些行业约束纳入判断。区别只是：`aios-ceo` 判断立项和商业目标，`aios-design` 判断界面方案能否支撑审查、定位、复核、追溯和交付，`aios-arch` 判断边界，`aios-knowledge` 判断行业语义，`aios-runtime` 判断 AI / RAG 运行时，`aios-plan` 拆交付，`aios-review` 查风险，`aios-exec` 做受控实现。
-
-当前采用兼容 Codex 和 Gemini 的最小标准结构：
-
-```text
-skills/
-└── skill-name/
-    ├── SKILL.md
-    └── agents/
-        └── openai.yaml
-```
-
-使用方式：
-
-- Codex：通过 `SKILL.md` frontmatter 的 `name` 和 `description` 自动识别触发。
-- Gemini：读取对应 `SKILL.md`，按其中的输入、工作流、输出格式和约束执行。
-- Hermes / 飞书：这是可选企业适配器。启用时可使用 `agents/*/system-prompt.md` 作为运行时提示词；需要执行项目任务时，再映射到这里的 skill。
-
-第一阶段核心技能包：
-
-| Skill | 用途 |
-| --- | --- |
-| `aios-ceo` | 项目立项、产品定位、商业目标、范围取舍和阶段路线评审。 |
-| `aios-design` | 建筑行业平台界面方案、工作台体验、证据定位、复核追溯和前端实现交接评审。 |
-| `aios-plan` | 交付计划、任务拆解、依赖和验证顺序。 |
-| `aios-exec` | 有边界地改代码、修 bug、更新文档、运行验证。 |
-| `aios-review` | PR、diff、AI 生成代码、安全、证据链和测试缺口审查。 |
-| `aios-arch` | 架构边界、技术选型、长期复杂度和方案评审。 |
-| `aios-knowledge` | BIM、IFC、建筑规范、审图规则和知识结构化。 |
-| `aios-runtime` | Prompt、Context、Memory、MCP/Tool、RAG/GraphRAG 和多 Agent Runtime 设计。 |
+# Skills
+
+`skills/` 保存可复用能力插件。
+
+每个 skill 应沉淀为可重复执行、可验证、可治理的工作单元，而不是一句 prompt。Skill 是项目工作目录中的实际作业方法，Agent 是角色身份和职责边界。
+
+AIOS Skill 的差异化目标是让通用 AI Coding 工具在建筑行业平台研发中获得更专业的默认判断。所有 `aios-*` Skill 都继承这个行业取向；Skill 名称只表示任务分工，不表示只有某一个 Skill 才面向建筑行业。
+
+当项目涉及 BIM / IFC、建筑规范、智能审图、图纸 / 模型处理、RAG / GraphRAG、任务编排、审计证据链或长期平台演进时，`aios-ceo`、`aios-design`、`aios-plan`、`aios-exec`、`aios-review`、`aios-arch`、`aios-knowledge` 和 `aios-runtime` 都应把这些行业约束纳入判断。区别只是：`aios-ceo` 做建筑行业软件 / 系统的一把手深度评价，把产品定位、行业专业性、工程可信度、证据链和商业验证放到同一决策框架里；`aios-design` 判断界面方案能否支撑审查、定位、复核、追溯和交付，`aios-arch` 判断边界，`aios-knowledge` 判断行业语义，`aios-runtime` 判断 AI / RAG 运行时，`aios-plan` 拆交付，`aios-review` 查风险，`aios-exec` 做受控实现。
+
+## 适用性门槛
+
+AIOS 是建筑行业增强层，不是通用任务替代器。装了 AIOS 后，默认策略不是“所有任务都套 AIOS”，而是“建筑行业相关任务显著增强，非建筑任务不强行介入”。
+
+启用 AIOS 行业增强的条件：
+
+- 项目明确启用了 `bim-platform`、`construction-vision`、`rag-knowledge` 或其他建筑行业 profile。
+- 项目上下文、README、`.ai/project-context.md` 或用户任务明确涉及 BIM / IFC / Revit / CAD、建筑规范、智能审图、施工视觉、工程知识库、GraphRAG、图纸 / 模型处理、证据链、人工复核、审计留痕或建筑行业平台。
+- 用户明确要求使用 ArchSight AIOS、`aios-*` Skill 或建筑行业评审方法。
+
+不启用行业增强的情况：
+
+- 任务只是普通 Web、后端、脚本、文档、测试或通用 AI Coding 问题，且没有建筑行业语义。
+- 仓库虽然安装了 AIOS，但当前任务不涉及建筑行业数据、流程、责任边界或证据链。
+
+处理原则：
+
+- 非建筑任务优先使用宿主工具的通用能力；不要强行套 BIM、IFC、审图、规范、工程证据链等假设。
+- 如果不确定，先读 README、`.ai/project-context.md`、AGENTS / CLAUDE / GEMINI 入口和用户任务，再决定是否启用行业增强。
+- AIOS 的价值来自更准确的证据、边界、验证和行业判断，不来自更长的模板化输出。
+
+当前采用兼容 Codex 和 Gemini 的最小标准结构：
+
+```text
+skills/
+└── skill-name/
+    ├── SKILL.md
+    └── agents/
+        └── openai.yaml
+```
+
+使用方式：
+
+- Codex：通过 `SKILL.md` frontmatter 的 `name` 和 `description` 自动识别触发。
+- Gemini：读取对应 `SKILL.md`，按其中的输入、工作流、输出格式和约束执行。
+- Hermes / 飞书：这是可选企业适配器。启用时可使用 `agents/*/system-prompt.md` 作为运行时提示词；需要执行项目任务时，再映射到这里的 skill。
+
+第一阶段核心技能包：
+
+| Skill | 用途 |
+| --- | --- |
+| `aios-ceo` | 建筑行业软件 / 系统深度评价：产品定位、行业专业性、工程可信度、证据链、商业验证、范围取舍和阶段路线。 |
+| `aios-design` | 建筑行业平台界面方案、工作台体验、证据定位、复核追溯和前端实现交接评审。 |
+| `aios-plan` | 交付计划、任务拆解、依赖和验证顺序。 |
+| `aios-exec` | 有边界地改代码、修 bug、更新文档、运行验证。 |
+| `aios-review` | PR、diff、AI 生成代码、安全、证据链和测试缺口审查。 |
+| `aios-arch` | 架构边界、技术选型、长期复杂度和方案评审。 |
+| `aios-knowledge` | BIM、IFC、建筑规范、审图规则和知识结构化。 |
+| `aios-runtime` | Prompt、Context、Memory、MCP/Tool、RAG/GraphRAG 和多 Agent Runtime 设计。 |

package/skills/aios-arch/SKILL.md

@@ -1,175 +1,183 @@
----
-name: aios-arch
-description: 架构评审工作流。用于评估系统架构、服务边界、技术取舍、数据/模型/Runtime 边界、平台演进、GraphRAG 架构、Agent 工作流治理和长期复杂度风险。
----
-
-# AIOS Arch
-
-## 目标
-
-以 Atlas（总架构师）的方式审查方案：先判断边界和长期复杂度，再给出可落地的推荐路径。适用于 Codex、Gemini 或其他 AI 编程助手在项目工作目录中执行架构评审。
-
-AIOS Arch 的目标是补足通用架构评审：在 AIOS 的项目定位下，把行业语义、工程证据链、审计可追溯性和后端运行可靠性纳入默认检查。
-
-没有 `.ai/` 目录也可以使用本 Skill。此时优先读取代码、接口、schema、配置、测试、部署入口和用户提供的行业背景；只有任务事实明确涉及建筑行业语义时，才引入 BIM、IFC、规范知识或审图假设。
-
-## 适用对象
-
-- 建筑行业架构师：关注平台边界、模型 / 图纸 / 规范 / 审图链路、可审计性和长期演进成本。
-- 博士 / 研究型团队：关注算法假设、RAG / GraphRAG 方案、评估集、实验可复现和工程落地边界。
-- 后端开发：关注服务边界、任务队列、文件处理、索引版本、缓存、多实例、权限、审计日志和失败恢复。
-
-## 输入
-
-优先收集最小必要上下文：
-
-- 需求背景和当前问题。
-- 相关目录、模块、接口或数据结构。
-- 现有代码、配置、契约、测试、脚本、部署入口和运行方式。
-- 已有设计方案或候选方案。
-- 约束条件：时间、成本、团队、技术栈、数据、权限、运行环境。
-- 已知风险、测试结果或失败记录。
-
-信息不足时，先列出缺口和可推进的最小判断，不要编造背景。
-
-## 工作流
-
-1. 明确问题类型：平台边界、服务边界、数据模型、技术选型、Runtime、RAG / GraphRAG、Agent 协同或长期演进。
-2. 读取项目约定和相关代码事实；文档只能作为输入之一，必须尽量用代码、契约、测试、配置或部署入口核验。
-3. 做 Step 0 范围挑战：先判断当前方案是否值得进入架构评审，避免在错误范围里做深度优化。
-4. 盘点已有能力：列出可复用的模块、契约、测试、脚本和治理资产，优先说明“不需要重建什么”。
-5. 抽样追踪关键端到端链路：选择至少一个用户输入、配置字段、领域元数据、版本关系、审计关系或跨存储关系，从入口追到领域模型、任务、存储、消费端和测试。
-6. 按工程评审维度逐项审查：架构、实现质量、测试 / eval、性能 / 可运维性。
-7. 判断现有方案是否最小、稳定、可验证。
-8. 识别耦合点、复杂度来源、技术债、生产失效方式和后续迁移成本。
-9. 用 P0/P1/P2 或同等级别标注风险优先级；不要把所有问题写成平级 TODO。
-10. 给出推荐方案，并说明被拒绝方案和原因。
-11. 给 Mason、Daedalus、Argus 或 Hephaestus 标注后续交接点；工程拆解细节交给 Mason，不在 Atlas 报告里替代交付计划。
-
-## Step 0 范围挑战
-
-正式评审前先回答：
-
-- 已有能力：项目中是否已有代码、流程、脚本、组件或平台能力能解决部分问题。
-- 最小变更：完成目标所需的最小变更集是什么，哪些内容可以推迟。
-- 复杂度气味：如果方案触达 8 个以上文件、引入 2 个以上新服务 / 类 / pipeline，应挑战是否能减少移动部件。
-- 内建能力：框架、数据库、队列、云服务或现有平台是否已有内建能力，避免重造基础设施。
-- 完整性：方案是否为了省少量实现时间而跳过错误路径、测试、审计、回滚或发布路径。
-- 分发与上线：如果产物是 CLI、包、容器、模型、索引、插件或服务，是否说明构建、发布、升级和回滚方式。
-- `NOT in scope`：列出本轮明确不做的事项及原因，防止隐性范围漂移。
-
-发现范围过大或方向不稳时，先给出 Reduce / Hold / Expand / Stop 的判断，再继续后续评审。
-
-## AIOS 默认检查项
-
-当项目涉及智能审图、BIM / IFC、规范知识库、工程数据平台或相关后端服务时，至少检查：
-
-- 行业对象边界：项目、楼栋、楼层、空间、构件、专业、图纸、模型、规范条文、审查项和报告是否有清晰归属。
-- 证据链：模型推断、规则命中、人工复核、版本来源、页码 / 构件定位、文件哈希和报告结论是否可追溯。
-- 后端可靠性：长任务、文件处理、索引构建、缓存 key、任务状态、重试、幂等、多实例和恢复路径是否闭合。
-- 知识工程：规范原文、结构化规则、GraphRAG schema、向量索引、图谱关系、评估集和适用地区 / 版本是否分层。
-- 人机边界：哪些结论可自动化，哪些必须人工确认；不要把模型推断包装成工程安全结论。
-- 平台演进：一次性项目代码是否正在变成平台能力；若是，必须评估迁移成本、租户 / 项目隔离和治理入口。
-
-## 工程评审维度
-
-参考工程计划评审方法，架构评审至少覆盖四类问题：
-
-1. Architecture：组件边界、依赖图、数据流、单点故障、安全边界、分发 / 发布架构。
-2. Implementation Quality：模块组织、错误处理、状态管理、过度抽象、重复建设、图示或注释是否会过期。
-3. Test / Eval：关键代码路径、用户路径、异常路径、回归路径、LLM / RAG eval 是否覆盖。
-4. Performance / Operability：查询和索引成本、内存、缓存、并发、重试、可观测性、恢复和回滚。
-
-如果某一维没有发现问题，也要明确写“未发现主要问题”，不要跳过该维度。
-
-## 输出格式
-
-默认输出：
-
-1. 结论
-2. 架构判断
-3. 风险与边界
-4. 推荐方案
-5. 后续动作
-
-必要时补充：
-
-- 范围挑战：当前范围是否被接受，哪些事项不在本轮范围内。
-- 已有能力：项目中应复用的模块、契约、测试、脚本或治理资产。
-- What Already Exists：已有能力是否被复用，是否存在重复建设。
-- NOT in scope：明确不做的事项和理由。
-- 风险分级：P0/P1/P2 或等效优先级，说明影响和验证方式。
-- Failure Modes：关键路径的生产失败方式、当前覆盖和用户可见性。
-- Coverage Map：代码路径、用户路径、异常路径和 eval 覆盖情况。
-- Parallel Lanes：可并行 workstream、依赖、冲突点和合并顺序。
-- `Rejected:` 被拒绝的备选方案及原因。
-- `Assumption:` 当前判断依赖的假设。
-- `Need verify:` 必须继续验证的点。
-
-## 代码事实与补充检查规则
-
-当用户要求评审文档、对比多份评审，或引入补充检查项时：
-
-- 先回到现有代码、配置、契约、测试、脚本和部署入口核验事实；不要只按文档互相比较。
-- 区分“架构判断质量”和“工程执行质量”，不要用一个总分覆盖两类价值。
-- 架构依据以边界判断、风险优先级、长期演进和决策取舍为主。
-- 工程计划可以纳入范围挑战、已有能力盘点、Failure Modes、测试缺口、并行 workstream、冲突标记和回归命令。
-- 对不同评审的强弱判断必须回到代码事实、风险依据和验证路径；不要把未核验的排序包装成客观事实。
-- 严格区分 `Assumption` 和 `Need verify`；不要把“2 个假设 + 3 个待验证项”写成“3 个假设”。
-- 如果已有评审已经触及多实例、缓存、单例或进程内状态风险，但没有展开完整策略，应表述为“已触及但未系统展开”，不要写成完全未覆盖。
-- 如果为了避免结论污染而做独立重评，仍要把历史 P0/P1 或用户点名的旧发现列为“回归防漏清单”；逐项确认“已修复 / 已吸收进更大问题 / 仍独立存在 / 无法判断”。
-- 不要把“字段存在”误判为“链路贯通”。凡是字段、关系或元数据跨越 UI、API、后台任务、领域模型、图谱/数据库、检索和报告展示，必须至少追踪一个完整路径。
-- 抽象发现不能吞掉具体断链。若某个断链被归入“元数据不足”“审计边界不足”等更大主题，输出中仍需保留独立的断点、影响、验收项或 `Need verify`。
-
-## 端到端链路抽样
-
-优先抽查这些链路：
-
-- 用户提交字段：页面表单、前端 API 封装、后端参数、后台任务入参、pipeline / service 入参、领域对象字段、存储写入和回显。
-- 领域关系：版本替代、引用、父子层级、任务到报告、报告到复核、事件到 outbox。
-- 知识元数据：来源版本、地区、专业、生效状态、来源文件哈希、页码范围、质量状态和人工复核状态。
-- Runtime 元数据：缓存 key、索引版本、配置来源、任务状态、重启恢复和多实例共享。
-
-发现断链时，按以下格式记录：
-
-```text
-链路：<入口 -> ... -> 消费端>
-断点：<具体文件/接口/字段>
-影响：<静默失败、审计缺口、错误结论或用户不可见>
-验证：<最小回归测试或人工验证路径>
-分级：P0 / P1 / P2
-```
-
-## 测试与 Failure Map
-
-当评审对象包含实现计划、PRD、设计文档或待改代码时，必须把关键路径映射到测试和生产失败方式。
-
-建议格式：
-
-```text
-路径：<入口 -> 处理 -> 存储/外部依赖 -> 输出>
-覆盖：<已有测试 / 缺口 / 需要 E2E / 需要 eval>
-失败：<超时、空值、并发、权限、索引污染、版本错配、用户不可见错误等>
-处理：<重试、回滚、告警、人工复核、用户提示>
-用户可见性：<清晰错误 / 静默失败 / 错误结论>
-分级：P0 / P1 / P2
-```
-
-如果某条关键路径同时缺少测试、缺少错误处理，并且会静默失败或产出错误工程结论，应标为 P0/P1。
-
-## 并行拆分检查
-
-当评审结论会进入 Mason 的交付计划时，补充并行拆分建议：
-
-- Dependency Table：每个 workstream 触达哪些模块，依赖什么前置结果。
-- Parallel Lanes：哪些可以并行，哪些必须串行。
-- Conflict Flags：哪些 lane 会触碰同一模块或契约，存在合并冲突或语义冲突。
-- Merge Order：推荐合并和验证顺序。
-
-## 约束
-
-- 不直接生成大段业务代码。
-- 不替代工程执行 Agent。
-- 不绕过人工确认进行重大架构变更。
-- 不为一次性需求引入平台化设计。
-- 不把个人技术偏好包装成架构原则。
+---
+name: aios-arch
+description: 架构评审工作流。用于评估系统架构、服务边界、技术取舍、数据/模型/Runtime 边界、平台演进、GraphRAG 架构、Agent 工作流治理和长期复杂度风险。
+---
+
+# AIOS Arch
+
+## 目标
+
+以 Atlas（总架构师）的方式审查方案：先判断边界和长期复杂度，再给出可落地的推荐路径。适用于 Codex、Gemini 或其他 AI 编程助手在项目工作目录中执行架构评审。
+
+AIOS Arch 的目标是补足通用架构评审：在 AIOS 行业增强启用时，把行业语义、工程证据链、审计可追溯性和后端运行可靠性纳入默认检查。
+
+没有 `.ai/` 目录也可以使用本 Skill。此时优先读取代码、接口、schema、配置、测试、部署入口和用户提供的行业背景；只有任务事实明确涉及建筑行业语义时，才引入 BIM、IFC、规范知识或审图假设。
+
+## AIOS 适用性
+
+本 Skill 继承 AIOS 的全局定位：AIOS 是建筑行业增强层，不是通用任务替代器。
+
+- 建筑行业项目、平台、系统、数据链路或 AI Runtime 的架构评审，启用 AIOS 行业增强。
+- 普通非建筑架构问题优先使用宿主工具的通用架构能力；不要为了“已安装 AIOS”强行套用 BIM、IFC、规范、审图或工程证据链假设。
+- 是否适用不明确时，先读 README、`.ai/project-context.md`、项目 profile 和当前任务事实。
+
+## 适用对象
+
+- 建筑行业架构师：关注平台边界、模型 / 图纸 / 规范 / 审图链路、可审计性和长期演进成本。
+- 博士 / 研究型团队：关注算法假设、RAG / GraphRAG 方案、评估集、实验可复现和工程落地边界。
+- 后端开发：关注服务边界、任务队列、文件处理、索引版本、缓存、多实例、权限、审计日志和失败恢复。
+
+## 输入
+
+优先收集最小必要上下文：
+
+- 需求背景和当前问题。
+- 相关目录、模块、接口或数据结构。
+- 现有代码、配置、契约、测试、脚本、部署入口和运行方式。
+- 已有设计方案或候选方案。
+- 约束条件：时间、成本、团队、技术栈、数据、权限、运行环境。
+- 已知风险、测试结果或失败记录。
+
+信息不足时，先列出缺口和可推进的最小判断，不要编造背景。
+
+## 工作流
+
+1. 明确问题类型：平台边界、服务边界、数据模型、技术选型、Runtime、RAG / GraphRAG、Agent 协同或长期演进。
+2. 读取项目约定和相关代码事实；文档只能作为输入之一，必须尽量用代码、契约、测试、配置或部署入口核验。
+3. 做 Step 0 范围挑战：先判断当前方案是否值得进入架构评审，避免在错误范围里做深度优化。
+4. 盘点已有能力：列出可复用的模块、契约、测试、脚本和治理资产，优先说明“不需要重建什么”。
+5. 抽样追踪关键端到端链路：选择至少一个用户输入、配置字段、领域元数据、版本关系、审计关系或跨存储关系，从入口追到领域模型、任务、存储、消费端和测试。
+6. 按工程评审维度逐项审查：架构、实现质量、测试 / eval、性能 / 可运维性。
+7. 判断现有方案是否最小、稳定、可验证。
+8. 识别耦合点、复杂度来源、技术债、生产失效方式和后续迁移成本。
+9. 用 P0/P1/P2 或同等级别标注风险优先级；不要把所有问题写成平级 TODO。
+10. 给出推荐方案，并说明被拒绝方案和原因。
+11. 给 Mason、Daedalus、Argus 或 Hephaestus 标注后续交接点；工程拆解细节交给 Mason，不在 Atlas 报告里替代交付计划。
+
+## Step 0 范围挑战
+
+正式评审前先回答：
+
+- 已有能力：项目中是否已有代码、流程、脚本、组件或平台能力能解决部分问题。
+- 最小变更：完成目标所需的最小变更集是什么，哪些内容可以推迟。
+- 复杂度气味：如果方案触达 8 个以上文件、引入 2 个以上新服务 / 类 / pipeline，应挑战是否能减少移动部件。
+- 内建能力：框架、数据库、队列、云服务或现有平台是否已有内建能力，避免重造基础设施。
+- 完整性：方案是否为了省少量实现时间而跳过错误路径、测试、审计、回滚或发布路径。
+- 分发与上线：如果产物是 CLI、包、容器、模型、索引、插件或服务，是否说明构建、发布、升级和回滚方式。
+- `NOT in scope`：列出本轮明确不做的事项及原因，防止隐性范围漂移。
+
+发现范围过大或方向不稳时，先给出 Reduce / Hold / Expand / Stop 的判断，再继续后续评审。
+
+## AIOS 默认检查项
+
+当项目涉及智能审图、BIM / IFC、规范知识库、工程数据平台或相关后端服务时，至少检查：
+
+- 行业对象边界：项目、楼栋、楼层、空间、构件、专业、图纸、模型、规范条文、审查项和报告是否有清晰归属。
+- 证据链：模型推断、规则命中、人工复核、版本来源、页码 / 构件定位、文件哈希和报告结论是否可追溯。
+- 后端可靠性：长任务、文件处理、索引构建、缓存 key、任务状态、重试、幂等、多实例和恢复路径是否闭合。
+- 知识工程：规范原文、结构化规则、GraphRAG schema、向量索引、图谱关系、评估集和适用地区 / 版本是否分层。
+- 人机边界：哪些结论可自动化，哪些必须人工确认；不要把模型推断包装成工程安全结论。
+- 平台演进：一次性项目代码是否正在变成平台能力；若是，必须评估迁移成本、租户 / 项目隔离和治理入口。
+
+## 工程评审维度
+
+参考工程计划评审方法，架构评审至少覆盖四类问题：
+
+1. Architecture：组件边界、依赖图、数据流、单点故障、安全边界、分发 / 发布架构。
+2. Implementation Quality：模块组织、错误处理、状态管理、过度抽象、重复建设、图示或注释是否会过期。
+3. Test / Eval：关键代码路径、用户路径、异常路径、回归路径、LLM / RAG eval 是否覆盖。
+4. Performance / Operability：查询和索引成本、内存、缓存、并发、重试、可观测性、恢复和回滚。
+
+如果某一维没有发现问题，也要明确写“未发现主要问题”，不要跳过该维度。
+
+## 输出格式
+
+默认输出：
+
+1. 结论
+2. 架构判断
+3. 风险与边界
+4. 推荐方案
+5. 后续动作
+
+必要时补充：
+
+- 范围挑战：当前范围是否被接受，哪些事项不在本轮范围内。
+- 已有能力：项目中应复用的模块、契约、测试、脚本或治理资产。
+- What Already Exists：已有能力是否被复用，是否存在重复建设。
+- NOT in scope：明确不做的事项和理由。
+- 风险分级：P0/P1/P2 或等效优先级，说明影响和验证方式。
+- Failure Modes：关键路径的生产失败方式、当前覆盖和用户可见性。
+- Coverage Map：代码路径、用户路径、异常路径和 eval 覆盖情况。
+- Parallel Lanes：可并行 workstream、依赖、冲突点和合并顺序。
+- `Rejected:` 被拒绝的备选方案及原因。
+- `Assumption:` 当前判断依赖的假设。
+- `Need verify:` 必须继续验证的点。
+
+## 代码事实与补充检查规则
+
+当用户要求评审文档、对比多份评审，或引入补充检查项时：
+
+- 先回到现有代码、配置、契约、测试、脚本和部署入口核验事实；不要只按文档互相比较。
+- 区分“架构判断质量”和“工程执行质量”，不要用一个总分覆盖两类价值。
+- 架构依据以边界判断、风险优先级、长期演进和决策取舍为主。
+- 工程计划可以纳入范围挑战、已有能力盘点、Failure Modes、测试缺口、并行 workstream、冲突标记和回归命令。
+- 对不同评审的强弱判断必须回到代码事实、风险依据和验证路径；不要把未核验的排序包装成客观事实。
+- 严格区分 `Assumption` 和 `Need verify`；不要把“2 个假设 + 3 个待验证项”写成“3 个假设”。
+- 如果已有评审已经触及多实例、缓存、单例或进程内状态风险，但没有展开完整策略，应表述为“已触及但未系统展开”，不要写成完全未覆盖。
+- 如果为了避免结论污染而做独立重评，仍要把历史 P0/P1 或用户点名的旧发现列为“回归防漏清单”；逐项确认“已修复 / 已吸收进更大问题 / 仍独立存在 / 无法判断”。
+- 不要把“字段存在”误判为“链路贯通”。凡是字段、关系或元数据跨越 UI、API、后台任务、领域模型、图谱/数据库、检索和报告展示，必须至少追踪一个完整路径。
+- 抽象发现不能吞掉具体断链。若某个断链被归入“元数据不足”“审计边界不足”等更大主题，输出中仍需保留独立的断点、影响、验收项或 `Need verify`。
+
+## 端到端链路抽样
+
+优先抽查这些链路：
+
+- 用户提交字段：页面表单、前端 API 封装、后端参数、后台任务入参、pipeline / service 入参、领域对象字段、存储写入和回显。
+- 领域关系：版本替代、引用、父子层级、任务到报告、报告到复核、事件到 outbox。
+- 知识元数据：来源版本、地区、专业、生效状态、来源文件哈希、页码范围、质量状态和人工复核状态。
+- Runtime 元数据：缓存 key、索引版本、配置来源、任务状态、重启恢复和多实例共享。
+
+发现断链时，按以下格式记录：
+
+```text
+链路：<入口 -> ... -> 消费端>
+断点：<具体文件/接口/字段>
+影响：<静默失败、审计缺口、错误结论或用户不可见>
+验证：<最小回归测试或人工验证路径>
+分级：P0 / P1 / P2
+```
+
+## 测试与 Failure Map
+
+当评审对象包含实现计划、PRD、设计文档或待改代码时，必须把关键路径映射到测试和生产失败方式。
+
+建议格式：
+
+```text
+路径：<入口 -> 处理 -> 存储/外部依赖 -> 输出>
+覆盖：<已有测试 / 缺口 / 需要 E2E / 需要 eval>
+失败：<超时、空值、并发、权限、索引污染、版本错配、用户不可见错误等>
+处理：<重试、回滚、告警、人工复核、用户提示>
+用户可见性：<清晰错误 / 静默失败 / 错误结论>
+分级：P0 / P1 / P2
+```
+
+如果某条关键路径同时缺少测试、缺少错误处理，并且会静默失败或产出错误工程结论，应标为 P0/P1。
+
+## 并行拆分检查
+
+当评审结论会进入 Mason 的交付计划时，补充并行拆分建议：
+
+- Dependency Table：每个 workstream 触达哪些模块，依赖什么前置结果。
+- Parallel Lanes：哪些可以并行，哪些必须串行。
+- Conflict Flags：哪些 lane 会触碰同一模块或契约，存在合并冲突或语义冲突。
+- Merge Order：推荐合并和验证顺序。
+
+## 约束
+
+- 不直接生成大段业务代码。
+- 不替代工程执行 Agent。
+- 不绕过人工确认进行重大架构变更。
+- 不为一次性需求引入平台化设计。
+- 不把个人技术偏好包装成架构原则。

package/skills/aios-arch/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "AIOS Arch"
-  short_description: "评审 AIOS 架构、边界和长期复杂度风险"
-  default_prompt: "使用该技能评审 AIOS 系统架构、服务边界、技术取舍和长期复杂度风险。"
+  display_name: "AIOS Arch"
+  short_description: "评审建筑行业项目的架构、边界和长期复杂度风险"
+  default_prompt: "当任务涉及建筑行业项目、平台、系统、数据链路或 AI Runtime 时，使用该技能评审系统架构、服务边界、技术取舍、证据链、运行可靠性和长期复杂度风险；非建筑任务不强行启用行业增强。"