when-stuck
When Stuck - Problem-Solving Dispatch
Overview
Different stuck-types need different techniques. This skill helps you quickly identify which problem-solving skill to use.
Core principle: Match stuck-symptom to technique.
Quick Dispatch
digraph stuck_dispatch {
rankdir=TB;
node [shape=box, style=rounded];
stuck [label="You're Stuck", shape=ellipse, style=filled, fillcolor=lightblue];
complexity [label="Same thing implemented 5+ ways?\nGrowing special cases?\nExcessive if/else?"];
innovation [label="Can't find fitting approach?\nConventional solutions inadequate?\nNeed breakthrough?"];
patterns [label="Same issue in different places?\nFeels familiar across domains?\nReinventing wheels?"];
assumptions [label="Solution feels forced?\n'This must be done this way'?\nStuck on assumptions?"];
scale [label="Will this work at production?\nEdge cases unclear?\nUnsure of limits?"];
bugs [label="Code behaving wrong?\nTest failing?\nUnexpected output?"];
stuck -> complexity;
stuck -> innovation;
stuck -> patterns;
stuck -> assumptions;
stuck -> scale;
stuck -> bugs;
complexity -> simp [label="yes"];
innovation -> collision [label="yes"];
patterns -> meta [label="yes"];
assumptions -> invert [label="yes"];
scale -> scale_skill [label="yes"];
bugs -> debug [label="yes"];
simp [label="skills/problem-solving/\nsimplification-cascades", shape=box, style="rounded,filled", fillcolor=lightgreen];
collision [label="skills/problem-solving/\ncollision-zone-thinking", shape=box, style="rounded,filled", fillcolor=lightgreen];
meta [label="skills/problem-solving/\nmeta-pattern-recognition", shape=box, style="rounded,filled", fillcolor=lightgreen];
invert [label="skills/problem-solving/\ninversion-exercise", shape=box, style="rounded,filled", fillcolor=lightgreen];
scale_skill [label="skills/problem-solving/\nscale-game", shape=box, style="rounded,filled", fillcolor=lightgreen];
debug [label="skills/debugging/\nsystematic-debugging", shape=box, style="rounded,filled", fillcolor=lightyellow];
}
Stuck-Type → Technique
| How You're Stuck | Use This Skill |
|---|---|
| Complexity spiraling - Same thing 5+ ways, growing special cases | skills/simplification-cascades |
| Need innovation - Conventional solutions inadequate, can't find fitting approach | skills/collision-zone-thinking |
| Recurring patterns - Same issue different places, reinventing wheels | skills/meta-pattern-recognition |
| Forced by assumptions - "Must be done this way", can't question premise | skills/inversion-exercise |
| Scale uncertainty - Will it work in production? Edge cases unclear? | skills/scale-game |
| Code broken - Wrong behavior, test failing, unexpected output | skills/systematic-debugging |
| Multiple independent problems - Can parallelize investigation | skills/dispatching-parallel-agents |
| Root cause unknown - Symptom clear, cause hidden | skills/root-cause-tracing |
Process
- Identify stuck-type - What symptom matches above?
- Load that skill - Read the specific technique
- Apply technique - Follow its process
- If still stuck - Try different technique or combine
Combining Techniques
Some problems need multiple techniques:
- Simplification + Meta-pattern: Find pattern, then simplify all instances
- Collision + Inversion: Force metaphor, then invert its assumptions
- Scale + Simplification: Extremes reveal what to eliminate
Remember
- Match symptom to technique
- One technique at a time
- Combine if first doesn't work
- Document what you tried
More from fimoklei/pm-ai-playbook
first-principles-decomposer
Break any problem down to fundamental truths, then rebuild solutions from atoms up. Use when user says "firstp", "first principles", "from scratch", "what are we assuming", "break this down", "atomic", "fundamental truth", "physics thinking", "Elon method", "bedrock", "ground up", "core problem", "strip away", or challenges assumptions about how things are done.
22optimize-docs
Condense markdown documentation for token efficiency while preserving all semantic meaning. Use when rules, documentation, or config files need optimization. Target 25-40% reduction through systematic condensation patterns.
20pre-mortem-analyst
Imagine the project already failed, then work backward to find why. More powerful than risk assessment because it assumes failure is certain. Use when user says "pre-mortem", "premortem", "imagine this failed", "what could go wrong", "risk analysis", "before we launch", "stress test", "what would kill this", "project risks".
20idea-challenger
Pre-launch red team analysis that identifies failure modes and validates assumptions before resource commitment. Use when evaluating new products/features/strategies, before significant resource allocation, when stakeholders seem overly optimistic, or when cost of failure would be high (reputation, budget, market position).
20inversion-strategist
Flip problems upside down - instead of "how to succeed", ask "how to definitely fail" then avoid those paths. Use when user says "invert", "inversion", "flip it", "opposite approach", "how would this fail", "avoid failure", "what NOT to do", "Munger", "anti-goals", "guarantee failure".
20security-threat-model
Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling.
18