mirror of https://github.com/NousResearch/hermes-agent.git synced 2026-06-25 11:02:03 +00:00

feat(optional-skills/creative-ideation): expand to v2.1.0 method library (#42402 )

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>

2026-06-19 15:40:02 -07:00

4.1 KiB

Raw Blame History

First Principles

Aristotle's protai archai. Decompose a problem to assumptions you trust, then rebuild without inheriting anything by default. Often paired with "5 Whys" excavation of why each assumption is in place.

When to use

A domain has accreted practice that may no longer be load-bearing
You're in an unfamiliar domain and bootstrapping understanding
You suspect the standard framing is wrong
Trying to reduce cost or complexity (accumulated overhead is often the main cost)
Teaching the domain (first-principles reconstruction surfaces what beginners actually need)

Don't use when

You don't know the domain well enough — first principles applied by an outsider produces confidently wrong answers
Transaction costs of replacement exceed the gains
Problem is irreducible (aesthetic, social, gestalt — decomposition destroys what makes it coherent)
You're trying to seem original — performance of first-principles thinking is slop

Procedure

State the problem precisely.
List assumptions in the conventional solution. What does the standard approach take for granted? List 5–10, including ones that "go without saying."
Categorize each:
- Physical — law of nature; can't be relaxed.
- Informational — logical / mathematical / information-theoretic; can't be relaxed without contradiction.
- Conventional — could be different; matters for compatibility.
- Historical — was necessary at some point; may not be now.
- Pedagogical — simplification used for teaching; may not be how experts actually do it.
For each non-physical / non-informational assumption: still load-bearing? Conventional and historical assumptions are where the gains live.
Rebuild. Construct a candidate respecting only physical and informational constraints, plus your specific context.
Apply Chesterton's fence. For each element you've removed, find the original reason it was added. If you can't find a reason, don't conclude there isn't one — assume you haven't looked hard enough.
Decide whether to switch. Even when the rebuild is technically better, consider transaction cost, ecosystem compatibility, team familiarity.

Worked example

Problem: typical CRUD web app — login, dashboard, few CRUD entities. Conventional stack: React + Node/Express + PostgreSQL + REST API + managed platform. ~12,000 LOC, monthly hosting ~$100.

Assumptions:

React: conventional, was historical (SPA promise ~2014), pedagogical (taught everywhere).
Backend separate from frontend: conventional; informational if multi-client, otherwise historical.
PostgreSQL: physical if concurrency/ACID required; otherwise conventional.
REST API between frontend and backend: was informational (network boundary), now historical for single-client apps.
Managed platform: conventional; was historical (datacenter complexity); pedagogical.

Context: 100 users, ~10 MB data, no real-time, single client (web), no HA constraint.

Rebuild:

Server-rendered HTML + small JS islands. (No SPA. No build pipeline. No API layer.)
SQLite single file. (No PG server. Backup = copy a file.)
Single small VM. (No managed platform. Deploy = rsync + systemctl restart.)
Single Go/Python/Ruby binary.

Result: ~1,500 LOC vs 12,000. ~$5/month vs $100. Tradeoffs: less impressive on resume, fewer contractors familiar with this style, no immediate path to 1M users.

Chesterton's fence: the conventional choices are load-bearing for some applications. The rebuild is correct only for this app's constraints. A different app — high concurrency, multiple clients, large data — needs different choices.

Anti-slop notes

The biggest slop is the performance of first-principles thinking. "I'm going to think from first principles" followed by a slightly-rearranged conventional answer is slop. Output should look measurably different.
Don't claim first principles when you're applying common sense.
Avoid the engineer-hero archetype. Real first principles often reveals what the field already knows.
Don't recommend removing structure you don't understand. Chesterton's fence applies hard.

4.1 KiB Raw Blame History Unescape Escape