sdd-riper-one-light

Category: Development & Coding | Uploader: huisezhiyin | Downloads: 0 | Version: v1.0（Latest）

面向 GPT-5.4 等强模型的轻量 spec-driven / checkpoint-driven coding skill。用于高输入、高频、多轮的代码与 agentic coding 任务，默认短输出、中文沟通、模型自行分解任务；常驻只保留最小 spec、先复述理解、执行前 checkpoint、批准后执行、执行后回写五类关键约束。

Changelog: Source: GitHub https://github.com/huisezhiyin/sdd-riper

Directory Structure

Current level: tree/main/skills/sdd-riper-one-light/

📁 agents/
- 📄 openai.yaml 981 B
📁 examples/
- 📁 codemap/
  - 📄 codemap-feature-content-control.md 3.3 KB
- 📁 specs/
  - 📄 spec-light-runtime-compat.md 2.9 KB
  - 📄 spec-standard-security-status-race.md 4.0 KB
- 📄 README.md 1016 B
📁 references/
- 📄 conventions.md 1.1 KB
- 📄 modules.md 2.4 KB
- 📄 spec-lite-template.md 2.5 KB
📄 README.md 4.9 KB
📄 SKILL.md 5.9 KB

SKILL.md

---
name: sdd-riper-one-light
description: 面向 GPT-5.4 等强模型的轻量 spec-driven / checkpoint-driven coding skill。用于高输入、高频、多轮的代码与 agentic coding 任务，默认短输出、中文沟通、模型自行分解任务；常驻只保留最小 spec、先复述理解、执行前 checkpoint、批准后执行、执行后回写五类关键约束。
---

# SDD-RIPER-ONE Light

## 核心定位

- 这是 `checkpoint-driven` 版本，不是 `phase-heavy` 版本。
- 默认假设强模型已经能自行分解任务、补足局部计划、按需追溯上下文。
- 主协议只保留少数高杠杆锚点，其余规范按需查看 reference。
- 目标不是减少控制力，而是减少低价值常驻 token。
- **Spec 受众分层与上下文保护**：Spec 的第一受众是人类（持久化的任务上下文与组织记忆），第二受众才是模型。协议对模型的核心价值是四件事：**注意力聚焦**（让模型只关注当前该关注的）、**信息索引**（需要时按路径回读，而非全量常驻）、**防止上下文腐烂**（用落盘的 Spec 对抗长对话中的遗忘与漂移）、**辅助 Review**（提供 Spec vs 代码的交叉验证基准）。协议绝不应导致上下文被塞满挤爆——RIPER 管流程，Spec 管记录，模型按需取用。

## 硬约束

- `Spec is Truth`：spec 是持久化上下文、压缩记忆与协作真相源。
- `No Spec, No Code`：未形成或更新最小 spec 前，不进入代码实现。
- `No Approval, No Execute`：未得到明确执行许可，不进入实现或高影响变更。
- `Restate First`：用户输入任务后，先用模型自己的话复述理解，再进入 spec 或计划。
- `Core Goal as Loop Anchor`：阶段性核心目标是当前 loop 的唯一锚点；进入执行前、发生偏差后、完成验证时，都必须重新对齐该锚点。
- `Checkpoint Before Execute`：实现前必须给一次短 checkpoint，确认理解、目标、下一步、风险与验证方式。
- `Done by Evidence`：完成应由验证结果与外部反馈证明，而不是由模型自行宣布。
- `Reverse Sync`：执行后必须把结果、偏差、验证结论回写 spec。
- `Resume Ready`：长任务或暂停前，应在 spec 中留下最小恢复锚点，支持重启与交接。

## 默认假设

- 强模型默认自行分解任务，不强制展开冗长 `Research / Innovate / Plan / Execute / Review` 文本。
- 小任务不为了协议而拆；大任务也不为了仪式感写长计划。
- 真正必须保留的，是最小 spec、先复述理解、执行前 checkpoint、明确批准、执行后回写。
- 默认只回读当前相关 spec 区块，不整份重载。

## 任务深度

### `zero`（零 Spec 通道）

- 适用于纯机械性改动（typo 修复、日志添加、配置值变更等无决策性的单点修改）
- 跳过 micro-spec，直接执行并在完成后用一句话 summary 回写
- 一旦发现复杂度超出预期，立即升级到 `fast` 或 `standard`

### `fast`

- 先写 `micro-spec`，不裸改。
- 用 1-3 句写清目标、涉及文件、主要风险、验证方式。
- 用户明确批准后再执行。
- 复杂度上升时升级到 `standard` 或 `deep`。

### `standard`

- 默认模式，适用于大多数 2+ 文件改动、一般功能开发、普通缺陷修复。
- 补齐必要上下文，维护一份轻量 spec 并落盘。
- 执行前给一次短 checkpoint，获批后实施并回写结论。

### `deep`

- 适用于需求模糊、架构改动、未知根因、跨模块/跨项目、长链路迭代。
- 允许显式分析、方案比较、风险说明，但仍保持短。
- 先把深思考结果写回 spec，再给用户审阅；获批后再进入实现。
- 按需加载 `references/modules.md`，而不是把深流程常驻。

## 最小工作流

- 用户给出任务后，先复述模型自己的理解，确保核心目标强一致。
- 用最小 spec 固化目标、边界、事实、计划与结论，并尽快落盘。
- 在 spec 中用 1-3 行写清 `Done Contract`：什么算完成、由什么证明、哪些情况算仍未完成。
- 实现前给一次短 checkpoint：`当前理解`、`核心目标`、`下一步 1-3 个动作`、`风险`、`验证方式`。
- 若测试、日志、人工反馈暴露出偏差，先基于外部证据重述“当前核心目标是否变化、还差什么”，再决定继续执行还是调整方案。
- 用户明确批准后执行；若范围或方案变化，先更新 spec 再重新请求批准。
- 执行后回写 `Change Log / Validation / Resume or Handoff`，并说明“当前核心目标是否已由证据证明完成；若未完成，下一轮核心目标是什么”。

## 何时暂停

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

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

## 按需模块

- `references/spec-lite-template.md`：最小 spec 模板。
- `references/modules.md`：`Deep Planning` / `Debug` / `Review` / `Multi-project`。
- `references/conventions.md`：落盘目录、命名规则、`micro-spec` 与正式 spec 的分流规则。

## 输出风格

- 默认中文。
- 默认短输出，不复述完整协议。
- 优先给“当前理解 + 核心目标 + spec 摘要 + 下一步 + 必要风险”。
- 不强制打印阶段状态机。
- 核心目标采用“事件触发式复述”：阶段开始、执行前 checkpoint、偏差暴露后、阶段收尾时必须重对齐；其他轮次不机械复读。
- 需要长链路推进时，优先给最小 `Done Contract` 与 `Resume/Handoff`，而不是扩写长计划。
- 小任务用 `micro-spec + micro-summary`；复杂任务再按需展开。

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

sdd-riper-one-light

Directory Structure

SKILL.md

Report

Notice