@archsight/aios 1.0.0 → 1.0.1

package/skills/aios-ceo/SKILL.md

@@ -1,89 +1,177 @@
----
-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 给出规范或工程专业结论。
-- 不把愿景包装成已验证商业事实。
-- 不为了“做大”而无边界扩大范围。
-- 不为了“最小化”而砍掉核心价值验证。
+---
+name: aios-ceo
+description: 一把手深度评审工作流。用于在 AIOS 建筑行业增强启用时评价软件 / 系统的产品定位、行业专业性、工程可信度、商业验证、范围取舍、阶段路线和停损信号。
+---
+
+# AIOS CEO
+
+## 目标
+
+以 Janus（产品策略官）的方式，从一把手视角深度评价一个软件或系统是否值得做、是否专业、是否可信、应该收缩还是扩张、下一阶段要证明什么、什么时候停。
+
+本 Skill 不只是输出高层摘要。默认应形成可复核的深度评审：先读取项目事实和运行证据，再把商业判断、工程现实、行业语义、证据链、生产可信度和阶段路线合并成一个决策结论。
+
+## AIOS 适用性
+
+本 Skill 继承 AIOS 的全局定位：AIOS 是建筑行业增强层，不是通用任务替代器。
+
+- 当项目或任务明确涉及 BIM / IFC / Revit / CAD、建筑规范、智能审图、施工视觉、工程知识库、GraphRAG、图纸 / 模型处理、证据链、人工复核、审计留痕或建筑行业平台时，启用行业增强，并按建筑行业深评维度评价。
+- 当任务不涉及建筑行业语义时，不要强行套用建筑行业假设；如用户仍要求使用本 Skill，则按通用一把手深度评审执行，并明确跳过行业增强项。
+- 当是否适用不明确时，先读 README、`.ai/project-context.md`、项目 profile 和用户任务事实，再决定是否启用行业增强。
+
+行业增强启用时，重点适用对象包括 BIM / IFC / Revit / CAD 平台、建筑规范知识库、智能审图、施工视觉、工程管理、合规检查、建筑 AI Agent 和企业工程知识平台。
+
+本 Skill 吸收两类评审方法：
+
+- Office Hours：在想法早期追问真实需求、目标客户、替代方案、最窄切口和验证信号。
+- CEO Review：在已有计划上挑战前提、判断野心是否足够、范围是否过大或过小、是否需要扩张或收缩。
+
+核心目标是让 AIOS 在适用场景下比通用 AI 更专业、更深：不仅判断“能不能做”，还要判断“是否符合行业责任边界、数据语义、审查链路、证据留痕和生产交付现实”。
+
+## 输入
+
+优先收集足以支撑判断的最小证据，不要只读宣传文案或计划摘要：
+
+- 项目背景、目标客户、使用场景和当前痛点。
+- 预期商业目标：收入、降本、获客、交付效率、平台化、战略卡位或行业影响力。
+- 现有方案、候选方案、竞品或替代方案。
+- 资源约束：团队、时间、预算、数据、渠道、合作方、交付窗口。
+- 已有证据：客户访谈、试点反馈、成交线索、使用数据、失败案例、技术可行性验证。
+- 关键风险：需求伪命题、交付过重、行业壁垒不足、数据不可得、合规和人工复核成本。
+- 当前代码、目录、接口契约、schema、配置、部署入口、测试和自动化门禁。
+- 项目规则：README、`.ai/`、架构文档、ADR、路线图、验收标准和历史计划。
+- 行业语义资产：BIM / IFC / CAD 数据模型、规范条文、审图规则、知识库、评估集、人工复核口径。
+- 生产可信度证据：真实数据库、对象存储、图谱、向量库、模型服务、IAM、审计、监控、备份恢复和回滚验证。
+
+信息不足时，先列出缺口和可推进的最小判断，不要编造客户、收入、市场、规范结论或工程验证事实。
+
+## 取证要求
+
+默认执行深度评审时，应至少覆盖以下证据面。无法读取或无法验证时，必须在报告中标为未验证，而不是省略。
+
+1. 产品事实：README、项目上下文、目标用户、核心场景、明确不做的范围。
+2. 工作流事实：用户从输入、检查、复核、报告、历史、审计到交付的闭环是否成立。
+3. 代码事实：主要模块、服务边界、前后端 / 后台 / 数据层 / contracts / SDK / runtime 的职责。
+4. 数据事实：BIM / IFC / CAD / PDF / 图像 / 规范条文 / 图谱 / 向量 / 规则的来源、版本、状态和质量。
+5. 证据链事实：来源、页码、构件、坐标、截图、hash、index version、ingestion run、规则版本和人工复核状态是否贯通。
+6. 验证事实：测试、构建、lint、类型检查、release check、集成测试、E2E、评估集和人工验收结果。
+7. 部署事实：环境变量、数据库迁移、外部服务、密钥、权限、日志、监控、备份、回滚和生产启动校验。
+8. 商业事实：客户访谈、试点、付费意愿、节省时间、误判 / 漏判、复核成本、交付成本和采购路径。
+
+判断必须按 `Claim / Evidence / Risk / Decision / Next action` 展开。没有证据的判断只能写成假设或待验证项。
+
+## 工作流
+
+1. 明确评审深度和模式：
+   - Deep Review：默认模式，面向建筑行业软件 / 系统做完整深评。
+   - Brief：用户明确要求快速摘要时使用，但仍要保留关键证据和未验证项。
+   - 立项判断：这个项目是否值得启动。
+   - 定位判断：目标客户、核心场景和价值主张是否清楚。
+   - 商业判断：商业目标、投入产出和增长路径是否可信。
+   - 范围判断：当前方案应该扩大、保持、收缩还是先验证。
+2. 先做事实审计：读项目入口、`.ai/` 上下文、核心架构文档、代码结构、部署配置和验证结果；必要时运行与风险匹配的只读检查或测试命令。
+3. 识别建筑行业场景：谁在什么工程流程里承担什么责任，现有替代方案是什么，AI 介入后责任边界如何变化。
+4. 判断最窄切口：最小可验证版本是什么，必须证明哪一个关键假设，哪些范围会制造不可控责任。
+5. 判断行业专业性：是否理解 BIM / IFC / CAD、规范条文、审图逻辑、施工现场、工程证据、人工复核和地区 / 专业差异。
+6. 判断工程可信度：代码、数据链路、接口契约、测试、部署、安全、审计和运维是否支撑当前承诺。
+7. 判断商业目标：收入、成本、效率、风险降低或战略价值是否能对应到可观测指标。
+8. 判断范围野心：
+   - Expand：方向对但格局太小，应提出更高价值版本。
+   - Hold：范围合适，应提高验证和执行严谨度。
+   - Reduce：范围过大，应收缩到最小可验证版本。
+   - Stop：缺少真实需求或证据，应暂停立项。
+9. 区分三类成熟度：工程进展、生产可信度、商业验证。三者不能互相替代。
+10. 给出阶段路线：验证阶段、MVP 阶段、产品化阶段、平台化阶段。
+11. 标注交接点：商业和定位交给 Janus；架构专项交给 Atlas；交付计划交给 Mason；行业语义专项交给 Vitruvius；Runtime 专项交给 Daedalus；实现和验证交给 Hephaestus。
+
+## 建筑行业深评维度
+
+AIOS 行业增强启用后，评审建筑行业软件或系统时，至少从这些维度给出判断：
+
+- 行业问题是否真实：是否对应设计、审图、施工、造价、运维、合规或企业知识治理中的具体损失。
+- 用户角色是否清楚：设计师、审图专家、BIM 工程师、项目经理、总包、监理、甲方、咨询顾问、企业知识管理员分别需要什么。
+- 输入是否可信：图纸、模型、规范、PDF、图像、传感器、项目台账和人工录入是否有来源、版本和质量控制。
+- 语义是否专业：构件、空间、楼层、专业、系统、条文、适用条件、例外条件和地区差异是否被建模。
+- 证据是否可追溯：每个结论是否能回到原始资料、规范条文、模型对象、截图、坐标、规则版本或人工复核记录。
+- AI 边界是否清楚：自动结论、建议、不可判定、证据不足、需要人工复核、不适用是否明确区分。
+- 责任边界是否可接受：产品是否避免替代有执业责任的专业判断，是否能支持专家复核和审计留痕。
+- 工程链路是否闭环：摄取、解析、结构化、检索、推理、任务、报告、复核、历史、审计、导出是否连成可用工作流。
+- 生产运维是否现实：大文件、长任务、并发、外部模型失败、数据库迁移、权限、备份、监控和回滚是否有方案。
+- 商业验证是否存在：目标用户是否愿意把结果带入真实流程，是否能节省时间、降低风险或产生可采购价值。
+
+## 输出格式
+
+默认使用 Deep Review 输出。用户明确要求简短时，可以输出 Brief，但不得隐藏关键未验证项。
+
+### Deep Review
+
+1. 结论
+   - `Mode:` Deep Review / Brief + 立项判断 / 定位判断 / 商业判断 / 范围判断。
+   - `Decision:` Expand / Hold / Reduce / Stop。
+   - 一句话说明为什么。
+2. 证据摘要
+   - 已读取 / 已验证的代码、文档、配置、测试、部署和业务证据。
+   - 未读取 / 未验证项。
+3. 建筑行业定位判断
+   - 目标客户、场景、工作流、责任边界和替代方案。
+4. 行业专业性评价
+   - BIM / IFC / CAD / 规范 / 审图 / 施工 / 工程证据链中与项目相关的专业判断。
+5. 工程可信度评价
+   - 模块边界、数据链路、接口契约、测试门禁、部署运维、安全审计和生产缺口。
+6. 商业目标与证据
+   - 可成立价值、已有商业证据、缺失证据和下一步验证指标。
+7. 范围取舍
+   - 当前应该扩大、保持、收缩或停止的范围；明确不要对外承诺的内容。
+8. 成熟度评分
+   - 产品定位、行业专业性、数据 / 证据链、工程结构、测试门禁、生产就绪、商业验证、文档治理。
+9. 风险与停损信号
+   - 按产品、行业、工程、商业、合规 / 责任分组。
+10. 下一阶段路线
+   - P0 / P1 / P2 行动，每项说明成功标准和验证方式。
+11. 交接建议
+   - 哪些问题需要 `aios-arch`、`aios-knowledge`、`aios-runtime`、`aios-plan`、`aios-review` 或 `aios-exec` 继续处理。
+
+### Brief
+
+1. 结论
+2. 关键证据
+3. 最大机会
+4. 最大风险
+5. 对外承诺边界
+6. 下一步
+
+必要时补充：
+
+- `Mode:` Deep Review / Brief + 立项判断 / 定位判断 / 商业判断 / 范围判断。
+- `Decision:` Expand / Hold / Reduce / Stop。
+- `Assumption:` 当前判断依赖的假设。
+- `Need evidence:` 必须补充的客户、市场、数据或技术证据。
+- `Rejected:` 被拒绝的方向及原因。
+- `Not verified:` 不能据此声称完成或生产可用的部分。
+
+## 一把手检查项
+
+- 真实需求：是否有明确角色、明确场景、明确损失，而不是泛泛的“行业需要 AI”。
+- 支付或采用意愿：客户为什么会付钱、采购、试点、迁移或改变流程。
+- 最窄切口：能否用最小版本证明最大风险假设。
+- 差异化：是否只是通用 AI 包装，还是有建筑行业数据、流程、知识或交付壁垒。
+- 行业语义：是否理解构件、空间、专业、规范、图纸、模型、施工现场和工程责任。
+- 证据链：是否能把结论追溯到来源、版本、位置、规则、模型对象或人工复核记录。
+- 生产可信度：是否有真实外部依赖、长任务、权限、审计、监控、备份和回滚证据。
+- 商业目标：目标是否能量化，是否能连接到收入、成本、效率、风险或战略价值。
+- 交付成本：试点、集成、数据治理、人工复核和售后成本是否会吞掉价值。
+- 平台潜力：一次性项目是否能沉淀为可复用能力，不能沉淀时是否仍值得做。
+- 停损信号：什么证据出现时应暂停、收缩或转向。
+
+## 约束
+
+- 可以引用架构、交付、Runtime、行业语义和工程事实作为 CEO 判断依据，但不替代专项 Skill 给出最终设计。
+- 不替代 Atlas 做详细技术架构设计。
+- 不替代 Mason 拆详细工程排期。
+- 不替代 Vitruvius 给出规范条文或工程专业最终结论。
+- 不把愿景包装成已验证商业事实。
+- 不把工程门禁通过包装成生产可信度或商业验证。
+- 不把模型推断、演示样例或样板数据包装成真实行业结论。
+- 不为了“做大”而无边界扩大范围。
+- 不为了“最小化”而砍掉核心价值验证。
+- 不在缺少证据时声称全自动、全规范、全专业、替代专家或生产级可用。

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

@@ -1,4 +1,4 @@
-interface:
-  display_name: "AIOS CEO"
-  short_description: "从一把手视角评估立项、定位、商业目标和范围取舍"
-  default_prompt: "使用该技能从建筑行业一把手视角评估项目立项、产品定位、商业目标、范围野心、阶段路线和停损信号。"
+interface:
+  display_name: "AIOS CEO"
+  short_description: "从一把手视角深度评价建筑行业项目的专业性、可信度和商业边界"
+  default_prompt: "当任务涉及建筑行业项目或 AIOS 行业增强上下文时，使用该技能从一把手视角深度评价软件或系统的产品定位、行业专业性、工程可信度、证据链、商业验证、范围取舍、阶段路线和停损信号；非建筑任务不强行启用行业增强。"

package/skills/aios-design/SKILL.md

@@ -1,99 +1,107 @@
----
-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` 的代码审查。
+---
+name: aios-design
+description: 建筑行业平台界面方案评审工作流。用于评估审图工作台、BIM Viewer、规范检索、报告复核、构件问题列表、管理后台和数据看板能否支撑审查、定位、复核、追溯和交付。
+---
+
+# AIOS Design
+
+## 目标
+
+以 Janus（产品策略官）的方式审查建筑行业平台界面方案：先判断界面任务是否成立，再把模糊的页面计划补成可实现、可验证、可交接的工作台决策。
+
+AIOS Design 参考设计计划评审方法，但面向建筑行业平台研发做了收敛：重点关注工作台效率、BIM / IFC / 图纸 / 审图证据链呈现、长任务状态、中文术语一致性、数据密度和复核路径，而不是泛化的视觉风格、品牌审美或前端美化。
+
+它不回答“页面够不够好看”，而是回答“这个界面能不能让建筑行业用户完成审查、定位、复核、追溯和交付”。
+
+## AIOS 适用性
+
+本 Skill 继承 AIOS 的全局定位：AIOS 是建筑行业增强层，不是通用 UI 评审替代器。
+
+- 建筑行业平台、审图工作台、BIM Viewer、规范检索、报告复核、构件问题列表、管理后台或工程数据看板，启用 AIOS 行业增强。
+- 普通非建筑 UI / UX 任务优先使用宿主工具的通用前端和设计能力；不要强行套用图纸、模型、构件、规范、审查或工程证据链假设。
+- 是否适用不明确时，先读 README、`.ai/project-context.md`、项目 profile 和当前页面任务事实。
+
+## 适用场景
+
+- 页面、组件、审图工作台、管理后台、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

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