skills/polya-problem-solving/SKILL.md
Classic mathematical problem-solving methodology: understand, plan, execute, review
npx skillsauth add curiositech/windags-skills polya-problem-solvingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
license: Apache-2.0
metadata:
name: polya-problem-solving
version: 1.0
source: "How to Solve It: A New Aspect of Mathematical Method — G. Polya (1945/1957)"
description: >
Systematic heuristics for navigating hard problems: identifying the unknown,
finding related problems, reasoning under uncertainty, and consolidating
knowledge after solving. Applies across all domains where the path to
solution is not immediately visible.
activation_triggers:
- "stuck on a hard problem with no clear path forward"
- "need to decompose a complex task into tractable subproblems"
- "unsure what the actual question is before starting work"
- "finished a problem and need to extract generalizable lessons"
- "reasoning under uncertainty about which approach to try"
- "debugging a solution that keeps failing in non-obvious ways"
- "designing a solution strategy before writing any code"
- "problem seems too hard / too vague / too large"
Load this skill when:
Do not load this skill when the problem is genuinely routine and the method is already known — Polya is for finding a path, not walking a known one.
UNDERSTAND → PLAN → EXECUTE → REVIEW
Every non-trivial problem traverses these phases. The phases are not optional and cannot safely be reordered.
| Phase | Key Question | Characteristic Failure | |-------|-------------|----------------------| | Understand | What is unknown? What is given? What is the condition? | Rushing to plan before the problem is fully stated | | Plan | Do I know a related problem? Can I reduce this? | Planning for the wrong problem; skipping to execution | | Execute | Carry out the plan, checking each step | Executing a plan that was never validated against the problem | | Review (Look Back) | Can I check the result? Can I use this elsewhere? | Skipping entirely; treating the solution as a closed event |
The most common failure: Understanding → Execution, skipping Planning entirely. This produces technically correct work that answers the wrong question.
Before mobilizing any knowledge, look at the unknown. Not the data. Not the constraints. The unknown.
This focuses all subsequent heuristic operations. It prevents the trap of drowning in data while the actual question goes unexamined. Almost every successful move in Polya's worked examples begins here.
Hard problems are hard because no direct path is visible. The solution is to find a stepping stone:
The Inventor's Paradox: A more general problem may be easier to solve than a specific one because it strips away misleading particulars and reveals the underlying structure.
Polya distinguishes two modes:
| Mode | Nature | Role | |------|--------|------| | Heuristic | Provisional, plausible, directional | The only reasoning available before the answer is known | | Demonstrative | Certain, complete, verifiable | What you write after the answer is found |
Heuristic reasoning is the scaffolding; demonstrative reasoning is the building. The danger is not using heuristic reasoning — it is either:
A heuristic that leads to a wrong answer is not a failure — it is information. Follow the plausible path, but label it as provisional.
After a solution is found, experts ask four questions:
Without Looking Back, each solved problem is an isolated event. With it, each solution cross-links to prior knowledge, creates transferable methods, and generates new productive questions. This is the difference between a solver who improves and one who merely completes tasks.
IF the problem is unclear or vague
→ Before doing anything: state the unknown explicitly.
What type of thing is the answer? What are the given data?
What is the condition connecting them?
[Load: polya-four-phase-problem-solving.md]
IF you are stuck and don't know where to start
→ Look at the unknown. Ask: have I seen this type of unknown before?
Try to recall a related problem and ask if its method transfers.
[Load: polya-look-at-the-unknown.md]
IF the problem feels too hard or too large
→ Try auxiliary problems first: specialize, generalize, analogize.
Consider the Inventor's Paradox — is the general version easier?
[Load: polya-auxiliary-problems-and-stepping-stones.md]
IF you have a vague sense of the right direction but can't prove it
→ Proceed heuristically; label the reasoning as provisional.
Follow the plausible path. Verify at the end, not before you start.
[Load: polya-heuristic-vs-demonstrative-reasoning.md]
IF you need to restructure a complex problem
→ Decompose into parts, manipulate the parts, recombine.
Look for structure in the problem itself, not just in your method.
[Load: polya-decomposing-and-recombining.md]
IF you feel like you're making no progress despite effort
→ Distinguish mobilization (retrieving relevant knowledge) from
organization (assembling it toward a plan). Check whether a
"bright idea" is being waited for vs. actively constructed.
[Load: polya-mobilization-organization-progress.md]
IF you have just solved a problem and are about to move on
→ Stop. Look back. Can you check it another way? Can you use
the method elsewhere? What does this solution open up?
[Load: polya-looking-back-and-knowledge-compounding.md]
IF you need to recognize whether you're making genuine progress
→ Learn the signs: subsymbolic sense of "getting warmer,"
productive subproblems being resolved, structure becoming visible.
[Load: polya-expert-intuition-and-signs-of-progress.md]
| File | When to Load |
|------|-------------|
| polya-four-phase-problem-solving.md | When setting up any non-trivial problem; when a solution attempt keeps failing and you suspect the process is wrong, not just the method |
| polya-look-at-the-unknown.md | When stuck at the start; when you need to focus mobilization of prior knowledge on what actually matters |
| polya-auxiliary-problems-and-stepping-stones.md | When the problem is too hard for direct attack; when considering generalization, specialization, or analogy as reduction strategies |
| polya-heuristic-vs-demonstrative-reasoning.md | When uncertain whether to proceed with a provisional approach; when distinguishing "I think this is right" from "I can prove this is right" |
| polya-decomposing-and-recombining.md | When a problem has multi-part structure; when you need to isolate which component is causing failure |
| polya-mobilization-organization-progress.md | When effort isn't converting to progress; when you need to distinguish between retrieving relevant knowledge and assembling it into a plan |
| polya-looking-back-and-knowledge-compounding.md | After solving any significant problem; when the goal is not just solution but learning that transfers |
| polya-expert-intuition-and-signs-of-progress.md | When navigating under uncertainty; when trying to assess whether a current approach is worth continuing |
The most common failures Polya warns against:
Understanding → Execution skip. Moving directly from problem statement to work without a plan. Produces correct-looking work that answers the wrong question. Test: can you state, in your own words, what the unknown is?
Drowning in the data. Fixating on what is given rather than what is sought. The data are only valuable insofar as they constrain or illuminate the unknown. Fix: always start from the unknown side, work backward toward the data.
Treating heuristic reasoning as shameful. Refusing to follow a plausible path because it isn't proved. This produces paralysis. Heuristic reasoning is not a fallback — it is the only tool available before the answer is known.
Confusing heuristic reasoning with proof. The opposite failure: taking a plausible guess as established. Always label provisional reasoning explicitly. Verify after executing, not before planning.
Skipping the Looking Back phase. Treating a solved problem as closed. This is where expertise compounds. Without it, you are always starting from scratch.
Attacking the hard problem directly and repeatedly. If direct attack hasn't worked three times, the structure of the problem is telling you something. Find an auxiliary problem instead of increasing effort on the same approach.
Waiting for the "bright idea." Inspiration is real, but it rewards organized preparation, not passive waiting. Mobilize relevant knowledge, organize it deliberately, and the bright idea becomes more likely — it is not random.
How to tell if someone has actually internalized Polya vs. merely read a summary:
They have internalized it if they:
They haven't internalized it if they:
This skill is the entry point. When a reference file is needed, load it explicitly. The reference files contain worked examples, extended reasoning, and deeper treatment of each concept.
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.