@rse/ase 0.9.55 → 0.9.56

package/plugin/skills/ase-code-insight/SKILL.md

@@ -51,7 +51,8 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
 
     Determine an <abstract/> summary of this project.
     For this, check a potentially existing `README.*` file
-    or scan the source files and figure it out indirectly.
+    or scan the source files of <getopt-arguments/> and figure it out
+    indirectly.
 
     Display the results with the following <template/>:
 
@@ -80,8 +81,8 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
     </step>
 
 3.  <step id="STEP 3: SOURCE CHURN">
-    Display the source files which caused the most churn by
-    figuring out which source files have the most commits.
+    Display the source files of <getopt-arguments/> which caused the
+    most churn by figuring out which of them have the most commits.
     Display the following <template/>:
 
     <template>
@@ -91,7 +92,7 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
     Then run the following command...
 
     ```
-    git log --format=format: --name-only --since="1 year ago" | grep -v '^$' | sort | uniq -c | sort -nr | head -10
+    git log --format=format: --name-only --since="1 year ago" -- <getopt-arguments/> | grep -v '^$' | sort | uniq -c | sort -nr | head -10
     ```
 
     ...and then display its result as a table with a table head and
@@ -106,9 +107,10 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
     <ase-tpl-bullet-normal/> **MODULE STRUCTURE**:
     </template>
 
-    Find all modules (or OOP classes) and build a Mermaid specification
-    <mermaid-spec/> for a `flowchart TB` diagram with all modules as
-    boxes and the imports between modules as the directed edges. Then
+    Find all modules (or OOP classes) of <getopt-arguments/> and build a
+    Mermaid specification <mermaid-spec/> for a `flowchart TB` diagram
+    with all modules as boxes and the imports between modules as the
+    directed edges. Then
     dispatch the rendering to the `ase-meta-diagram` sub-agent by
     calling the tool `Agent(description: "Diagram Rendering",
     subagent_type: "ase:ase-meta-diagram", prompt: <mermaid-spec/>,

package/plugin/skills/ase-code-lint/SKILL.md

@@ -276,10 +276,12 @@ related to a set of code quality aspects.
 
                     Set <old-start/> to the 1-based line number of the
                     *first* old-side hunk line: if <context-before/> is
-                    non-empty, that is its line (one before <line/>);
-                    otherwise it is <line/> itself (the first line of
-                    <old-text/>). For a hunk that *only inserts* new lines
-                    (empty <old-text/> *and* empty context), set it to the
+                    non-empty, that is the line of its *first* context
+                    line, i.e. <line/> minus the number of lines in
+                    <context-before/>; otherwise it is <line/> itself
+                    (the first line of <old-text/>). For a hunk that
+                    *only inserts* new lines (empty <old-text/> *and*
+                    empty context), set it to the
                     line *before* which the insertion happens, clamped to a
                     minimum of `0`, so a top-of-file insertion yields
                     `@@ -0,0 ... @@`.
@@ -341,7 +343,7 @@ related to a set of code quality aspects.
 
             </template>
 
-        5.  <if condition="<getopt-option-auto/> is not equal `true` and <ase-project-boxing/> is not equal `black`">
+        5.  <if condition="<getopt-option-auto/> is not equal `true`">
 
             <if condition="<ase-project-boxing/> is equal `grey`">
 

package/plugin/skills/ase-code-refactor/SKILL.md

@@ -138,91 +138,7 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 4.  <step id="STEP 4: Choose Refactoring Approaches">
 
-    You *MUST* perform the following sub-steps *internally* and *without
-    any output* until and including the recommendation decision. Only
-    sub-steps 4-7 below are allowed to produce output; sub-steps 4-6 only if
-    <getopt-option-auto/> is equal `false` *and* <ase-project-boxing/>
-    is *not* equal `black`.
-
-    If <getopt-option-auto/> is equal `true` or <ase-project-boxing/> is
-    equal `black`, *skip* the reporting sub-steps 4-6 entirely (they
-    perform no output at all) to speed up processing.
-
-    1.  *Propose* a corresponding *refactoring approach*, optionally
-        including some *alternative* refactoring approaches. Do *not*
-        output anything in this sub-step.
-
-    2.  *Reflect* on and *critique* the proposed approaches by deriving,
-        per approach, a small set of concrete *pros* and *cons*. Do
-        *not* output anything in this sub-step.
-
-    3.  Based on the reflection, *decide* which approach to recommend
-        and annotate it with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
-        empty <annotation/>. Do *not* output anything in this sub-step.
-
-    4.  Indicate start of reporting by showing the following <template/>:
-
-        <template>
-        <ase-tpl-head title="APPROACHES"/>
-        </template>
-
-    5.  Now report each approach with the following <template/>,
-        inlining its pros/cons derived in sub-step 2, and do not output
-        anything else in this step:
-
-        <template>
-        ●   **APPROACH A<n/>**<annotation/>: **<summary/>**
-        ○   [...]
-        ⊕   *PRO*: [...]
-        ⊖   *CON*: [...]
-        </template>
-
-        Hints:
-
-        -   Give a short one-sentence <summary/> of the refactoring
-            approach plus *precise* and *ultra brief and concise*
-            refactoring information. Try to keep the number of bullet
-            points (`○ [...]`) in the range of 1-4.
-
-    6.  Indicate end of reporting by showing the following <template/>:
-
-        <template>
-        <ase-tpl-foot title="APPROACHES"/>
-        </template>
-
-    7.  <if condition="<getopt-option-auto/> is not equal `true` and <ase-project-boxing/> is not equal `black`">
-
-        In the following, you *MUST* *NOT* use your built-in
-        <user-dialog-tool/> tool! Instead, you *MUST* just show a
-        custom dialog according to the expanded `custom-dialog`
-        definition. You *MUST* closely follow this definition.
-
-        Let the user choose the preferred approach A<n/> by raising
-        a question with the following custom dialog, where per
-        approach A<n/>, you determine an ultra brief summary
-        <short-summary/> and then use the answer option `A<n/>:
-        ⚝ **RECOMMENDATION** ⚝ - <short-summary/>` for your
-        recommended approach plus zero or more answer options `A<n/>:
-        <short-summary/>` for all other approaches:
-
-        <expand name="custom-dialog" arg1="--no-other">
-            Select Approach: Select your preferred refactoring approach to follow?
-            A<n/>: <short-summary/>
-            [...]
-        </expand>
-
-        </if>
-        <else>
-
-        Set <n/> to the number of the refactoring approach A<n/> you recommend.
-        Output a hint with the following <template/>:
-
-        <template>
-        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
-        </template>
-
-        </else>
+    <expand name="code-approaches" arg1="refactoring" arg2="refactoring"></expand>
 
     </step>
 
@@ -265,76 +181,9 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan created**
         </template>
 
-    5.  Directly pass-through control to the next skill:
-
-        Treat <getopt-option-next/> as a comma-separated chronological
-        list of pre-selected next-step tokens. *Peek* the *first* token
-        as <head/> (or `none` if the list is `none`/empty).
-        Set <args>--int-reuse-task</args>.
-
-        1.  <if condition="<head/> is equal `DONE`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty). `DONE`
-            means the freshly composed plan is finalized as-is, so do
-            *not* hand off to `ase-task-edit`. Only output the following
-            <template/> and then *STOP*. Do *not* implement the plan.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan finalized -- done**
-            </template>
-            </if>
-
-        2.  <elseif condition="<head/> is equal `IMPLEMENT`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty).
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-implement", args: "<args/>")`
-            to *implement* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        3.  <elseif condition="<head/> is equal `PREFLIGHT`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty).
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-preflight", args: "<args/>")`
-            to *preflight* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        4.  <elseif condition="<head/> is equal `GRILL`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty). `GRILL`
-            is this skill's own dispatch token, *not* part of
-            `ase-task-grill`'s `--next` vocabulary, so it must be
-            stripped here rather than forwarded. All remaining tokens are
-            `ase-task-grill`'s own vocabulary and are forwarded verbatim.
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-grill", args: "<args/>")`
-            to *grill* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        5.  <else>
-            Hand off to `ase-task-edit`.
-            <if condition="<head/> is equal `EDIT`">
-                Consume the head: set <getopt-option-next/> to the remaining
-                tokens (joined back with `,`, or `none` if empty). `EDIT`
-                is this skill's own dispatch token, *not* part of
-                `ase-task-edit`'s `--next` vocabulary, so it must be
-                stripped here rather than forwarded.
-            </if>
-            All remaining tokens are `ase-task-edit`'s own vocabulary
-            and are forwarded verbatim, so `ase-task-edit` consumes its
-            own head itself.
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Then call the tool `Skill(skill: "ase:ase-task-edit", args: "<args/>")`.
-            </else>
+    5.  Directly pass through control to the next skill:
+
+        <expand name="code-next-dispatch"></expand>
 
     </step>
 

package/plugin/skills/ase-code-resolve/SKILL.md

@@ -151,10 +151,10 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
           Try to keep the number of bullet points (●) in the range of 1-4.
 
         - In case of a *complex context situation* with complex *structure*
-          (layout, components, dependencies, etc), complex *control flow*
-          (branching, concurrency, etc), complex *state machine* (states,
-          transitions, etc), complex *data flow* (actors, messages, etc), or
-          complex *data structure* (classes, entities, relationships, etc),
+          (layout, components, dependencies, etc.), complex *control flow*
+          (branching, concurrency, etc.), complex *state machine* (states,
+          transitions, etc.), complex *data flow* (actors, messages, etc.), or
+          complex *data structure* (classes, entities, relationships, etc.),
           visualize it with an optional diagram <optional-diagram/> by
           building a Mermaid specification <mermaid-spec/> (e.g. `flowchart
           TB`, `stateDiagram-v2`, `sequenceDiagram`, `classDiagram`, or
@@ -192,91 +192,7 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 4.  <step id="STEP 4: Choose Problem Resolution Approaches">
 
-    You *MUST* perform the following sub-steps *internally* and *without
-    any output* until and including the recommendation decision. Only
-    sub-steps 4-7 below are allowed to produce output; sub-steps 4-6 only if
-    <getopt-option-auto/> is equal `false` *and* <ase-project-boxing/>
-    is *not* equal `black`.
-
-    If <getopt-option-auto/> is equal `true` or <ase-project-boxing/> is
-    equal `black`, *skip* the reporting sub-steps 4-6 entirely (they
-    perform no output at all) to speed up processing.
-
-    1.  *Propose* a corresponding *resolution approach*, optionally including
-        some *alternative* resolution approaches. Do *not* output anything
-        in this sub-step.
-
-    2.  *Reflect* on and *critique* the proposed approaches by deriving,
-        per approach, a small set of concrete *pros* and *cons*. Do
-        *not* output anything in this sub-step.
-
-    3.  Based on the reflection, *decide* which approach to recommend
-        and annotate it with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
-        empty <annotation/>. Do *not* output anything in this sub-step.
-
-    4.  Indicate start of reporting by showing the following <template/>:
-
-        <template>
-        <ase-tpl-head title="APPROACHES"/>
-        </template>
-
-    5.  Now report each approach with the following <template/>,
-        inlining its pros/cons derived in sub-step 2, and do not output
-        anything else in this step:
-
-        <template>
-        ●   **APPROACH A<n/>**<annotation/>: **<summary/>**
-        ○   [...]
-        ⊕   *PRO*: [...]
-        ⊖   *CON*: [...]
-        </template>
-
-        Hints:
-
-        -   Give a short one-sentence <summary/> of the resolution
-            approach plus *precise* and *ultra brief and concise*
-            resolution information. Try to keep the number of bullet points
-            (`○ [...]`) in the range of 1-4.
-
-    6.  Indicate end of reporting by showing the following <template/>:
-
-        <template>
-        <ase-tpl-foot title="APPROACHES"/>
-        </template>
-
-    7.  <if condition="<getopt-option-auto/> is not equal `true` and <ase-project-boxing/> is not equal `black`">
-
-        In the following, you *MUST* *NOT* use your built-in
-        <user-dialog-tool/> tool! Instead, you *MUST* just show a
-        custom dialog according to the expanded `custom-dialog`
-        definition. You *MUST* closely follow this definition.
-
-        Let the user choose the preferred approach A<n/> by raising
-        a question with the following custom dialog, where per
-        approach A<n/>, you determine an ultra brief summary
-        <short-summary/> and then use the answer option `A<n/>:
-        ⚝ **RECOMMENDATION** ⚝ - <short-summary/>` for your
-        recommended approach plus zero or more answer options `A<n/>:
-        <short-summary/>` for all other approaches:
-
-        <expand name="custom-dialog" arg1="--no-other">
-            Select Approach: Select your preferred resolution approach to follow?
-            A<n/>: <short-summary/>
-            [...]
-        </expand>
-
-        </if>
-        <else>
-
-        Set <n/> to the number of the resolution approach A<n/> you recommend.
-        Output a hint with the following <template/>:
-
-        <template>
-        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
-        </template>
-
-        </else>
+    <expand name="code-approaches" arg1="resolution" arg2="resolution"></expand>
 
     </step>
 
@@ -326,76 +242,9 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan created**
         </template>
 
-    6.  Directly pass-through control to the next skill:
-
-        Treat <getopt-option-next/> as a comma-separated chronological
-        list of pre-selected next-step tokens. *Peek* the *first* token
-        as <head/> (or `none` if the list is `none`/empty).
-        Set <args>--int-reuse-task</args>.
-
-        1.  <if condition="<head/> is equal `DONE`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty). `DONE`
-            means the freshly composed plan is finalized as-is, so do
-            *not* hand off to `ase-task-edit`. Only output the following
-            <template/> and then *STOP*. Do *not* implement the plan.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan finalized -- done**
-            </template>
-            </if>
-
-        2.  <elseif condition="<head/> is equal `IMPLEMENT`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty).
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-implement", args: "<args/>")`
-            to *implement* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        3.  <elseif condition="<head/> is equal `PREFLIGHT`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty).
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-preflight", args: "<args/>")`
-            to *preflight* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        4.  <elseif condition="<head/> is equal `GRILL`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty). `GRILL`
-            is this skill's own dispatch token, *not* part of
-            `ase-task-grill`'s `--next` vocabulary, so it must be
-            stripped here rather than forwarded. All remaining tokens are
-            `ase-task-grill`'s own vocabulary and are forwarded verbatim.
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-grill", args: "<args/>")`
-            to *grill* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        5.  <else>
-            Hand off to `ase-task-edit`.
-            <if condition="<head/> is equal `EDIT`">
-                Consume the head: set <getopt-option-next/> to the remaining
-                tokens (joined back with `,`, or `none` if empty). `EDIT`
-                is this skill's own dispatch token, *not* part of
-                `ase-task-edit`'s `--next` vocabulary, so it must be
-                stripped here rather than forwarded.
-            </if>
-            All remaining tokens are `ase-task-edit`'s own vocabulary
-            and are forwarded verbatim, so `ase-task-edit` consumes its
-            own head itself.
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Then call the tool `Skill(skill: "ase:ase-task-edit", args: "<args/>")`.
-            </else>
+    6.  Directly pass through control to the next skill:
+
+        <expand name="code-next-dispatch"></expand>
 
     </step>
 

package/plugin/skills/ase-docs-distill/SKILL.md

@@ -77,7 +77,7 @@ Procedure
 
         </if>
 
-    You *MUST* *NOT* output anything in this STEP 1.
+    You *MUST* *NOT* output anything else in this STEP 1.
 
     </step>
 
@@ -141,7 +141,7 @@ Procedure
 
     </template>
 
-    In the <location/>, markup the line-range reference as
+    In the <location/>, mark up the line-range reference as
     code (with backticks) and prepend it with `▢ `.
 
     Keep the overall report *concise* and *brief*. Do *not* output any

package/plugin/skills/ase-docs-distill/help.md

@@ -15,7 +15,7 @@
 The `ase-docs-distill` skill reads a *provided document* and distills it
 into a *flat*, *importance-ranked* list of its *key points*. The
 *document-reference* is resolved *probe-as-file-first*: if the argument names
-a *readable file* it is read from disk, otherwise the argument is taken
+a *readable file* it is read from disk; otherwise the argument is taken
 *verbatim* as *pasted text*. The document is read *silently* - only the
 final ranked list is shown - so even a large document does not flood the
 transcript.

package/plugin/skills/ase-docs-proofread/SKILL.md

@@ -217,7 +217,8 @@ Analyze documents for spelling, punctuation, or grammar errors
 
             Set <old-start/> to the 1-based line number of the *first*
             old-side hunk line: if <context-before/> is non-empty, that is
-            its line (one before <line/>); otherwise it is <line/> itself
+            the line of its *first* context line, i.e. <line/> minus the
+            number of lines in <context-before/>; otherwise it is <line/> itself
             (the first line of <old-text/>). For a hunk that *only inserts*
             new lines (empty <old-text/> *and* empty context), set it to the
             line *before* which the insertion happens, clamped to a minimum
@@ -288,8 +289,11 @@ Analyze documents for spelling, punctuation, or grammar errors
                 proposal (<old-text/> stays anchored to the existing text
                 at <file/>:<line/>; <new-text/> and <description/> carry the
                 refinement) so the subsequent rendering and any `Edit` use
-                the new proposal rather than the original. Then *go back* to
-                substep 2 of this `for`-iteration. There is *no* cap on
+                the new proposal rather than the original. Then *re-apply*
+                the minimal-form normalization of substep 1 to the refined
+                <old-text/> and <new-text/> (so the re-rendered diff again
+                shows exactly the changed lines) and *go back* to substep 2
+                of this `for`-iteration. There is *no* cap on
                 refinement rounds - keep refining until the user picks
                 `ACCEPT` or `REJECT`.
 

package/plugin/skills/ase-help-intent/SKILL.md

@@ -81,14 +81,18 @@ catalog you match <intent/> against:
         -   Set <rationale/> to a *very brief*, single-sentence
             justification of why the selected skill and its options match
             <intent/>.
+        -   Set <matched>yes</matched>.
 
     2.  *Guard No Match*:
 
         <if condition="no skill in <corpus/> adequately matches <intent/>">
-        Output the following <template/> and then *continue* the *loop*
-        at sub-step 4 to prompt the user for a refined or clearer intent
-        via the dialog's free-text channel (do *not* stop and do *not*
-        render a command):
+        Set <matched>no</matched> and discard the inadequate selection of
+        sub-step 1 by setting <name></name>, <arguments></arguments>, and
+        <command></command> (all set to empty), so that no stale command
+        can survive into the dialog of sub-step 4. Then output the
+        following <template/> and *continue* the *loop* at sub-step 4 to
+        prompt the user for a refined or clearer intent via the dialog's
+        free-text channel (do *not* stop and do *not* render a command):
 
         <template>
         <ase-tpl-bullet-secondary/> **WARNING**: no confident match for the intent -- please refine or clarify it.
@@ -116,16 +120,27 @@ catalog you match <intent/> against:
         dialog according to the expanded `custom-dialog` definition. You
         *MUST* closely follow this definition.
 
-        Let the user decide what to do with the generated command by
-        raising a question with the following custom dialog (invoked with
-        `--other`, so that any free-text instruction is accepted as an
-        intent refinement):
+        Let the user decide how to proceed by raising a question with the
+        following custom dialog (invoked with `--other`, so that any
+        free-text instruction is accepted as an intent refinement). Which
+        dialog is raised depends on <matched/>, so that `EXECUTE` is
+        offered *only* when a command was actually generated in sub-step 1
+        *and* rendered in sub-step 3:
 
+        <if condition="<matched/> is `no`">
+        <expand name="custom-dialog" arg1="--other">
+            Dispatch: What would you like to do with the unmatched intent?
+            REFINE: Refine or clarify the intent.
+            CANCEL: Cancel this dialog.
+        </expand>
+        </if>
+        <else>
         <expand name="custom-dialog" arg1="--other">
             Dispatch: What would you like to do with the generated command?
             EXECUTE: Execute the generated command now.
             CANCEL:  Cancel this dialog.
         </expand>
+        </else>
 
         Check the tool <result/> and dispatch accordingly:
 
@@ -133,7 +148,16 @@ catalog you match <intent/> against:
             *Break* out of the *loop* and stop processing without any
             further output.
 
-        -   If <result/> is `EXECUTE`:
+        -   If <result/> is `REFINE`, or <result/> is `EXECUTE` while
+            <matched/> is `no`: do *not* execute anything -- output the
+            following <template/> and *continue* the *loop* at sub-step 4
+            to obtain a refined intent via the dialog's free-text channel:
+
+            <template>
+            <ase-tpl-bullet-secondary/> **HINT**: please enter a refined or clearer intent as free text.
+            </template>
+
+        -   If <result/> is `EXECUTE` (which implies <matched/> is `yes`):
             *Break* out of the *loop*, output the following <template/>,
             and then call the tool `Skill(skill: "ase:<name/>", args:
             "<arguments/>")` to *execute* the generated command:

package/plugin/skills/ase-help-skill/SKILL.md

@@ -35,7 +35,7 @@ skill name, abbreviation of it, or description of its purpose:
 <skill-ref><getopt-arguments/></skill-ref>
 </objective>
 
-The following <catalog/> is index of all ASE skills -- one
+The following <catalog/> is the index of all ASE skills -- one
 `⎈ **<group/>**` entry per skill group and one
 ``○ `<name/>`: <purpose/>`` entry per skill -- and this is
 the *sole* index <skill-ref/> is resolved against:

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

@@ -78,6 +78,15 @@ Honor the following tenets throughout the brainstorming:
 
 1.  <step id="STEP 1: Restate Topic">
 
+    <if condition="<topic/> is empty">
+    Only output the following <template/> and then immediately *STOP*
+    processing the entire current skill:
+
+    <template>
+    ⧉ **ASE**: ✪ skill: **ase-meta-brainstorm**, ▶ ERROR: expected a `<topic>` argument
+    </template>
+    </if>
+
     Restate the topic to be brainstormed by outputting the following <template/>:
 
     <template>
@@ -99,7 +108,7 @@ Honor the following tenets throughout the brainstorming:
     1..<getopt-option-max-clarify/> unknowns, as too much upfront intent
     clarification kills the brainstorming of ideas later. So, you *MUST*
     reduce the clarifications of the unknowns to the absolute minimum in
-    general and cap it at <getopt-option-max-clarify/>!
+    general and cap them at <getopt-option-max-clarify/>!
 
     For each essential unknown to clarify, derive a short 1-3 word facet
     <facet-M/> and a corresponding question <question-M/> whose answer
@@ -185,7 +194,7 @@ Honor the following tenets throughout the brainstorming:
     the unconventional/wildcard angle - because variety in origin yields
     variety in outcome.
 
-    Do still *not* judge, rank, or prune ideas in this step. Generate
+    Still do *not* judge, rank, or prune ideas in this step. Generate
     ideas until you either reach at least <getopt-option-min-ideas/> distinct
     candidate ideas or have clearly exhausted the meaningfully distinct
     space.

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

@@ -106,14 +106,18 @@ Processing
     correct baseline Git tag. Take the `N.M.K` from the *first* (most
     recent) level-2 header in the *ChangeLog* file and check whether a
     corresponding Git tag already exists with the command `git tag --list
-    N.M.K`. If this command produces *no* output, the first section is
-    still in-progress/untagged, so use the `N.M.K` from the *second*
-    level-2 header as the baseline tag instead. If *no* second level-2
-    header exists (very first, still untagged release), skip the baseline
-    tag and check *all* Git commits with the command `git log HEAD
-    --numstat --pretty=format:'%h: %s'` instead. If this command *does*
-    produce output, the first section is already released/tagged, so use
-    the `N.M.K` from the *first* level-2 header as the baseline tag. Then
+    N.M.K`. If this command *does* produce output, the first section is
+    already released/tagged, so use the `N.M.K` from the *first* level-2
+    header as the baseline tag and *insert* a new, still-unreleased
+    level-2 section (next patch version, current date) *above* it, which
+    then becomes the *first* (most recent) section all subsequent steps
+    operate on - the already released section *MUST* *NOT* be modified.
+    If this command produces *no* output, the
+    first section is still in-progress/untagged, so use the `N.M.K` from
+    the *second* level-2 header as the baseline tag instead. If *no*
+    second level-2 header exists (very first, still untagged release),
+    skip the baseline tag and check *all* Git commits with the command
+    `git log HEAD --numstat --pretty=format:'%h: %s'` instead. Then
     check all Git commits between `HEAD` and this baseline tag with the
     command `git log N.M.K..HEAD --numstat --pretty=format:'%h: %s'`.