OMO使用介绍

关于本笔记

本笔记用于沉淀 oh-my-opencode（OMO）插件在 OpenCode 中的使用方法与适用场景，目标是理清四类 Agent 的职责边界，以及如何与 Superpowers skills、vibe 治理流程配合，形成可重复的开发工作流。

项目地址：https://github.com/code-yeongyu/oh-my-openagent

目录

项目简介

oh-my-opencode（OMO）是一套面向软件开发的 Agent 编排系统，它不是单一聊天机器人，而是把开发过程拆成不同角色：

  • 规划 — 想清楚怎么做
  • 深度执行 — 深入解决问题
  • 编排 — 统筹全局推进
  • 按计划落地 — 照既定计划执行

一句话：用对的人做对的事，不把所有期望压在一个 Agent 上。

安装配置参考https://www.opencodecn.com/docs/best-practices/oh-my-opencode

项目结构概览（四类 Agent）

OMO 通过 oh-my-opencode 插件注册到 OpenCode，提供四类预定义 Agent：

1
2
3
4
5
6
7
8
9
10
11
12
oh-my-opencode（OMO 插件）
├─ Prometheus（规划者）
│   把模糊需求拆成可执行计划，保存为 .sisyphus/plans/*.md
│
├─ Hephaestus（深度执行者）
│   端到端解决问题：探索 → 定位 → 实现 → 验证 → 修复
│
├─ Sisyphus（编排器/总控）
│   统筹复杂任务：决定何时规划、搜索、查文档、派子 Agent、整体验证
│
└─ Atlas（计划执行者）
    读取已有计划，按步骤推进，不重新设计

配合的外部 Agent 角色：

  • explore — 代码库快速搜索（contextual grep）
  • librarian — 外部文档/官方 API 查询
  • oracle — 复杂架构咨询与调试
  • Momus — 计划/工作审查

四类 Agent 的职责

Prometheus：Plan Builder，规划者

Prometheus 负责把目标拆成可执行计划。它适合需求不够清晰、影响范围较大、需要先设计方案时使用。

典型流程：

  1. 理解目标、约束和验收标准。
  2. 分析代码结构、依赖关系和风险点。
  3. 拆分阶段、任务、文件范围和验证方式。
  4. 输出可执行计划，形式是 .sisyphus/plans/*.md。
  5. 后续交给 Atlas、Hephaestus 或 Sisyphus 执行。

适合的请求：

1
先用 Prometheus 给这个重构做实施计划，不要改代码。
1
这个功能影响范围比较大，先帮我拆解方案和风险。

Hephaestus：Deep Agent，深度执行者

Hephaestus 负责端到端解决一个明确目标。它会探索代码、定位问题、实现修改、运行验证，并根据验证结果继续修复。

典型流程：

  1. 判断用户真实意图：分析、修复、实现、重构还是调研。
  2. 阅读代码库上下文，不凭空猜测。
  3. 必要时调用 explore、librarian、oracle 等辅助 Agent。
  4. 修改代码或文档。
  5. 运行诊断、测试、类型检查或构建。
  6. 修复验证阶段发现的问题。
  7. 输出完成内容和验证证据。

适合的请求：

1
使用 Hephaestus 深入排查这个性能问题，找到根因并修复。
1
帮我修复登录页 token 过期后无法刷新的问题，并跑相关测试。

Sisyphus：Ultraworker，编排器 / 总控

Sisyphus 负责统筹复杂任务。它像项目总控，决定何时规划、何时搜索、何时查文档、何时分派子 Agent，以及何时做整体验证。

典型流程：

  1. 接收目标并判断复杂度。
  2. 需要时调用 Prometheus 生成计划。
  3. 将不同子任务分派给 Hephaestus、Atlas、explore、librarian 等。
  4. 收集子任务结果。
  5. 处理冲突、依赖和验证缺口。
  6. 推动任务直到收敛。

适合的请求：

1
使用 Sisyphus 统筹完成这个 issue：先规划，再实现，再验证。
1
这个需求涉及多个模块，请自动拆分、执行并验证。

Atlas：Plan Executor，计划执行者

Atlas 负责执行已经确认的计划。它不适合重新设计方案，而适合按步骤稳定推进。

典型流程：

  1. 读取已有计划。
  2. 按计划步骤执行。
  3. 每完成一步做局部验证。
  4. 遇到计划不清楚或执行失败时反馈。
  5. 最后运行整体验证。

适合的请求：

1
使用 Atlas 执行 .sisyphus/plans/payment-refactor.md，不要重新规划。
1
这个计划已经确认了，请按步骤实现并验证。

Agent 组合关系与流转

大型任务可以按如下方式流转：

1
2
3
4
5
6
7
8
9
10
11
12
13
用户目标
  ↓
Sisyphus 判断复杂度并统筹
  ↓
Prometheus 生成计划
  ↓
人工或 Momus 审查计划，可选
  ↓
Atlas 按计划执行
  ↓
Hephaestus 处理复杂子任务或深水区问题
  ↓
Sisyphus 汇总、验证、收尾

轻量任务不需要完整链路。例如一个小 bug 可以直接交给 Hephaestus；一个已有计划可以直接交给 Atlas。

分类使用场景

日常小修小改

适合 bug fix、小功能、测试失败、类型错误、局部重构。

1
修复这个报错，并跑相关测试。
1
给这个组件补一个 loading 状态，保持现有样式风格。

不确定怎么做

适合影响多个模块、业务规则复杂、技术方案不明确、需要先审查方案的任务。

1
先用 Prometheus 规划这个权限系统改造，不要修改代码。

已有计划

适合已经确认实施方案，不希望 Agent 重新设计的任务。

1
使用 Atlas 执行 .sisyphus/plans/auth-refactor.md，按步骤验证。

复杂端到端任务

适合多模块、多阶段、需要搜索代码、查文档、实现和验证的任务。

1
使用 Sisyphus 统筹完成这个需求：先规划，再实现，再验证。

难 bug 或深水区问题

适合性能问题、复杂业务逻辑、类型系统问题、难以复现的 bug。

1
使用 Hephaestus 深入排查这个问题，定位根因、修复并验证。

选择 Agent 速查表

你的需求 推荐用法
小修小改 直接描述目标，让 Hephaestus 执行
不确定怎么做 先让 Prometheus 出计划
已有明确计划 让 Atlas 按计划执行
大型端到端任务 让 Sisyphus 统筹
难查的 bug / 性能问题 让 Hephaestus 深入排查
只想了解代码 明确说”只分析，不修改文件”
涉及外部库或框架 让流程加入 librarian / documentation lookup
需要浏览器验证 让流程加入 playwright

推荐提示词模板

只规划，不改代码

1
使用 Prometheus 规划这个任务。只输出计划、影响范围、风险和验证方式，不修改文件。

按计划执行

1
使用 Atlas 执行 .sisyphus/plans/xxx.md。不要重新规划，按步骤实现并验证。

端到端完成

1
使用 Sisyphus 统筹完成这个需求：先理解目标，再规划，实现后运行相关测试和构建。

深入排查并修复

1
使用 Hephaestus 深入排查这个 bug，找到根因，修复后运行相关验证。

明确禁止修改

1
只分析，不修改任何文件。请说明当前实现、问题点和建议方案。

使用 OMO 默认编排

1
本次按 OMO 默认方式执行，不启用 vibe 流程。

使用 vibe 治理

1
本次按 vibe 流程执行，禁用自动花式分派。

并发与安全边界

OMO 支持并发子代理，但是否并发取决于调用方式和任务类型。

常见并发场景：

  • 多个 explore 同时搜索不同代码区域。
  • librarian 查询外部文档时，主 Agent 做本地非重叠探索。
  • 多个只读分析任务并行执行。

需要谨慎的场景：

  • 多个 Agent 同时修改同一文件。
  • 多个 Agent 同时重构同一个模块。
  • 一个任务依赖另一个任务的结果，却被提前并发执行。

经验原则：

探索可以并发，写代码要控制边界；只读任务适合并行，写入任务需要明确文件范围。

OMO 与 vibe 的关系

一次任务只选一个主控框架：

  • 如果选择 OMO 主导，就让 Sisyphus / Hephaestus / Prometheus / Atlas 按 OMO 方式推进。
  • 如果选择 vibe 主导，就明确说”本次按 vibe 流程执行”。
  • 不建议在同一个任务中同时叠加 OMO 自由编排和 vibe 治理流程，避免两套调度逻辑互相覆盖。

vibe 是治理型运行协议，适合中大型任务的约束、计划和阶段清理。OMO 是 Agent 编排系统，适合自动分派、深度执行和上下文探索。

推荐做法：

  • 日常快速开发：OMO 主导。
  • 大型、风险高、需求需要冻结的任务：vibe 主导。
  • 如果 vibe 主导，OMO/skills 可以作为执行阶段的能力补充，但不再另起一套自由编排。

项目级增强：AGENTS.md 与任务技能映射

默认 OMO 的 Agent 编排已经能完成很多工作，但在项目级别还可以进一步增强。核心思路是：不要只依赖 OMO 的默认 Agent 行为，而是在项目里写清楚 Agent 应该如何选择 skills、如何与 Superpowers 工作流配合、何时切换到 vibe 治理流程。

项目通过两个文件做增强：

  • AGENTS.md：告诉所有 Agent 本项目的协作原则、运行时边界、可用 skills、OMO 与 vibe 的关系。
  • .sisyphus/task-skill-map.md：告诉 Sisyphus 在分派子任务时，应该如何把任务类型映射到 load_skills。

为什么需要项目级定制

默认 OMO 可能知道有哪些 Agent，但不一定天然知道你的项目希望如何使用 skills。例如：

  • Bug 修复是否必须先诊断？
  • 前端视觉任务是否必须加载 frontend-design 和 frontend-ui-ux？
  • 实现任务是否默认走 TDD？
  • 完成前是否必须运行验证？
  • 大型任务是交给 OMO 统筹，还是交给 vibe 治理？

这些偏好不应该每次都靠口头提醒，而应该沉淀到项目级文档中。

AGENTS.md 核心原则

AGENTS.md 适合放高层规则，例如：

  • 先理解问题，再选择 skill。
  • 证据优先，不能在没有验证时声称完成。
  • 一次任务只选一个主控框架：OMO 或 vibe。
  • 轻量任务走最短路径，中大型任务可以进入治理流程。
  • 子 Agent 分派时不能默认 load_skills=[]。

任务技能映射表（.sisyphus/task-skill-map.md）

Sisyphus 通过 task() 分派子 Agent 时，必须把任务类型映射为明确的 load_skills，不要把实现、调试、重构、审查任务默认派成 load_skills=[]。

选择技能时区分两类：

  • 工作流技能：负责”怎么推进” — brainstorming、writing-plans、test-driven-development、subagent-driven-development、verification-before-completion
  • 领域/实现技能：负责”怎么写对” — context-hunter、aios-dev、frontend-design、diagnose

常用基线：

任务类型 推荐 category 推荐 load_skills
后端/API/认证/持久层 deep 或 quick context-hunter, aios-dev, tdd
全栈功能 deep context-hunter, autonomous-builder, aios-dev, tdd
前端 UI/布局/交互 visual-engineering context-hunter, frontend-design, frontend-ui-ux, tdd
Bug/失败测试/异常行为 deep 或 quick diagnose, context-hunter, tdd
架构/重构/模块边界 ultrabrain 或 deep context-hunter, zoom-out, improve-codebase-architecture
代码审查 unspecified-high code-reviewer, reviewing-code, code-review-excellence
Git 操作 quick 或 unspecified-high git-master

Superpowers 与 OMO 的配合方式

Superpowers 是”工作方法论 skills”，OMO 是”Agent 编排系统”。两者配合但不竞争。

常见组合：

  • 需求不清楚：brainstorming + Prometheus
  • 计划编写：writing-plans + Prometheus
  • 按计划执行：executing-plans 或 subagent-driven-development + Atlas
  • 实现/修复：test-driven-development 或 tdd + Hephaestus
  • 完成前验证：verification-before-completion + Sisyphus/Hephaestus
  • 开发分支收尾：finishing-a-development-branch + Git

关键原则：OMO 决定”谁来做”，Superpowers 约束”怎么做”。

推荐的项目级配置结构

1
2
3
4
5
AGENTS.md                        # 全局协作规则
.sisyphus/
  task-skill-map.md              # 任务到 skills 的映射
  plans/
    <task-plan>.md               # Prometheus 生成的执行计划

配置文件说明（重点）

使用 OMO 后重点关注以下配置文件：

  • opencode.json
    • 插件加载入口，注册 oh-my-openagent 和 superpowers
  • AGENTS.md
    • 项目级 AI 协作规则、Skill 选择原则、Agent 职责边界
  • .sisyphus/task-skill-map.md
    • Sisyphus 分派子 Agent 时 load_skills 的映射表，避免默认传空
  • .sisyphus/plans/*.md
    • Prometheus 生成的执行计划

常见误区与修正

误区 1：让 Sisyphus 做所有事，不区分 Agent 角色。

修正：Sisyphus 是编排器，不是执行器。实现交给 Hephaestus，计划交给 Prometheus，已有计划交给 Atlas。

误区 2：子 Agent 分派时默认 load_skills=[]。

修正：实现、调试、重构、审查任务都应带上明确 skills。只有 explore/librarian 等纯搜索 agent 才适合空列表。

误区 3：同时启用 OMO 自由编排和 vibe 治理流程。

修正：一次任务只选一个主控框架。OMO 主导就禁用 vibe，vibe 主导就禁用 OMO 自由编排。

误区 4：未澄清需求直接让 Agent 写代码。

修正：大任务先用 Prometheus 规划，难问题先用 Hephaestus 排查，边界模糊时先用 brainstorming。

误区 5：完成声明没有验证证据。

修正：任何”完成/修复/通过”声明，必须附验证命令和输出。verification-before-completion skill 强制此规则。

我的最小实践模板

以下的AGENTS.md与task-skill-map.md不一定符合你的项目, 使用AI根据你的实际情况进行重构

AGENTS.md:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
# AI 协作启示（本地 Skills 能力地图）

> 目的：这是一个**启示型**协作文档，不是死板流程表。  
> 目标：让 AI 知道你本地具备大量 Skills，可按任务实际情况动态组合调用。

## 核心原则

1. **先理解问题，再选 Skill**：先澄清目标、约束、验收标准，再决定调用路径。
2. **组合是动态的，不设上限**：Skill 可以多段拼接，按任务复杂度增减，不固定套餐。
3. **证据优先**：任何“完成/修复/通过”声明，必须附验证证据（命令、输出、检查点）。
4. **单一运行时权威**：涉及实现任务时，优先沿 `vibe` 治理链路推进，避免并行造第二套路由。
5. **最小充分调用**：优先少而准；当任务复杂时，再扩展到多 Skill/多 Agent。

## 本地 Skills 现状（能力提示）

当前环境已安装大规模 Skills，覆盖但不限于：

- **工程开发**：调试、测试、评审、CI、部署、性能、架构
- **数据与 ML**：EDA、统计建模、可视化、训练与评估
- **文档与知识**：Markdown/Docx/PDF/PPTX、报告、引用、知识沉淀
- **科研生信与化学**：多数据库查询、组学分析、药化与结构相关流程
- **平台集成**：GitHub、OpenAI、Sentry、Vercel、Netlify、MCP 等

> 注意：以上只是能力地图，不是限制列表；未列出的技能同样可以被调用。

## 智能体情况

除了vibe的智能体(Vibe-Review, Vibe-Implement, Vibe-Plan), 还有来自 oh-my-opencode 插件(oh-my-opencode@latest注入到 OpenCode 的“agent 注册表”)的智能体

- Prometheus (Plan Builder)：偏“规划/拆解”。把目标拆成可执行步骤/计划（文档里称它是 planner），通常配合 Sisyphus 的编排工作流使用。
- Hephaestus (Deep Agent)：偏“深度执行”。更像 autonomous worker，适合端到端实现一个较大的子任务（需要自己探索、自己完成）。
- Sisyphus (Ultraworker)：编排器/总控。负责决定何时探索、何时查文档、何时把任务拆给子 agent、以及验证/推进整体流程。
- Atlas (Plan Executor)：偏“按计划执行”。把已经写好的计划按步骤推进执行（相当于执行器/协调执行）。

## 推荐工作方式（非强制）

### 轻量任务

- 直接执行最短路径（可不进入复杂编排）
- 只在必要时调用 1-2 个针对性 Skills

### 中大型任务

- 使用 `vibe` 的治理阶段进行约束与计划：
- `skeleton_check`
- `deep_interview`
- `requirement_doc`
- `xl_plan`
- `plan_execute`
- `phase_cleanup`
- 在执行阶段动态选择最合适 Skills（可并行）
- 搭配 Superpowers 插件提供的工作流技能，但不要让它成为第二套运行时：
- `brainstorming`：理解需求、澄清模糊点、形成设计。
- `writing-plans`：把设计拆成可执行计划。
- `test-driven-development` / `tdd`：实现与修复时执行红-绿-重构。
- `subagent-driven-development`：按计划分派子 Agent，并在任务间做审查。
- `requesting-code-review` / `reviewing-code` / `code-reviewer`：完成任务后审查。
- `verification-before-completion`：任何完成声明前先跑验证命令。
- `finishing-a-development-branch`：实现完成后的合并、PR、保留或清理选择。

### vibe or oh-my-opencode

- oh-my-opencode 是作为 OpenCode 插件加载的（C:\Users\<Users>\.config\opencode\opencode.json:28）。
- vibe 是作为 skill 体系中的运行协议（governed runtime）存在，不是另一个插件内核。

实操建议（最稳）：

1. 一次任务只选一个主控框架：要么“vibe主导”，要么“oh-my-opencode主导”。
2. 需要 vibe 时，明确写：“本次按 vibe 流程执行，禁用自动花式分派”。
3. 日常快速开发就用 oh-my-opencode 默认自动编排，不额外叠加 vibe 管控。

### 研究/探索类任务

- 先做上下文收集（代码、数据、文档）
- 必要时引入专长 Skill（统计、可视化、数据库、文献）
- 输出结论时区分：已证实 / 待验证 / 假设

## 动态选型提示（给 AI）

当用户提出任务时，请按下列顺序自检：

1. 任务类型：实现 / 修复 / 分析 / 文档 / 调研 / 部署
2. 风险等级：是否涉及生产、数据安全、凭据、不可逆操作
3. 证据需求：需要哪些验证命令与验收标准
4. Skill 组合：从本地已装技能中选最匹配组合，必要时迭代替换

### Sisyphus 子 Agent 技能分发规则

Sisyphus 通过 `task()` 分派子 Agent 时，必须把任务类型映射为明确的 `load_skills`，不要把实现、调试、重构、审查任务默认派成 `load_skills=[]`。

项目级映射表位于 `.sisyphus/task-skill-map.md`。分派前先按该表选择技能；若没有精确匹配，默认传入 `context-hunter`，涉及生产行为变更时再加入 `tdd`。

选择技能时区分两类：Superpowers 工作流技能负责“怎么推进”（如 `brainstorming`、`writing-plans`、`test-driven-development`、`subagent-driven-development`、`verification-before-completion`），领域/实现技能负责“怎么写对”（如 `context-hunter`、`aios-dev`、`frontend-design`、`diagnose`）。大型任务可以两类组合；轻量任务优先选择最少必要技能。

允许 `load_skills=[]` 的主要场景是纯搜索型子 Agent，例如 `explore` / `librarian`，或者明确不需要技能的轻量文本整理。除此之外，空列表必须视为需要重新评估的异常。

常用基线：

- 后端/API/认证/持久层：`context-hunter`, `aios-dev`, `tdd`
- 前端/UI/布局/交互：`context-hunter`, `frontend-design`, `frontend-ui-ux`, `tdd`
- Bug/失败测试/异常行为：`diagnose`, `context-hunter`, `tdd`
- 架构/重构/模块边界：`context-hunter`, `zoom-out`, `improve-codebase-architecture`
- 代码审查：`code-reviewer`, `reviewing-code`, `code-review-excellence`
- Git 操作：`git-master`

子 Agent prompt 中也应显式写明：`Required skills for this task: ... Load and follow them before editing files.` 这只是兜底；首选机制仍然是 `task(load_skills=[...])`。

## 禁止与边界

- 不得把“示例组合”当作唯一固定流程。
- 不得在证据不足时声称任务完成。
- 不得因某个 Skill 不匹配而停止思考；应改用更合适技能或回退基础链路。

## 一句话执行约定

> **以任务事实为中心，动态编排本地 Skills；先约束、后实现、再验证。**

task-skill-map.md:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

# Sisyphus Task Skill Map

This file is the project-local source of truth for choosing `load_skills` when Sisyphus delegates work through `task()`.

## Core rule

Do not default implementation, review, debugging, or refactoring subagents to `load_skills=[]`.

Use an empty skill list only for pure discovery agents whose job is contextual search, such as `explore` and `librarian`, or when a task is explicitly skill-neutral.

## Default fallback

If no row clearly matches, use:

```text
load_skills=["context-hunter"]
```

If the task writes or changes production behavior, add `tdd` unless the task is explicitly documentation-only, generated output, or configuration-only.

## Skill families

Use two families together when the task is large enough:

- **Workflow skills** describe how to run the work: `brainstorming`, `writing-plans`, `test-driven-development`, `subagent-driven-development`, `executing-plans`, `requesting-code-review`, `verification-before-completion`, `finishing-a-development-branch`.
- **Domain skills** describe how to do the work well: `context-hunter`, `aios-dev`, `frontend-design`, `diagnose`, `documentation-lookup`, `improve-codebase-architecture`, file-format skills, and similar specialist skills.

Do not add every workflow skill to every subagent. Pick the stage-specific one: planning gets planning skills, implementation gets TDD/context skills, completion gets verification/finish skills.

## Task mapping

| Task shape | Recommended category | Required `load_skills` | Notes |
|---|---:|---|---|
| Backend API, service logic, persistence, auth, job processing | `deep` or `quick` by scope | `context-hunter`, `aios-dev`, `tdd` | Use `deep` for cross-module changes; `quick` only for narrow edits. |
| Full-stack feature touching frontend and backend | `deep` | `context-hunter`, `autonomous-builder`, `aios-dev`, `tdd` | Add frontend skills if visual/UI behavior changes. |
| Frontend UI, layout, CSS, component polish, UX flow | `visual-engineering` | `context-hunter`, `frontend-design`, `frontend-ui-ux`, `tdd` | Visual work must use `visual-engineering`; add `playwright` when browser verification is needed. |
| Browser automation, UI-flow verification, screenshots | `visual-engineering` or `quick` by scope | `playwright`, `playwright-cli` | Use with implementation skills when validating UI changes. |
| Bug, failing test, unexpected behavior, regression | `deep` or `quick` by scope | `diagnose`, `context-hunter`, `tdd` | Find root cause before fixing; prove with a failing test when possible. |
| Architecture review, refactor opportunity, module deepening | `ultrabrain` or `deep` | `context-hunter`, `zoom-out`, `improve-codebase-architecture` | Add `tdd` when code changes will follow. |
| Code review, PR review, quality check | `unspecified-high` | `code-reviewer`, `reviewing-code`, `code-review-excellence` | For post-implementation review, prefer `review-work` when available. |
| Documentation or prose-only changes | `writing` | `writing-plans` when planning, otherwise no required implementation skill | Do not force `tdd` for prose-only work. |
| Requirements clarification, design exploration, product tradeoffs | `deep` or `writing` | `brainstorming` | Use before creative behavior/design work; stop before implementation until design is approved. |
| Implementation plan creation from an approved design/spec | `deep` or `writing` | `writing-plans` | Save plans under the project's chosen plan location; include exact files, tests, and commands. |
| Saved plan execution with mostly independent tasks | `deep` | `subagent-driven-development`, `context-hunter`, `tdd`, `requesting-code-review` | If executing a saved plan, pass the relevant per-task domain skills too. |
| Saved plan execution in a single session without subagent split | `deep` | `executing-plans`, `verification-before-completion` | Prefer `subagent-driven-development` when subagents are available. |
| Before claiming completion/fixed/passing | same as parent task | `verification-before-completion` | Run fresh verification before any completion claim. |
| Implementation complete and user asks how to finish/merge/PR | `quick` or `unspecified-high` | `finishing-a-development-branch`, `git-master` | Verify tests before offering merge/PR/keep/discard options. |
| Vibe-governed implementation | `deep` | `vibe`, plus the row-specific skills above | `vibe` owns runtime stages; Superpowers skills provide stage discipline only. |
| Git commit, branch, PR, blame, rebase, squash | `quick` or `unspecified-high` by risk | `git-master` | Never commit unless the user explicitly asks. |
| File write failure or high-risk file generation | same as parent task | `smart-file-writer` | Use reactively on write errors or proactively for critical writes. |
| Library/framework/API usage needing current docs | same as parent task | `documentation-lookup` | Also fire `librarian` for external examples or official docs research. |
| Word/PDF/PPTX/XLSX work | `writing` or domain category | `docx`/`pdf`/`pptx`/`spreadsheet`/`xlsx` as applicable | Use the file-format-specific skill before editing or generating artifacts. |

## Delegation prompt contract

When delegating implementation work, include a short line near the top of the subagent prompt:

```text
Required skills for this task: <comma-separated skill names from this map>. Load and follow them before editing files.
```

This text is a backup guard. The primary mechanism is still the `task(load_skills=[...])` argument.

## Examples

```text
Backend bug fix:
task(category="deep", load_skills=["diagnose", "context-hunter", "tdd"], ...)
```
```text
React page polish:
task(category="visual-engineering", load_skills=["context-hunter", "frontend-design", "frontend-ui-ux", "tdd", "playwright"], ...)
```

```text
Architecture refactor candidate:
task(category="ultrabrain", load_skills=["context-hunter", "zoom-out", "improve-codebase-architecture"], ...)
```