Structure Thinking

Structured problem analysis and communication using system mapping and hierarchical logic. Use when a request involves messy, multi-factor problems, root-cau...

Security Scan

This is an instruction-only skill for structured problem analysis; it contains guidance and templates only and requests no installs, credentials, or file/system access.

Purpose & Capability

The name/description (structured problem analysis, system mapping, hierarchical logic) matches the SKILL.md and reference files. All included materials are guidance, templates, and examples that support the stated purpose.

Instruction Scope

Runtime instructions are limited to asking for user inputs, building models, and producing templates/memos. They do not instruct the agent to read system files, call external or hidden endpoints, access environment variables, or exfiltrate data. Prompts reference metrics and trends but expect the user or agent context to provide those, which is appropriate for this type of skill.

Install Mechanism

No install spec and no code files that execute. Instruction-only skill — nothing is downloaded or written to disk as part of installation.

Credentials

The skill declares no required environment variables, no credentials, and no config paths. There are no unexplained secrets or cross-service credentials requested.

Persistence & Privilege

always:false (not force-installed) and disable-model-invocation:false (normal — agent may invoke the skill when eligible). The skill does not request persistent system changes or modify other skills' configs.

Assessment

This skill is a set of templates and step-by-step guidance for structuring messy problems and appears internally consistent. Before installing, confirm that you understand it will ask for context (metrics, owners, constraints) — it does not itself access your systems or secrets. If you plan to let the agent access external data sources (databases, monitoring, or files) to populate metrics, make sure those data-accessing skills/tools are authorized and reviewed separately. If you prefer the agent not to invoke skills autonomously, consider disabling autonomous invocation at the agent/platform level.

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.