arkweb-brainstorm

ArkWeb Requirement Decomposition and Solution Design

Announce at start: "I am using the arkweb-brainstorm skill for requirement decomposition."

Run Modes

Mode A: Subagent Mode — Pre-injection (Recommended)

Scheduled as an independent subagent by arkweb-architect . The main Session has already completed knowledge base retrieval, reference document reading, and expert panel discussion. All key information is directly injected through the task description, and the subagent does not need to read the knowledge base or reference files on its own。

Advantages: Avoids the subagent repeatedly retrieving the knowledge base, which leads to excessive token consumption and timeouts.

Input format (parsed from the task description):

## 用户需求
{需求描述}

Constraints

Target devices: {device scope, default full coverage}
OHOS version: {version range, default all}
Confirmed boundary conditions: {Q&A results, if any}

Reference Information Summary (pre-read by the main Session)

{Key information, extracted and injected by the main Session from reference documents}

Knowledge Base Evidence Package (pre-retrieved by the main Session)

{Evidence retrieved through the knowledge base degradation strategy, including LOCAL_KB / DEEPWIKI / LOCAL_DOC / CODE evidence}

Expert Panel Discussion Minutes (pre-collected by the main Session)

{Summary of expert opinions}


**执行规则：**
1. **不自行检索知识库**——知识库证据包已在 task 描述中提供
2. **不读取任何参考文件**——所有信息已在 task 描述中提供
3. 直接从 Step 2（需求拆解）开始，跳过 Step 1（理解项目上下文 + 知识库检索）
4. 在方案设计中引用知识库证据包中的条目
5. 跳过 Step 2.5（专家团讨论）——已在主 Session 完成
6. 直接进入 Step 3（提出方案）→ Step 4（交互场景分析）→ Step 5（输出）
7. **【强制】** 文档末尾必须输出「知识证据清单」，引用知识库证据包中的条目

**输出：** 完整的 brainstorm 文档 → 保存到指定路径 → 回复摘要

### 模式 B：交互模式

在主 session 中直接调用时，逐项确认需求边界后再输出方案。流程见下方 Step 2。

---

## 概述

将 ArkWeb 相关需求从 PRD/想法拆解为可落地的技术方案。输出 2-3 个可选方案及推荐建议。

## 知识库驱动规则

通用规则统一引用：`../_shared/KB_RULES.md`。本 skill 的增量要求：

- **模式 A**：主 Session 已在 Phase 2 Step 2.0 执行知识库检索并注入证据包，subagent 直接引用，不重复检索
- **模式 B**：subagent 自行按 `_shared/KB_RULES.md` 的降级策略检索
- brainstorm 文档必须新增「知识证据清单」小节
- 专家团讨论与方案推荐必须引用同一份证据包，避免跨专家口径不一致

## 流程

### Step 1: 理解项目上下文

> **⚠️ Subagent 预注入模式下跳过此步骤**——主 Session 已在 Phase 2 Step 2.0 完成知识库检索并注入证据包。

1. 读取已有参考文档：
   - `{DOCS_REPO}/docs/` 下的相关文档
   - `{DOCS_REPO}/analysis/arkweb-ace-engine-analysis.md`（ACE Engine 代码索引）
   - `{DOCS_REPO}/references/arkweb-architecture.md`（架构参考）
2. 检查 git 最近提交，了解项目当前状态
3. 按 `_shared/KB_RULES.md` 的降级策略执行知识库检索
4. 生成「候选子系统/部件/API」列表
5. 输出知识证据包（后续专家讨论与方案设计都必须引用该证据包）
6. **【强制持久化】** 证据包 Write 到 `{DOCS_REPO}/tmp/`，详见 `_shared/KB_RULES.md` 第 10 节

### Step 2: 需求拆解

#### Subagent 模式
直接从 task 描述中读取约束条件，跳过交互确认。

#### 交互模式
逐项确认，一次只问一个问题：

1. **功能边界**：这个需求涉及哪些 ArkWeb 层？（API 层 / 框架层 / 内核层 / 平台层）
2. **设备范围**：目标设备有哪些？（手机/平板/PC/2in1/智慧屏/手表/车机/IoT）
3. **兼容性要求**：需要兼容哪些 OHOS 版本 / API Level？
4. **性能基线**：有无明确的性能指标要求？
5. **安全约束**：有无隐私/安全/沙箱方面的限制？

### Step 2.3: 知识库候选集收敛（新增）

在专家讨论前，基于知识库证据包先输出候选集，避免专家讨论偏题：

- 核心候选子系统（1~3 个）
- 核心候选部件（3~8 个）
- 代表性候选接口（5~15 个）
- 每项都必须附证据来源（按 `_shared/KB_RULES.md` 的 source_type 标注）

### Step 2.5: 专家团讨论（Subagent 并行）

#### 总架构师（自己）角色
你是总 Web 大架构师，负责召集专家团、收集意见、总结归纳。

#### 专家团成员（10 个独立 Subagent）
| # | Expert ID | 角色 | Skill 路径 |
|---|-----------|------|-----------|
| 1 | arkweb-expert-performance | ⚡ 性能专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-performance/SKILL.md |
| 2 | arkweb-expert-multimedia | 🎬 多媒体专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-multimedia/SKILL.md |
| 3 | arkweb-expert-peripheral | 🔌 外设服务专家（传感器/电池/唤醒锁/震动/屏幕） | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-peripheral/SKILL.md |
| 4 | arkweb-expert-interaction-security | 🔐 交互安全专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-interaction-security/SKILL.md |
| 5 | arkweb-expert-rendering | 🎨 渲染引擎专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-rendering/SKILL.md |
| 6 | arkweb-expert-compositing | 🖼️ 渲染合成专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-compositing/SKILL.md |
| 7 | arkweb-expert-interaction-motion | ✨ 交互专家（滚动/缩放/菜单/选择/拖拽/上传/焦点/填充/AI化） | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-interaction-motion/SKILL.md |
| 8 | arkweb-expert-network | 🌐 网络加载专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-network/SKILL.md |
| 9 | arkweb-expert-js-engine | ⚙️ JS 引擎专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-js-engine/SKILL.md |
| 10 | arkweb-expert-stability | 🛡️ 稳定性与 DFX 专家 | {SKILL_HOME}/skills/arkweb-experts/arkweb-expert-stability/SKILL.md |

#### 执行方式

**并行 spawn 10 个专家 subagent**，每个专家独立分析需求并输出意见。

每个专家的 task 模板：

You are a {role name} expert in the ArkWeb field. Please analyze the following requirement and give your opinion from your professional perspective.

Read your skill file: {skill_path}
Give your opinion according to the output format defined by the skill

User Requirement

{user_requirement}

Constraints

Target devices: {device_scope}
OHOS version: {ohos_versions}

Reference Materials (read as needed)

Architecture reference: {DOCS_REPO}/references/arkweb-architecture.md
ACE Engine analysis: {DOCS_REPO}/analysis/arkweb-ace-engine-analysis.md
Offline knowledge base: {kb_root}
DeepWiki supplementary evidence: {deepwiki_hits}

Output

Directly output your expert opinion; no need to save a file. The opinion must cite knowledge evidence (LOCAL_KB or DEEPWIKI).


#### 总架构师汇总

所有专家意见收集完成后，总架构师执行以下汇总工作：

1. **分类整理**：将专家意见按"采纳/参考/暂不考虑"分类
2. **提取共识**：多个专家共同关注的问题
3. **识别冲突**：不同专家之间的意见分歧
4. **融入方案**：将采纳的意见融入后续方案设计中

汇总格式：
```markdown
## 🧠 专家团讨论纪要

### 共识（3+专家一致）
- {共识1}

### 高价值建议（2专家提出）
- {建议1}

### 分歧与权衡
- {分歧1}：{专家A} 认为... vs {专家B} 认为... → 结论：{总架构师裁定}

### 领域特定关切
- ⚡ 性能：{关键点}
- 🎬 多媒体：{关键点}
- ...

### 对方案的影响
- 采纳的专家意见将如何影响方案设计

Notes

The expert panel discussion is executed only under Subagent Mode(can be skipped in interactive mode)
If the requirement clearly involves only 1-2 domains, you may spawn only the relevant experts (but at least 3)
Expert opinions are input, not the deciding factor — the final solution is comprehensively determined by the chief architect

Relevance Weight Mechanism

To prevent the discussion from deviating from the topic, the relevance weight rules must be followed:

Weight levels:

🟢 Core expert(weight 3x): the main functionality of the requirement directly belongs to this expert's domain
🟡 Related expert(weight 2x): the requirement may indirectly affect this expert's domain
⚪ Observer expert(weight 1x): the requirement is basically unrelated to this expert's domain

Determination method: Before spawning experts, the chief architect first determines the relevance level of each expert.

Discussion control:

Core experts' opinions should account for 40%+ of the total opinions
Related experts' opinions should account for 30%
Observing experts only need to give brief statements (1-2 points), no more than 30%
If more than 5 experts are judged as "observing", these experts can be skipped from spawning (to save resources)

Summary annotation: In the expert panel discussion minutes, annotate each expert opinion with a weight level (🟢/🟡/⚪).

Example: If the requirement is "gesture simulation injection":

🟢 Core experts: Interaction experts (scrolling/gestures/dragging), Rendering engine (DOM event dispatch)
🟡 Related experts: Rendering composition (compositor gesture handling), Performance (input latency), Stability (ANR)
⚪ Observing experts: Multimedia, Network, JS engine, Peripherals

Step 3: Propose solutions

Note: The solution design must incorporate the suggestions adopted in the Step 2.5 expert panel discussion. In the solution description, indicate "adopted the suggestion of expert XX".

Output 2-3 solutions, classified by degree of intrusion:

Solution	Degree of intrusion	Description
A	API layer	Pure ArkWeb API extension, does not involve kernel modification
B	Framework layer	Modify web_webview / ace_engine
C	Kernel layer	Modify the Chromium source branch

Each solution includes:

Architecture: Layered description + ASCII architecture diagram
Key modification points: Repositories, modules, and files involved
Pros and cons: Comparison matrix (10+ dimensions)
Risks: Technical risks / compatibility risks / schedule risks
Schedule estimate: In person-days
Knowledge basis: Corresponding subsystem/component/API evidence (offline path + DeepWiki URL)

Step 4: Interaction scenario analysis (supplementary)

For the parts of the solution involving user interaction, analyze boundary scenarios:

Drag + scroll conflict
Multi-finger operations
Keyboard/mouse vs touch mode differences
Special layouts (RTL, nested overflow, etc.)

Step 5: Output

Subagent mode

Save the document directly and reply with a summary.

Interactive mode

After the user selects a solution, notify the main session to enter the design-doc phase
If the user requests modifications to the solution, return to Step 3 for revision

Deliverables

Path：{project_root}/docs/YYYY-MM-DD-{feature-name}-brainstorm.md

Subagent reply format：

✅ brainstorm 完成
📄 文档：{file_path}
📋 方案摘要：
- 方案 A（{侵入程度}）：{一句话描述}，工期 {N}d
- 方案 B（{侵入程度}）：{一句话描述}，工期 {N}d
- 推荐：方案 {X}

About this skill

Run Modes

Mode A: Subagent Mode — Pre-injection (Recommended)

Constraints

Reference Information Summary (pre-read by the main Session)

Knowledge Base Evidence Package (pre-retrieved by the main Session)

Expert Panel Discussion Minutes (pre-collected by the main Session)

User Requirement

Constraints

Reference Materials (read as needed)

Output

Notes

Relevance Weight Mechanism

Step 3: Propose solutions

Step 4: Interaction scenario analysis (supplementary)

Step 5: Output

Subagent mode

Interactive mode

Deliverables