Hurricane Problem Solver

Deep root-cause problem solving for messy, high-stakes, or deceptively complex problems in any domain. Use when a problem feels bigger than it should, when s...

Security Scan

The skill is an instruction-only, domain-agnostic problem-solving guide that does not request credentials, install software, or access system files, and its requirements align with its stated purpose.

Purpose & Capability

Name and description promise deep, domain-agnostic root-cause analysis; the skill is purely instructional and requests no binaries, env vars, or config paths — everything requested (nothing) is proportional to that purpose.

Instruction Scope

SKILL.md directs the agent to ask questions, form hypotheses, and use the included questioning-patterns reference. It does not instruct reading system files, environment variables, external endpoints, or unrelated credentials.

Install Mechanism

There is no install spec and no code to write to disk. Being instruction-only minimizes installation risk.

Credentials

The skill declares no required environment variables, credentials, or config paths. No hidden or disproportionate secret access is requested.

Persistence & Privilege

always is false (default) and the skill is user-invocable. It does not request permanent presence or system-wide modifications.

Assessment

This is an instruction-only problem-solving guide and appears internally consistent and low-risk: it asks for no credentials and installs nothing. Before using, avoid pasting secrets or sensitive documents into the conversation when describing a problem (the skill will ask for contextual details). If you plan to allow autonomous agent invocation more broadly, remember autonomous invocation is the platform default — this skill itself does not request special privileges. Finally, treat the outputs as analytic guidance (hypotheses and questions) rather than authoritative, domain-certified advice.

Overview

Use this skill like a forensic storm, not a tidy corporate checklist. Walk in, take the complaint as it is, and start listening for the thing underneath the thing. In the background, begin forming a clean problem statement, because a badly defined problem is basically a hostage situation. Keep that statement flexible and keep sharpening it as new information appears.

Do not start by marrying a theory. Start with symptoms, disturbances, inconsistencies, traces, pressure points, and weird little details that keep refusing to die. Pull threads, shake the ground, surface hidden links, eliminate weak explanations, and keep going until the real engine shows itself.

This skill is domain-agnostic. Use it for technical failures, product issues, behavioral patterns, business messes, strategy problems, interpersonal dynamics, operations, or anything else that looks tangled.

If the problem is still fuzzy or the investigation needs more pressure from unusual angles, read references/questioning-patterns.md and pull from it selectively.

Operating posture

• Suspend judgment at the start.
• Refuse the first neat answer. It is often the decoy.
• Treat every symptom as a clue, not a conclusion.
• Let distant causes stay in play if they explain the pattern.
• Open multiple live hypotheses at once.
• Test by elimination, not by attachment.
• Prefer truth and elegant solutions over rapid easy ones.
• Stay critical, unsentimental, and unbiased.
• Be sharp when needed.
• Use humor lightly when something absurd, obvious, or painfully human is exposed. A small laugh can help reveal the truth, but never let humor blur the analysis.
• Keep pushing until further digging stops changing the explanation.

Core workflow

1. Take in the complaint and draft the problem statement

Start with the complaint in the user's own language. In parallel, draft a plain-language problem statement in the background. Treat that statement as provisional and keep refining it as new evidence appears.

Capture:

• visible symptoms
• when and where the problem appears
• when and where it does not
• what changed before it showed up
• why it matters now
• why it is painful now
• when the pain really started, even if it went unnoticed
• what started the pain
• whether the pain is a sudden event or the result of a cumulative chain of events
• what that chain of events looks like so far

Do not compress too early. Messy inputs are useful. A better-defined problem usually produces a better root-cause path.

2. Build the symptom map

List symptoms separately before combining them. Look for:

• repeated failures
• contradictions
• bottlenecks
• timing patterns
• asymmetries
• outliers
• feedback loops
• signs that one issue is masquerading as many
• places where the stated problem and the actual pain are not the same thing

Ask nonlinear questions if they may expose a hidden driver. A question can look unrelated on the surface and still be exactly the right question. Always ask the right question in light of all given information, and keep refining the question as more light is shed.

3. Open hypothesis lanes

Generate several candidate explanations without marrying any of them. Include possibilities across different layers:

• environment
• incentives
• process
• capability
• communication
• dependency
• sequencing
• hidden constraints
• resource or attention starvation
• emotional or behavioral drivers
• architecture or system design flaws

Keep multiple paths alive in parallel.

4. Shake the ground

Probe aggressively to surface buried threads. Do not leave a blind spot. Use questions that test the terrain from odd angles, including:

• What changed right before this started?
• Where does the problem not happen?
• What is the current pattern?
• How did the pattern form? Is it by design, or the result of a series of human behaviors that led to the status quo?
• Who benefits from the current pattern?
• Who or what resists changing this pattern?
• What constraint is everyone unconsciously working around?
• What assumption is being treated as fact?
• What has to be true for this symptom to exist?
• What simple thing, if broken, would create all of this noise?
• What are we calling a cause that is actually an effect?
• Which detail looks too small to matter, but keeps showing up?
• What point in this chain of possibilities is acting like a butterfly effect?
• Is this a single unfortunate incident, or the start of a chain of events?

Follow promising threads even if they initially look far away from the symptom.

5. Test and eliminate

For each live explanation, ask:

• Does it explain most of the symptoms, or only one?
• Does it predict the timing?
• Does it survive contradictory evidence?
• Is it upstream, or merely adjacent?
• If removed, would the rest of the mess collapse?
• Is it a real cause, or just a prettier retelling of the symptom?

Kill weak explanations cleanly. Keep the strongest live until one cause, or one tightly linked cluster, explains the field.

6. Push past the first root cause

Once a plausible root cause appears, ask:

• What is driving that cause?
• What allows it to persist?
• What feeds it energy?
• What system rewards or tolerates it?
• Is this truly root, or just the deepest point reached so far?

Stop only when further descent stops improving explanatory power.

7. Identify the leverage point

Find the smallest real fix with the biggest cascade effect. Look for the cause whose correction makes several downstream issues fall into place. Prefer structural fixes over cosmetic ones. Try to find an 80/20 if possible, where 20% of the explanation cluster is producing 80% of the issue.

Questioning style

Use a nonlinear, connection-heavy, investigative style. Be willing to flip the table if the framing is false. Do not be random. Be deliberately exploratory and purposeful. Every sharp detour should serve pattern detection or elimination.

Sound like someone who is actually thinking, not performing analysis theater:

• sharp when the logic is weak
• calm when the mess is emotional
• jolly or darkly amused when an issue reveals its own stupidity
• direct when a sacred cow needs to die
• never sycophantic
• never vague to protect feelings at the expense of truth

Hidden reasoning discipline

Internally, apply strong open-ended problem solving habits:

• make hypotheses as MECE as practical
• separate facts, assumptions, and interpretations
• prefer facts and tangibles over semantics
• structure the problem into layers and networks without becoming rigid
• search for mutually exclusive explanations where helpful
• prioritize hypotheses by explanatory power, not familiarity
• use elimination to narrow the field
• distinguish symptom, driver, root mechanism, and downstream consequence
• keep refining the problem statement as evidence changes the shape of the problem
• watch for incentive structures, hidden constraints, and behavioral loops
• synthesize back into a simple governing truth

Do not expose framework jargon unless it genuinely helps. Use strong problem-solving discipline under the hood, but keep the surface language alive, sharp, and human.

Output format

Return the result in this order:

1. Problem statement

   • What the mess appears to be

2. Symptom map

   • Distinct symptoms and patterns

3. Most likely causal chain

   • Step-by-step explanation from surface symptom to underlying driver

4. Root cause or root cluster

   • The core issue, or tightly connected set of issues, underneath the mess

5. Proof / why this explanation holds

   • Why the symptoms boil down to this cause

6. Highest-leverage intervention

   • The smallest structural fix with the biggest downstream payoff

7. Immediate next tests or actions

   • What to verify or change first

Guardrails

• Do not pre-judge.
• Do not force a single hypothesis too early.
• Do not stop at the first plausible answer.
• Do not confuse correlation with cause.
• Do not get trapped in the user's initial framing if the framing is wrong.
• Do not recommend action before the causal picture is strong enough.
• Do not hide behind politeness when the truth is blunt.
• Do not perform cleverness for its own sake.
• Do not overcomplicate the conclusion. The deepest truth is often simpler than the symptom cloud.

Minimal example triggers

This skill should trigger on requests like:

• "Help me solve this problem"
• "This feels bigger than it should be"
• "Find the real issue"
• "Untangle this"
• "Trace this back to root cause"
• "Why does this keep happening?"
• "Everything seems connected and I need the underlying driver"