@rse/ase 0.9.55 → 0.9.57

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

@@ -1,6 +1,6 @@
 ---
 name: ase-code-resolve
-argument-hint: "[--help|-h] [--auto|-a] [--dry|-d] [--quick|-Q] [--next|-n <option>[,...]] [<task-id>:] <problem>"
+argument-hint: "[--help|-h] [--auto|-a] [--dry|-d] [--direct|-D] [--quick|-Q] [--next|-n <option>[,...]] [<task-id>:] <problem>"
 description: >
     Resolve Problem:
     Use when user wants to "bugfix" or "fix" code or "resolve" a problem.
@@ -10,6 +10,7 @@ effort: xhigh
 allowed-tools:
     - "Skill"
     - "Agent"
+    - "Read"
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
@@ -23,7 +24,7 @@ Resolve Problem
 
 <expand name="getopt"
     arg1="ase-code-resolve"
-    arg2="--auto|-a --dry|-d --quick|-Q --next|-n=(none|DONE|EDIT|GRILL|PREFLIGHT|IMPLEMENT)...">
+    arg2="--auto|-a --dry|-d --direct|-D --quick|-Q --next|-n=(none|DONE|EDIT|GRILL|PREFLIGHT|IMPLEMENT)...">
     $ARGUMENTS
 </expand>
 
@@ -45,9 +46,18 @@ to `true`, <getopt-option-dry/> to `true`, and <getopt-option-next/> to
 Procedure
 ---------
 
+<if condition="<getopt-option-direct/> is not equal to 'true'">
 You *MUST* *NOT* call `Edit`, `Write`, `NotebookEdit`, or any
 filesystem-modifying tool during this entire skill. The *only*
 permitted way to persist artifacts is via `ase_task_save(...)`.
+</if>
+<else>
+The `--direct`/`-D` mode applies the resolution *in place*, so STEP 4
+below *requires* `Edit` and `Write` to modify the affected artifacts.
+Every modification *MUST* still stay restricted to the artifacts the
+resolution actually demands, and you *MUST* *NOT* call
+`ase_task_save(...)`, as no task plan is composed at all.
+</else>
 
 <flow>
 
@@ -120,14 +130,19 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
         ⧉ **ASE**: ⇌ problem: **<problem/>**
         </template>
 
-    7.  Figure out what the requested <problem/> is about.
+    </step>
+
+2.  <step id="STEP 2: Investigate Code Base">
+
+    1.  Check the existing source files for all code which is related to the
+        requested <problem/> resolution.
 
-    8.  Ask the user for clarification if the goal of this resolution is
-        too unclear.
+    2.  Check the architecture of the existing code base to understand the
+        overall structures and dynamics.
 
-    9.  Do not output anything else in this step, unless you asked the user.
+    3.  Investigate and *figure out details* related to this problem.
 
-    10. Investigate and *figure out details* related to this problem.
+        <if condition="<getopt-option-direct/> is not equal to 'true'">
         Report those details with the following <template/>:
 
         <template>
@@ -151,10 +166,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
@@ -165,18 +180,9 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
           run_in_background: false)`, reproducing its
           returned fenced code block verbatim. Omit <optional-diagram/>
           entirely for simple or purely local situations.
+        </if>
 
-    </step>
-
-2.  <step id="STEP 2: Investigate Code Base">
-
-    1.  Check the existing source files for all code which is related to the
-        requested <problem/> resolution.
-
-    2.  Check the architecture of the existing code base to understand the
-        overall structures and dynamics.
-
-    3.  Do not output anything in this STEP 2.
+    4.  Do not output anything else in this STEP 2.
 
     </step>
 
@@ -190,97 +196,31 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
     </step>
 
-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`.
+4.  <if condition="<getopt-option-direct/> is equal to 'true'">
 
-    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.
+    <step id="STEP 4: Direct Problem Resolution">
 
-    1.  *Propose* a corresponding *resolution approach*, optionally including
-        some *alternative* resolution approaches. Do *not* output anything
-        in this sub-step.
+    1.  Directly resolve the <problem/> by modifying the affected
+        *artifacts* with a corresponding, complete *change set*,
+        based on your gathered knowledge about the code base and your
+        internalized problem resolution tenets. Also, if a CHANGELOG.md
+        file exists, make an appropriate entry there, too.
 
-    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.
+    2.  Do not output anything else in this STEP 4. Especially, do not
+        output a change summary or a unified diff of the changes.
 
-    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>
+    </step>
 
-        Set <n/> to the number of the resolution approach A<n/> you recommend.
-        Output a hint with the following <template/>:
+    </if>
+    <else>
 
-        <template>
-        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
-        </template>
+    <step id="STEP 4: Choose Problem Resolution Approaches">
 
-        </else>
+    <expand name="code-approaches" arg1="resolution" arg2="resolution"></expand>
 
     </step>
 
-5.  <step id="STEP 5: Compose Problem Resolution Plan">
+    <step id="STEP 5: Compose Problem Resolution Plan">
 
     1.  *Compose a plan* with code references, a precise description of the
         problem, the chosen resolution approach, a preview of the *unified
@@ -326,78 +266,13 @@ 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>
 
+    </else>
+
 </flow>
 

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

@@ -9,6 +9,7 @@
     [`--help`|`-h`]
     [`--auto`|`-a`]
     [`--dry`|`-d`]
+    [`--direct`|`-D`]
     [`--quick`|`-Q`]
     [`--next`|`-n` *option*[,...]]
     [*task-id*:] *problem*
@@ -27,10 +28,11 @@ or `T1`) previously produced by `ase-code-analyze` or
 `ase-arch-analyze` and persisted in the `ase` MCP key/value store
 under `ase-issue-<id>`.
 
-The skill does *not* directly modify source files. It persists the
-plan via `ase_task_save` and then hands off to `ase-task-edit`,
-`ase-task-preflight`, or `ase-task-implement`, as selected by
-`--next`.
+By default the skill does *not* directly modify source files. It
+persists the plan via `ase_task_save` and then hands off to
+`ase-task-edit`, `ase-task-preflight`, or `ase-task-implement`, as
+selected by `--next`. Only under `--direct` it skips the plan
+entirely and applies the change set to the affected artifacts itself.
 
 ##  OPTIONS
 
@@ -45,6 +47,15 @@ plan via `ase_task_save` and then hands off to `ase-task-edit`,
     type-checker, or program execution) once the source files have
     been modified.
 
+`--direct`|`-D`:
+    Resolve the problem *immediately* and *in place*: skip the
+    resolution approaches, the interactive dialog, and the entire task
+    plan ceremony, and directly apply the complete change set to the
+    affected artifacts, including a corresponding entry in an existing
+    `CHANGELOG.md` file. In this mode `--auto`, `--dry`, `--quick`, and
+    `--next` have no effect, as neither approaches are proposed nor a
+    plan is composed.
+
 `--quick`|`-Q`:
     Shorthand alias for `-a -d -n IMPLEMENT,DELETE`: automatically pick
     the recommended resolution approach, compose the plan *without* the

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: