rb-discuss

Audit documentation and prompt decisions on interfaces, edge cases, and acceptance criteria.

Updated Jul 2, 2026

Search Tags:#workflow #planning #requirements #clarification #alignment #decision-making

Ready to run

npx skills add https://github.com/richardmbailey/rb-skills --skill rb-discuss

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: rb-discuss
Source: https://github.com/richardmbailey/rb-skills/tree/main/rb-discuss
Command: npx skills add https://github.com/richardmbailey/rb-skills --skill rb-discuss

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill prevents wasted development effort by ensuring that non-trivial features or changes have clearly defined requirements, interfaces, and acceptance criteria before any code is written.

Core Features & Use Cases

Requirement Clarification: Systematically identifies missing information regarding edge cases, failure modes, and scientific assumptions.
Decision Documentation: Provides a structured approach to recording agreed-upon requirements and risks in a working diary.
Use Case: Use this when a stakeholder requests a complex feature but the technical implementation details, such as error handling or data compatibility, remain undefined.

Quick Start

Invoke the rb-discuss skill to clarify the unresolved material requirements for the proposed feature before starting the implementation plan.

Frequently Asked Questions about rb-discuss

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

FAQPage Schema

How do I resolve material requirements ambiguity before coding starts?▼

To resolve material requirements ambiguity before coding, you can audit existing documentation and prompt for targeted decisions on interfaces, edge cases, and acceptance criteria to ensure project alignment.

What is the best way to define technical implementation details for a complex feature?▼

Defining technical implementation details for a complex feature requires systematically identifying missing information regarding failure modes and data compatibility, then recording the agreed-upon requirements in a working diary.

When do I need to clarify requirements for non-trivial software changes?▼

You need to clarify requirements for non-trivial software changes when a stakeholder requests a feature but technical implementation details like error handling or data compatibility remain undefined.

How do I document decision-making and mitigate risks prior to an implementation workflow?▼

To document decision-making and mitigate risks prior to an implementation workflow, use a structured approach to record agreed-upon requirements and risks, ensuring alignment before planning commences.

Does this requirements clarification process work without predefined components or dependencies?▼

Yes, this requirements clarification process works without predefined dependencies or components, operating instead by auditing existing documentation to facilitate the resolution of technical ambiguities.