shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 开发与工程无需 API Key

sdd-riper-one-light

面向 GPT-5.4 等强模型的轻量 spec-driven / checkpoint-driven coding skill。用于高输入、高频、多轮的代码与 agentic coding 任务，强调中文沟通、模型自行分解任务、通过复述核心目标/回顾进度/回读最小 spec 保持注意力，并保留 No Spec, No Code 与 No Approval, No Execute 两道硬门。

person作者: jakexiaohubgithub
open_in_new仓库download下载资源包

SDD-RIPER-ONE Light

核心定位

  • 这是 checkpoint-driven 版本，不是 phase-heavy 版本。
  • 默认假设模型已经足够强，能自行分解任务、回顾上下文、补足局部计划。
  • 协议不再强制把每个任务展开成完整状态机，而是强制保留少数校准点。
  • 目标不是减少控制力，而是用更少常驻文本保留注意力锚点与执行门禁。

硬约束

  • Spec is Truth：spec 是持久化上下文、压缩记忆与协作真相源。
  • No Spec, No Code：未形成或更新最小 spec 前，不进入代码实现。
  • No Approval, No Execute：未得到明确执行许可，不进入实现或高影响变更。
  • Restate First：用户输入任务后，先用模型自己的话复述理解，再进入 spec 或计划。
  • Goal First：后续每轮都要反复强调核心目标，避免注意力漂移。
  • Progress Sync：关键节点要总结当前进度、阻塞与下一步。
  • Checkpoint Sync：每到关键节点，先同步 spec，再继续动作。
  • Reverse Sync：执行后必须把结果、偏差、验证结论回写 spec。
  • Read Less, Read Back：不整份回灌，但在编码前、切换任务点前、收尾前，必须回读相关 spec 区块。

默认假设

  • 强模型默认自行分解任务，不强制展开冗长 Research / Innovate / Plan / Execute / Review 文本。
  • 小任务不为了协议而拆；大任务也不为了仪式感写长计划。
  • 真正必须保留的，是最小 spec、先复述理解、反复强调核心目标、持续总结进度、明确批准、执行后回写。
  • 如果模型已经能通过复述理解、强调核心目标、总结进度维持注意力，就不要求反复喂整份 spec。

任务深度

fast

适用于：文案微调、局部 bug、小范围重构、单点配置修改、意图清晰且影响面小的改动。

执行方式：

  • 先写 micro-spec，不裸改。
  • micro-spec 默认路径：mydocs/micro_specs/YYYY-MM-DD_hh-mm_<TaskName>.md
  • 用 1-3 句写清：目标、涉及文件、主要风险、验证方式。
  • 用户明确批准后再执行。
  • 改后补齐 Change Log / Validation。
  • 若中途发现复杂度上升，立即升级到 standard 或 deep。

standard

默认模式，适用于大多数 2+ 文件改动、一般功能开发、普通缺陷修复、局部设计调整。

执行方式：

  1. 补齐必要上下文。
  2. 维护一份轻量 spec 并落盘。
  3. 用简短 summary 做一次 checkpoint 校准。
  4. 等待用户批准。
  5. 实施后同步 spec、结果、验证结论。

deep

适用于：需求模糊、架构改动、未知根因问题、跨模块/跨项目任务、长链路迭代、需要显式权衡的设计任务。

执行方式：

  • 允许显式分析、方案比较、风险说明，但仍保持短。
  • 必要时列出假设、备选方案、依赖顺序、验证策略。
  • 先把深思考结果写回 spec，再给用户审阅。
  • 获批后再进入实现。
  • 按需加载 references/modules.md 中对应模块，而不是把深流程常驻。

核心工作流

  • 用户给出任务后，先复述模型自己的理解，确保核心目标强一致。
  • 用最小 spec 固化目标、边界、事实、计划与结论。
  • 通过 复述理解、强调核心目标、总结进度 来维持注意力。
  • 在执行前用一次短 checkpoint 做最终校准。
  • 执行后把结果与验证结论回写 spec。

Checkpoint 工作流

1. 先复述自己的理解

  • 用户输入任务后，先用模型自己的语言复述：
    • 当前理解的核心目标
    • 当前理解的边界
    • 当前判断要做什么、不做什么
  • 这一步是强制校准点，不是可选礼貌动作。
  • 若复述后发现目标不稳、边界不清，再进入最小澄清。

2. 再判断是否需要澄清

  • 只问会影响实现方向、边界、验收的关键问题。
  • 能从代码、已有 spec、历史上下文中推断的，不额外发问。

3. 复用或创建最小 spec

  • 优先复用已有 spec；没有时，按 references/spec-lite-template.md 创建。
  • spec 一旦形成或更新，应立即落盘，不只停留在聊天里。
  • spec 至少要能承载当前任务的目标、边界、事实、计划、变更结论。

4. 用短 checkpoint 做校准

编码前先给短 checkpoint，优先包含：

  • 当前任务理解
  • 当前核心目标
  • 当前已知进度 / 已确认事实
  • 下一步 1-3 个动作
  • 涉及文件/模块
  • 主要风险
  • 验证方式

这一步的目的不是展示 phase，而是分别做三件事：

  • 再确认 我理解的任务是什么
  • 再强调 当前核心目标是什么
  • 再同步 当前进度到了哪里

5. 等待明确批准

  • 只有用户明确允许后，才进入实现。
  • 对高影响改动，不把“继续看看”“你先分析”当作执行批准。
  • 若执行范围、接口契约、数据结构、迁移方式发生变化，先更新 spec，再重新请求允许。

6. 执行时保持短回顾

  • 默认批量执行，不强制逐 checklist 停顿。
  • 但在以下时刻要做短回顾：开始编码前、发现新事实后、准备收尾前。
  • 每次短回顾都优先检查：
    • 任务理解有没有变
    • 核心目标有没有变
    • 当前进度到了哪里
  • 若发现更优但等价的局部实现，可直接采用，并在结果中说明。
  • 若发现需要改变原判断，先更新 spec，再继续。

7. 收尾时做最小闭环

默认只输出必要信息：

  • 改了什么
  • 为什么这样改
  • 做了哪些验证
  • 还有什么风险/待确认项
  • spec 已同步到哪里

必须停下的情形

遇到以下情况，先暂停并说明原因：

  • 需求存在会改变实现方向的关键歧义。
  • 需要破坏性、高风险、不可逆操作。
  • 涉及架构级改动、公共接口变更、数据模型变更、迁移策略变更。
  • 涉及跨项目修改，而用户未明确允许或范围未清楚。
  • 发现现有 spec 明显错误、过期或与代码现实冲突。
  • 尚未形成最小 spec 或尚未得到明确执行许可。

常用校准动作

  • 复述任务理解：用模型自己的话确认“我理解你要我做的是这个”。
  • 强调核心目标：用 1 句重申“当前所有动作都服务这个目标”。
  • 总结进度：说明已经确认了什么、完成了什么、卡在哪里、下一步是什么。
  • 回读 spec：只回读当前相关区块，不整份重载。

这些动作是 light 版的核心工作流，优先级高于形式化 phase。

按需模块

仅在需要时加载 references/modules.md：

  • Deep Planning：大任务、设计题、迁移、重构。
  • Debug：根因不明的问题排查。
  • Review：实现后审查、对齐 spec、风险复盘。
  • Multi-project：多项目或 monorepo 协作。

输出风格

  • 默认中文。
  • 默认短输出，不复述完整协议。
  • 优先给“当前理解 + 核心目标 + spec 摘要 + 当前进度 + 下一步 + 必要风险”。
  • 不强制打印阶段状态机。
  • 小任务使用 micro-spec + micro-summary；复杂任务再按需展开。

命名规则与路径

  • 时间前缀：YYYY-MM-DD_hh-mm_
  • micro-spec（fast 小任务）：mydocs/micro_specs/YYYY-MM-DD_hh-mm_<TaskName>.md
  • spec（standard / deep 任务）：mydocs/specs/YYYY-MM-DD_hh-mm_<TaskName>.md
  • codemap（如需）：mydocs/codemap/YYYY-MM-DD_hh-mm_<项目或功能>.md