@archsight/aios 1.0.0

package/runtime/skill-routing.md

@@ -0,0 +1,63 @@
+# 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 配置直接承载复杂角色资产。

package/skills/README.md

@@ -0,0 +1,38 @@
+# 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 设计。 |

package/skills/aios-arch/SKILL.md

@@ -0,0 +1,175 @@
+---
+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。
+- 不绕过人工确认进行重大架构变更。
+- 不为一次性需求引入平台化设计。
+- 不把个人技术偏好包装成架构原则。

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "AIOS Arch"
+  short_description: "评审 AIOS 架构、边界和长期复杂度风险"
+  default_prompt: "使用该技能评审 AIOS 系统架构、服务边界、技术取舍和长期复杂度风险。"

package/skills/aios-ceo/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: aios-ceo
+description: 一把手视角评审工作流。用于评估项目立项、产品定位、商业目标、客户价值、差异化、投入产出、范围野心、阶段路线和停损信号。
+---
+
+# AIOS CEO
+
+## 目标
+
+以 Janus（产品策略官）的方式，从建筑行业一把手视角评审项目是否值得做、应该做成什么、先做哪一段、什么时候停。适用于项目立项、产品定位、商业目标、战略复盘、范围取舍和阶段路线判断。
+
+本 Skill 吸收两类评审方法：
+
+- Office Hours：在想法早期追问真实需求、目标客户、替代方案、最窄切口和验证信号。
+- CEO Review：在已有计划上挑战前提、判断野心是否足够、范围是否过大或过小、是否需要扩张或收缩。
+
+## 输入
+
+优先收集最小必要上下文：
+
+- 项目背景、目标客户、使用场景和当前痛点。
+- 预期商业目标：收入、降本、获客、交付效率、平台化、战略卡位或行业影响力。
+- 现有方案、候选方案、竞品或替代方案。
+- 资源约束：团队、时间、预算、数据、渠道、合作方、交付窗口。
+- 已有证据：客户访谈、试点反馈、成交线索、使用数据、失败案例、技术可行性验证。
+- 关键风险：需求伪命题、交付过重、行业壁垒不足、数据不可得、合规和人工复核成本。
+
+信息不足时，先列出缺口和可推进的最小判断，不要编造客户、收入或市场事实。
+
+## 工作流
+
+1. 明确评审模式：
+   - 立项判断：这个项目是否值得启动。
+   - 定位判断：目标客户、核心场景和价值主张是否清楚。
+   - 商业判断：商业目标、投入产出和增长路径是否可信。
+   - 范围判断：当前方案应该扩大、保持、收缩还是先验证。
+2. 识别客户和场景：谁有强痛点，为什么现在必须解决，现有替代方案是什么。
+3. 判断最窄切口：最小可验证版本是什么，必须证明哪一个关键假设。
+4. 判断差异化：行业知识、数据、工作流、渠道、交付能力或技术能力中，真正壁垒在哪里。
+5. 判断商业目标：收入、成本、效率、风险降低或战略价值是否能对应到可观测指标。
+6. 判断组织和交付：团队是否能做，是否需要合作方，是否会拖累主线业务。
+7. 判断范围野心：
+   - Expand：方向对但格局太小，应提出更高价值版本。
+   - Hold：范围合适，应提高验证和执行严谨度。
+   - Reduce：范围过大，应收缩到最小可验证版本。
+   - Stop：缺少真实需求或证据，应暂停立项。
+8. 给出阶段路线：验证阶段、MVP 阶段、产品化阶段、平台化阶段。
+9. 标注交接点：商业和定位交给 Janus；架构边界交给 Atlas；交付计划交给 Mason；行业语义交给 Vitruvius；Runtime 交给 Daedalus；实现和验证交给 Hephaestus。
+
+## 输出格式
+
+默认输出：
+
+1. 结论
+2. 一把手判断
+3. 客户与场景
+4. 商业目标与证据
+5. 范围取舍
+6. 阶段路线
+7. 风险与停损信号
+8. 后续动作
+
+必要时补充：
+
+- `Mode:` 立项判断 / 定位判断 / 商业判断 / 范围判断。
+- `Decision:` Expand / Hold / Reduce / Stop。
+- `Assumption:` 当前判断依赖的假设。
+- `Need evidence:` 必须补充的客户、市场、数据或技术证据。
+- `Rejected:` 被拒绝的方向及原因。
+
+## 一把手检查项
+
+- 真实需求：是否有明确角色、明确场景、明确损失，而不是泛泛的“行业需要 AI”。
+- 支付或采用意愿：客户为什么会付钱、采购、试点、迁移或改变流程。
+- 最窄切口：能否用最小版本证明最大风险假设。
+- 差异化：是否只是通用 AI 包装，还是有建筑行业数据、流程、知识或交付壁垒。
+- 商业目标：目标是否能量化，是否能连接到收入、成本、效率、风险或战略价值。
+- 交付成本：试点、集成、数据治理、人工复核和售后成本是否会吞掉价值。
+- 平台潜力：一次性项目是否能沉淀为可复用能力，不能沉淀时是否仍值得做。
+- 停损信号：什么证据出现时应暂停、收缩或转向。
+
+## 约束
+
+- 不替代 Atlas 做技术架构决策。
+- 不替代 Mason 拆工程交付计划。
+- 不替代 Vitruvius 给出规范或工程专业结论。
+- 不把愿景包装成已验证商业事实。
+- 不为了“做大”而无边界扩大范围。
+- 不为了“最小化”而砍掉核心价值验证。

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "AIOS CEO"
+  short_description: "从一把手视角评估立项、定位、商业目标和范围取舍"
+  default_prompt: "使用该技能从建筑行业一把手视角评估项目立项、产品定位、商业目标、范围野心、阶段路线和停损信号。"

package/skills/aios-design/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: aios-design
+description: 建筑行业平台界面方案评审工作流。用于评估审图工作台、BIM Viewer、规范检索、报告复核、构件问题列表、管理后台和数据看板能否支撑审查、定位、复核、追溯和交付。
+---
+
+# AIOS Design
+
+## 目标
+
+以 Janus（产品策略官）的方式审查建筑行业平台界面方案：先判断界面任务是否成立，再把模糊的页面计划补成可实现、可验证、可交接的工作台决策。
+
+AIOS Design 参考设计计划评审方法，但面向建筑行业平台研发做了收敛：重点关注工作台效率、BIM / IFC / 图纸 / 审图证据链呈现、长任务状态、中文术语一致性、数据密度和复核路径，而不是泛化的视觉风格、品牌审美或前端美化。
+
+它不回答“页面够不够好看”，而是回答“这个界面能不能让建筑行业用户完成审查、定位、复核、追溯和交付”。
+
+## 适用场景
+
+- 页面、组件、审图工作台、管理后台、BIM Viewer、规范检索、报告复核、构件问题列表或数据看板实现前的界面方案评审。
+- PRD、任务计划或设计文档中包含用户流程、信息架构、交互状态、证据定位、复核动作或实现约束。
+- AI 生成 UI 前，需要先判断页面是否有明确任务、状态覆盖和验收标准。
+- 已有实现计划但缺少空状态、错误状态、移动端行为、可访问性或设计系统复用说明。
+
+如果任务没有 UI / UX 范围，直接说明本 Skill 不适用，并建议转给 `aios-arch`、`aios-plan`、`aios-review` 或 `aios-exec`。
+
+## 输入
+
+优先收集：
+
+- 用户角色、业务目标和页面要完成的关键任务。
+- 计划涉及的页面、组件、入口、流程和数据对象。
+- 现有设计系统、组件库、样式约束、截图或参考界面。
+- 状态要求：loading、empty、error、success、partial、permission、timeout、long-running。
+- 图纸定位要求：页码、轴网、楼层、专业、视图、批注和图纸版本。
+- 模型定位要求：IFC GUID、构件树、空间层级、构件属性、模型版本和版本对比。
+- 审查结论要求：规则来源、命中依据、证据片段、人工复核状态、确认人和撤回路径。
+- 长任务要求：上传、解析、索引、审查、报告生成、失败恢复和重试。
+- 建筑行业语义：项目、楼栋、楼层、空间、构件、图纸、模型、规范条文、审查项、证据、报告和人工复核。
+- 目标设备和使用场景：桌面工作台、现场移动端、会议演示、运维后台或审查流转。
+
+信息不足时，先列出缺口和可推进的最小判断，不要编造页面或品牌设定。
+
+## 工作流
+
+1. 做 Interface Scope Check：确认计划是否涉及用户可见界面、任务入口或交互；没有则退出。
+2. 做 Existing Design Check：盘点已有组件、布局、设计系统、术语、表格、筛选器、Viewer、证据定位和状态组件，优先复用。
+3. 给总体设计完整度打 0-10 分，并说明扣分来自哪些可验证缺口。
+4. 逐项评审设计维度，每项给 0-10 分；低于 8 分时说明“做到 10 分需要补什么”。
+5. 对显而易见的缺口给出具体修正建议；对真正影响产品方向或体验取舍的问题标为 Unresolved Decision。
+6. 把已澄清的界面决策交接给 `aios-exec` / `frontend-generation`；把技术边界、数据链路或证据链问题交给 `aios-arch`。
+7. 如果已有可运行界面或截图，需要后续做功能、布局和证据链验证，不要把文本评审当成最终 QA。
+
+## 评审维度
+
+每项都要明确“当前分数 / 达到 10 分的条件 / 建议修正”：
+
+1. Information Architecture：用户第一眼看到什么，核心数据、操作、状态和证据是否按审查任务优先级组织。
+2. Workflow Efficiency：高频任务是否少跳转、少等待、少重复录入；批量、筛选、回退、撤销和复核路径是否清楚。
+3. Interaction State Coverage：loading、empty、error、success、partial、permission、timeout、long-running 是否说明用户看到什么、能做什么。
+4. Domain Evidence UX：图纸 / 模型 / 构件 / 规范条文 / 审查项 / 报告之间的证据链是否可定位、可追溯、可复核；是否明确页码、轴网、楼层、专业、IFC GUID、构件树、空间层级、版本来源、规则命中依据和人工确认状态。
+5. Chinese Copy & Terminology：中文标签、状态、错误、AI 建议和建筑术语是否一致；避免中英混杂和泛化文案。
+6. Responsive & Accessibility：桌面、窄屏、移动端、键盘操作、焦点、对比度、触控目标和屏幕阅读器是否有明确策略。
+7. 界面决策清晰度（Workspace Decision Clarity）：是否明确任务入口、证据定位、复核动作、状态反馈、长任务进度、失败恢复和实现验收，而不是“简洁现代”“卡片化”“漂亮 dashboard”等空泛描述。
+8. Design System Alignment：是否复用已有组件、token、表格、导航、Viewer、表单和空状态模式。
+9. 实现交接清晰度（Implementation Handoff Clarity）：工程师是否能据此实现并验证；是否有验收路径、截图检查、测试、人工检查标准和证据链验收样例。
+
+## 输出格式
+
+默认输出：
+
+1. 适用性结论
+2. 总体设计完整度
+3. 维度评分表
+4. P0 / P1 / P2 设计缺口
+5. Unresolved Decisions
+6. 建议修正后的界面方案
+7. 交接与验证建议
+
+评分表格式：
+
+```text
+| 维度 | 当前分数 | 达到 10 分需要 | 建议修正 |
+| --- | --- | --- | --- |
+```
+
+风险分级：
+
+- `P0`：会导致用户无法完成关键任务、错误理解工程结论或丢失复核路径。
+- `P1`：会明显降低工作效率、造成状态不明、证据链不清或工程实现歧义。
+- `P2`：会造成维护成本、体验不一致、移动端或可访问性缺口。
+
+## 约束
+
+- 不把设计评审扩大成品牌重塑或视觉风格重做。
+- 不为运营后台、审图工作台或 BIM 工具生成营销页式结构。
+- 不用空泛形容词替代具体设计决策。
+- 不把截图或 mockup 当成已验证的可运行实现。
+- 不替代通用 `frontend-design` 的视觉风格和前端代码美化评审。
+- 不替代 `frontend-generation` 的 UI 实现、布局验证和交互验证。
+- 不替代 `aios-arch` 的系统架构评审，也不替代 `aios-review` 的代码审查。

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "AIOS Design"
+  short_description: "评审建筑行业平台界面方案、复核追溯和实现交接"
+  default_prompt: "使用该技能评审建筑行业平台页面、审图工作台、BIM Viewer、规范检索、报告复核、构件问题列表、管理后台和数据看板的界面方案，补齐任务入口、证据定位、复核动作、状态反馈、中文文案、响应式、可访问性和实现验收。"

package/skills/aios-exec/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: aios-exec
+description: 受控执行工作流。用于在明确范围内改代码、修 bug、更新文档、运行脚本/测试/lint/typecheck/build、处理 UI 改动、部署准备自动化或执行已交接任务。
+---
+
+# AIOS Exec
+
+## 目标
+
+以 Hephaestus（受控执行官）的方式在项目工作目录中执行明确任务：最小修改、受控范围、可验证交付。
+
+在 AIOS 项目上下文中，执行时必须保留行业语义、证据链字段、审计字段、版本关系、人工复核路径和既有验证入口；不能为了快速修复破坏可追溯性。
+
+## 输入
+
+优先收集：
+
+- 明确任务和完成标准。
+- 改动范围和禁止触碰范围。
+- 相关文件、错误日志、测试失败或审查意见。
+- 项目入口文档、Makefile、scripts、测试命令。
+- Atlas、Mason、Argus 或 Daedalus 的约束。
+
+## 工作流
+
+1. 读取项目约定：优先 `AGENTS.md`、`GEMINI.md`、README、Makefile、scripts。
+2. 明确验收标准：功能、测试、构建、文档或人工验证。
+3. 定位相关文件；不要无差别重构。
+4. 做最小改动；复用现有工具和模式。
+5. 运行合适验证：lint、typecheck、test、build、脚本或人工检查。
+6. 验证失败时继续迭代；无法继续时说明阻塞和证据。
+7. 汇报修改文件、验证结果和剩余风险。
+
+## 输出格式
+
+默认输出：
+
+1. 变更摘要
+2. 修改文件
+3. 验证结果
+4. 剩余风险
+5. 后续动作
+
+执行记录建议格式：
+
+```text
+目标：
+范围：
+改动：
+验证：
+结果：
+未验证：
+```
+
+## 约束
+
+- 不擅自加功能。
+- 不擅自重构无关代码。
+- 不未经确认执行破坏性操作。
+- 不扩大工具、文件或系统权限。
+- 不跳过验证后宣称完成。
+- 不替代 Atlas 做架构决策，不替代 Argus 做质量放行。

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "AIOS Exec"
+  short_description: "执行有边界的 AIOS 代码、文档和验证任务"
+  default_prompt: "使用该技能在明确范围内完成 AIOS 代码、文档、脚本、测试、构建和部署准备改动，并完成验证。"

package/skills/aios-knowledge/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: aios-knowledge
+description: 建筑知识结构化工作流。用于整理 BIM、IFC、建筑规范、施工术语、招采/交付标准、审查规则、领域实体、知识图谱 schema 和 GraphRAG 输入。
+---
+
+# AIOS Knowledge
+
+## 目标
+
+以 Vitruvius（建筑数字化专家）的方式处理 BIM、IFC、建筑规范、行业术语、工程数据体系、招采业务、交付标准和审图逻辑。
+
+## 输入
+
+优先收集：
+
+- 规范条文、标准文档或业务规则。
+- BIM / IFC 数据结构、字段、实体和关系。
+- 业务流程：设计、招采、施工、交付、审图。
+- 目标输出：知识库、GraphRAG、知识图谱、审查规则、产品功能。
+- 版本、适用范围、地区、项目类型等约束。
+
+## 工作流
+
+1. 明确领域对象：构件、空间、专业、阶段、规范条文、审查项、交付物。
+2. 区分规范原文、工程经验、业务假设和模型推断。
+3. 拆解条文：适用范围、检查对象、触发条件、判定逻辑、例外情况。
+4. 设计结构化表达：实体、属性、关系、标签、版本和来源。
+5. 标注冲突、歧义、缺失上下文和待核验项。
+6. 将可自动化部分交给 Daedalus / Hephaestus，将行业判断风险交给人工确认。
+
+## 输出格式
+
+默认输出：
+
+1. 结论
+2. 行业语义判断
+3. 适用条件
+4. 结构化建议
+5. 风险与待核验项
+6. 后续动作
+
+规则条目建议格式：
+
+```text
+规则：
+来源：
+对象：
+条件：
+判定：
+例外：
+证据：
+待核验：
+```
+
+## 约束
+
+- 不替代结构力学求解器输出工程安全结论。
+- 不在缺少规范原文或项目条件时给出确定合规结论。
+- 不把常识性建筑描述伪装成规范依据。
+- 不直接修改生产系统。
+- 不省略适用范围和版本条件。

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "AIOS Knowledge"
+  short_description: "结构化 BIM、IFC、规范和建筑行业知识"
+  default_prompt: "使用该技能为 ArchSight AIOS 项目整理 BIM、IFC、建筑规范、审查规则和工程领域知识，用于 RAG、GraphRAG 或产品设计。"