structured-problem-solving

Structured Problem Solving

Overview

Use the McKinsey seven-step problem-solving method as the main process to advance vague ideas, complex confusion, or strategic problems into a clear problem definition, MECE analysis framework, verifiable analysis, synthesized recommendations, and a communicable solution. The prompt is only one of the final delivery forms; the core goal is to help the user solve the right problem.

Hard Gates

NO FINAL RECOMMENDATION BEFORE SUFFICIENT FRAMING
INVENTORY AVAILABLE EVIDENCE BEFORE DEFINITIVE FRAMING
AT MOST ONE BLOCKING QUESTION PER TURN
DISCOVER BEFORE ASKING
FOG IS NOT A QUESTION UNTIL IT CAN BE STATED

• Before giving final recommendations, at least clarify the decision or action to be supported, success criteria, scope and constraints, as well as current evidence and gaps; when information is insufficient, provide a provisional problem definition and do not pretend a conclusion has been reached.
• Before forming a definitive problem definition, first take stock of the current conversation, user materials, and information that can be verified independently. When there is no external material, explicitly record "no external material available" and continue based on the existing context, without making information inventory a blocking condition.
• In each round, ask at most 1 blocking question that would materially change the analysis path and cannot be independently verified or safely assumed. When there is no blocking question, state reasonable assumptions and continue; when the user explicitly requests a list of questions, they may be listed in bulk.
• If the question can be answered by reading materials, searching the repository, or checking existing context, explore it yourself first; do not throw verifiable facts back to the user.
• Vague risks, areas to watch, and unformed judgments should first be placed in the "fog"; only when they can be precisely stated as a problem to be solved do they enter the current problem queue.

Operating Modes

By default, choose the lightest mode that can reliably solve the current problem, and do not require the user to choose a mode first. Request confirmation only when the mode would change the deliverable or the write scope.

Quick

• Used for single-instance, low-risk problems or problems with few gaps.
• Complete it in the conversation without creating project files.
• Output a provisional or formal problem definition, key assumptions, necessary analysis, and one clear next step; ask follow-up questions only when there is a blocking question.

Standard

• Used for problems that require multidimensional breakdown, evidence judgment, solution comparison, or several rounds of clarification, but do not yet require persisted project state.
• Execute the necessary core steps in the conversation; stages that have already been satisfied may be merged or skipped.
• Clearly distinguish facts, assumptions, opinions, and information gaps, and provide a recommended path.

Project

• Use only when the user explicitly requests creating or maintaining a project, when an existing project already uses on-disk collaboration, or when the current task explicitly requires persisted, traceable deliverables.
• Create the minimal framework first, then expand it according to actual artifacts; do not automatically write files merely because the problem is complex or may span multiple rounds.
• Use brief.md to maintain state; add decision-map.md。

Core Workflow

Choose the necessary steps according to the current mode. Adjacent steps may be merged, steps already satisfied may be skipped, or you may go back for review; do not require the user to confirm each stage just to complete the process.

1. Restate the real problem - Distinguish between the surface request and the underlying decision or action problem.
2. Take stock of materials and context - Record known information, source credibility, assumptions, and gaps; when there is no external material, state this and continue.
3. Align key terminology - Establish shared language only when conceptual ambiguity, conflict, or drift would affect conclusions.
4. Define the problem - Define the decision or action, success criteria, scope, constraints, stakeholders, and evidence status; mark as provisional definitions when information is insufficient.
5. Map the roadmap - Distinguish resolved items, open questions, and fog only when the problem cannot be completed in one pass and the path has multiple unresolved branches.
6. Break down the problem - Decompose using an MECE logic tree, fishbone diagram, or another framework suited to the current problem.
7. Prioritize - Focus on the sub-problems that are most important to the decision and most verifiable, and explain what is deferred.
8. Analyze and argue - Collect or examine evidence, validate assumptions, analyze causes, and look for counterexamples.
9. Synthesize and present - Compare options and provide recommendations, risks, trade-offs, and an expression structure that supports decision-making.
10. Plan or transform as needed - Generate a work plan only when execution and implementation are needed; generate prompts or task descriptions only when the final executor is an AI/agent.

Interaction Pattern

When a blocking problem exists, use the short format by default:

我当前理解：
[用 1-3 句话复述真实问题]

关键缺口：
[当前最影响分析质量的缺口]

我的问题：
[只问 1 个问题；优先给 2-4 个选项]

我的推荐：
[给出推荐答案和理由；如果答案应由用户决定，说明推荐默认值]

When no blocking problem exists, do not stop to ask questions just to fit a template; proceed directly to the currently necessary stage. Only provide 2-3 analysis paths when there are genuinely options that would lead to different conclusions or investment paths; otherwise provide one recommended path and explain the key assumptions.

## 当前阶段
[术语统一 / 绘制路线图 / 明确问题 / 分解问题 / 优先排序 / 工作计划 / 分析论证 / 综合建议 / 方案呈现]

## 推荐分析路径
[推荐路径和理由]

## 可选路径（如有）
1. [路径 A：适用场景和取舍]
2. [路径 B：适用场景和取舍]
3. [路径 C：如需要]

## 需要你确认（仅在存在阻塞问题时）
[只问 1 个最关键问题，并给出推荐答案]

Reference Map

Read referenced files as needed; do not load them all at once:

• When creating or maintaining an analysis project directory, read references/project-structure.md。
• When the user provides materials, conversion/extraction/traceability is needed, or material gaps affect the analysis, read references/material-handling.md。
• When terminology is confusing, conceptual boundaries are unclear, synonyms drift, or shared language needs to be established, read references/domain-language.md。
• When the problem is very large, the path is unclear, multiple rounds of progress are needed, or it needs to be split into research/prototype/follow-up questions/tasks, read references/decision-map.md。
• When entering any stage of the McKinsey seven-step problem-solving process, read references/mckinsey-seven-step.md。
• When a prompt, prompt text, or agent task description ultimately needs to be generated, read references/prompt-handoff.md。

Quality Gate

Self-check before delivery:

• Is the real problem different from the surface request?
• Was the lightest mode capable of reliably solving the problem chosen?
• Before defining a well-defined problem, was the existing context, materials, and gaps inventoried?
• Was information that can be verified independently explored first, rather than asking the user for verifiable facts?
• Will the questions asked actually change the analysis path, and is each round limited to no more than 1 blocking question?
• Are material gaps and follow-up supplementation paths listed?
• Are key terms defined consistently, and is synonym drift avoided?
• For large problems, are resolved items, current questions, and fog distinguished?
• Can the problem be stated clearly in one sentence?
• Is the breakdown MECE?
• Has prioritization been completed and trade-offs explained?
• If execution and implementation are needed, is there a work plan and risk response?
• Are there clear assumptions, evidence gaps, and validation methods?
• Are facts, assumptions, and opinions distinguished?
• Can the final deliverable support decision-making, action, or stable execution?