mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-06-26 11:12:03 +00:00
d799284b15
The optional-skills copy was still the v1.0.0 constraint-dispatch skill (SKILL.md + full-prompt-library.md only). This brings it up to the current tool: a situation-routed library of 22 named ideation methods drawn from working artists, scientists, designers, and writers. SKILL.md becomes a 4-step router (extract PHASE/DOMAIN/SPECIFICITY signals → apply overrides → route phase-then-domain → resolve ambiguity), with anti-slop operating rules and an anti-default check. Adds: - 22 method files under references/methods/ — oblique-strategies (Eno/Schmidt), oulipo, scamper, lateral-provocations (de Bono), triz (Altshuller), leverage-points (Meadows), pattern-languages (Alexander), compression-progress (Schmidhuber), analogy-and-blending, pataphysics, first-principles, polya, biomimicry, volume-generation, creative-discipline, premortem-and-inversion, defamiliarization, derive-and-mapping, affinity-diagrams, jobs-to-be-done, story-skeletons, chance-and-remix. Each: when/when-not, the actual cards/principles/operators, a procedure, a worked example, anti-slop notes. - references/method-catalog.md (index + when-to-use), heuristics.md (extended decision tree), anti-slop.md (rules applied to every output), exercises.md (time-boxed exercises). - full-prompt-library.md restructured into domain-affinity sections (general / software / physical / social / lists) so the no-direction default isn't developer-biased. Frontmatter: name aligned to directory slug (creative-ideation, folding in the fix from #18084); version 2.0.0→2.1.0; platforms field preserved. Original wttdotm-derived constraint dispatch is kept as the default path. Supersedes #19295 (which targeted the pre-move skills/ path). Co-authored-by: SHL0MS <SHL0MS@users.noreply.github.com>
77 lines
3.5 KiB
Markdown
77 lines
3.5 KiB
Markdown
# Pólya's Heuristics
|
|
|
|
George Pólya, *How to Solve It* (Princeton UP, 1945). Four-phase problem-solving framework + dictionary of heuristic moves. Written for math but applies to any well-defined "find X such that..." problem.
|
|
|
|
## When to use
|
|
|
|
- Math, physics, theoretical problems
|
|
- Algorithm design, debugging
|
|
- Any problem with a clear target (find X such that...)
|
|
- Teaching problem-solving
|
|
|
|
## Don't use when
|
|
|
|
- Open-ended creative problems with no defined target
|
|
- Difficulty is *understanding the problem space*, not solving within it (use dérive or compression-progress first)
|
|
- Solution is more about taste than analysis
|
|
- Real-world problems where data is incomplete and conditions vague
|
|
|
|
## The four phases
|
|
|
|
### 1. Understand the problem
|
|
- What is the **unknown**?
|
|
- What are the **data**?
|
|
- What is the **condition** linking them?
|
|
- Is the condition sufficient? Insufficient? Redundant? Contradictory?
|
|
- State in your own words.
|
|
- Draw a figure. Introduce notation.
|
|
|
|
This phase is most often skipped. **Most problem-solving failures are upstream of method** — they're failures to understand the problem precisely.
|
|
|
|
### 2. Devise a plan
|
|
Find the connection between data and unknown. Heuristic moves:
|
|
- **Have you seen this problem before?** Or in slightly different form?
|
|
- **Do you know a related problem?**
|
|
- **Look at the unknown** — find a familiar problem with the same or similar unknown.
|
|
- **Could you use a related problem's result? Its method?**
|
|
- **Restate.**
|
|
- If you can't solve the proposed problem, solve a related one:
|
|
- More general
|
|
- More specific
|
|
- Analogous
|
|
- A part of the problem
|
|
- With a condition relaxed
|
|
- **Did you use all the data?** All the conditions?
|
|
|
|
### 3. Carry out the plan
|
|
- Can you see clearly that each step is correct?
|
|
- Can you prove it?
|
|
|
|
### 4. Look back
|
|
- Check the result. Check the argument.
|
|
- Can you derive it differently? See it at a glance?
|
|
- Can you use the result, or the method, for some other problem?
|
|
|
|
The looking-back phase is the *learning* phase — what makes Pólya's method an *educational* method, not just a problem-solving one.
|
|
|
|
## Key heuristics from the dictionary
|
|
|
|
- **Decompose and recombine.** Break into parts; solve each; combine.
|
|
- **Generalization.** The general case is sometimes easier than the specific because it forces you to identify essential structure.
|
|
- **Specialization.** Try the smallest case, the simplest case, the case where one parameter is zero. Look for pattern.
|
|
- **Analogy.** Find a related problem with same structure, different surface.
|
|
- **Auxiliary problem.** Solve a related problem first; use its result.
|
|
- **Working backwards.** Start from the unknown and work back. Forward direction often has too many branches; backward is more constrained.
|
|
- **Setting up an equation.** Most word-problem failure is in translation, not algebra.
|
|
- **Reductio ad absurdum.** Assume the conclusion is false; derive contradiction.
|
|
- **Pattern recognition.** Small cases → conjecture → prove.
|
|
- **Symmetry.** Where there's symmetry in the problem, there's usually symmetry in the solution.
|
|
|
|
## Anti-slop notes
|
|
|
|
- Reciting the four phases without doing them = slop. The structure is fine; the value is in actually executing each phase.
|
|
- Don't pretend you've understood when you haven't. State the unknown, the data, the condition concretely.
|
|
- Don't claim "Pólya'd it" without consulting specific heuristics.
|
|
- Don't apply to fuzzy problems. Pólya assumes clear problem statements.
|
|
|
|
Source: Pólya, *How to Solve It* (Princeton UP, 1945; current edition 2014).
|