RDD — Requirements-Driven Development for Openclaw

RDD guides an AI coding agent from ambiguous requirements to human-approved specifications, acceptance tests, implementation, and verification.

anyjohn
v0.1.0
Aug 27, 2026
0
282
0

Install & Download

1. ClawHub CLI

The fastest way to install a skill directly from the registry.

npx clawhub@latest install rdd

2. Manual Installation

Copy the skill folder to one of these locations

Global
~/.openclaw/skills/
Workspace
<project>/skills/

Priority: Workspace > Local > Bundled

3. Prompt Installation

Copy this prompt to OpenClaw to install it automatically.

Help me install rdd using Clawhub. If Clawhub is not installed, install it first (npm i -g clawhub).

Prefer to download?

Get the raw skill files in a ZIP archive.

What is RDD — Requirements-Driven Development?

Requirements-Driven Development (RDD) is an Openclaw Skills workflow for converging natural-language requests into clear, testable, and traceable software changes before implementation begins. It separates intent, behavior, evidence, and code through a structured lifecycle: Raw Requirement, Feature, Story, Specification, Acceptance Criteria, implementation, and verification.

The skill keeps humans responsible for product decisions while the agent handles analysis, refinement, question generation, specification drafting, coding, and validation. It supports full .rdd/ work-item chains, a Lite path for smaller changes, and a zero-file Solo-dev path where the commit message serves as the specification.

RDD — Requirements-Driven Development Use Cases

  • Convert vague feature requests into structured Features and user Stories.
  • Clarify scope, architecture, constraints, assumptions, and unresolved requirements before coding.
  • Define Behavior, Constraints, Invariants, and Given/When/Then Acceptance Criteria.
  • Add features safely to existing systems through impact analysis and Spec Reconstruction.
  • Distinguish incremental changes, full replacements, and lightweight bug fixes.
  • Preserve traceability from requirements to specifications, acceptance criteria, commits, and code.
  • Coordinate human-in-the-loop decisions without interrupting the agent for every minor gap.
  • Validate LLM-dependent behavior with real LLM runs instead of relying only on mocked unit tests.
  • Use a lightweight commit-based workflow for solo developers and small changes.

How RDD — Requirements-Driven Development Works

  1. Receive the raw requirement: Create an RR Work Item from the user's natural-language request, record its source and goal, identify scope, and set its status to analyzing.
  2. Classify the change: Select the appropriate path: incremental improvement, full replacement, lightweight change, or Solo-dev zero-file mode.
  3. Perform Requirement Engineering: Decompose the Raw Requirement into Features and INVEST-aligned Stories, identify boundaries, and collect Open Questions.
  4. Pause for human decisions: Group questions into blocking and non-blocking items, provide recommended options, and wait for human decisions where business meaning or scope is affected.
  5. Perform Specification Engineering: Convert the approved Story into a structured Spec containing behaviors, constraints, invariants, acceptance criteria, assumptions, decisions, and uncertainty statuses.
  6. Run the Spec Discovery Loop: Analyze the candidate Spec, detect missing information, ask batched questions, incorporate human decisions, and refine until all blocking issues are resolved and the criteria are testable.
  7. Approve the specification: Move the Spec through draft, candidate, and approved states only when open questions and assumptions are appropriately resolved or labeled.
  8. Design tests from the contract: Treat Acceptance Criteria as the test contract. Do not create separate TEST-*.md descriptions; write test code alongside product code during implementation.
  9. Implement without changing business meaning: Build the code and corresponding tests from the approved Spec. If the Spec is insufficient, return SPECIFICATION_BLOCKED instead of inventing requirements.
  10. Verify behavior: Run automated tests, real application checks, browser or experiential validation where relevant, and manual checklists. Passing work becomes completed; failures return to specification refinement.
  11. Record traceability and cleanup: Use commit messages, .rdd/links.yml when needed, and Work Item parent relationships to connect requirements to code. Archive or remove temporary artifacts according to their retention policy.

RDD — Requirements-Driven Development Setup

RDD is a workflow skill rather than a standalone runtime package. Enable or install it through the host Openclaw Skills mechanism, then invoke it with phrases such as RDD, requirement driven, or the equivalent requirements-convergence trigger supported by your agent environment.

For a full repository-based workflow, initialize the expected workspace structure:

mkdir -p .rdd/items
printf '%s\n' '.rdd/state.yml' >> .gitignore

Use the templates supplied in references/templates.md for Raw Requirements, Specifications, and traceability artifacts. For Solo-dev work, no .rdd files are required: place the Feature ID in the commit subject and behaviors, Acceptance Criteria, and decisions in the commit body.

To inspect commit-based traceability, use:

git log --grep "FE-00"

If enforcement is required, configure the repository's pre-commit checker to prevent invalid state transitions such as draft directly to implementing. The default RDD mode is advisory, so status values guide the workflow without automatically blocking commits.

RDD — Requirements-Driven Development Data Schema & Taxonomy

RDD organizes information as typed Work Items, structured Specifications, Decisions, and optional traceability manifests.

Artifact Identifier Purpose Typical location
Raw Requirement RR-### Captures the original user request .rdd/items/RR-###.md
Feature FE-### Defines a deliverable product capability .rdd/items/FE-###.md
Story US-### Describes a user-centered requirement .rdd/items/US-###.md
Task TK-### Tracks a concrete development task .rdd/items/TK-###.md
Bug BG-### Records a defect .rdd/items/BG-###.md
Specification SPEC-### Stores behaviors, constraints, invariants, AC, questions, decisions, and assumptions .rdd/items/SPEC-###.md
Decision DEC-### Persists important human-approved business or architectural choices .rdd/items/DEC-###.md
Traceability manifest — Maps file and line ranges to Acceptance Criteria IDs .rdd/links.yml
Session state — Stores temporary workflow state and is not committed .rdd/state.yml

Work Item files use YAML frontmatter plus a Markdown body. Each item includes an ID, type, parent relationship, status, owner, and creation metadata. Standard parent chains connect RR → FE → US → SPEC → AC → CODE.

A Spec uses statuses such as draft, candidate, approved, and invalidated. Information must be labeled as confirmed, inferred, or unresolved; the agent must not present an inference as a human-confirmed requirement. Decisions may be marked frozen, while Work Items can use permanent, migration-only, or session-only retention policies.

For Solo-dev projects, Git is the primary artifact repository. Feature IDs belong in commit subjects, while behaviors, Acceptance Criteria, and decisions belong in commit bodies. Use .rdd/items/ only for frozen cross-feature decisions and unresolved questions when needed.

RDD — Requirements-Driven Development Advanced Features

  • Human-in-the-loop control: Pause at structured decision points, especially after blocking questions, before Spec approval, and whenever business semantics are unclear.
  • Batched clarification: Group three to four Open Questions, separate blocking from non-blocking issues, and provide recommended options to reduce decision ping-pong.
  • Spec uncertainty tracking: Explicitly distinguish confirmed facts, LLM-inferred behavior, and unresolved information.
  • Change-path detection: Automatically choose incremental, replacement, or lightweight workflows based on API compatibility, affected modules, and change scope.
  • Spec Reconstruction: Reverse-engineer existing behavior into inferred behaviors, constraints, and invariants when legacy code lacks documentation.
  • Impact analysis: Report affected files, risk, backward compatibility, constraints to check, existing Specs, and discovered gaps.
  • Spec relationship modeling: Track modifies, depends_on, and violates relationships between Specifications.
  • State-machine guidance: Enforce or advise valid transitions from draft through analyzing, refining, approved, implementing, verifying, and completed.
  • Manifest-based traceability: Keep code references in .rdd/links.yml instead of scattering IDs through source comments; use rdd detach when embedded IDs must be removed.
  • Adaptive documentation levels: Use the full .rdd/ chain for complex, multi-person, or cross-session work; use Lite or commit-based workflows for smaller changes.
  • Real LLM verification: Test autonomous tool use and decision behavior with genuine LLM runs, including both trigger and non-trigger scenarios.
  • Retention-aware cleanup: Generate cleanup guidance identifying which artifacts should be archived, deleted, or detached after delivery.

SKILL.md


Loading

Related Openclaw Skills

METADATA

Github Stars: 0
forks: 0

Featured*