requirement_decomposer

Requirement Decomposer

⚡ Quick Reference

When requirements are vague, incomplete, or ambiguous, execute according to this process.Experienced models can first read this quick reference, confirm the process, and then decide whether they need to read each Phase in detail.

1️⃣ RESTATE  — 复述需求，标注已理解/不确定的部分
2️⃣ EXTRACT  — 提取 7 维信息：目标/角色/输入/输出/约束/非功能/上下文
3️⃣ CLARIFY  — 三分类模糊点：🔴必须确认 / 🟡可以假设 / 🟢可忽略
4️⃣ DECOMPOSE— 拆解为 P0/P1/P2 任务树 + 依赖关系 + 技术选型
5️⃣ PLAN     — 行动计划 + 风险 + 成功标准

See the corresponding Phase below for detailed explanations and examples.

When to use

the requirement given by the useris incomplete, ambiguous, or needs further clarification. Core value: ensure correct understanding before starting work.

Typical scenarios:

• Programming assignments/interview questions (deliberately vague, testing comprehension ability)
• Product Requirements Document (PRD) fragments
• Technical solution/architecture design requirements
• "Help me make an XX" type vague requests
• Any task that requires "thinking it through before starting"

Cases where it should not be used: The requirement is already very clear and explicit and can be executed directly; simple single-step queries or factual questions.

Trigger signals: Vague words such as "probably", "more or less", "appropriately", "etc.", "and the like", "as the case may be" appear in the user's requirement; or there is only a goal without input/output/constraint descriptions.

Workflow

Phase 1: Receive and Restate (RESTATE)

🎯 Why it matters: Restating is the first checkpoint for aligning understanding. What you understand and what the user said may be two different things — restating gives the user a chance to correct you. Skip this step, and all subsequent analysis may be built on a wrong foundation.

1. Fully receivethe user's original requirement text
2. Restate in your own wordsthe core content of the requirement
3. Markthe understood partsandthe uncertain parts

Example:

The user says: "Help me write a task management tool" Your restatement: "Your goal is to make a task management tool. I understand the core features should be creating tasks, marking them complete, and viewing the list. But I'm not sure: is this for single-person use or a team? Does it need a Web interface or a command line? Does the data need to be persisted?"

Note: Do not add information that is not in the original text out of thin air (such as "it should have a Gantt chart/kanban"), unless you explicitly state it in your assumptions.

Output format:

## 📥 原始需求
> [粘贴用户的原始输入]

## 🔄 我的理解
[用一句话概括目标]
[列出已确认的关键要素]

Phase 2: Structured Extraction (EXTRACT)

🎯 Why it matters: People tend to focus only on the goal and ignore constraints and context. The 7-dimension framework ensures you do not miss key dimensions — especially information that users feel is "a given" and do not say.

Extract the following dimensions from the requirement.For each dimension, try to think: is what the user said specific enough? If not, this is a vague point; leave it for Phase 3.

Dimension	Extracted content	Example
Goal	What is to be achieved? State it clearly in one sentence	"Implement a file search feature"
Actor	Who is using it / who cares about the result?	"End user / administrator"
Input	What data is given? Format? Scale?	"List of file paths + keywords"
Output	What result is expected? For whom? Format?	"List of matching files + highlight positions"
Constraint	What hard limits are there?	"Time complexity O(n), memory < 100MB"
Non-functional requirements (NFR)	Performance/security/availability?	"Support concurrency, need to handle large files"
Context	Why does this requirement exist? Background story?	"Programming assignment, testing requirement understanding ability"

Tip: If a dimension has no information at all in the original text, do not leave it blank—mark it as "not mentioned"; this itself is input for Phase 3.

Phase 3: Ambiguity identification and classification (CLARIFY)

🎯 Why it matters: Not every ambiguous point needs to be clarified with the user. Over-asking annoys the user, while failing to ask what should be asked leads to rework. Three-way classification helps you find a balance between "clarification cost" and "understanding risk".

Classify each ambiguous point into three categories.Remember one sentence for the classification principle: if different answers would lead to different technical solutions, this is 🔴; otherwise, see whether there is a reasonable default value.

## ❓ 澄清问题清单

### 🔴 必须确认（Blocker）
| # | 模糊点 | 为什么重要 | 建议提问方式 |
|---|--------|-----------|-------------|
| 1 | ... | 不确认会导致... | "您希望...？" |

### 🟡 可以假设（Assumption）
| # | 模糊点 | 我的假设 | 假设理由 |
|---|--------|---------|---------|
| 1 | ... | 我假设... | 因为... |

### 🟢 可忽略/延后（Defer）
| # | 模糊点 | 为什么可忽略 |
|---|--------|-------------|
| 1 | ... | 不影响核心流程... |

Classification principle:

• 🔴 Must confirm: different answers would lead to completely different technical solutions
• 🟡 Can assume: there is a reasonable default value, and it can be adjusted afterward
• 🟢 Can ignore: does not affect the core decision of the current phase

Questioning techniques: Prefer closed-ended questions (Yes/No or either-or) to reduce the user's answering cost. List all 🔴 questions at once to avoid repeatedly disturbing the user. For 🟡 assumptions, directly give the default value and rationale; the user only needs to say "incorrect".

Phase 4: Subtask decomposition (DECOMPOSE)

🎯 Why it matters: Large tasks look intimidating; only by breaking them into small steps do you know where to start. At the same time, the decomposition process reveals hidden dependencies—"ah, this must be done first before that can be done"—avoiding getting stuck halfway through execution.

Decompose the requirement intoan executable subtask tree. Choose a decomposition method suitable for the scenario (process decomposition/data flow decomposition/module decomposition/layered decomposition).

## 🧩 任务分解

### 任务树
[根任务]
├── [子任务 1] ⭐ P0（必须做）
│   ├── [步骤 1.1]
│   └── [步骤 1.2]
├── [子任务 2] ⭐ P0
│   └── ...
├── [子任务 3] ⭐ P1（应该做）
└── [子任务 4] ⭐ P2（可以做）

### 依赖关系
- [子任务 2] 依赖于 [子任务 1]
- [子任务 3] 和 [子任务 4] 可并行

### 技术选型建议
| 决策点 | 选项 A | 选项 B | 推荐 | 理由 |
|--------|--------|--------|------|------|
| 语言 | Python | JavaScript | 视场景 | ... |
| 数据结构 | 数组 | 哈希表 | 哈希表 | O(1)查找 |

Decomposition principle:

• Eachleaf nodeshould bea directly executable single step
• Markpriority（P0/P1/P2）
• Markdependency relationships（→ blocking dependency,↔ mutual dependency,|| parallelizable)
• Providetechnology selection suggestions—at least 2 options, with rationale

Example leaf nodes (good): "Create a form component for user registration: includes three input fields for username, password, and email + a submit button" Example leaf node (bad): "Implement the user system" — this can still be broken down further!

Phase 5: Action Plan (PLAN)

🎯 Why it matters: Breakdown is only analysis; the action plan is the starting point for taking action. Clarify "what can be done now" and "what needs to wait," so the user knows how to proceed next.

## 🚀 建议行动计划

### 立即执行（本轮）
1. [第一步具体操作]

### 等待确认后执行
1. [依赖澄清问题的步骤]

### 风险点
- [风险1]: [缓解措施]
- [风险2]: [缓解措施]

### 成功标准
- ✅ [可验证的标准1]
- ✅ [可验证的标准2]

Breakdown Depth Control

When do you stop breaking down? Use a simple test:

• Can this subtask becompleted independently?
• Estimated within 30 minutes — can it be done?
• When the executor sees this task, do they no longer need to ask "how exactly do I do this"?

All three are Yes → ✅ Stop here Any one is No → Continue breaking it down

Counterexample: "Implement the user system" (No, needs further breakdown) Positive example: "Create a user registration form: includes username/password/email input fields + form validation + submit button"

Note: Do not over-decompose to the level of implementation details (such as "use a for loop to iterate over the array") — that is a matter for the execution phase, not the requirements breakdown phase.

Output contract

Required output for each run (in order):

1. 📥 Original requirement + 🔄 Restatement of understanding — Confirm nothing has gone off track
2. 📊 Structured extraction table — Goal / Actor / Input / Output / Constraint / NFR / Context
3. ❓ Clarifying question list — 🔴 Must confirm / 🟡 Can assume / 🟢 Can ignore
4. 🧩 Task breakdown tree — Subtasks + priorities + dependencies + technology choices
5. 🚀 Action plan — Immediate action items + risks + success criteria

Quality standards:

• The restatement must not introduce information not present in the original requirement (unless explicitly declared in the assumptions)
• Each assumption must state its rationale
• Each technology choice recommendation must have a rationale
• Leaf nodes must be single steps (not further divisible)
• Clarifying questions must be specific enough that the user can directly answer Yes/No or give a short value

Interaction mode

Choose the mode based on the user's original intent:

Mode A: Pure breakdown (default)

• Only do requirements breakdown, do not execute implementation
• After outputting the above 5 parts, wait for user feedback
• After the user supplements information → switch to Mode C for iterative refinement
• Applicable: the user says "help me analyze this requirement"

Mode B: Breakdown + guided execution

• After completing the breakdown, proactively advance execution in P0→P1→P2 order
• Confirm each 🟡 assumption one by one ("I assumed X, is that correct?")
• For 🔴 must-confirm items, wait for an answer before continuing
• Applicable: the user says "help me do this"

Mode C: Iterative refinement

• After the user supplements information, update the breakdown results
• Use a diff to mark the changed parts (which understandings changed/were added/were deleted)
• Re-output the complete 5 parts (not just the changed parts — give the user a complete updated picture)
• Applicable: the process in which requirements gradually become clearer over multiple rounds of dialogue

Failure handling

Scenario	Handling approach
Requirements completely blank	Ask the user to provide at least a one-sentence description
Requirements too broad (e.g., "build a good system")	Ask 3 focused questions to narrow the scope
Requirements self-contradictory	List the contradictions and ask the user to choose
Unable to judge technical feasibility	Mark as a risk item and provide both feasible/infeasible paths
User dissatisfied with the decomposition result	Ask which part is inaccurate and make targeted corrections
Requirements change during the conversation	Record version changes, switch to mode C, and output a diff
User explicitly says "just do it first and talk later"	Switch to mode B, but mark unconfirmed risk points and stay vigilant during execution

Tips & Anti-patterns

✅ Do:

• Restate first, then analyze, to avoid drawing conclusions too early
• Explicitly declare each assumption
• Turn "I don't know" into specific clarifying questions
• Present with tables and tree structures; clearer than plain text
• When giving technical selection recommendations, provide at least 2 options
• Check "information the user didn't say"—the absence itself is a finding

❌ Don't:

• Do not make business decisions for the user (e.g., "I think you should build feature X")
• Do not settle on a single technical solution before confirming
• Do not ignore ambiguous points and pretend everything is clear
• Do not write a leaf node as a large step like "implement XXX" that still needs decomposition
• Do not output only conclusions without explanation—every conclusion must have a reason
• Do not over-decompose to the level of implementation details like "use a for loop"

References

For the detailed methodology guide (ambiguity matrix, ambiguity detection patterns, questioning techniques for each Phase, complete examples), see references/methodology.md。