Menu
创建计划文档——Plan Mode 下写设计文档；独立使用时写可执行实现计划（含 TDD/验证命令）
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Frontend UI prototype workflow — clarify intent, explore directions, preview across viewports, diff against references, deliver with screenshot evidence
Excel 电子表格读写与编辑最佳实践 — 用 xlsx_read/xlsx_write/xlsx_edit 处理 .xlsx 时遵守的公式、数字格式与可维护性纪律
生成与读取 PDF 文档（报告、合同、交付文档）——原生 pdfkit 渲染，自动解析系统 CJK 字体支持中文，支持 heading/paragraph/table/code/list 内容块与页码页脚
PowerPoint 演示文稿生成纪律 — 用 pptx_create/pptx_read 产出有设计感、零 AI 味的 .pptx（PPT、幻灯片、deck、演讲稿、汇报）
在任意项目中执行开发任务时的测试方法论——包括测试能力探测、RED→GREEN 纪律、探针管理、环境模拟、测试策略选择。当面对 bugfix、功能开发、重构等需要验证的代码改动时使用。
认知对齐前置闸门：复杂任务前强制完成意图保存、问题层级标注、证据时间线标注和关键词扩展搜索。 防止 AI 过早把用户的复杂意图压缩成局部工程任务。 触发词：「认知对齐」「cognitive alignment」「先对齐」「别急着写代码」「我们在解决什么问题」。 也可由 deep-brainstorm / brainstorming 在复杂任务前自动前置调用。
| name | writing-plans |
| description | 创建计划文档——Plan Mode 下写设计文档；独立使用时写可执行实现计划（含 TDD/验证命令） |
为功能需求先深入调研现有代码，理解每个拟修改函数的"为什么存在"，再设计方案并落盘。
开始时宣布： "我正在使用 writing-plans 技能创建实现计划。"
与 superpowers writing-plans 的差异：
using-git-worktrees / finishing-a-development-branch——改为 B1 归属门禁保存路径与收尾方式（按当前模式二选一）：
<plan-mode> 块）：产出设计文档（不是逐步 bash/commit 菜谱）。写入活动计划文件（<plan-mode> 块中给出的路径，通常是 .rivet/plans/draft-*.md——这是唯一可写的文件），成熟后用 plan action=submit 提交等待用户批准。不要写 docs/superpowers/plans/（会被写入门禁拦截），也不要以 executing-plans 交接收尾。对话里只给短摘要，正文只进文件。用下方 §3.1a 设计文档模板。<plan-mode> 块）：产出可执行实现计划，保存到 docs/superpowers/plans/YYYY-MM-DD-<slug>.md，完成后交接给 executing-plans 执行。用下方 §3.1b 可执行模板。原则：问题不在审查阶段，在调研深度。 如果读得够深，计划自然不会错。
git log --oneline -10 -- <file>）理解修改历史对计划中每个要删除或修改行为的函数，必须回答：
grep 调用者，列出文件:行号）当你产生"需要新建 X 模块/函数"的判断时，先做水平扫描——不沿着任务边界（要改的文件列表）往下读，而是沿着代码库的邻域关系搜索：
grep 目标功能的关键词（如 compress/collapse/fold/signature/extract）在整个 src/ 中搜索对每个拟修改/删除/导出的函数，不只沿主调用路径找消费方——grep 函数名，逐一列出 所有 调用位置的行号和上下文：
当你判断"这个函数破坏了 X 纪律"时，先拆开：
不要把调用链下游行为归因到纯函数。同一个纯函数在不同调用方可能产生完全不同的系统行为。
完成调研后，自检：
如果对某个函数的修改理由只有"不需要了"而没有"因为 X 已经由 Y 处理"，继续往下读：
read_file 直接读函数本体和所有调用方（grep 列出引用位置）git log --oneline -10 -- <file>）当任务涉及 3+ 个独立模块、跨层影响面不明、或需要多视角审视时，不要串行逐文件读——派只读星域子代理并行探查：
何时派：
如何派：
delegate_task（单方向）或 delegate_batch（多方向并行），只读 profile：code_scout 或 doc_scoutauthority 让子代理带入该域方法论：yaoguang（复现验证）、tianquan（架构称量）、tianji（前提质疑）、tianfu（变更守护）等read_file / grep 对关键结论做独立确认不要：
task / Agent 等非 Rivet 的子代理工具——这些是 Cursor/Claude Code 的约定，在 Rivet 中会被自动映射到 delegate_task。Rivet 的搜索/调研工具是 web_search 和 web_fetch，子代理工具是 delegate_task / delegate_batch列出每个要创建或修改的文件，说明其职责：
| 文件 | 操作 | 职责 |
|------|------|------|
| `src/tools/new-tool.ts` | 创建 | 新工具实现 |
| `src/main.tsx` | 修改 | 注册新工具 |
| `src/tools/__tests__/new-tool.test.ts` | 创建 | 新工具测试 |
对每个"删除"或"修改行为"的操作，附上调研结果：
**调研背书**：
- `functionA`: 调用者 3 处（file1:L10, file2:L20, file3:L30），存在原因：处理 DeepSeek 重复输出。修改后需要替代方案。
- `functionB`: 无外部调用者，仅内部使用。可安全删除。
没有调研背书的"删除"操作，在执行阶段会被标记为"未验证假设"。
保存位置见开头「保存路径与收尾方式」。
对话禁止贴完整计划或逐步 shell/
git commit/npx菜谱。正文只进活动计划文件。
# [功能名称] 设计
**目标：** [一句话]
**问题与根因：** [表面症状 vs 根因]
**架构：** [2-3 句 + 下方 Mermaid]
```mermaid
flowchart TD
U(用户/入口) --> R[[处理]]
R --> S[(状态)]
```
## 方案取舍（有决策时）
| 方案 | 优点 | 缺点 | 选择 |
|------|------|------|------|
| A | … | … | ✓/— |
## 改动面
| 文件 | 操作 | 提议（diff/伪代码摘要） |
|------|------|-------------------------|
| `path:line` | 修改 | … |
## 验证清单
- [ ] 场景/测试名：期望可见结果
- [ ] 人工检查点：……
（不要写逐步 bash/commit 块）
## 瑶光反证（计划期复现）
| 断言 | 证据类型 | 证据 |
|------|---------|------|
| … | 定稿后回读 | `file.ts:123` |
**待验证假设：** …
## 回归清单（重构类必填）
- [ ] 锚点 + 验证方式
# [功能名称] 实现计划
> **面向 AI 代理：** 使用 `executing-plans` 逐任务实现。
> 步骤使用复选框（`- [ ]`）语法来跟踪进度。
**目标：** [一句话描述要构建什么]
**架构：** [2-3 句话描述方案，关键设计决策及其理由]
**技术栈：** [关键技术/库]
---
## 瑶光反证（计划期复现）
> 绿非证明，复现即证。设计阶段发明的断言（"机制 X 会在时机 Y 生效"）最容易错——在这里逐条复现，不留到执行期。
**关键断言清单**：方案依赖的每条代码行为断言，附计划期证据：
| 断言 | 证据类型 | 证据 |
|------|---------|------|
| [例：块 B 在 seq=1 baseline 时不渲染] | 设计定稿后回读 | `engine.ts:1059`（[定稿后重新 read 确认]） |
| [例：修复前测试 T 失败] | run_tests RED 输出 | [命令 + 关键输出行] |
**原缺陷复现**（bugfix 类必填）：复现命令 + 观察到的 RED 输出。
**待验证假设**：计划期无法复现的推论，逐条标注 + 执行期第一步如何验证。
---
## 任务
### 任务 1：[任务名称]
- [ ] 创建 `exact/path/to/new-file.ts`
- [ ] 修改 `exact/path/to/existing-file.ts:line-range`
- [ ] 测试 `exact/path/to/test.test.ts`
**目标：** [这个任务完成什么]
**调研背书：**（如涉及删除/修改行为）
- `functionX`: [调用者、存在原因、风险]
**实现：**
```typescript
// 具体代码或精确的编辑描述
```
**验证：**
```bash
npx tsc --noEmit # typecheck
npm exec -- tsx --test src/path/to/test.test.ts # 期望全部通过
```
**提交：**
```bash
git add <files>
git commit -m "feat(scope): 描述（任务 N/M）"
```
### 任务 2：[任务名称]
...
Plan Mode（3.1a）：
独立使用（3.1b）：
以下模式不得出现在最终计划中：
在完成计划后，执行以下自检并报告结果：
run_tests 拿 RED 证据，跑不了的派 delegate_task profile=adversarial_verifier authority=yaoguang。证据填入「瑶光反证」章节；复现不了的降级为"待验证假设"，禁止写成结论Plan Mode 下：用 plan action=submit 提交（可省略 plan 字段，从活动计划文件读取；多方案时传 options），然后等待用户 /plan-approve 或 /plan-reject——未批准前不推进。
独立使用时，计划完成后输出：
计划已完成并保存到 `docs/superpowers/plans/YYYY-MM-DD-<slug>.md`。
执行方式：使用 `executing-plans` 在当前会话中逐任务执行。
计划执行技能：
交付验证：
finishing-a-development-branch——天枢用 deliver_task 替代