mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-07 13:02:07 +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>
63 lines
4.1 KiB
Markdown
63 lines
4.1 KiB
Markdown
# 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
|
||
|
||
1. **State the problem precisely.**
|
||
2. **List assumptions in the conventional solution.** What does the standard approach take for granted? List 5–10, including ones that "go without saying."
|
||
3. **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.
|
||
4. **For each non-physical / non-informational assumption:** still load-bearing? Conventional and historical assumptions are where the gains live.
|
||
5. **Rebuild.** Construct a candidate respecting only physical and informational constraints, plus your specific context.
|
||
6. **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.
|
||
7. **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.
|