rdd-defect-workflow

Guides receipt-driven defect workflows with issue gates, evidence receipts, and delivery validation.

Updated Aug 25, 2026
One-click install
npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill rdd-defect-workflow-carloswilliamsr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rdd-defect-workflow
Source: https://github.com/CarlosWilliamsR/SketchOS/tree/main/.config/opencode/skills/rdd-defect-workflow
Command: npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill rdd-defect-workflow-carloswilliamsr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Defect fixes often ship without verified reproduction, scoped authority, or runtime evidence, causing superseded PRs, unbounded changes, and unproven claims. This Skill enforces a receipt-driven development (RDD) workflow that gates every defect fix on approval, reproduction, bounded change budgets, and candidate-bound proof. ## Core Features & Use Cases - Authority and kill-switch gating: Checks the user-owned RDD mode, requires an approved issue and clean main reproduction, and audits existing PRs for supersession or conflict before any work begins. - Bounded, evidence-backed fixes: Groups work by causal invariant, enforces a 400-line change budget with chain or exception handling, and requires black-box bench journeys or real runtime E2E proof per operator flow. - Independent validation and structured output: Requires read-only candidate validation before publication and returns a structured verdict covering receipts, lineage, rollback, tests, and unresolved maintainer decisions. - Use Case: A maintainer asks you to fix a CLI defect. The Skill verifies the issue is approved, reproduces the bug on main, isolates a worktree, adds failing tests, keeps the diff under budget, records per-flow runtime evidence, and delivers a validated verdict. ## Quick Start Ask the assistant to guide a defect fix using the RDD workflow for an approved issue, starting with the kill-switch and reproduction checks.

Frequently Asked Questions about rdd-defect-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a receipt-driven defect fix workflow?

Start by checking the RDD kill switch and confirming an approved issue with clean reproduction on main. Then isolate a worktree, map impact, add failing tests, keep changes under the 400-line budget, record per-flow runtime evidence, and obtain independent read-only validation before publishing.

What happens when the RDD kill switch is disabled?

When RDD is disabled, the workflow does not start receipt reviews or fabricate approvals. It follows ordinary repository policy and reports the status as disabled or unmanaged, with no receipt or approval claims.

What is the change size limit for an RDD defect fix?

The hard limit is 400 additions plus deletions, forecast before any edits. If the forecast exceeds this budget, work must stop and proceed as a chain of smaller changes or obtain an explicit maintainer-approved exception.

Does synthetic test coverage count as runtime evidence?

No. Each CLI or lifecycle flow requires one truthful black-box bench journey, or actual runtime E2E proof when the core bench cannot represent it. Synthetic proxy coverage never proves another runtime.

When should a defect fix be split into multiple PRs?

Split when causes are independent: each causal authority invariant and rollback boundary gets one issue and one PR or an explicit chain. Superseded or conflicting authority lines must never be merged together.