OpenCode Superpowers：编码 + 写博客 skills 使用方案（自用版）
这篇不解释太多背景，目标是：我在写博客和写代码时，如何用 Superpowers
这套 skills 把工作流“固定下来”，减少跑偏与返工。
一、先记住一句话：先定方向，再列步骤，最后做验证
我把 skills 当成“工作流开关”，只要记住这 3 句就够用了：
- 不确定怎么做：
brainstorming（先把方向定清楚） - 知道要做什么但步骤多：
writing-plans（把步骤写成清单） - 说“做完了”之前：
verification-before-completion（把验证跑完再收工）
后面所有场景，基本都是这 3 个的排列组合。
二、最小前提：你得先能加载到这些 skills
我默认你已经按 Superpowers 的方式装好（仓库 + 插件 + skills symlink），并且
OpenCode 已重启。
在对话里直接加载某个 skill（注意：这里的名字通常不带 superpowers/ 前缀）：
use skill tool to load brainstorming如果你想确认当前可用 skills，可以让 OpenCode 输出“当前环境已暴露的技能列表”。
三、三种场景：按步骤直接照做
下面每个场景我都写成“第 1 步 / 第 2 步 / 第 3 步...”。
你只要把 use skill tool to load ... 复制到 OpenCode 里就行。
四、场景 1：写新项目（从 0 到能跑）
目标：把事情做成，而不是先把代码写漂亮。
第 1 步：先把需求说清楚（brainstorming）
这一部的目的：把“我想做什么”说成“我到底要交付什么”，避免一上来就写错方向。
use skill tool to load brainstorming我常用输入：
我要做一个新项目：<一句话描述>。
请你：
1) 只问我 1 个最关键澄清问题
2) 给 2-3 种方案对比（含取舍）
3) 给你推荐的方案（写清楚为什么）第 2 步：把落地步骤写成清单（writing-plans）
这一部的目的：把任务拆成你能按部就班执行的步骤，并且每一步都有验证方法。
use skill tool to load writing-plans我会要求它至少写清：
- 要建/要改哪些文件（精确路径）
- 每一步怎么验证（命令）
第 3 步：按计划执行（executing-plans）
这一部的目的：按清单逐步推进，避免“想到哪改到哪”，也方便中途停下来复盘。
use skill tool to load executing-plans第 4 步：跑验证，确认真能用（verification-before-completion）
这一部的目的：用实际命令证明项目能跑/能构建，而不是凭感觉说完成。
use skill tool to load verification-before-completion第 5 步：收尾（finishing-a-development-branch）
这一部的目的：决定怎么合并/怎么交付/怎么清理临时分支，让工作可结束、可回滚。
use skill tool to load finishing-a-development-branch五、场景 2：改已有项目（新增/修 bug/重构）
这个场景的关键是：先判断你现在是哪一类工作。
第 1 步：先选“起手 skill”（二选一）
这一部的目的：先选对“模式”。改功能和排障的思路完全不同，起手选错会浪费时间。
- 需求/改功能（容易跑偏）：用
brainstorming
use skill tool to load brainstorming- 报错/构建失败/线上行为不对：用
systematic-debugging
use skill tool to load systematic-debugging第 2 步：把修改拆成可执行清单（writing-plans）
这一部的目的：把改动限制在可控范围里，避免无意改到无关文件。
use skill tool to load writing-plans第 3 步：如果是“新增功能 / 修 bug”，优先用 TDD（test-driven-development，可选但推荐）
这一部的目的：先把预期行为写成测试（或可复现步骤），让修改有明确的对错标准。
use skill tool to load test-driven-development第 4 步：按计划执行（executing-plans）
这一部的目的：按步骤做小改动、频繁验证，减少一次性大改带来的风险。
use skill tool to load executing-plans第 5 步：完成前必须验证（verification-before-completion）
这一部的目的：在提交/合并前用证据确认“真的修好/真的没破坏”。
use skill tool to load verification-before-completion第 6 步：需要更稳就做一次评审（requesting-code-review，可选）
这一部的目的：让 AI 用审查视角检查逻辑、边界、改动范围，帮你补漏。
use skill tool to load requesting-code-review第 7 步：收尾（finishing-a-development-branch）
这一部的目的：把任务“结束干净”：合并策略明确、分支/工作区清理到位。
use skill tool to load finishing-a-development-branch六、场景 3：写博客到当前这个博客（VuePress）
目标：按我博客风格产出一篇能构建通过的文章。
第 1 步：先把文章的边界定清楚（brainstorming）
这一部的目的：确定文章要写给谁、要解决什么问题、最终交付什么文件。
use skill tool to load brainstorming我常用输入：
把这篇文章整理到我的 VuePress 博客（当前仓库）里。
要求：
1) 中文，偏实战
2) 要有 frontmatter + <!-- more -->
3) 命令块可复制，少废话
4) 产物：1 篇 Markdown + 如需要更新 sidebar
5) 验收：npm run docs:build 通过第 2 步：先写提纲 + 文件清单（writing-plans）
这一部的目的：先把结构定住（标题/小节/命令块），写作时不跑题。
use skill tool to load writing-plans第 3 步：按清单写文章/改 sidebar（executing-plans）
这一部的目的：按提纲逐段落地，并确保目录/导航能找到文章。
use skill tool to load executing-plans第 4 步：构建验证（verification-before-completion）
这一部的目的：用构建结果证明“文章不会把站点打挂”。
use skill tool to load verification-before-completion对本仓库最关键的验收命令就是：
npm run docs:build第 5 步：需要更稳就让它做一次“编辑校对”（requesting-code-review，可选）
这一部的目的：检查表达是否清晰、命令是否危险/错误、是否遗漏验收。
use skill tool to load requesting-code-review七、并行提效（可选）：任务隔离 + 多任务并发
如果你同时推进多个任务（例如：写两篇文章 + 修一个构建问题），建议用这两件事：
using-git-worktrees：把任务隔离到不同 worktree，避免 diff 越滚越大。dispatching-parallel-agents：把互不依赖的子任务拆开并行跑。
加载方式：
use skill tool to load using-git-worktrees
use skill tool to load dispatching-parallel-agents八、附录：我常复制的提示词块
6.1 整理外部文章到博客
请把这篇文章整理成我的博客风格（VuePress）。
要求：
1) 中文输出，分段用 ---，小节用“## 一/二/三”。
2) 必须包含 frontmatter（title/date/category/tag/icon）和 <!-- more -->。
3) 内容偏实战：命令、坑点、验证步骤优先。
4) 不要照搬原文结构，按“我会怎么用”重组。
5) 产物是 1 篇 Markdown（给出建议文件名）。6.2 改代码前先要执行计划
先不要改代码。
请输出一个可执行的实施计划：
- 要改的文件路径清单
- 每一步做什么
- 每一步如何验证（命令）
- 最后必须给出完整的验收命令集合6.3 构建失败/运行报错时的排障输入
我遇到一个错误，请按系统化排障流程来。
复现步骤：
1) ...
2) ...
期望行为：...
实际行为：...
错误输出（完整粘贴）：
...