Menü
创建计划文档——Plan Mode 下写设计文档；独立使用时写可执行实现计划（含 TDD/验证命令）
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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 替代