用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/curiositech/windags-skills --skill polya-problem-solving命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
Design and build beautiful, accessible graphical interfaces — web, desktop (Electron/Tauri), and native (iOS/macOS/Android). Use for visual hierarchy and layout, color and theming (light/dark, semantic tokens, WCAG contrast), typography systems, motion and micro-interactions, accessibility, component systems and design tokens, responsive/adaptive layout, and platform-native idioms. The GUI counterpart to beautiful-cli-design. NOT for terminal/CLI output (use beautiful-cli-design) or API/data schemas.
Capstone/orchestration skill — build an M-Agent + N-Human cooperative IDE in Rust gpui (the Harbor): many agents and humans co-editing the same files as co-equal CRDT replicas, governed by claims/guard/salvage, across LAN/shared/remote harbors. The INDEX that dispatches into the sibling rust skills. Use when building the collaborative editor, the agent-fleet console, multiplayer editing with agents-as-peers, or any slice of the Harbor. Trigger on: cooperative IDE, collaborative editor, multiplayer editor, agents and humans co-editing, gpui IDE, Loro CRDT editor, harbor editor, claims/salvage, "build the cooperative IDE". NOT for: a single non-collaborative gpui screen (compose the siblings directly), web editors, or non-editor apps.
Build and extend pd-console — Port Daddy's GPU-native macOS operator console (GPUI 0.2.x, Zed's Rust UI). Covers the render-agnostic Block/Pane(Surface) contract, the two-thread reqwest↔smol refresh pipeline, Taffy flexbox layout, uniform_list virtual scroll, focus + keyboard nav, the OKLCH theme and ICS maritime flag badges, GPUI's missing text-input, and the real feature-gated cargo/CI gate. Use when adding panes, visual polish, or debugging GPUI rendering/layout/focus in core/pd-console. NOT for the TypeScript daemon, generic Rust toolchain/borrow-checker help (use rust-with-claude-code), or non-pd GPUI apps with a different theme/architecture.
基于 SOC 职业分类
正在显示 SKILL.md
| license | Apache-2.0 |
| name | polya-problem-solving |
| description | Classic mathematical problem-solving methodology: understand, plan, execute, review |
| category | Cognitive Science & Decision Making |
| tags | ["problem-solving","heuristics","mathematics","methodology","strategy"] |
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.