prd-decomposer

PRD Decomposer Skill

Overview

This skill transforms complex, lengthy PRDs (Product Requirement Documents) into purely structural documentation (a set of Markdown files) defining optimally sized requirement units (REQs).

Core Focus: A high-quality decomposition focuses on WHAT we are building and the underlying Business Logic, never on HOW to code it. The Agent proactively identifies ambiguous logic, confirms boundaries, and breaks the logic into atomic manageable pieces without dictating implementation methods to downstream agents.

When to Use

• User provides a new PRD or feature requirement document
• The business logic needs to be pressure-tested and clarified before development
• Requirements need to be broken down into atomic business logic requirement units (REQs)

Core Principles

1. Clarify First, Decompose Later Never blindly parse a poorly defined PRD. Always interactively force the user to confirm ambiguous logic, edge cases, and boundaries first.

2. Code Exploration as INPUT, Not OUTPUT When the user provides a codebase reference (e.g., project path), thoroughly explore the code to understand existing functionality, current behavior, and business context. This understanding is your INPUT — it helps you describe the current state accurately, identify affected features, and fill in PRD gaps. However, the OUTPUT must be expressed in pure business language. NEVER include file paths, line numbers, variable names, function names, or architectural patterns in the generated documents. The downstream Dev Agent will explore the code themselves.

3. Focus on Business Logic (What, Not How) Requirement breakdown is strictly about decomposing Business Logic, not dictating implementation. Clearly explain WHAT the feature is and WHAT the business rules are. NEVER tell the downstream AI "how to code it" (e.g., do not suggest using arrays, specific hooks, or CSS frameworks unless strictly mandated by the PRD). Do NOT create REQs that are purely about code refactoring or architectural migration — if it's not a business behavior change, it doesn't belong in the breakdown.

4. Current State → Target State → Delta Every REQ must clearly describe: what exists today (现状), what the product wants (需求), and the precise difference (变更: add/modify/remove). This framing helps the downstream Dev Agent understand the full business context and make informed implementation decisions.

5. File-Based Progressive Disclosure Output the breakdown as a structured directory of files, starting with an outline index.