メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
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.
SKILL.md を表示中
SOC 職業分類に基づく
| 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