SDD-RIPER: a lightweight control plane for coding agents

The control problem SDD-RIPER addresses

Strong coding agents no longer stop at suggestions: they read a repository, change many files, run tools and push a task forward. Once a model can act, the bottleneck moves from writing code to keeping the work aligned, observable, recoverable and provable. SDD-RIPER is a small, repo-native harness for that control problem. Its slogan, that code is cheap while context, control and evidence are not, sets the division of labor: the human owns goals, boundaries, permissions, checkpoints and acceptance, the agent owns exploration, implementation and tool use, and the project preserves specs, context indexes, validation evidence and recovery state. The audience is developers running capable agents who want a durable working surface without turning every task into heavyweight spec-driven process. The README is explicit that it is neither a magic prompt nor full-weight spec-driven development.

Four skills for execution, mapping and recovery

The harness is organized as four complementary skills rather than one monolith. The default entry, sdd-riper-one-light, and its heavier sibling sdd-riper-one control execution, checkpoints, validation and reverse sync, with the heavier one reserved for tasks that need stricter gates, denser artifacts or audit-ready traces. A codemap skill turns unfamiliar code into an agent-facing context index, so the agent works from a map rather than rediscovering the repository each time. A new-chat-ready skill preserves recovery context for new chats, handoffs and long pauses, which addresses the very real problem of losing state when a session ends. The split matters: you adopt the light skill for ordinary work and reach for the heavier one only when the stakes justify the extra ceremony, so the harness scales its overhead to the task instead of imposing a fixed process.

Starting a task with the light skill

Adoption is prompt-driven rather than an install. For ordinary coding or documentation work, the README gives a starting prompt that puts the human in control before any files change:

Use sdd-riper-one-light for this task.
Do not change files yet.

First give me:
- your understanding of the task
- the core goal for this loop
- a minimal spec / summary
- Done Contract: what counts as done, and what proves it
- next actions
- risks
- validation method

The agent responds with that plan and waits for your approval before executing. The Done Contract is the key element: it forces the agent to state up front what will count as done and what evidence proves it, which is the checkpoint the human approves against. Because the skills live in the repository, the harness is available to any agent you point at them rather than tied to one tool.

Checkpoints, validation and reverse sync

The mechanism that gives the harness its value is the loop of checkpoints, validation and reverse sync. The agent proposes understanding, a minimal spec and a Done Contract, the human approves boundaries and permissions, and execution proceeds against that agreed contract with validation evidence recorded rather than assumed. Reverse sync is the part that keeps the durable artifacts honest: as the work changes the code, the specs and context indexes are updated back so the preserved state reflects reality instead of drifting into fiction. The project frames this as giving strong agents a durable working surface without process theater, and the distinction it draws is between minimal specs that steer and heavy specs that merely generate paperwork. The heavier sdd-riper-one exists precisely for cases where training or audit-ready traces justify the denser artifacts.

The missing license and prompt-based limits

Two limits deserve attention. First, the repository ships no license file, so default copyright applies and you have no granted right to modify or redistribute the skills even though you can read them, which is worth resolving with the author before you fold them into your own workflow. Second, this is a discipline expressed as skills and prompts, not a program that enforces itself, so its effectiveness depends on the agent honoring the protocol and on the human actually using the checkpoints rather than waving them through. A capable agent is assumed; a weak one will not follow the loop well. The harness reduces drift and improves recoverability, but it does not guarantee correctness, and the Done Contract is only as good as the evidence the human insists on before approving completion.

SDD-RIPER versus heavyweight spec-driven development

The two alternatives sit on either side of it. Full spec-driven development front-loads detailed specifications and gates, which gives strong traceability but can turn small tasks into process theater, the exact failure the README names. At the other extreme is unstructured prompting, where the agent acts with no checkpoints, no preserved specs and no recovery state, which is fast until the work drifts or a session is lost. SDD-RIPER positions itself between them: minimal specs and a Done Contract for steering, checkpoints for control, and reverse sync for durable state, without the density of heavyweight SDD. If your task is trivial, plain prompting is fine; if it is regulated or training-bound, full SDD or the heavier sdd-riper-one may be warranted; for ordinary agentic coding that still needs control and evidence, the light skill is what this project is built for.

No license, and current status

The facts to weigh are straightforward. SDD-RIPER is a repo-native set of skills for Claude, Cursor and similar agents, adopted by prompt rather than installed, and it ships no license, which is the first thing to settle before reuse. The last push was on 2026-08-28, and the repository is bilingual with English and Chinese documentation, a docs map and examples, plus a PROJECT_KNOWLEDGE file, which fits a harness that treats preserved knowledge as a first-class artifact. Start with sdd-riper-one-light on a real but bounded task, hold the agent to its Done Contract before approving completion, and move to sdd-riper-one only when a task genuinely needs stricter gates or audit-ready traces.

Editorial conclusion

Adopt SDD-RIPER if you drive a capable coding agent and want lightweight control, minimal specs, checkpoints, a Done Contract and reverse sync, without the overhead of full spec-driven development. Do not expect it to enforce itself: it is a prompt-driven discipline that depends on a capable agent and a human who actually uses the checkpoints, and its missing license should be resolved before reuse. Start with the sdd-riper-one-light prompt, hold the agent to its Done Contract, and escalate to sdd-riper-one only when a task needs stricter gates.

Frequently asked questions

Official sources

1. huisezhiyin/sdd-riper on GitHub
2. Issues
3. README