mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-15 14:22:43 +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>
67 lines
4.6 KiB
Markdown
67 lines
4.6 KiB
Markdown
# Affinity Diagrams
|
||
|
||
Jiro Kawakita, *Hassōhō* (1967). The KJ method (Kawakita's initials, Japanese order). Bottom-up procedure for finding structure in qualitative items without imposing it beforehand.
|
||
|
||
## When to use
|
||
|
||
- After volume generation (100+ ideas from Crazy 8s or brainwriting need clusters)
|
||
- Qualitative research synthesis (interview transcripts, ethnographic notes, observations)
|
||
- Requirements gathering (pile of user requests / bug reports / suggestions)
|
||
- Sense-making after a workshop (whiteboard full of stickies)
|
||
- Bottom-up taxonomy when no good existing one fits
|
||
- Diagnosing what's missing — gaps between clusters often reveal what the data set lacks
|
||
|
||
## Don't use when
|
||
|
||
- Few items (under ~15 — overkill, hold them in mind instead)
|
||
- The right structure is already known (use deductive coding)
|
||
- Time pressure — done well takes hours
|
||
- Solo without enough cognitive distance from items (you'll produce the categories you'd have produced anyway)
|
||
- Highly quantitative data (use stats)
|
||
|
||
## Procedure
|
||
|
||
1. **Atomize items.** One observation per card. Items must be self-contained, specific, comparable in granularity.
|
||
2. **Make them physically separable.** Sticky notes; index cards; or a shared canvas (Miro/Mural/FigJam). Free movement matters; a list in a doc doesn't work.
|
||
3. **Spread out.** Distribute across a flat surface. No structure yet.
|
||
4. **Cluster silently.** Each participant moves items into proximity with similar ones. **Silently** — talking shapes group thinking, defeats bottom-up. If two participants disagree on placement, *duplicate the item* and let it appear in both.
|
||
5. **Continue until movement slows.**
|
||
6. **Name each cluster.** Specific names ("requests for offline functionality"), not generic ("technical issues"). Resist generic names.
|
||
7. **Look at orphans and gaps.**
|
||
- Orphans: items not fitting any cluster — often the most surprising data.
|
||
- Gaps: spaces between clusters — suggest categories the data lacks (questions like "why didn't anyone mention X?").
|
||
- Cluster sizes: very large = items not differentiated enough; very small = specialized concerns worth noting.
|
||
8. **Look for relationships between clusters.** Some depend on others. Some conflict.
|
||
9. **Narrative test (Kawakita).** Write a 1–2 paragraph narrative using the cluster names to tell a coherent story about the domain. If you can't, the clusters are misapprehension.
|
||
|
||
## Worked example
|
||
|
||
50-person team brainwrites about "what would make the codebase more maintainable" — 108 raw ideas.
|
||
|
||
After 45 minutes silent clustering:
|
||
|
||
- **Dependency hygiene** (~22 items)
|
||
- **Test coverage and CI speed** (~18)
|
||
- **Documentation drift** (~14)
|
||
- **Onboarding friction** (~12)
|
||
- **Implicit knowledge** ("only Sara knows how X works") (~10)
|
||
- **Tooling fragmentation** (~9)
|
||
- **Technical debt visibility** (~8)
|
||
- **Orphans** (~15 — scattered specific concerns)
|
||
|
||
**Gap**: noticeably absent — almost no items about *production reliability*, *security review*, or *cross-team API contracts*. The team's perception of "maintainability" is internal-developer-facing; user-facing reliability is not surfaced.
|
||
|
||
**Narrative**: "Maintainability concerns cluster around (1) dependencies, (2) tests, (3) docs-code drift, with secondary concerns around onboarding and implicit knowledge. The team experiences maintainability as a developer-experience problem rather than a reliability problem."
|
||
|
||
The diagram has produced a *map of perceived maintainability problems*. Decisions about which to address require additional inputs (impact, cost, owner). But the map shows what the team thinks the problem is — and the gap is itself useful.
|
||
|
||
## Anti-slop notes
|
||
|
||
- **Fast affinity grouping that produces familiar categories = deductive coding pretending to be inductive.** If the categories are the same as you'd have written before looking at the items, you've performed deductive coding.
|
||
- Don't generate fake observations to populate clusters.
|
||
- Avoid generic cluster names ("things to improve", "various concerns").
|
||
- Don't compress too aggressively. Real data has variable cluster sizes (5–25 typical); uniform sizes suggest forced grouping.
|
||
- Affinity diagrams are sense-making, not proof. Clusters represent *the researcher's perception* of items, not objective truth.
|
||
- For LLM-driven affinity grouping: models impose familiar taxonomies. After clustering, ask "what's the most surprising cluster?" If nothing surprising, redo or supplement with human eyes.
|
||
|
||
Source: Kawakita, *Hassōhō* (Chuko Shinsho, 1967, in Japanese). Mizuno (ed.), *Management for Quality Improvement: The Seven New QC Tools* (Productivity Press, 1988).
|