@rse/ase 0.0.59 → 0.0.61

package/plugin/skills/ase-meta-brainstorm/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: ase-meta-brainstorm
+argument-hint: "[--help|-h] <topic>"
+description: >
+    Collaboratively brainstorm a topic by diverging on ideas, converging
+    through clustering and scoring, and distilling a shortlist with
+    a recommended direction. Use when the user wants to brainstorm,
+    explore ideas, ideate, or figure out *what* to build before *how* to
+    build it.
+user-invocable: true
+disable-model-invocation: false
+effort: high
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
+
+<skill name="ase-meta-brainstorm">
+Collaboratively Brainstorm a Topic
+</skill>
+
+<objective>
+Collaboratively brainstorm the topic <topic>$ARGUMENTS</topic> by first
+*diverging* into a broad space of candidate ideas, then *converging*
+through clustering and scoring, and finally distilling a *shortlist*
+with a single recommended direction.
+</objective>
+
+Guiding Tenets
+--------------
+
+Honor the following tenets throughout the brainstorming:
+
+-   **No Assumption of Simplicity**:
+    Every topic goes through the full process — a one-line config
+    change as much as a new subsystem — because the simplest-looking
+    topics often hide the most harmful assumptions.
+
+-   **Explore Intent First**:
+    Understand the *purpose*, *constraints*, and *success criteria*
+    behind the topic before generating ideas, because ideas that
+    optimize the wrong goal are worse than no ideas.
+
+-   **Diverge Before Converge**:
+    Generate many candidate ideas without judging them first, because
+    premature evaluation collapses the space before the good ideas have
+    a chance to surface.
+
+-   **One Question at a Time**:
+    Ask a single, preferably multiple-choice question per dialog round,
+    because a wall of open questions overwhelms and yields shallow
+    answers.
+
+-   **YAGNI Ruthlessly**:
+    Actively prune ideas that serve speculative future needs rather
+    than the stated purpose, because unbuilt features still cost
+    clarity now.
+
+-   **Ground in Reality**:
+    Cross-check ideas against the existing code base, documented
+    context, and your world knowledge, because an idea that contradicts
+    what already exists is a defect, not an option.
+
+-   **Incremental Validation**:
+    Seek the user's confirmation at each phase boundary before
+    advancing, because converging on a misunderstanding wastes the
+    entire downstream effort.
+
+<flow>
+
+1.  <step id="STEP 1: Restate Topic">
+
+    Restate the topic to be brainstormed by output the following <template/>:
+
+    <template>
+    <ase-tpl-bullet-secondary/> **TOPIC**: <topic/>
+    </template>
+
+    </step>
+
+2.  <step id="STEP 2: Clarify Intent">
+
+    Before generating any ideas, *explore the project context* (review
+    relevant existing files, documentation, and recent changes) and
+    determine the <m/> *essential unknowns* about the topic — the
+    purpose, constraints, scope boundaries, and success criteria that
+    must be pinned down for the brainstorming to be reasonably grounded.
+
+    For each essential unknown, derive a short 1-3 word facet <facet-M/>
+    and a corresponding question <question-M/> whose answer materially
+    changes which ideas make sense at all.
+
+    1.  For each <question-M/> in the iteration cycle <M/> (<M/>=1...<m/>):
+
+        1.  Output the following <template/>:
+
+            <template>
+            <ase-tpl-bullet-signal/> FACET <M/>/<m/>: **<facet-M/>**, QUESTION: **<question-M/>**
+            </template>
+
+        2.  Determine *up to 4* grounded candidate answers
+            <answer-M-K/> (K={1,2,3,4}) from the code base, the documented
+            context, and your world knowledge.
+
+        3.  Use an interactive user dialog with header <facet-M/> and
+            question <question-M/>, and let the user select the
+            <answer-M/> out of the candidate answers <answer-M-K/> (just
+            leave out all answers in case you have determined less than
+            4 potential answers)
+
+            <expand name="user-dialog">
+                <facet-M/>: <question-M/>
+                <answer-M-1/>: (first grounded candidate answer)
+                <answer-M-2/>: (second grounded candidate answer)
+                <answer-M-3/>: (third grounded candidate answer)
+                <answer-M-4/>: (forth grounded candidate answer)
+            </expand>
+
+        4.  Output the following <template/>:
+
+            <template>
+            <ase-tpl-bullet-normal/> FACET <M/>/<m/>: **<facet-M/>**, ANSWER: **<answer-M/>**
+            </template>
+
+    2.  If at any point <result/> is `CANCEL`:
+        Only output the following <template/> and then immediately *STOP*
+        processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ✪ skill: **ase-meta-brainstorm**, ▶ status: **brainstorm cancelled**
+        </template>
+
+    </step>
+
+3.  <step id="STEP 3: Diverge Idea Space">
+
+    Generate a *broad* space of candidate ideas that address the
+    <topic/> within the constraints established by the answers
+    <answer-M/>.
+
+    Deliberately pursue *diverse angles* — e.g. the minimal/MVP-first
+    angle, the robustness/risk-first angle, the user-experience-first
+    angle, the reuse-existing-machinery angle, the coolness angle, and
+    the unconventional/wildcard angle — because variety in origin yields
+    variety in outcome.
+
+    Do still *not* judge, rank, or prune ideas in this step. Generate
+    ideas until you either reach at least 12 distinct candidate ideas or
+    have clearly exhausted the meaningfully distinct space.
+
+    Store each candidate idea in <idea-N/> with the format
+    `**<idea-name-N/>**: <idea-statement-N/>` (where <idea-name-N/> is a
+    short 1-4 word summary and <idea-statement-N/> is a single-sentence
+    statement of not more than 40 words), and output the following
+    <template/>:
+
+    <template>
+    <ase-tpl-bullet-normal/> **IDEA <N/>**: <idea-N/>
+    </template>
+
+    </step>
+
+4.  <step id="STEP 4: Converge Idea Space">
+
+    Converge the candidate ideas <idea-N/> into a smaller, structured
+    sets and finally into a recommendation.
+
+    1.  *Cluster*: group the candidate ideas into <c/> coherent clusters
+        <cluster-C/> (a short 1-4 word label, C=1...</c>), collapsing
+        near-duplicates and discarding ideas pruned by *You Aren't Gonna
+        Need It (YAGNI)* (speculative, out-of-scope, or contradicting
+        documented context).
+
+        For each cluster and its contained retained ideas, output the
+        following <template/> (<cluster-summary-C/> is a single-sentence
+        statement of not more than 40 words):
+
+        <template>
+        <ase-tpl-bullet-secondary/> **IDEA CLUSTER <C/>/<c/>**: <cluster-C/> — <cluster-summary-C/>,
+        **IDEAS**: <N/>, <M/>[, ...]
+        </template>
+
+    2.  *Score*: for each retained idea <idea-N/> in the clusters, rank its *fit* against the
+        purpose and constraints on a Likert scale of 0 (poor) to 10
+        (excellent), considering *value*, *uniqueness*, *risk*, and
+        *alignment with the existing code base*. Keep only ideas in the
+        clusters with a rank of at least 7.
+
+    3.  From the scored ideas <idea-N/>, distill a *shortlist* of the top
+        3-4 options, sorted by rank from highest to lowest.
+
+        For this, draw the shortlist from *distinct* clusters <cluster-C/>
+        wherever possible — prefer a diverse shortlist spanning different
+        clusters over several high-ranked variations of the same cluster,
+        unless one cluster clearly dominates on rank.
+
+        Store each distilled option in <option-N/> with the format
+        `**<option-name-N/>** (rank: <option-rank-N/>/10, cluster:
+        <option-cluster-N/>): <option-statement-N/>` (where the statement is
+        a single sentence of not more than 40 words capturing the direction
+        and its primary trade-off), and output the following <template/>:
+
+        <template>
+        <ase-tpl-bullet-normal/> **DISTILLED IDEA <N/>**: <option-N/>
+        </template>
+
+    4.  Finally, derive a single *recommended idea* — the highest-ranked
+        option, or a principled synthesis of the option shortlist that preserves
+        what is strongest in each — store its one-sentence rationale (not
+        more than 40 words) in <recommendation/>, and output the following
+        <template/>:
+
+        <template>
+        <ase-tpl-bullet-signal/> **RECOMMENDED IDEA**: <recommendation/>
+        </template>
+
+    </step>
+
+</flow>

package/plugin/skills/ase-meta-brainstorm/help.md

@@ -0,0 +1,51 @@
+
+##  NAME
+
+`ase-meta-brainstorm` - Collaboratively Brainstorm a Topic
+
+##  SYNOPSIS
+
+`ase-meta-brainstorm`
+    [`--help`|`-h`]
+    *topic*
+
+##  DESCRIPTION
+
+The `ase-meta-brainstorm` skill guides a collaborative ideation
+session on a *topic* *before* any implementation begins. It first
+*clarifies intent* by exploring the project context and interviewing
+the user — one grounded, multiple-choice question at a time — about
+purpose, constraints, scope, and success criteria. It then *diverges*
+into a broad space of candidate ideas pursued from deliberately diverse
+angles (MVP-first, risk-first, UX-first, reuse-first, and wildcard),
+without judging them.
+
+Next it *converges* by clustering the ideas into coherent themes,
+pruning speculative or out-of-scope ones via *YAGNI*, and scoring the
+survivors on a 0-10 fit scale (keeping only those ranked 7 or higher).
+Finally it distills a *shortlist* of the top 3-4 directions — drawn from
+distinct clusters wherever possible — and derives a single
+*RECOMMENDATION*, being either the highest-ranked option or a principled
+synthesis of the shortlist.
+
+On completion the skill offers a *next step*: stop, or hand the
+recommended direction off to the `ase-task-edit`, `ase-code-craft`, or
+`ase-task-preflight` skills.
+
+##  ARGUMENTS
+
+*topic*:
+    The subject to brainstorm — a feature, component, behavior, or
+    design question to explore *what* to build before *how*.
+
+##  EXAMPLES
+
+Brainstorm an approach for a new feature:
+
+```text
+❯ /ase-meta-brainstorm an offline-first sync layer for the mobile app
+```
+
+##  SEE ALSO
+
+`ase-meta-evaluate`, `ase-meta-quorum`, `ase-meta-diaboli`

package/plugin/skills/ase-meta-changes/SKILL.md

@@ -63,7 +63,7 @@ Processing
     following <template/>:
 
     <template>
-    &#x1F535; **CHANGELOG FILE:** `<filename/>`
+    <ase-tpl-bullet-normal/> **CHANGELOG FILE:** `<filename/>`
     </template>
 
     </step>
@@ -74,7 +74,7 @@ Processing
     operation with an output based on the following <template/>:
 
     <template>
-    &#x1F535; **DETERMINE ARTIFACT CHANGES:**
+    <ase-tpl-bullet-normal/> **DETERMINE ARTIFACT CHANGES:**
     </template>
 
     To update to entries of the most recent *ChangeLog* section, consult
@@ -102,7 +102,7 @@ Processing
     operation with an output based on the following <template/>:
 
     <template>
-    &#x1F535; **COMPLETE ENTRIES:**
+    <ase-tpl-bullet-normal/> **COMPLETE ENTRIES:**
     </template>
 
     Without immediately modifying the `CHANGELOG.md` file, *complete*
@@ -127,7 +127,7 @@ Processing
     operation with an output based on the following <template/>:
 
     <template>
-    &#x1F535; **CONSOLIDATE ENTRIES:**
+    <ase-tpl-bullet-normal/> **CONSOLIDATE ENTRIES:**
     </template>
 
     Without immediately modifying the `CHANGELOG.md` file, *consolidate*
@@ -147,7 +147,7 @@ Processing
     operation with an output based on the following <template/>:
 
     <template>
-    &#x1F7E0; **UPDATING CHANGELOG:**
+    <ase-tpl-bullet-signal/> **UPDATING CHANGELOG:**
     </template>
 
     Finally, *update* the `CHANGELOG.md` file with the completed,

package/plugin/skills/ase-meta-diaboli/SKILL.md

@@ -27,7 +27,7 @@ effort: xhigh
     Output the thesis with the following <template/>:
 
     <template>
-    &#x26AA; **THESIS**: <thesis/>
+    <ase-tpl-bullet-secondary/> **THESIS**: <thesis/>
     </template>
 
 2.  **Determine Anti-Thesis**:
@@ -117,7 +117,7 @@ effort: xhigh
     <template/>:
 
     <template>
-    &#x1F7E0; **ANTITHESIS**: <antithesis-N/>
+    <ase-tpl-bullet-signal/> **ANTITHESIS**: <antithesis-N/>
     </template>
 
 3.  **Dialectical Reasoning**:
@@ -147,6 +147,6 @@ effort: xhigh
     in <synthesis/>, and then finally output the following <template/>:
 
     <template>
-    &#x1F535; **SYNTHESIS**: <synthesis/>
+    <ase-tpl-bullet-normal/> **SYNTHESIS**: <synthesis/>
     </template>
 

package/plugin/skills/ase-meta-diff/SKILL.md

@@ -0,0 +1,301 @@
+---
+name: ase-meta-diff
+argument-hint: "[--help|-h] [--risk|-r] [--blast|-b]"
+description: >
+    Summarize the currently staged Git changes as a human-readable,
+    intent-grouped narrative. Use when the user wants a concise and
+    brief report of what changed and why. Optionally can show a risk and
+    blast radius report.
+user-invocable: true
+disable-model-invocation: false
+effort: high
+allowed-tools:
+    - "Bash(git diff *)"
+    - "Bash(git grep:*)"
+    - "Bash(git ls-files:*)"
+    - "Bash(grep:*)"
+    - "Agent"
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
+
+<skill name="ase-meta-diff">
+Summarize Diff
+</skill>
+
+<expand name="getopt"
+    arg1="ase-meta-diff"
+    arg2="--risk|-r --blast|-b">
+    $ARGUMENTS
+</expand>
+
+<objective>
+Summarize the currently staged Git changes into a *concise*,
+*human-readable* narrative of what changed and why, *grouped by
+intent* rather than by file. Optionally *score* the diff against a
+*coupling-criticality-coverage- reversibility* rubric and emit a *graded
+risk report* with *mitigations*. Optionally render a *blast-radius map*.
+</objective>
+
+Procedure
+---------
+
+You *MUST* follow the following numbered items *strictly* *sequentially*!
+You *MUST* not skip any numbered item during processing!
+
+You *MUST* *NOT* output anything in this entire procedure, *except* when
+explicitly requested by this procedure via outputs based on a <template/>!
+
+<flow>
+
+1.  <step id="STEP 1: Determine Change Set">
+
+    1.  Determine the *diff details* by running the corresponding command
+        (taken exactly as given) and capturing the full diff output into
+        <diff/> for the subsequent analysis:
+
+        `git diff --cached HEAD`
+
+    2.  Determine the *diff statistics* by running the corresponding command
+        (taken exactly as given) and capturing the full stat output into
+        <stat/> for the subsequent analysis:
+
+        `git diff --cached --numstat HEAD`
+
+    </step>
+
+2.  <step id="STEP 2: Summarize By Intent">
+
+    1.  <if condition="<diff/> is empty">
+        Only output the following <template/> and then *STOP* immediately:
+
+        <template>
+        ⧉ **ASE**: ✪ skill: **ase-meta-diff**, ▶ status: **no changes to summarize**
+        </template>
+        </if>
+
+    2.   Analyze the <diff/> and <stat/> and synthesize a *concise* narrative of
+         WHAT changed and WHY, *grouped by intent* rather than by file.
+         Honor the following intents:
+
+         -   `FEATURE`:     new        functionality or configuration
+         -   `IMPROVEMENT`: improved   functionality or configuration
+         -   `BUGFIX`:      corrected  functionality or configuration
+         -   `UPDATE`:      updated    functionality or configuration
+         -   `CLEANUP`:     cleaned up functionality or configuration
+         -   `REFACTOR`:    refactored functionality or configuration
+
+    3.  <if condition="<diff/> is NOT empty">
+        1.  First, output the following header <template/>:
+
+            <template>
+
+            <ase-tpl-bullet-normal/> **CHANGE INTENT REPORT**:
+
+            </template>
+
+        2.  Render a *two-column table* with one row per discovered
+            *intent group* present in the <diff/>. Output the following
+            table header <template/>:
+
+            <template>
+            | Intent | Changes (LoC) | Files &amp; Description |
+            | ------ | ------------- | ----------------------- |
+            </template>
+
+        3.  For each discovered *intent group*, emit the following row
+            <template/>, where <intent/> is the intent label, <changes/>
+            is the total number of lines changes per feature in format
+            `+N/-M`, <files/> is the list of affected file references,
+            and <description/> is a *brief* one-to-two-sentence
+            narrative of what changed and why:
+
+            <template>
+            | **<intent/>** | <changes/> | <files/>: <description/> |
+            </template>
+
+            In the <files/> part of the second column, markup all file
+            references as code (with backticks), prepend them with `▢ `,
+            append ` [+N/-M]` (based on the information in <stat/>) to them,
+            and separate them with `, ` (a comma and space). Do *not* repeat
+            file references in the <description/>.
+
+            Keep the overall report *concise* and *brief*. Try to keep the
+            number of intent groups (table rows) in the range of 1-10. Do
+            *not* output any further explanation.
+        </if>
+
+    </step>
+
+3.  <step id="STEP 3: Score Against Risk Rubric (optional)">
+
+    1.  <if condition="<getopt-option-risk/> is NOT equal `true`">
+        Silently *SKIP* this entire step.
+        </if>
+
+    2.  <if condition="<diff/> is empty">
+        Silently *SKIP* this entire step (STEP 2 already reported it).
+        </if>
+
+    3.  <if condition="<getopt-option-risk/> is equal `true` and <diff/> is NOT empty">
+
+        Score the *same* captured <diff/> and <stat/> information
+        against the four-axis rubric below. Each axis is scored on an
+        integer scale of *1* (lowest risk) to *5* (highest risk) against
+        the *fixed anchors* given, and *every* score *MUST* be backed
+        by a one-line <evidence/> grounded in the *actual* hunks or the
+        read-only repository probe.
+
+        Probe the repository *read-only* and *heuristically* (via `git
+        grep` / `grep` / `git ls-files`, restricted to first-party code)
+        only as needed to substantiate the *Coupling* and *Coverage*
+        axes (e.g. who imports a touched module, whether touched code has
+        adjacent tests). Do not output anything during the probe.
+
+        Score each axis against these anchors:
+
+        1.  **COUPLING** — how widely the touched code is depended upon.
+            *1*: self-contained, no first-party importers.
+            *3*: a handful of dependent modules.
+            *5*: a hub touched by many modules or a public interface.
+
+        2.  **CRITICALITY** — how essential the touched path is.
+            *1*: docs, comments, dead/peripheral code.
+            *3*: ordinary feature logic.
+            *5*: core/security/auth/data-integrity/money path.
+
+        3.  **COVERAGE** — how well the change is exercised by tests.
+            *1*: tests touched in this diff or directly covering the
+            changed hunks.
+            *3*: adjacent tests exist but are not clearly exercising the
+            changed hunks.
+            *5*: no tests anywhere near the touched code.
+
+        4.  **REVERSIBILITY** — how easily the change can be undone.
+            *1*: pure code change, revert restores prior state.
+            *3*: needs coordinated revert or a config rollback.
+            *5*: irreversible-by-revert (schema/data migration, released
+            artifact, external side effect).
+
+        Compute the *aggregate risk* as the *equal-weighted* mean of
+        the four risk contributions (Coupling, Criticality, Coverage,
+        Reversibility), rounded to one decimal, and map it to a *graded
+        band*: *1.0-1.9* → **LOW**, *2.0-2.9* → **MODERATE**, *3.0-3.9*
+        → **HIGH**, *4.0-5.0* → **CRITICAL**.
+
+        Then emit the following <template/>, with the overall band and
+        aggregate score, followed by a *three-column table* with one row
+        per axis: column 1 is the *axis*, column 2 is the *score*, and
+        column 3 is the *evidence* (as a `●` bullet point) plus —
+        *only* if the axis reached the mitigation threshold of '>= 4' —
+        the *mitigation* (as a second `●` bullet point). If an axis did
+        not reach that threshold, omit the ` ● **MITIGATION**:
+        <mitigation/>` part from its row. Keep the overall <evidence/>
+        and <mitigation/> texts *concise* and *ultra brief*. Do *not*
+        output any further explanation.
+
+        In <evidence/> markup all file references as code (with
+        backticks), prepend them with `▢ ` and append ` [+N/-M]` (based
+        on the information in <stat/>) to them.
+
+        <template>
+
+        <ase-tpl-bullet-signal/> **CHANGE RISK REPORT**: Overall: **<band/>** (<aggregate/>/5)
+
+        | Axis | Score | Findings |
+        | ---- | ----- | -------- |
+        </template>
+
+        For each axis, emit the following row <template/>:
+
+        <template>
+        | **<axis/>** | <score/>/5 | ● **EVIDENCE**: <evidence/> ● **MITIGATION**: <mitigation/> |
+        </template>
+
+        Finally, output the following footer <template/>:
+
+        <template>
+
+        </template>
+
+        </if>
+
+    </step>
+
+4.  <step id="STEP 4: Render Blast-Radius Map (optional)">
+
+    1.  <if condition="<getopt-option-blast/> is NOT equal `true`">
+        Silently *SKIP* this entire step.
+        </if>
+
+    2.  <if condition="<diff/> is empty">
+        Silently *SKIP* this entire step (STEP 2 already reported it).
+        </if>
+
+    3.  <if condition="<getopt-option-blast/> is equal `true` and <diff/> is NOT empty">
+        From the *same* captured <diff/> and <stat/>, *extract the
+        touched modules* — the distinct changed source files (or their
+        enclosing modules/ packages, according to the language idiom).
+
+        Then, for each touched module, *scan its reverse dependencies*
+        — the other first-party files that *import* or *reference* it
+        across the current project (e.g. by the module's basename,
+        exported symbol, or import path). Keep the scan *read-only*
+        and *heuristic*; restrict it to first-party code within the
+        repository. Do not output anything during the scan.
+
+        Then build a *blast-radius graph* and render it as a diagram:
+
+        1.  Build a Mermaid specification <mermaid-spec/> for a `flowchart
+            TB` whose *touched* modules are the origin nodes and whose
+            *reverse-dependency* edges fan out to the dependent modules
+            (origin → dependent).
+
+            Flag each *touched* node as a problem node per the
+            `ase-meta-diagram` anomaly convention — prefix its label
+            with `⚑ ` inside quotes, e.g. `T1["⚑ src/core.ts"]`. Keep
+            labels ultra short (basenames or module names only).
+
+        2.  Dispatch the rendering to the `ase-meta-diagram` sub-agent by
+            calling the tool `Agent(name: "ase:ase-meta-diagram",
+            description: "Diagram Rendering", subagent_type:
+            "ase:ase-meta-diagram", prompt: "<mermaid-spec/>")` and capture
+            its returned `text` field as <diagram/>.
+
+        Then emit the following <template/>, showing <diagram/> and
+        appending a *brief impact summary* of bullets, where each
+        <module/> is a *touched* module and <impact/> is a one-sentence
+        note on *what depends on it* and *how far the blast reaches*.
+
+        In <module/> and <impact/>, markup all file references as code
+        (with backticks), prepend them with `▢ ` and append ` [+N/-M]`
+        (based on the information in <stat/>) to them.
+
+        <template>
+        <ase-tpl-head title="Hello World"/>
+
+        <ase-tpl-bullet-signal/> **CHANGE BLAST RADIUS MAP**:
+
+        ```text
+        <diagram/>
+        ```
+
+        <ase-tpl-bullet-signal/> **BLAST**: ⚑ **<module/>**: <impact/>
+
+        <ase-tpl-bullet-signal/> **BLAST**: ⚑ **<module/>**: <impact/>
+
+        [...]
+
+        <ase-tpl-foot/>
+        </template>
+
+        Keep the overall report *concise* and *brief*. Do *not* output
+        any further explanation.
+        </if>
+
+    </step>
+
+</flow>
+