rdra

Structure business requirements into RDRA 3.0 four-layer analysis artifacts.

Updated Jan 30, 2026
One-click install
npx skills add https://github.com/RyoMa99/chezmoi_dotfiles --skill rdra-ryoma99
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rdra
Source: https://github.com/RyoMa99/chezmoi_dotfiles/tree/main/dot_claude/skills/rdra
Command: npx skills add https://github.com/RyoMa99/chezmoi_dotfiles --skill rdra-ryoma99

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When starting a new system or large feature, teams often jump into implementation without clarifying who the system serves and why it exists. This Skill structures the business "Why" using the RDRA 3.0 methodology, producing traceable requirement artifacts before any specification work begins. ## Core Features & Use Cases - Four-Layer Requirement Structuring: Organizes analysis into system value (actors, goals), external environment (BUCs, business flows), system boundary (use cases, screens, events), and system internals (information and state models). - Phased Analysis Workflow: Guides three phases from context gathering and goal definition through business flow modeling to EARS-based requirement definition with traceability verification. - Existing System Reverse Analysis: Generates draft RDRA artifacts from codebases, DB schemas, and business documents, with confidence labels distinguishing confirmed facts from hypotheses. - Use Case: When starting development of a new contract management feature, run this Skill to enumerate actors and goals, map as-is/to-be business flows, derive use cases, and produce EARS requirements saved under docs/rdra/. ## Quick Start Ask the AI to analyze the requirements for your new feature using RDRA and produce the actor, goal, BUC, and use case lists.

Frequently Asked Questions about rdra

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

FAQPage Schema
How do I structure requirements with RDRA before development?

RDRA organizes requirements into four layers: system value (actors and goals), external environment (BUCs and business flows), system boundary (use cases, screens, events), and system internals (information and state models). The Skill walks through three phases from context gathering to EARS requirement definition.

What is the EARS pattern for writing requirements?

EARS (Easy Approach to Requirements Syntax) defines six patterns: ubiquitous, event-driven, state-driven, optional feature, unwanted behavior, and complex. Each uses keywords like "when" or "while" to constrain natural language into testable requirement statements.

Can RDRA analysis work on an existing legacy codebase?

Yes. The Skill supports an existing-system mode that drafts information and state models from DB schemas and code symbols, then cross-checks use cases against business documents. Elements are labeled as confirmed, hypothesis, or needs-interview to track confidence.

When should I not use RDRA requirement analysis?

Skip RDRA for bug fixes, refactoring, and small changes where code and tests already serve as the specification. It is also unnecessary when existing RDRA artifacts already cover the scope adequately.

How do EARS requirements convert into acceptance criteria?

Each EARS requirement derives multiple Given-When-Then scenarios covering normal cases, input and state error cases, boundary values, and concurrency. These GWT conditions become task acceptance criteria in the planning phase.