# Structure Thinking

> Structured problem analysis and communication using system mapping and hierarchical logic. Use when a request involves messy, multi-factor problems, root-cause analysis, intervention design, feedback loops or delays, or when a clear top-line recommendation with logically grouped support is required.

- Skill: `dvcrn/structure-thinking` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add dvcrn/structure-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dvcrn/structure-thinking/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dvcrn (https://skillmd.com/u/dvcrn)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/dvcrn/structure-thinking

---


# Structure Thinking

## Overview
Use this skill to turn a messy situation into a clear decision path. You will model the system to find real levers, then build a compact argument that enables action. The focus is practical: define the decision, diagnose the system behavior, choose interventions, and communicate a decisive recommendation.

## Preferred Inputs
- Decision owner and deadline.
- Success definition (metric, threshold, or observable change).
- Constraints (budget, time, policy, technical limits).
- Behavior over time (trend, seasonality, oscillation).

If any are missing and the user wants an answer now, proceed with explicit assumptions and mark them as `Assumed`.

## Workflow

### 1) Define the Decision and Question
Goal: one clear governing question and a provisional answer.

Do:
- Write a one-sentence decision statement: “Decide whether to X by date Y to achieve Z.”
- Capture `Situation`, `Complication`, `Question`, `Answer`.
- List assumptions and unknowns explicitly.

Output:
- Governing question.
- Provisional answer in one sentence.

### 2) Describe Behavior Over Time
Goal: pin the problem to a trend, not a feeling.

Do:
- Summarize how the key metric changes over time.
- Note seasonality, spikes, or oscillations.
- State the time horizon that matters.

Output:
- Behavior-over-time summary (2-4 bullets).

### 3) Model the System
Goal: explain why the behavior persists.

Do:
- Define system boundary and stakeholders.
- Identify 1-3 critical stocks and their flows.
- Draw reinforcing and balancing loops.
- Mark delays and missing information.

Output:
- System map notes: stocks, flows, loops, delays.

### 4) Generate Hypotheses (MECE)
Goal: create testable explanations or options.

Do:
- Build an issue tree with 3-5 MECE branches.
- Label each branch as an assertion (not a topic).
- Rank branches by impact and evidence availability.

Output:
- Issue tree with ranked branches.

### 5) Select Leverage Points and Interventions
Goal: choose a small set of actions that change structure, not just parameters.

Do:
- Map top branches to leverage points.
- Propose 1-3 interventions and how they change the system.
- Identify risks, side effects, and where resistance will appear.

Output:
- Intervention shortlist with mechanism + risks.

### 6) Build the Argument Hierarchy
Goal: make the decision obvious and actionable.

Do:
- Lead with the answer.
- Add 2-5 support points, each an assertion.
- Place evidence under each support.
- Keep each layer MECE and parallel.

Output:
- Decision-ready outline (top-line + supports + evidence).

### 7) Validate and Iterate
Goal: avoid false confidence.

Do:
- Run counterfactuals and ask what would disprove the answer.
- Check for feedback delays and unintended consequences.
- Update the system model and argument as evidence changes.

Output:
- Final recommendation with confidence level and known gaps.

## When Inputs Are Missing
Deliver a best-effort output with explicit assumptions.

Use this format:
- `Assumed`: list what you assumed and why.
- `Open questions`: list what would change the answer most.
- `Provisional diagnosis`: short system explanation.
- `Interventions`: 2-3 actions with risks.

Do not block the answer unless the user explicitly asks you to wait.

## Practical Prompts
Use these to move fast when information is incomplete.

Decision framing:
- “What single decision are we making, by when, and who owns it?”
- “What does success look like in one metric?”

Behavior over time:
- “Show the metric trend for the last N weeks/months.”
- “Where are the spikes, delays, or oscillations?”

System modeling:
- “What is the main stock that is accumulating or draining?”
- “Which loop is reinforcing the problem?”
- “Where is the delay that hides the effect?”

Interventions:
- “Which rule change would prevent the loop from amplifying?”
- “Which information flow, if made visible, would change behavior?”

## Intervention Checklist
For each proposed action, answer:
- Mechanism: which loop or stock does it change?
- Owner: who can implement it?
- Trigger: when does it take effect?
- Metric: what leading indicator confirms it works?
- Risk: what side effect or resistance might appear?

## Evidence Quick Check
- Baseline: what is the current level and trend?
- Attribution: what evidence links cause to effect?
- Counterfactual: what would disprove this claim?
- Lag: how long until impact should show up?

## Output Templates

Decision memo (short):
- Answer (1 sentence)
- Why now (1-2 sentences)
- Key supports (2-5 bullets)
- Evidence per support (2-4 bullets)
- Intervention plan (actions, owner, timing)
- Risks and mitigations

System summary (short):
- Boundary and actors
- Key stocks and flows
- Dominant loops
- Delays and information gaps

## Mini Example (Software)
Problem: API latency spikes during peak traffic.

Decision statement:
- Decide whether to change retry and rate-limit policy this quarter to stabilize p95 latency.

Provisional answer:
- Yes, reduce retry amplification and shorten scaling delay.

Top-line outline:
- Answer: change retry and rate-limit rules and adjust scaling thresholds.
- Support 1: retry amplification dominates peak load.
- Support 2: scaling delay creates overshoot.
- Support 3: policy changes reduce queue growth without lowering throughput.

## Common Failure Modes
- Jumping to solutions without modeling the system.
- Mixing causes, solutions, and evidence in one layer.
- Optimizing a local metric that harms the whole system.
- Parameter tweaks that ignore feedback or delays.
- Vague supports with no mechanism or evidence.

## Reference Map
- Load `references/structured-communication-core.md` for hierarchical logic, MECE, SCQA, and writing rules.
- Load `references/systems-dynamics-core.md` for system concepts, leverage points, and practice rules.
- Load `references/integrated-framework.md` for the unified method and example.
- Load `references/software-playbooks.md` for software-focused playbooks.