rhachet-roles-ehmpathy 1.15.12 → 1.15.14

package/dist/roles/bhrain/.briefs/terms.motive.intent.goal.md

@@ -1,46 +0,0 @@
-🔥 [motive] — an internal pressure or desire
-.what = the underlying reason the actor wants anything at all
-
-.form = emotional, value-driven, often implicit
-
-.examples:
-[motive] = avoid failure
-[motive] = gain respect
-[motive] = feel in control
-
----
-
-🎯 [intent] — a chosen next action
-.what = a specific thing the actor plans to do next
-
-.form = short-term, actionable, verb-shaped
-
-.examples:
-[intent] = schedule a call
-[intent] = submit proposal
-[intent] = clean the garage
-
----
-
-🥅 [goal] — a desired future state
-.what = a future outcome the actor wants to reach
-
-.form = long-term, state-shaped, noun/condition
-
-.examples:
-[goal] = get more customers
-[goal] = have a clean house
-[goal] = win the bid
-
----
-
-🧠 mental model
-[motive] = source of pressure
-[goal] = destination
-[intent] = chosen step toward it
-
-- `[motive]` fuels the journey
-- `[goal]` gives it direction
-- `[intent]` initiates motion
-
-> every `[intent]` serves a `[goal]`, and every `[goal]` is backed by a `[motive]` — but these are not always visible on the surface.

package/dist/roles/bhrain/.briefs/thinker.tactics/<cluster>._.[article].frame.tactical._.md

@@ -1,85 +0,0 @@
-# 🧩 .brief: `thought process of <cluster>`
-
-## .what
-
-The `<cluster>` operation involves grouping related concepts, ideas, or data points into cohesive units based on shared characteristics or themes. This process leverages pattern recognition and categorization principles to enhance understanding, comparison, and analysis.
-
----
-
-## 🎯 purpose
-
-- to identify and form meaningful groups from disparate elements
-- to facilitate deeper insights through pattern recognition
-- to simplify complex information by breaking it into manageable parts
-
----
-
-## ⚙️ method
-
-1. **identify elements**
-   - gather concepts, ideas, or data points that need clustering
-   - ensure a diverse and representative sample
-
-2. **determine criteria**
-   - establish the basis for clustering (e.g., shared attributes, function, purpose)
-   - criteria should be clear and consistent across all elements
-
-3. **analyze and group**
-   - assess each element against the criteria
-   - form clusters based on the most significant matches or relationships
-
-4. **review and refine**
-   - evaluate clusters for clarity, coherence, and relevance
-   - adjust groupings as necessary for optimal structure
-
----
-
-## 🧠 cognitive basis
-
-Clustering relies on the brain's natural ability to recognize patterns and associations. It mimics cognitive processes involved in categorization, memory retrieval, and decision-making, thereby streamlining information processing and comprehension.
-
----
-
-## 📐 when to use
-
-- when dealing with large volumes of information that need organization
-- when exploring relationships between concepts for strategic insight or analysis
-- when preparing data for presentation, highlighting key themes or trends
-
----
-
-## 🔁 dynamic behavior
-
-Clustering is often iterative, with repeated cycles of grouping, reviewing, and refining. This helps to accommodate new information or evolving understanding, ensuring clusters remain relevant and actionable.
-
----
-
-## ⚠️ caution: over-clustering
-
-Avoid creating too many clusters or overly complex structures, which can obscure rather than clarify. Clusters should strike a balance between granularity and cohesion.
-
----
-
-## 🧰 use it for:
-
-- data analysis and research
-- strategic planning and brainstorming
-- knowledge management and taxonomy development
-
----
-
-## 📊 examples
-
-1. **Market Segmentation**
-   - Grouping customers based on demographic, geographic, or behavioral characteristics to tailor marketing strategies.
-
-2. **Academic Research**
-   - Clustering academic papers or references by themes or topics to identify research gaps or emerging trends.
-
-3. **Product Categorization**
-   - Organizing products into categories like electronics, clothing, and home appliances to enhance user navigation in online stores.
-
-4. **Strategic Brainstorming**
-   - Grouping ideas from brainstorming sessions into actionable categories such as short-term tactics, long-term strategies, and innovative solutions.
-
----

package/dist/roles/bhrain/.briefs/thinker.tactics/<cluster>.vs_<diverge>.duality.[article].md

@@ -1,43 +0,0 @@
-# 🧩 .brief: `<diverge> ↔ <cluster>`
-
-## .what
-the **duality** between `<diverge>` and `<cluster>` describes a **complementary motion of thought**:
-- `<diverge>` expands a concept outward into **maximum variance instances**
-- `<cluster>` contracts many instances inward into **coherent groupings**
-
-together they form a **push–pull dynamic** of exploration and organization.
-
----
-
-## 🎯 purpose
-- balance **creativity and clarity**: generate wide variety, then refine into structure
-- ensure **coverage and coherence**: divergence prevents blind spots, clustering prevents overload
-- support **iterative cycles of insight**: each informs and strengthens the other
-
----
-
-## ⚙️ motion
-1. **<diverge>**
-   - spread focus to surface **differences, alternatives, and variations**
-   - motion is centrifugal — outward, increasing breadth
-
-2. **<cluster>**
-   - compress focus to reveal **patterns, affinities, and themes**
-   - motion is centripetal — inward, increasing coherence
-
----
-
-## 🔄 interplay
-- divergence without clustering → noise, endless fragments, lack of synthesis
-- clustering without divergence → rigidity, premature convergence, missed options
-- **dual-cycle**:
-  1. diverge to gather possibilities
-  2. cluster to extract structure
-  3. repeat as needed, each cycle sharper
-
----
-
-## 📐 metaphor
-- `<diverge>` = scattering seeds across a field
-- `<cluster>` = harvesting them into sheaves
-- the **crop of thought** emerges only through both motions in rhythm

package/dist/roles/bhrain/.briefs/thinker.tactics/<diverge>._.[article].frame.cognitive.[seed].md

@@ -1,4 +0,0 @@
-<diverge> is an extreme example of <vary>
-
-see cognition briefs for reference
-

package/dist/roles/bhrain/.briefs/thinker.tactics/<diverge>._.[article].frame.tactical.md

@@ -1,89 +0,0 @@
-# 🧩 .brief: `diverge.refs`
-
-## .what
-**`diverge.refs`** is a **generation tactic** that creates multiple distinct `[concept][ref]` (reference) forms from a single seed question.
-instead of locking into one framing, it **branches** the expression into alternative answer-forms — each still anchored to the intent of the original question.
-
----
-
-## 🎯 goal
-- explore **variety in expression** while retaining core meaning
-- surface **different entry points** for the same underlying concept
-- identify **strongest, most resonant refs** for specific audiences or purposes
-
----
-
-## 📜 contract
-for `<diverge.refs>` to work as intended:
-
-input = [seed][question]
-  - **only questions** — the `[seed][ref]` **must** be phrased as a question that clearly guides what to diverge into.
-  - **no statements** — statement seeds are disallowed, as they create uncertainty about whether outputs should be synonyms, examples, or subtopics.
-
-output = [concept][ref]
-  - **only answers** — each divergence **must** be an **alternative answer reference** to the seed question.
-
-**why this contract exists:**
-- questions naturally define a **search space of possible answers**, capable of precise generation guidance
-- answers can be compared for **completeness and variety** relative to the same inquiry
-- keeps outputs consistently interpretable as **answer-forms** to the same guiding question
-
----
-
-## ⚙️ method
-1. **anchor to the seed question**
-   - start from a single clear question (seed `[ref]`)
-   - clarify the essential meaning to preserve across all divergences
-
-2. **generate branches**
-   - vary along one or more axes relevant to the goal
-   - ensure each `[ref]` is **meaningfully different**, not just cosmetic rewording
-
-3. **assess & refine**
-   - check for clarity, accuracy, and audience fit
-   - prune weak or redundant variations
-
----
-
-## 📐 when to use
-- when testing **messaging resonance**
-- when creating **menus of choices** or **navigation labels**
-- when brainstorming **campaign slogans, feature names, or thematic headers**
-
----
-
-## 🖼 examples
-
-### example 1
-
-**seed `[ref]`:** "what makes historic train travel memorable?"
-
-- "luxury journeys aboard restored locomotives"
-- "guided scenic tours through mountain passes"
-- "onboard dining with period-accurate menus"
-- "storytelling from railway historians"
-- "overnight sleeper cars with vintage charm"
-
----
-
-### example 2
-
-**seed `[ref]`:** "how can cooks work smarter in the kitchen?"
-
-- "by prepping ingredients in bulk ahead of time"
-- "by keeping knives sharpened for faster cutting"
-- "by labeling and dating all stored food"
-- "by cleaning as they go to save time"
-- "by organizing stations for smoother workflow"
-
----
-
-### example 3
-
-**seed `[ref]`:** "what are different types of ducks?"
-
-- "mallard"
-- "wood duck"
-- "northern pintail"
-- "muscovy duck"
-- "american black duck"

package/dist/roles/bhrain/.briefs/thinker.tactics/<elaborate>_vs_<elucidate>.[seed].md

@@ -1 +0,0 @@
-To elucidate is to make something clear and easy to understand, essentially to shed light on it, while to elaborate is to provide more details, information, or examples to expand upon a topic or idea. The choice depends on whether the goal is to clarify a concept or to provide greater depth and breadth of information about it.

package/dist/roles/bhrain/.briefs/thinker.tactics/<enquestion>._.[article].md

@@ -1,113 +0,0 @@
-# ❓ .brief: `<enquestion>`
-
-## 🧭 .what
-**`<enquestion>`** is a **structural traversal mechanism** that **leverages the `<ponder>` framework**
-to generate the **questions needed to advance toward a goal**.
-
-It consumes:
-- **`ponder`** — curated or pre-authored questions organized into `<contextualize>` and `<conceptualize>` subgoals (per the `<ponder>` contract)
-- **`focus`** — the current state of questioning (`focus.concept`) and the situational frame (`focus.context`)
-
-It produces:
-1. An **enriched `ponder`** with context-aware insights for each seed question.
-2. A **`produce.questions`** set — the refined, ready-to-ask questions that bridge context to goal.
-
-Because `<enquestion>` itself **uses `<ponder>`** internally:
-- It can be **chained with downstream `<ponder>` calls** — producing questions that feed into subsequent pondering stages.
-- It can **loop with itself** — where the output `produce.questions` becomes the new `focus.concept`, allowing iterative deepening of inquiry.
-
----
-
-## 🔗 relationship to `focus.sufficiency`
-In `focus.sufficiency`, most failures come from:
-1. **Context gap** → missing something in `focus.context`
-2. **Concept gap** → missing something in `focus.concept`
-
-`<enquestion>` helps overcome both failure modes by:
-- Using `<ponder>`’s `<contextualize>` to fill gaps in `focus.context`.
-- Using `<ponder>`’s `<conceptualize>` to shift or refine the `focus.concept` anchor.
-
----
-
-## 🧠 input / output contract
-
-### 📥 input
-\`\`\`ts
-type PonderQuestions = {
-  contextualize: string[],
-  conceptualize: string[]
-}
-
-type EnquestionInput = {
-  ponder: PonderQuestions,
-  focus: {
-    concept: Maybe<PonderQuestions>, // enquestion upserts ponder questions
-    context: {
-      goal: string,            // required for ponder
-      ...other context facts   // optional, domain-specific
-    }
-  }
-}
-\`\`\`
-- `ponder` = question seeds from `<ponder>`, structured by subgoal.
-- `focus.concept` = the *current state* of questioning.
-- `focus.context` = the situation, **must** include `.goal`.
-
----
-
-### 📤 output
-\`\`\`ts
-type PonderAnswers = {
-  contextualize: Record<string, string>,
-  conceptualize: Record<string, string>
-}
-
-type EnquestionOutput = {
-  ponder: PonderAnswers,
-  produce: {
-    questions: PonderQuestions
-  }
-}
-\`\`\`
-- Output `ponder` enriches the seeds with contextual rationale.
-- Output `produce.questions` contains the **final, ready-to-use** question set.
-- These `produce.questions` can be used as **input to downstream `<ponder>` calls** or to the **next `<enquestion>` iteration**.
-
----
-
-## 🌿 exploration of the question treestruct fabric
-Questions inhabit a **semantic treestruct** — a branching space defined by:
-- **Axes** (categorical, temporal, causal, etc.)
-- **Depth** (abstraction vs. instantiation)
-- **Breadth** (variation in attribute or structure)
-- **Acuity** (articulation or decomposition)
-
-`<enquestion>` explores this fabric to:
-- Identify **possible branches** from `<ponder>`’s seeds.
-- Expand or condense branches based on goal utility.
-- Map **follow-up pathways** so inquiry flows logically.
-
----
-
-## 📦 system pattern
-\`\`\`ts
-<enquestion>.with({ contextualize, conceptualize })({
-  ponder,
-  focus
-})
-→ { ponder: {...}, produce: { questions: {...} } }
-\`\`\`
-
----
-
-## 💡 runtime / devtime reflection
-- **Runtime**: dynamically adapt questions as focus/context changes.
-- **Devtime**: tune `<ponder>` question seeds for domain-specific flows.
-
----
-
-## 📎 notes
-- `<enquestion>` is a **consumer** of `<ponder>`; it applies `<ponder>`’s `<contextualize>` and `<conceptualize>` subgoals to generate, adapt, and arrange questions into a goal-driven sequence.
-- **Downstream use**: The resulting `produce.questions` can directly seed new `<ponder>` calls for further semantic refinement.
-- **Looping**: Since it uses `<ponder>`, `<enquestion>` can call itself iteratively, deepening or broadening inquiry as needed.
-- Treats inquiry as **navigating the question treestruct fabric**, not generating in isolation.

package/dist/roles/bhrain/.briefs/thinker.tactics/<enquestion>._.[gallery].plumber.diagnose.md

@@ -1,130 +0,0 @@
----
-
-## 🛠️ example — <enquestion> a devtime PonderQuestions kit for `@[plumber]<diagnose>` → runtime reuse
-
-**intent**
-Produce a **general-purpose devtime `PonderQuestions` kit** for `<diagnose>` in plumbing.
-At **runtime**, any plumber plugs in case-specific facts and **reuses the same kit** to save time and keep diagnosis consistent.
-
----
-
-### 📥 devtime input to `<enquestion>`
-\`\`\`ts
-ponder: {
-  contextualize: [
-    // meta-questions whose answers generate case-ready questions
-    "which observable conditions would *spawn* follow-up diagnostics?",
-    "which environment factors would *change* the diagnostic path?",
-    "which usage/repair history would *influence* failure likelihood?"
-  ],
-  conceptualize: [
-    "which subsystems, treated as suspects, *generate* distinct tests?",
-    "which minimal discriminators best *split* root causes early?",
-    "which symptom patterns should *trigger* immediate checks?"
-  ]
-},
-focus: {
-  concept: null,
-  context: { goal: "design a reusable diagnosis question set for plumbing" }
-}
-\`\`\`
-
----
-
-### 📤 devtime output from `<enquestion>` (the reusable kit)
-\`\`\`ts
-{
-  ponder: {
-    contextualize: {
-      "which observable conditions would *spawn* follow-up diagnostics?":
-        "visible moisture points, pooling patterns, pressure/flow anomalies",
-      "which environment factors would *change* the diagnostic path?":
-        "freezing temps, recent renovations, water quality/pressure changes",
-      "which usage/repair history would *influence* failure likelihood?":
-        "installation age, prior repairs, high-demand cycles"
-    },
-    conceptualize: {
-      "which subsystems, treated as suspects, *generate* distinct tests?":
-        "supply (hot/cold), fixture assemblies, drainage (trap/joints), venting, appliances (DW/disposal/heater)",
-      "which minimal discriminators best *split* root causes early?":
-        "static (pressurized, no-flow) vs dynamic (flow/drain) behavior; local vs distributed wetness",
-      "which symptom patterns should *trigger* immediate checks?":
-        "base gasket wet after run, trap joint first-wet on dump, hammering after valve close"
-    }
-  },
-
-  produce: {
-    questions: {
-      contextualize: [
-        "where is first-wet observed (fitting, hose, base, joint)?",
-        "does moisture appear with supply pressurized but all fixtures OFF?",
-        "does moisture appear only with faucet ON and no drain flow?",
-        "does moisture appear only during/after a full-basin drain?",
-        "have fixtures or appliances been installed/repaired recently?",
-        "are there freeze events, renovations, or pressure changes on site?"
-      ],
-      conceptualize: [
-        "if static leak: which pressurized components are in range (stop valves, lines, connectors)?",
-        "if dynamic/no-drain leak: which fixture seals or bodies are suspect?",
-        "if drain-only leak: which trap/compression joints or tees are first-wet?",
-        "does the pattern map to supply, fixture body, drain, vent, or appliance branch?",
-        "what single test will most decisively split supply vs drain?",
-        "which repair path corresponds to each confirmed source?"
-      ]
-    }
-  }
-}
-\`\`\`
-
-> This **devtime kit** is authored once and becomes the standard **starting point** for any plumbing diagnosis.
-
----
-
-### 🧩 runtime reuse — plugging in case specifics
-
-**scenario**
-Customer reports water pooling under a kitchen sink after use.
-
-**runtime inputs**
-- The plumber keeps the **devtime kit** unchanged.
-- They add **case facts** via `focus.context` and use the kit’s `produce.questions` as the runbook.
-
-\`\`\`ts
-focus: {
-  concept: null, // or last run's questions if continuing
-  context: {
-    goal: "identify leak source and repair steps",
-    symptoms: "pooling under sink after faucet use",
-    recent_changes: "faucet replaced last month",
-    environment: "unheated exterior wall; freeze last week"
-  }
-}
-\`\`\`
-
-**runtime application**
-- Ask the kit’s **contextualize** set (now grounded by the case):
-  - "where is first-wet observed?" → *bottom of faucet base*
-  - "static or dynamic?" → *only when faucet ON; not on pressurized idle*
-  - "drain-only?" → *no, dry on full-basin dump; wet only with ON/no-drain*
-  - "recent changes?" → *new faucet last month*
-
-- Use answers to pick **conceptualize** branches:
-  - Pattern maps to **fixture body/base** (not supply idle; not drain dump).
-  - **Decisive test**: run 30s ON with no drain, inspect base and supply nut.
-  - If base wets first → **replace/seat base gasket**; if supply nut wets → **re-crimp/replace line**.
-
-**runtime result**
-- Source isolated: **faucet base gasket**.
-- **Repair path** chosen from the kit’s mapping: reseat/replace gasket; retest static/dynamic.
-
----
-
-### 🔁 why this split (devtime → runtime) is valuable
-
-- **Consistency at scale**: every technician starts with the same high-leverage questions, reducing misses.
-- **Speed**: devtime questions are already optimized to **produce** decision-making questions; no ad-hoc thinking at the curb.
-- **Coverage**: the kit bakes in static vs dynamic splits, first-wet logic, and subsystem mapping.
-- **Composability**: outputs from one run can become `focus.concept` for a second `<enquestion>` pass (deeper probing).
-- **Maintainability**: improve the kit once at devtime; all future diagnoses benefit automatically.
-
----

package/dist/roles/bhrain/.briefs/thinker.tactics/<enquestion>._.[gallery].thinker.enquestion.md

@@ -1,125 +0,0 @@
----
-
-## 🎯 example — `<enquestion>` devtime PonderQuestions kit for `<envision>` a `[product][journey]` → runtime reuse
-
-**intent**
-Produce a **general-purpose devtime `PonderQuestions` kit** for `<envision>` a `[product][journey]`.
-At **runtime**, a product strategist, designer, or founder can plug in case-specific facts about the product and its audience, reusing this kit for **every journey-mapping session** to ensure nothing critical is overlooked.
-
----
-
-### 📥 devtime input to `<enquestion>`
-\`\`\`ts
-ponder: {
-  contextualize: [
-    "which key stages should *spawn* exploration of user touchpoints?",
-    "which external constraints or dependencies might *alter* the journey flow?",
-    "which success/failure signals at each stage would *generate* follow-up mapping?"
-  ],
-  conceptualize: [
-    "which types of users or segments should *spawn* separate journey branches?",
-    "which journey paths should be *visualized* first for greatest clarity?",
-    "which cross-stage patterns should be *highlighted* to reveal bottlenecks or accelerators?"
-  ]
-},
-focus: {
-  concept: null,
-  context: { goal: "design a reusable envision question set for mapping a product journey" }
-}
-\`\`\`
-
----
-
-### 📤 devtime output from `<enquestion>` (the reusable kit)
-\`\`\`ts
-{
-  ponder: {
-    contextualize: {
-      "which key stages should *spawn* exploration of user touchpoints?":
-        "awareness, consideration, onboarding, active use, support, retention/loyalty, advocacy",
-      "which external constraints or dependencies might *alter* the journey flow?":
-        "regulatory steps, technical onboarding limits, seasonal buying cycles, external integrations",
-      "which success/failure signals at each stage would *generate* follow-up mapping?":
-        "conversion rates, drop-off points, repeat engagement, feature adoption patterns"
-    },
-    conceptualize: {
-      "which types of users or segments should *spawn* separate journey branches?":
-        "new vs returning, free vs paid, novice vs expert, B2B vs B2C",
-      "which journey paths should be *visualized* first for greatest clarity?":
-        "most common conversion flow, highest revenue flow, most problematic drop-off flow",
-      "which cross-stage patterns should be *highlighted* to reveal bottlenecks or accelerators?":
-        "time-to-first-value, handoff delays between teams, repeated support touchpoints"
-    }
-  },
-
-  produce: {
-    questions: {
-      contextualize: [
-        "what is the first trigger or awareness moment for the target user?",
-        "what touchpoints exist at awareness, consideration, onboarding, active use, and retention?",
-        "what constraints or dependencies shape each stage?",
-        "what measurable outcomes indicate success or failure at each stage?",
-        "where do handoffs occur and what risks exist there?"
-      ],
-      conceptualize: [
-        "which user segments require separate mapping due to differing behaviors?",
-        "which journey flow should be visualized first to clarify the main path?",
-        "what alternative or edge-case flows must also be mapped?",
-        "what repeating patterns across stages suggest systemic strengths or weaknesses?",
-        "which single improvement could shorten time-to-first-value?",
-        "what flow variations could be tested for performance impact?"
-      ]
-    }
-  }
-}
-\`\`\`
-
----
-
-### 🧩 runtime reuse — plugging in case specifics
-
-**scenario**
-A SaaS startup is mapping the journey for their **new AI-driven analytics platform**.
-
-**runtime inputs**
-- The **devtime kit** stays the same.
-- Case-specific facts are added to `focus.context`:
-\`\`\`ts
-focus: {
-  concept: null,
-  context: {
-    goal: "map product journey for AI analytics SaaS",
-    target_segments: ["SMB owners", "mid-level data analysts"],
-    launch_region: "North America",
-    constraint: "initial onboarding must complete within 15 minutes",
-    success_metric: "conversion to paid within 14 days"
-  }
-}
-\`\`\`
-
-**runtime application**
-- **Contextualize** questions adapted to case:
-  - First awareness moment? → *LinkedIn ad or industry blog review*.
-  - Stage touchpoints? → *ad → landing page → signup → guided setup → dashboard insights*.
-  - Constraints? → *must integrate with Google Sheets in setup*.
-  - Stage success signals? → *dashboard accessed 3+ times in week 1*.
-
-- **Conceptualize** questions to frame mapping:
-  - Segment split? → *separate flows for SMB owners vs analysts*.
-  - Visualize first? → *SMB owner’s full journey to paid plan*.
-  - Cross-stage bottlenecks? → *handoff from setup to first insights*.
-
-**runtime result**
-- Journey map drafted with two parallel flows.
-- Bottleneck identified: **delay in generating first insights**.
-- Next iteration: add onboarding tweak to surface sample insights instantly.
-
----
-
-### 🔁 why this split (devtime → runtime) is valuable
-- **Framework stability**: devtime kit ensures every journey map starts with full stage coverage.
-- **Efficiency**: runtime mapping skips reinvention, focuses on populating specifics.
-- **Comparability**: journeys across products share the same backbone, making patterns visible.
-- **Scalability**: improvements to the kit (e.g., adding “advocacy” stage) propagate to all future mappings.
-
----

package/dist/roles/bhrain/.briefs/thinker.tactics/<enquestion>.tactic.perspectives.[article].md

@@ -1,36 +0,0 @@
-# `<enquestion>.tactic.perspectives` — parallel multi-perspective question generation
-
-*generate, curate, and catalog diverse questions from many perspectives in parallel.*
-
-**purpose**
-generate the richest, most diverse, and well-structured set of questions possible by leveraging parallelized, high-variance thinking across multiple perspectives.
-
----
-
-## steps
-
-1. **run `<enquestion>` repeatedly**
-   - **parallel:** execute many `<enquestion>` calls simultaneously
-   - **high temperature:** encourage creative divergence by increasing variability
-   - **multi-perspective:** supply each run with different [context] or [role] to surface unique angles
-
-2. **`<curate>` → produce a `[gallery]` of questions**
-   - `<collect>` all raw questions from every run
-   - `<cluster>` by thematic or semantic similarity
-   - `<triage>` to remove duplicates, irrelevancies, and low-value items
-
-3. **`<catalogize>` → produce a `[catalog]` of questions**
-   - organize final questions into a structured, reusable index
-   - annotate with tags, difficulty, scope, or intended audience
-
----
-
-## outcome
-a `[catalog]` containing the best, most contextually diverse set of questions — **curated from many perspectives** and ready for structured use.
-
----
-
-## example syntax
-\`\`\`
-<enquestion>.with(perspectives) -> [catalog]
-\`\`\`