---
name: using-specpow
description: Bootstrap 元技能。Host-Driven 模式下会话启动时自动加载。教会宿主 Agent 使用原生工具执行 SDD 工作流。融合 Superpowers using-superpowers 模式 + SpecPow SDD 编排能力。
version: 1.0.0
trigger: session-start
mode: host-driven
---

<SUBAGENT-STOP>
如果你是被分发去执行特定任务的子代理，忽略此技能。
</SUBAGENT-STOP>

<EXTREMELY_IMPORTANT>
如果你认为有任何 1% 的可能性某个技能适用于你正在做的事，你绝对必须调用该技能。
如果一个技能适用于你的任务，你没有选择。你必须使用它。
这不可协商。你不能合理化地绕过它。
</EXTREMELY_IMPORTANT>

# SpecPow Host-Driven SDD 工作流

你已加载 **SpecPow** — 一个规范驱动的 AI 开发框架。
它结合了 OpenSpec 的规范驱动规划与 Superpowers 的子代理驱动执行。

**当前模式：Host-Driven** — 你将使用**原生工具**（subagent、file I/O、bash）执行整个 SDD 方法论。
TypeScript 代码仅负责非 AI 工作（文件创建、schema 解析）。**你是编排者。**

## 铁律

1. **先查技能** — 任何响应或行动之前，先扫描 `.specpow/skills/` 目录查找相关技能
2. **文件即接口** — 子代理通过文件通信（brief、report、review JSON），不通过对话上下文
3. **Ledger 是真相** — 上下文压缩后，信任 Ledger（`.specpow/changes/<change>/sdd/progress.md`）和 git log，不信任自己的记忆
4. **TDD 强制** — RED → GREEN → REFACTOR，不可跳过
5. **规范即契约** — specs 中定义的行为必须被实现遵守
6. **审查+测试才完成** — 每个任务实施完成后，必须经过**代码审查**且**测试全部通过**，才能标记为 done。审查通过后标记完成；审查未通过则进入修复循环（最多 5 轮），每轮修复后重新审查修复部分。
7. **发现必须验证** — 审查中发现的每个问题，必须**确认其真实存在**（读代码、跑测试、看 diff）后才能记录。禁止无中生有——不确定的发现标记为 `cannotVerify`，不标记为 finding。

## 触发纪律（Trigger Discipline）

| 用户说 / 场景 | 你做什么 |
|---------------|----------|
| `specpow apply`（默认模式） | 不干预 — TypeScript SDD 引擎接管 |
| `specpow apply --host-driven`（计划中） | 读取任务清单，按 `execution-subagent-driven-dev` 技能逐任务执行 |
| `specpow explore "..."` | 调用 `planning-explore` 技能 |
| `specpow propose <name>` | 调用 `planning-propose` 技能 |
| 任何编码任务 | 先检查 `.specpow/skills/` 是否有适用技能 |
| 发现 SDD 工作区（`.specpow/changes/<change>/sdd/`） | 自动读取 progress.md 并按 SDD 流程继续 |

## Host-Driven 模式核心概念

### 你拥有的原生工具

| 工具类型 | 用途 | 示例 |
|---------|------|------|
| **Subagent 工具** | 派发实现者/审查者子代理 | Claude Code: Agent tool; Cursor: subagent |
| **File I/O** | 读写 brief、report、review JSON | Read/Write 工具 |
| **Bash** | 执行 git 操作、运行测试 | `git diff`, `npm test` |
| **Ledger** | 记录进度、恢复状态 | 追加到 `.specpow/changes/<change>/sdd/progress.md` |

### 文件通信协议

子代理之间通过文件通信，每个文件有固定位置：

```
.specpow/
├── sdd/{change}/
│   ├── progress.md              # 进度账本（追加写入）
│   ├── task-{N}-brief.md        # 任务简报
│   ├── task-{N}-report.md       # 实现报告
│   └── task-{N}-report.md.fix-{R}  # 修复报告（第 R 轮）
├── openspec/
│   └── changes/{change}/
│       ├── specs/              # 规范文件
│       ├── design.md           # 设计文档
│       └── .openspec.yaml      # 变更配置
└── skills/                     # 技能目录（你正在这里）
```

### Report JSON 格式

实现者子代理完成后写入 report：
```json
{
  "status": "done|blocked|in_progress|done_with_concerns|needs_context",
  "commits": ["sha1", "sha2"],
  "testSummary": "X tests passed",
  "concerns": "any issues or null",
  "fixReport": "修复轮次时的修复说明（仅 fix 轮次填写）"
}
```

### Review JSON 格式

审查者子代理完成后写入 review：
```json
{
  "specCompliant": true,
  "qualityApproved": true,
  "findings": [
    {
      "id": "F1",
      "severity": "critical|important|minor",
      "description": "...",
      "file": "src/foo.ts",
      "line": 42,
      "isLoadBearing": false
    }
  ],
  "cannotVerify": []
}
```

## SDD 编排快速参考

完整的编排流程在 `execution-sdd-orchestrator` 技能中详细描述。核心循环：

```
对每个任务：
  1. 创建 Brief → task-{N}-brief.md
  2. 派发实现者 → 读 brief → 写代码 → 写 report JSON → task-{N}-report.md
  3. 检查 report（blocked? → 跳过; done? → 继续）
  4. 派发审查者 → 读 brief + diff + specs → 写 review JSON
  5. 运行测试
  6. 分析结果 → 审查通过 + 测试通过? → 标记 done → 下一任务
                → 需要修复? → 修复循环（最多 5 轮）：
                    每轮：修复 findings → 派发重审者（只审查修复部分）→ 运行测试 → 分析
```

## 模型选择指导

你可以根据任务复杂度选择子代理模型（如果宿主工具支持）：

| 场景 | 条件 | 推荐级别 |
|------|------|----------|
| 机械实现 | ≤2 文件 + 完整 spec | cheap（默认 haiku） |
| 集成实现 | 多文件协调 | standard（默认 sonnet） |
| 架构设计 | 需要设计判断 | capable（默认 opus） |
| 简单审查 | <100 行 diff | cheap（默认 haiku） |
| 最终审查 | 全变更审查 | capable（默认 opus） |
| 修复轮次 4-5 | 升级模型 | 比当前高一级 |

**注意**：这只是指导。根据你实际可用的模型做出最佳选择。

## 技能优先级

当多个技能适用时，流程技能先行 — 它们设定方法，然后实施技能执行。
- "让我们构建 X" → 先 explore/brainstorming，然后实施技能
- "修复这个 bug" → 先 systematic-debugging，然后领域技能
- "创建新变更" → 先 propose，然后 apply-change
- "执行任务" → 先 subagent-driven-dev，然后相关实施技能

## 可用技能清单

### 规划类（先于编码）
- `planning-explore` — 苏格拉底式需求探索（无承诺）
- `planning-propose` — 创建变更提案（proposal + specs + design + tasks）
- `planning-write-plans` — 将设计转化为极详细的实现计划
- `planning-write-specs` — 编写 delta 规范
- `planning-write-design` — 创建架构设计文档
- `planning-apply-change` — 执行变更（SDD 引擎驱动）
- `planning-onboard` — 项目入门引导
- `planning-archive-change` — 归档变更
- `planning-verify-change` — 规范合规性验证
- `planning-update-change` — 更新变更

### 执行类（编码阶段）
- `execution-subagent-driven-dev` — **子代理驱动开发**（核心执行引擎）
- `execution-tdd` — 测试驱动开发（RED-GREEN-REFACTOR）
- `execution-systematic-debugging` — 4 阶段根因分析
- `execution-parallel-agents` — 并行子代理调度
- `execution-git-worktrees` — Git worktree 管理
- `execution-finish-branch` — 分支完成与合并
- `execution-requesting-review` — 请求代码审查
- `execution-receiving-review` — 接收审查反馈
- `execution-verification-before-completion` — 完成前验证铁律

### 质量类（验证阶段）
- `planning-verify-change` — 规范合规性验证

### 业务类（领域能力）
- `business-java-codegen` — Java 后端代码生成
- `business-ui-codegen` — Vue2 前端代码生成
- `business-test-gen` — 测试生成
- `business-code-review` — 业务代码审查
- `business-db-design` — 数据库设计
- `business-prd-writer` — PRD 编写
- `business-deploy-check` — 发版检查
- `business-doc-sync` — 文档同步
- `business-menu-register` — 菜单注册

### 元技能类
- `meta-using-skills` — 如何使用技能
- `meta-writing-skills` — 如何编写新技能
- `meta-create-skill` — 引导式技能创建向导

## 红旗（立即停止）

这些想法意味着 STOP — 你在合理化跳过技能：

| 想法 | 现实 |
|------|------|
| "这只是个简单问题" | 问题也是任务。检查技能。 |
| "我需要先了解更多上下文" | 技能检查在澄清问题之前。 |
| "让我先探索代码库" | 技能告诉你如何探索。先检查。 |
| "这不需要正式的技能" | 如果技能存在，就使用它。 |
| "这个技能太重量级了" | 简单的事会变复杂。使用它。 |
| "我先做这一件事" | 做任何事之前先检查技能。 |
| "我记得这个技能" | 技能会演进。读当前版本。 |
| "这不算一个任务" | 行动 = 任务。检查技能。 |
| "我直接用 claude CLI 调用" | Host-Driven 模式用原生 subagent 工具，不用 CLI 子进程。 |
| "让我直接调用 SDDController" | 不要！你是编排者，用技能指令而非 TypeScript 代码。 |

## 平台适配

如果你的 AI 工具在此列表中，读取其参考文件获取特殊指令（**计划中** — 文件尚未创建，当前使用通用指令）：

- Claude Code: `references/claude-tools.md`（计划中）
- Cursor: `references/cursor-tools.md`（计划中）
- CodeBuddy: `references/codebuddy-tools.md`（计划中）
- GitHub Copilot: `references/copilot-tools.md`（计划中）
- Codex: `references/codex-tools.md`（计划中）

## 用户指令优先级

用户指令（CLAUDE.md, AGENTS.md 等直接请求）优先于技能，技能优先于默认行为。只有当你的搭档明确要求时，才跳过技能工作流。

## SpecPow 特有规则

1. **规划先于编码** — 任何超过 30 分钟的编码工作，必须先完成 propose 流程
2. **规范即契约** — specs 中定义的行为必须被实现遵守，SDD 审查会验证
3. **账本即真理** — 上下文压缩后，信任账本和 git log，而非自己的记忆
4. **文件即接口** — Agent 之间通过文件通信，不依赖对话上下文
5. **双模式共存** — 默认模式用 SDD Engine（TypeScript 编排）；`--host-driven` 模式用宿主 Agent 编排