How the Requirement‑Decomposition Skill Eliminates 99% of Missed Test Risks with One‑Click Structured Reports

Background – Test engineers often receive PRDs and then spend time manually marking unclear points, guessing business rules, searching chat logs for product clarification, and creating ad‑hoc decomposition tables. This leads to frequent omissions, inconsistent granularity, reliance on experience, and non‑reusable outputs.

What the skill solves – The requirement-decomposition skill replaces the manual “brain‑power” step with a structured 12‑dimension framework that covers functional goals, user roles, business rules, state flows, input/output specifications, data logic, permission rules, exception scenarios, boundary conditions, concurrency risks, idempotency, and dependent services. AI fills the table and marks any inferred items as "AI inference, to be confirmed".

Comparison with requirement‑analysis – Requirement‑analysis works on a vague idea (0→1) and produces a complete PRD, while requirement‑decomposition works on an existing PRD (1→100) and produces a detailed, test‑oriented report. The former asks for clarification; the latter extracts and structures information.

Core highlights

12 dimensions derived from extensive incident post‑mortems ensure coverage of all high‑frequency failure points.

Dual‑mode operation: a detailed mode for PRDs longer than 100 words and a minimal mode that asks 3‑5 key questions for one‑sentence requirements.

Four red‑line safeguards: (1) never output test‑case steps, (2) never add rules without explicit confirmation, (3) never fabricate dependent services, (4) require exhaustive listing of business rules, data logic, amount calculations, and dependencies.

Example: e‑commerce coupon

Input PRD: "Platform launches a coupon system; users can claim a 100‑yuan‑off‑10 coupon, one per person, valid for 7 days, usable at checkout."

Output includes:

Dimension 1 – Requirement summary : three core flows – activity creation, user claim, order checkout; key constraints are "limit per user" and "full‑reduction threshold".

Dimension 2 – Business flow : visual flowchart (activity → page → claim → validation → stock deduction → order → coupon validation → discount calculation → order generation).

Dimension 4 – Business rules (partial) – e.g., BR‑01: "Spend ≥ 100 ¥ to get 10 ¥ off"; BR‑02: "One coupon per user" (pending clarification on identifier); BR‑03: "Coupon expires 7 days after claim" (pending start‑time clarification).

Dimension 7 – Data calculation – formula: if A ≥ 100: discount = B else: discount = 0 (precision to be confirmed).

Dimension 8 – Exception scenarios – EX‑01: "Coupon sold out" → prompt "All coupons have been claimed"; EX‑02: "Order amount below threshold" → prompt "Order does not meet discount condition"; EX‑03: "Duplicate claim" (pending handling).

Dimension 11 – Open questions – 18 items flagged for product or engineering confirmation, including whether discount includes shipping, the exact user identifier for the limit, and refund handling.

Dimension 12 – Preliminary risk rating – High concurrency risk (over‑claim, duplicate claim), high amount‑boundary risk (99.99 ¥, 100.00 ¥, 100.01 ¥), medium state and dependency risks, low permission risk.

Report value – The structured report delivers three concrete benefits: (1) early identification of 18 pending questions (including four P0‑critical items), (2) explicit marking of concurrency and amount risks that guide test‑case focus, (3) a unified business‑rule baseline that eliminates discussion friction.

How to use

WorkBuddy chat – simply type "Decompose this requirement: [PRD]" and the skill runs automatically.

Copy prompt-template.md into any AI tool (Cursor, Claude, ChatGPT) and append your PRD.

Run the Python script:

python decomposer.py --input requirement.md --output decomposition.md

for CI integration.

Browser bookmarklet – drag bookmarklet.html to the toolbar; clicking it opens the AI dialog with the prompt pre‑filled.

Combining this skill with the earlier requirement-reviewer skill yields a complete workflow: first decompose the PRD from a testing perspective, then review its overall quality. Together they provide both "what to test" and "is the requirement acceptable" insights.

Conclusion – Requirement decomposition is a fundamental "test‑left‑shift" practice. A reusable, structured, and risk‑aware decomposition report reduces rework, omissions, and disputes while creating a valuable team asset for future similar features.