القائمة
ArkWeb 设计文档生成。可作为独立 subagent 运行。Phase 4 产出两个文档：requirement.md（需求基线评审）和 design.md（架构设计）。触发词：写设计文档、生成需求评审、写功能设计、输出 Spec。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill arkweb-design-docيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | arkweb-design-doc |
| description | ArkWeb 设计文档生成。可作为独立 subagent 运行。Phase 4 产出两个文档：requirement.md（需求基线评审）和 design.md（架构设计）。触发词：写设计文档、生成需求评审、写功能设计、输出 Spec。 |
Announce at start: "我正在使用 arkweb-design-doc skill 生成设计文档。"
作为独立 subagent 被 arkweb-architect 调用时，方案和代码分析结果已在 task 描述中提供，直接生成文档。
输入格式（从 task 描述中解析）：
## 确认的方案
{方案详情：方案类型、架构思路、关键修改点}
## 代码分析结果（读取此文件）
{DOCS_REPO}/analysis/{date}-{feature}-analysis.md
## 参考资料（按需读取）
- proposal 文档：{DOCS_REPO}/docs/features/{feature-name}/proposal.md
- brainstorm 文档：{DOCS_REPO}/docs/{date}-{feature}-brainstorm.md
- 架构参考：{DOCS_REPO}/references/arkweb-architecture.md
- 兼容性检查：{DOCS_REPO}/docs/api-compatibility-check-arkweb.md
输出： 两个文档 → 保存到指定路径 → 回复文档结构摘要
requirement.md：需求基线评审文档（模板：assets/templates/requirement.md）design.md：架构设计文档（模板：assets/templates/design.md）在主 session 中直接调用，用户确认方案后生成文档，生成后请用户审阅。
基于 brainstorm 阶段确定的方案，按标准模板输出正式设计文档。
核心原则：单一方案文档。 设计文档中只体现最终确认的一个方案，不呈现方案 A/B/C 对比或多方案选型过程。brainstorm 阶段的方案对比分析保留在 brainstorm 文档中，设计文档聚焦于选定方案的完整实现细节。如果某功能存在降级/回退路径（如 CDP 不可用时回退 JS 注入），应在实现方案中作为异常处理章节说明，而非独立方案。
通用规则统一引用：../_shared/KB_RULES.md。本 skill 的增量要求：
| 阶段 | 模板 | 适用场景 |
|---|---|---|
| 需求导入检查 | requirement-import-checklist.md | 需求刚进入时的 17 项检查 |
| 需求基线评审 | requirement-baseline-review-template.md | 正式评审（推荐） |
| 功能设计说明书 | widget-ai-functional-design.md | 复杂需求，含 DFX 分析 |
| API Spec | template-openharmony-spec.md | API 设计 Spec |
根据 brainstorm 的方案类型，读取相关文档：
{DOCS_REPO}/docs/api-compatibility-check-arkweb.md{DOCS_REPO}/references/arkweb-architecture.md{DOCS_REPO}/references/competitor-analysis.md{DOCS_REPO}/references/device-matrix.md{DOCS_REPO}/analysis/arkweb-ace-engine-analysis.md{DOCS_REPO}/analysis/{date}-{feature}-analysis.mdStep 1 输出要求（强制）：
{DOCS_REPO}/tmp/，详见 _shared/KB_RULES.md 第 10 节在生成文档前，先向用户展示模板分析项清单，让用户选择哪些章节需要分析，哪些不需要：
📋 模板分析项清单（回复序号，不需要分析的项我会标记"不涉及"）：
1. 诉求方
2. 需求背景（问题背景/现状/目标/技术说明）
3. 竞品分析（各竞品现状/竞品分析总结）
4. 需求描述（功能范围、典型场景、验收标准）
5. 功能点（AR）拆解
6. 功能概述
7. 0层架构设计（周边依赖、进程/线程模型、数据流）
8. 实现方案（架构图/类图/时序图）
9. 接口设计（参数表、类型定义、示例代码，标注内部/外部）
10. 芯片平台和产品约束（1+8 设备差异表，仅有效功能点）
11. 周边依赖关系
12. 安全隐私设计
12. 性能功耗设计（表格格式：性能/内存/功耗）
13. 本地数据库设计
14. DFX 分析（可靠性/基础安全保障/埋点规格/可服务性/可扩展性/可配置/兼容性/可测试性）
15. 其他非功能性分析（分档分级/边界场景矩阵/演进路线）
回复示例：`1-8, 10, 14-15`（跳过 9/11/12/13）
或：`全部分析`
用户选择后：
> 不涉及，不展开在 task 描述中通过 ## 分析项范围 字段指定，格式同上。若未指定，默认全部分析。
Phase 4 产出两个文档，各自使用独立模板：
【强制】生成文档前，必须先 Read 模板文件，严格按模板的章节结构、中文章节标题、表格格式填充内容。不得自行改为英文结构或英文标题。这是硬性要求，不是建议。
1. requirement.md（需求基线评审）
{DOCS_REPO}/assets/templates/requirement.md> 不涉及，不展开> 引用块为格式规范说明，生成时删除2. design.md（架构设计）
{DOCS_REPO}/assets/templates/design.md【需求背景】（四段式，必选 + 可选）
【竞品分析】（表格化呈现）
【需求描述】
【功能点（AR）拆解】
【0层架构设计】（作为 2.0 子章节，位于实现方案内）
【性能功耗设计】（表格格式）
【DFX 分析】
【其他非功能性分析】
subsystems/*.json -> component_files，未使用字符串拼路径设计文档只做三件事：讲清楚为什么做、怎么做、验收标准是什么。不堆砌实现细节。
| 章节 | ✅ 该放 | ❌ 不该放 |
|---|---|---|
| 需求背景 | 问题背景、现状、目标（三段式） | 具体代码/API/类名 |
| 竞品分析 | 表格对比（竞品/场景/实现/限制） | 未来设计实现方案 |
| 需求描述 | 功能范围、典型场景、验收标准 | 实现方式、架构细节 |
| 功能概述 | 关键设计特点、设计约束 | 代码实现链路（5仓库表）、调用链路图、ASCII 详细伪代码 |
| 0层架构 | 进程划分、数据流、核心类关系 | 数据约束表、错误码枚举 |
| 接口设计 | 参数表、错误码、C++ 签名 | 架构图、实现伪代码细节 |
| DFX 埋点 | 埋点内容 + 触发示例 + 全局关键词 | 埋点位置（代码层面）、性能 trace 数据 |
| 可服务性设计 | 错误码覆盖、DFX 日志、远程排查 | |
| 测试方式 | 测试方式、边界场景 | 框架兼容性矩阵、不可测试点 |
| 其他非功能分析 | 分档分级、边界场景矩阵、兼容性说明 | 参考文档索引 |
| 场景 | ✅ 正确 | ❌ 错误 |
|---|---|---|
| 设计文档类型 | 需求基线评审文档 | 代码实现文档、PR 摘要 |
在 arkweb-spec-review skill 的自检中新增模板合规检查项，评审前自动扫描以下问题：
checklist = [
("章节职责", "0层架构.*数据约束|功能概述.*PR清单|接口设计.*架构图|DFX.*埋点位置"),
("最小必要", "附录|调用链路|参考文档|框架兼容性矩阵"),
("风险标注", "低|中|高.*无.*风险.*说明"),
]
保存两个文档并回复结构摘要。不等待用户审阅（由主 session 的决策 2 处理）。
输出文档后请用户审阅，修改后重新自检。
{DOCS_REPO}/docs/features/{feature-name}/{date}-{feature}-requirement.md（需求基线评审）{date}-{feature}-design.md（架构设计）<!-- architect: ... -->✅ design-doc 完成
📄 requirement.md：{file_path}
📄 design.md：{file_path}
📋 requirement.md 结构：
- 需求描述：{N} 个典型场景，{N} 个验收标准
- 功能点（AR）：{N} 个（P0: {N}, P1: {N}）
- 0层架构：进程模型 ✅ 线程模型 ✅ 数据流 ✅
- 功能设计：架构图 ✅ 类图 ✅ 时序图 {N}个
- 接口设计：{N} 个外部接口，{N} 个内部接口
- 设备矩阵：{N} 个有效功能点 × 6 类设备
- DFX：8/8 维度覆盖，日志 {N} 处，trace {N} 处
📋 design.md 结构：
- 涉及仓：{N} 个
- ADR：{N} 项
- 骨架 Spec：{N} 个 Task
Use when managing GitCode repositories from the terminal with oh-gc CLI — auth, issues, PRs, reviewers, testers, labels, releases, and repo config. Triggers on oh-gc commands, GitCode issue/PR management, or when user wants to interact with GitCode without a browser.
对 ArkUI 公共 UI API 与 Android（Compose/View）和 iOS（SwiftUI/UIKit）进行可审计的能力与规格竞品分析。 适用于接口设计评审、能力补齐、Android/iOS 与 ArkUI 迁移评估、API 对标和 capability gap analysis， 覆盖触摸/指针输入、键盘快捷键、手势、组件、布局、状态和动画。要求锁定作用域与版本，以 interface_sdk-js 为 ArkUI 公共接口权威源，优先引用 Android/iOS 官方文档，区分等价关系，并输出带逐项证据、影响和优先级建议的报告。
Use when orchestrating OHOS Phase 0 intake workflow, from raw requirement to IR + proposal splitting + handoff contract. Triggers: requirement intake, Phase 0, requirement review, generate IR, 需求导入, 需求评审, 生成IR. Do NOT use for single-feature design work, Phase 1-9 delivery, ad-hoc document generation, or any task outside the Phase 0 requirement intake workflow.