Verified:GitHub

requirement-clarification

Convert ambiguous product-change requests into decision-ready clarification records.

4|Updated May 16, 2026

Search Tags:#requirements #migration risk #clarification record #blocking vs non-blocking #assumptions management #authorization boundary #compliance gating

Ready to run

npx skills add https://github.com/machenjie/rd-skills --skill requirement-clarification-machenjie

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: requirement-clarification
Source: https://github.com/machenjie/rd-skills/tree/main/src/foundation/capabilities/requirement-clarification
Command: npx skills add https://github.com/machenjie/rd-skills --skill requirement-clarification-machenjie

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents teams from starting implementation on unclear change requests by forcing every unresolved question to be explicitly classified as blocking or non-blocking before any coding begins.

Core Features & Use Cases

It converts an incoming product-change request into a decision-ready clarification record that separates blocking unknowns from safely deferred items, names safe vs. explicit assumptions, and defines the minimum safe scope for implementation when non-blocking unknowns exist. It is especially useful when requirements are ambiguous, conflicting, touch authorization boundaries, data retention/migration, irreversibility/rollback, financial flows, or compliance obligations, where hidden assumptions can create security, legal, or data-loss risk.

Quick Start

Use requirement-clarification to convert a change request you received without enough detail into a clarification record with blocking and non-blocking unknowns and a minimum safe implementation scope.

Frequently Asked Questions about requirement-clarification

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

FAQPage Schema

How do I clarify ambiguous product change requests before implementation?▼

Clarify ambiguous change requests by converting them into a decision-ready record that explicitly separates blocking unknowns from safely deferred items. This prevents teams from starting coding on unclear requests by forcing every unresolved question to be classified before implementation begins.

What is the best way to manage assumptions for risky requirement changes?▼

Manage assumptions for risky requirement changes by documenting safe versus explicit assumptions within a clarification record. This ensures hidden assumptions involving authorization boundaries, data migration, or compliance obligations are explicitly bounded by owner decisions before implementation.

How do I identify blocking versus non-blocking unknowns in stakeholder requirements?▼

Identify blocking versus non-blocking unknowns by evaluating conflicting stakeholder signals and categorizing each unresolved question. This process separates critical implementation blockers from safely deferred items, allowing you to define a minimum safe scope for non-blocking unknowns.

When do I need a clarification record for product requirements?▼

You need a clarification record when change requests involve unknown behavior, authorization boundaries, data retention, rollback, financial flows, or compliance gating. It is required whenever hidden assumptions create security, legal, or data-loss risks that make implementation decisions unsafe.

How do I define a minimum safe scope for implementation with unresolved requirements?▼

Define a minimum safe scope by bounding the proceed scope with explicit owner decisions. The clarification record outlines what can be safely implemented now while deferring non-blocking unknowns, ensuring risky areas like irreversibility or migration are not touched without authorization.

Does requirement clarification handle compliance gating and authorization boundaries?▼

Requirement clarification handles compliance gating and authorization boundaries by explicitly flagging these concerns during the review process. It forces unresolved questions regarding compliance obligations and authorization limits to be classified as blocking or non-blocking with explicit owner decisions.