mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-06-25 11:02:03 +00:00
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>
78 lines
4.5 KiB
Markdown
78 lines
4.5 KiB
Markdown
# Pattern Languages
|
|
|
|
Christopher Alexander et al., *A Pattern Language* (1977). 253 patterns for designing buildings, towns, rooms — structured as a generative grammar with explicit cross-references. Spawned the Gang of Four software design patterns (1994) and many domain adaptations.
|
|
|
|
## Pattern format
|
|
|
|
A pattern has three parts:
|
|
1. **Context** — the situation in which it applies
|
|
2. **Problem** — a recurring tension in that context
|
|
3. **Solution** — a *generative* principle (not a specific design — capable of many instantiations)
|
|
|
|
A pattern *language* is a network of patterns at different scales, with explicit links: which patterns *contain* this one, which patterns *complete* it.
|
|
|
|
## When to use
|
|
|
|
- Designing physical environments (buildings, rooms, gardens, neighborhoods)
|
|
- Designing interactional environments (UX, software architecture)
|
|
- Building shared design vocabulary with a team
|
|
- Documenting design intuitions for transmission
|
|
- Civic / community design
|
|
|
|
## Don't use when
|
|
|
|
- You want to break with tradition (patterns are conservative — they encode what has worked)
|
|
- Domain has no established practice yet (no patterns to extract)
|
|
- Pure conceptual / artistic work
|
|
- You'd be implementing patterns literally (collapses generative → rule)
|
|
|
|
## Selected patterns from Alexander's 253
|
|
|
|
For texture. Real use means buying or borrowing the book.
|
|
|
|
- **8. Mosaic of Subcultures** — a region needs distinct subcultures with their own ecology, separated by zones of disuse, not homogenized.
|
|
- **53. Main Gateways** — mark every entrance with a substantial visible threshold.
|
|
- **60. Accessible Green** — green outdoor space within 3 minutes' walk.
|
|
- **105. South-Facing Outdoors** — most-used outdoor space to the south of the building.
|
|
- **111. Half-Hidden Garden** — garden right at street is too public; behind house is unused. Place it half-hidden.
|
|
- **159. Light on Two Sides of Every Room** — windows on at least two sides. Single-sided rooms are uncomfortable, rarely used.
|
|
- **179. Alcoves** — rooms with no place to retreat are unsettling. Build niches, bays, window seats.
|
|
- **188. Bed Alcove** — bed in the open is exposed. Build at least a partial enclosure.
|
|
- **191. Shape of Indoor Space** — simple, mostly orthogonal; deviate only for clear local reason.
|
|
- **230. Radiant Heat** — radiant heat (fireplace, radiator) is qualitatively different from forced air.
|
|
|
|
The patterns are arguably true and arguably false; what matters is the *form*.
|
|
|
|
## Procedure
|
|
|
|
### Using an existing language
|
|
1. Identify the relevant scale (region / neighborhood / building / room / detail).
|
|
2. Read patterns at and above your scale; note which apply.
|
|
3. Compose: apply higher-scale patterns first; let them constrain lower-scale ones.
|
|
4. Adapt to your specifics. Patterns are generative, not literal.
|
|
|
|
### Developing your own language (more useful for software, org, pedagogy)
|
|
1. Identify recurring problems in your domain. Look across many cases.
|
|
2. Name each (short, memorable, describes the *solution* shape — "Light on Two Sides", not "Insufficient Daylight").
|
|
3. State each in: context — problem — solution — therefore: [generative principle] — see also: [related patterns].
|
|
4. Map containment relations between patterns.
|
|
5. Test by applying to a fresh problem; revise.
|
|
|
|
## Worked example (software, in Alexander's form)
|
|
|
|
**Iterator pattern** (Gang of Four, 1994)
|
|
|
|
*Context*: a collection of objects must be traversable by client code.
|
|
*Problem*: client shouldn't need to know the internal structure (array vs tree vs linked list); collection shouldn't have traversal logic scattered across clients.
|
|
*Solution*: provide an Iterator object with `next()`, `hasNext()`, `current()` that encapsulates traversal state. Collection produces an Iterator on request.
|
|
*Therefore*: separate "what is being traversed" from "how it is traversed."
|
|
*See also*: Composite (tree traversal), Visitor (operations during traversal), Factory Method (producing the right Iterator).
|
|
|
|
## Anti-slop notes
|
|
|
|
- Bullet-list "design tips" are not patterns. A pattern has context, problem, generative solution, and place in a network.
|
|
- Don't generate patterns to seem comprehensive. Real patterns come from many cases.
|
|
- Don't apply Alexander's residential patterns to non-residential domains literally.
|
|
- Patterns are conservative *and* generative. They don't anti-novelty; they shape novelty.
|
|
|
|
Source: Alexander et al., *A Pattern Language* (Oxford UP, 1977); *The Timeless Way of Building* (Oxford UP, 1979). For software: Gamma et al., *Design Patterns* (Addison-Wesley, 1994).
|