@rse/ase 0.9.55 → 0.9.56

package/plugin/meta/ase-format-arch.md

@@ -28,7 +28,7 @@ is the timestamp when this **Artifact** was created. The
 <timestamp-modified/> is the timestamp when this **Artifact** was last
 modified. Both use an ISO-style format value. The value of both can be
 determined by a call to the `ase_timestamp(format: "yyyy-LL-dd HH:mm")`
-tool of the `ase` MCP server and use the `text` field of its response.
+tool of the `ase` MCP server, using the `text` field of its response.
 Whenever an **Artifact** is updated, the <timestamp-modified/> *MUST* be
 updated, too.
 
@@ -84,7 +84,6 @@ distinct **Artifact**s (listed under their <artifact-name/> and their
 The **Artifact**s have the following cross-references:
 
 ```text
-ARCH-02-FV Functionality View   ──(depends on)─► ARCH-01-CV Context View
 ARCH-03-IV Information View     ──(entity)─►     SPEC-07-DM Data Model
 ARCH-03-IV Information View     ──(owner)─►      ARCH-02-FV Functionality View
 ARCH-04-CO Concurrency View     ──(hosts)─►      ARCH-02-FV Functionality View
@@ -831,7 +830,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
 
     -   <arch-dr-decision-notes/> is *OPTIONAL* and can be omitted when it
         does not add genuine value - most decisions won't need it. The
-        following usually goes into it: information of the decision *process*
+        following usually goes into it: information about the decision *process*
         (e.g. a weighted decision matrix of considered alternatives);
         consequences of the decision (but only when non-obvious downstream
         effects need to be called out); and links to strongly related
@@ -850,7 +849,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
         almost inevitable answer to the context - if a reader is surprised
         by the decision, either the context is missing a force, or the
         decision is under-justified. The rationale should make the decision
-        feel earned, not asserted - if you would delete the rationale and
+        feel earned, not asserted - if you delete the rationale and
         the decision suddenly looks arbitrary, the rationale was doing its
         job.
 
@@ -892,7 +891,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
 
     -   **Boundary and scope decisions.** "Customer data is owned by the
         Customer context; other contexts reference it by ID only." The explicit
-        no-s are as valuable as the yes-s.
+        no's are as valuable as the yes's.
 
     -   **Deliberate deviations from the obvious path.** "We're using
         manual SQL instead of an ORM because X." Anything where a reasonable
@@ -1091,7 +1090,7 @@ its purpose, and the alternatives that were considered but not chosen.
         to bootstrap application parameters.
 
     -   **Configuration Parsing**:
-        Load and parse directives from configuration file to bootstrap
+        Load and parse directives from a configuration file to bootstrap
         application parameters.
 
     -   **Process Daemonizing**:
@@ -1103,7 +1102,7 @@ its purpose, and the alternatives that were considered but not chosen.
         and control them during the life-cycle of the application.
 
     -   **Component Management**:
-        Structure the code into components, instantiate them under run-time
+        Structure the code into components, instantiate them at run-time
         and manage them in a stateful component life-cycle.
 
     -   **Component Communication**:
@@ -1151,7 +1150,7 @@ its purpose, and the alternatives that were considered but not chosen.
         measurement information at certain points of interest.
 
     -   **Database Access**:
-        Map in-memory domain entities onto data store dependent persistent
+        Map in-memory domain entities onto a data-store-dependent persistent
         data structure.
 
     -   **Database Connectivity**:

package/plugin/meta/ase-format-spec.md

@@ -28,7 +28,7 @@ is the timestamp when this **Artifact** was created. The
 <timestamp-modified/> is the timestamp when this **Artifact** was last
 modified. Both use an ISO-style format value. The value of both can be
 determined by a call to the `ase_timestamp(format: "yyyy-LL-dd HH:mm")`
-tool of the `ase` MCP server and use the `text` field of its response.
+tool of the `ase` MCP server, using the `text` field of its response.
 Whenever an **Artifact** is updated, the <timestamp-modified/> *MUST* be
 updated, too.
 
@@ -122,7 +122,6 @@ SPEC-06-BR Business Rules    ──(constrains)─►     SPEC-05-NR Non-Functio
 SPEC-08-SM State Model       ──(of entity)─►      SPEC-07-DM Data Model
 SPEC-10-UC Use Cases         ──(use case actor)─► SPEC-02-PE Personas
 SPEC-10-UC Use Cases         ──(realizes)─►       SPEC-04-FR Functional Requirements
-SPEC-10-UC Use Cases         ──(transitions)─►    SPEC-08-SM State Model
 SPEC-11-TC Test Cases        ──(verifies)─►       SPEC-04-FR Functional Requirements
 SPEC-11-TC Test Cases        ──(verifies)─►       SPEC-05-NR Non-Functional Requirements
 SPEC-15-DS Dialog Storyboard ──(scenario)─►       SPEC-10-UC Use Cases
@@ -221,7 +220,7 @@ capturing their goals, needs, behaviors, and context.
         in total not longer than 30 characters), derived from
         <spec-pe-persona-name/>.
 
-    -   <spec-pe-persona-name/>: per-artifact unique first name of fictional
+    -   <spec-pe-persona-name/>: per-artifact unique first name of the fictional
         described person.
 
     -   <spec-pe-persona-gender/>: the gender of the persona: `male`,
@@ -231,7 +230,7 @@ capturing their goals, needs, behaviors, and context.
 
     -   <spec-pe-persona-role/>: the role of the persona.
 
-    -   <spec-pe-persona-quote/>: a short and bold, first-person statement -
+    -   <spec-pe-persona-quote/>: a short and bold first-person statement -
         written in the persona's own voice - that captures their core
         attitude, motivation, frustration, or need in a single memorable line.
         It's sometimes called the persona's "tagline," "mantra," or "defining
@@ -287,12 +286,12 @@ over time.
 
     -   <spec-cj-step-stage/> is one of:
 
-        -   `Awareness`:     Customer is not aware of solution, but has a need.
-        -   `Consideration`: Customer is aware of solution, and should consider its use.
+        -   `Awareness`:     Customer is not aware of the solution, but has a need.
+        -   `Consideration`: Customer is aware of the solution, and should consider its use.
         -   `Decision`:      Customer wants to pick the solution.
         -   `Onboarding`:    Customer is using the solution.
-        -   `Retention`:     Customer in the long-term stays a customer.
-        -   `Advocacy`:      Customer is a fan of solution and tells the tribe.
+        -   `Retention`:     Customer in the long term stays a customer.
+        -   `Advocacy`:      Customer is a fan of the solution and tells the tribe.
 
     -   <spec-cj-step-actor/> is a `SPEC-PE-<spec-pe-persona-id/>` reference to the
         corresponding **Aspect** of the Personas **Artifact**.
@@ -564,7 +563,7 @@ manages, defining how information is organized and connected.
 
     ### RELATIONS
 
-    -   `<spec-dm-relation-id/>`: [`<spec-dm-relation-target/>`](#<spec-dm-relation-target-id/>)(`<spec-dm-relation-cardinality/>`):<br/>
+    -   `<spec-dm-relation-id/>`: [`<spec-dm-relation-target/>`](#SPEC-DM-<spec-dm-relation-target-id/>)(`<spec-dm-relation-cardinality/>`):<br/>
         <spec-dm-relation-description/>,
         **BECAUSE** <spec-dm-relation-rationale/>.
 
@@ -664,12 +663,12 @@ manages, defining how information is organized and connected.
         -   `Type`          (`<spec-dm-attribute-qualifier/><spec-dm-attribute-type/>`)
         -   `Description`   (`<spec-dm-attribute-description/>, **BECAUSE** <spec-dm-attribute-rationale/>.`)
 
-    -   <export-table-2/> is a Markdown table for the relation with one
+    -   <export-table-2/> is a Markdown table for the relations with one
         row per <spec-dm-relation-id/>, sorted by <spec-dm-relation-id/> --
         with the columns:
 
         -   `Relation`      (`**<spec-dm-relation-id/>**`)
-        -   `Target`        (`[<spec-dm-relation-target/>](#<spec-dm-relation-target-id/>) (<spec-dm-relation-cardinality/>)`)
+        -   `Target`        (`[<spec-dm-relation-target/>](#SPEC-DM-<spec-dm-relation-target-id/>) (<spec-dm-relation-cardinality/>)`)
         -   `Description`   (`<spec-dm-relation-description/>, **BECAUSE** <spec-dm-relation-rationale/>.`)
 
     -   In case a <spec-dm-entity/> has no relations at all, the

package/plugin/meta/ase-format-task.md

@@ -139,14 +139,14 @@ You *MUST* honor the following hints on this *task* format:
     task plan was last modified. Both use an ISO-style format
     value. The value of both can be determined by a call to the
     `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the `ase` MCP
-    server and use the `text` field of its response.
+    server, using the `text` field of its response.
 
 -   The <title/> is a short summary of the <summary-what/>, no longer than
     50 characters.
 
 -   The sections `##  CHANGES` and `##  VERIFICATION` are each just a short
     list of 1-5 bullet points. Each bullet point is formatted as
-    `- **<aspect/>**: <specification/>` where <aspect/> indicates
+    `-   **<aspect/>**: <specification/>` where <aspect/> indicates
     the aspect of the section and <specification/> is 1-3 sentences
     giving an *ultra precise* but also *ultra brief* and *ultra concise*
     description of the aspect.

package/plugin/meta/ase-getopt.md

@@ -36,7 +36,7 @@ set placeholders into the context as a side-effect.
         Additionally, simulate <getopt-info/> as a comma-separated
         markdown rendering of the parsed options in the form `<longN/>:
         **<valueN/>**, [...]` (joined with `, `, with each value
-        shell-quoted if value contains spaces or special characters, and
+        shell-quoted if the value contains spaces or special characters, and
         excluding the `help` option and any *internal* option whose long
         name starts with `int-`).
 

package/plugin/meta/ase-persona.md

@@ -61,7 +61,7 @@ requested communication style at any time during a session.
         -   <keywords/> is only one to four keywords summarizing the <details/>
         -   <details/> is one to four concise prose sentences explaining the aspect
 
--   If <ase-persona-style/> is `telegrapher`, or `caveman`:
+-   If <ase-persona-style/> is `telegrapher` or `caveman`:
     -   You *MUST* *use only* bullet point lists without blank lines between bullet points.
     -   You *MUST* *use only* one bullet point per explanation aspect.
     -   You *MUST* *use* shorter synonyms
@@ -89,13 +89,13 @@ requested communication style at any time during a session.
             -   `<subject/> ▶ <action/> ▷ <object/>.`
             -   `<subject/> ▶ <action/>.`
             Each of <subject/>, <action/>, <object/>, and <reason/>
-            are just one to six words.
+            is just one to six words.
 
 -   If <ase-persona-style/> is `caveman`:
     -   You *MUST* structure every bullet point by
         following exactly the formatting `○ <core/>`, where:
         <core/> is a *very terse core* stating the essence of the aspect
-        using one of the following three sentence patterns:
+        using one of the following four sentence patterns:
         -   `<expression/>!`
         -   `<subject/> <action/> <object/>, <reason/>.`
         -   `<subject/> <action/> <object/>.`

package/plugin/meta/ase-skill.md

@@ -13,7 +13,7 @@ Skill Output
     the value of a placeholder named `xxx`.
 
 -   *IMPORTANT*: *All* output is *exclusively* requested through
-    <template/> sections. You *MUST* *NOT* output anything *EXCEPT* it
+    <template/> sections. You *MUST* *NOT* output anything *UNLESS* it
     is explicitly included in such a <template/> section. Especially,
     you *MUST* *NOT* output any explanations on your own, unless
     explicitly requested.
@@ -95,8 +95,8 @@ Skill Output
 
         -   *Fix conflicts with documented priority*: the
             recommendation would violate a documented priority
-            (hot-path, allocation-free, lock-free, latency-
-            sensitive, sub-µs budget). Either weaken the
+            (hot-path, allocation-free, lock-free,
+            latency-sensitive, sub-µs budget). Either weaken the
             recommendation, convert it to a tradeoff, or mark
             severity `ACCEPTED` with note "priority-conflict
             accepted".
@@ -113,7 +113,7 @@ Skill Sequential Processing
     Each `<step id="xxx" [...]>...</step>` corresponds to a
     `TaskCreate({ subject: "xxx", description: "xxx" })`. In other
     words, use the text of the `id` attribute of <step/> exactly
-    *as-is* for both the `subject`, and the `description` fields of
+    *as-is* for both the `subject` and the `description` fields of
     `TaskCreate`.
 
     For speed, emit *all* `TaskCreate` calls together in a *single* turn
@@ -121,7 +121,7 @@ Skill Sequential Processing
     rely on the call order to establish the step order, as the parallel
     results carry no guaranteed ordering.
 
-    Instead, in the *immediately single following* turn, first
+    Instead, in the *single immediately following* turn, first
     reconstruct the step-id-to-taskId mapping: because each task's
     `subject` equals the originating <step/> `id` (and <step/> ids are
     unique), match every created task back to its <step/> by comparing
@@ -138,7 +138,7 @@ Skill Sequential Processing
     predecessor step (with `taskId` <prev/>).
 
 -   *IMPORTANT*: For each <step/> you *MUST* use the `TaskUpdate` tool
-    for updating its status *during* processing, once a <step/> finished.
+    for updating its status *during* processing, once a <step/> has finished.
 
 -   *IMPORTANT*: Whenever a skill *stops early* -- because a <step/>
     instructed you to *STOP* processing (on an error, a cancelled
@@ -151,12 +151,12 @@ Skill Sequential Processing
 
 -   *IMPORTANT*: You *MUST* *strictly sequentially* execute every <step/> in
     a <flow/>. You *MUST* not implicitly skip any <step/> during
-    processing, except you were explicitly requested to do this or the
+    processing, unless you were explicitly requested to do this or the
     step is configured to be a conditional step!
 
 -   *IMPORTANT*: You *MUST* *strictly sequentially* execute every numbered
     item in a <step/>. You *MUST* not implicitly skip any numbered item during
-    processing, except you were explicitly requested to do this!
+    processing, unless you were explicitly requested to do this!
 
 -   *IMPORTANT*: For any <step/> that specifies an *agent* in its
     `agent="[...]"` XML attribute, you *MUST* use the specified
@@ -252,7 +252,7 @@ Skill Identification
 
 -   *IMPORTANT*:
     You *MUST* *NOT* output any summaries, explanations, or next
-    steps at the end of a skill beside the explicit outputs via any
+    steps at the end of a skill besides the explicit outputs via any
     <template/>.
 
 Artifact Boxing Transparency
@@ -291,7 +291,7 @@ Artifact Boxing Transparency
         -   Findings surfaced: *none* (report only the *outcome*)
         -   Internals exposed: *none* (no diffs, no code, no per-artifact explanation)
 
--   *IMPORTANT*: Precedence rule: skill's *explicit* `black` branches
+-   *IMPORTANT*: Precedence rule: a skill's *explicit* `black` branches
     deterministically skip or suppress and *win* over the implicit decisions
     above. Where no such branches exist, the decisions above apply.
 
@@ -458,19 +458,6 @@ Template Patterns
         Do not output anything.
     </else>
 
--   When `<ase-tpl-boxline><line/></ase-tpl-boxline>` should be expanded, use:
-
-    <if condition="<line/> is not empty">
-        <template>
-        │ <line/>
-        </template>
-    </if>
-    <else>
-        <template>
-        │
-        </template>
-    </else>
-
 -   When `<ase-tpl-boxed title="<title/>"[ subtitle="<subtitle/>"]><content/></ase-tpl-boxed>`
     should be expanded use the following helper placeholders and then
     the following <template/>:
@@ -487,7 +474,10 @@ Template Patterns
         un-styled text <raw-title/>.
     -   Set <bar/> to the `─` character repeated exactly max(0, 67 - <raw-title-len/>)
         times -- clamped to zero so an over-long title never yields a negative count.
-    -   Set <body/> to <content/> with all line-starts prefixed with `│ `.
+    -   Set <body/> to <content/> with all non-empty lines prefixed with
+        `│ ` and all empty lines prefixed with just `│` (so no trailing
+        whitespace is produced). Do *not* prefix any line twice -- the
+        <content/> itself *MUST* *NOT* contain any `│` prefixes already.
 
     <template>
 

package/plugin/meta/ase-tenets.md

@@ -37,9 +37,9 @@ you *MUST* honor the following so-called **GENERIC TENETS**:
     -   Handle obvious or expected errors near the origin.
     -   Handle theoretical or unexpected errors in parent scopes.
     -   Avoid introducing dedicated state variables for individual error cases.
-    -   If state variables are needed to detect error cases, use minimum
+    -   If state variables are needed to detect error cases, use the minimum
         number of those variables only.
-    -   Use minimum number of state variables to span the maximum of error space.
+    -   Use the minimum number of state variables to span the maximum of error space.
 
 -   **Surgical Changes**:
     *Keep changes as small as possible.*
@@ -61,7 +61,7 @@ you *MUST* honor the following so-called **GENERIC TENETS**:
     -   When one concern changes, the change should not ripple into unrelated ones.
 
 -   **Code Base Alignment**:
-    *Blend in. New aspect should read as if the existing aspects wrote it.*
+    *Blend in. A new aspect should read as if the existing aspects wrote it.*
     -   Follow the established coding style, formatting, and idioms exactly.
     -   Mirror the existing structure, layering, and file organization.
     -   Reuse the prevailing naming conventions, patterns, and libraries.
@@ -150,12 +150,12 @@ you *MUST* honor the following so-called **RECONCILIATION TENETS**:
     Re-express source facts at the *target's* level of abstraction and
     altitude; do not copy verbatim across artifact levels. A SPEC states
     intent, an ARCH states structure, CODE states realization, DOCS
-    states facts, etc -- align the *meaning*, not the wording.
+    states facts, etc. -- align the *meaning*, not the wording.
 
 -   **Format Conformance**:
     Keep every formatted target (SPEC, ARCH, TASK) conformant to its
     format contract (headings, structure, identifiers). Treat CODE,
-    DOCS, INFR, and OTHR kinds of artifacts as foreign defined, but not
+    DOCS, INFR, and OTHR kinds of artifacts as foreign-defined, but not
     as free-form.
 
 -   **Alignment Traceability**:

package/plugin/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "https://ase.tools",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "https://github.com/rse/ase/issues" },
-    "version":                              "0.9.55",
+    "version":                              "0.9.56",
     "license":                              "Apache-2.0",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -19,7 +19,7 @@
         "markdownlint-cli2":                "0.23.2",
         "eslint":                           "10.8.0",
         "@eslint/markdown":                 "8.0.3",
-        "eslint-markdown":                  "0.12.1"
+        "eslint-markdown":                  "0.13.0"
     },
     "engines": {
         "npm":                              ">=10.0.0",

package/plugin/skills/ase-arch-analyze/SKILL.md

@@ -130,7 +130,7 @@ interface quality, quality attributes, and architecture governance.
     surfaced. *Skip* the entire investigation and reporting: do *not*
     invoke any `Agent` tool and do *not* read any source, only output
     the following <template/> and then *SKIP* the remaining steps STEP 2
-    through STEP 4:
+    and STEP 3:
 
     <template>
     <ase-tpl-bullet-normal/> **ARCHITECTURE ANALYSIS**: *suppressed* (`project.boxing` is `black`)

package/plugin/skills/ase-arch-analyze/help.md

@@ -54,7 +54,7 @@ Analyze a specific module:
 ❯ /ase-arch-analyze src/core
 ```
 
-Analyze a module under an own id namespace, yielding `core-P1`, `core-T1`, ...:
+Analyze a module under its own id namespace, yielding `core-P1`, `core-T1`, ...:
 
 ```text
 ❯ /ase-arch-analyze --prefix core src/core

package/plugin/skills/ase-arch-discover/SKILL.md

@@ -78,8 +78,9 @@ for the technology stack to *provide* the *needed functionality*
         2.  Else, if a file `package.json` is found in the top-level directory
             of the project, then <stack>JavaScript</stack>.
 
-        3.  Else, if a file `build.gradle.kts` or `settings.gradle.kts`
-            is found in the top-level directory, then <stack>Kotlin</stack>.
+        3.  Else, if a file `build.gradle.kts` is found in the top-level directory and
+            is applying `kotlin`, `org.jetbrains.kotlin.jvm`, `kotlin-android`,
+            or `kotlin-multiplatform` plugins, then <stack>Kotlin</stack>.
 
         4.  Else, if a file `build.gradle` is found in the top-level directory and
             is applying `kotlin`, `org.jetbrains.kotlin.jvm`, `kotlin-android`,
@@ -89,8 +90,8 @@ for the technology stack to *provide* the *needed functionality*
             contains `kotlin-maven-plugin` or `kotlin-stdlib` dependencies, then
             <stack>Kotlin</stack>.
 
-        6.  Else, if a file `pom.xml` or `build.gradle` is found in the top-level directory
-            of the project, then <stack>Java</stack>.
+        6.  Else, if a file `pom.xml`, `build.gradle`, or `build.gradle.kts` is found
+            in the top-level directory of the project, then <stack>Java</stack>.
 
         7.  Else, use <stack>Unknown</stack>.
 
@@ -123,7 +124,7 @@ for the technology stack to *provide* the *needed functionality*
         (which alone is governed by <getopt-option-limit/>) has a
         meaningful set to choose from.
 
-        In the to be discovered candidate set of components <component-K/>
+        In the to-be-discovered candidate set of components <component-K/>
         (K=1-C, where C is the merged and deduplicated candidate count),
         remember the component name as <name-K/>, the
         official package name as <package-K/>, the latest version as
@@ -178,7 +179,8 @@ for the technology stack to *provide* the *needed functionality*
         and fetches all metadata in maximum parallel and returns an array
         of objects `{ name, version, created, updated, repository, stars,
         downloads, deps, rank }`. For each component <component-K/>
-        (K=1-C) read from its corresponding entry: <version-K/> from
+        (K=1-C) read from its corresponding entry: <name-K/> from `name`
+        (unless already known from the discovery above), <version-K/> from
         `version`, <updated-K/> from `updated`, <created-K/> from
         `created`, <repository-K/> from `repository`, <stars-K/> from
         `stars` (numeric or `N.A.`), <downloads-K/> from `downloads`

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

@@ -1,6 +1,6 @@
 ---
 name: ase-code-analyze
-argument-hint: "[--help|-h] [--performance|-p] [--security|-s] [--severity|-S=(LOW|MEDIUM|HIGH)] <source-reference>"
+argument-hint: "[--help|-h] [--performance|-p] [--security|-s] [--severity|-S=(LOW|MEDIUM|HIGH)] [--prefix|-P=<prefix>] <source-reference>"
 description: >
     Analyze the source code for problems in either the logic and
     semantics and its related control flow, performance and efficiency,

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

@@ -92,7 +92,7 @@ Analyze a directory, reporting only `MEDIUM` and `HIGH` problems:
 ❯ /ase-code-analyze -S MEDIUM src/handlers/
 ```
 
-Analyze a directory under an own id namespace, yielding `auth-P1`, `auth-P2`, ...:
+Analyze a directory under its own id namespace, yielding `auth-P1`, `auth-P2`, ...:
 
 ```text
 ❯ /ase-code-analyze --prefix auth src/auth/

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

@@ -138,91 +138,7 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 4.  <step id="STEP 4: Choose Feature Crafting 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 *feature approach*, optionally including
-        some *alternative* feature 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 feature
-            approach plus *precise* and *ultra brief and concise*
-            feature 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 crafting approach to follow?
-            A<n/>: <short-summary/>
-            [...]
-        </expand>
-
-        </if>
-        <else>
-
-        Set <n/> to the number of the feature 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="feature" arg2="crafting"></expand>
 
     </step>
 
@@ -267,74 +183,7 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
     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>
+        <expand name="code-next-dispatch"></expand>
 
     </step>
 

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

@@ -56,7 +56,7 @@ plan via `ase_task_save` and then hands off to `ase-task-edit`,
     skill. For all other head tokens, the *entire* list is forwarded
     to `ase-task-edit`, which consumes its head itself. This lets an
     entire pipeline be pre-scripted in one shot. Recognized tokens at
-    this skill: `none` (default, hand-off to `ase-task-edit`
+    this skill: `none` (default, hand off to `ase-task-edit`
     interactively), `DONE` (stop), `EDIT` (hand off to
     `ase-task-edit`), `GRILL` (hand off to `ase-task-grill`),
     `PREFLIGHT` (hand off to `ase-task-preflight`),

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

@@ -25,7 +25,7 @@ Explain Source Code
 
 <objective>
 *Analyze* the source code of <getopt-arguments/>, and its directly related source
-code and *explain* it in a *brief*, *standardized*, and *concise* way.
+code, and *explain* it in a *brief*, *standardized*, and *concise* way.
 </objective>
 
 <flow>
@@ -126,10 +126,10 @@ code and *explain* it in a *brief*, *standardized*, and *concise* way.
 4.  <step id="STEP 4: CRUXES and GOTCHAS">
     **Highlight CRUXES and GOTCHAS**.
 
-    First, tell what are the *cruxes* of the code.
+    First, tell what the *cruxes* of the code are.
     Is there something one should really *notice*?
 
-    Second, tell what are the gotchas of the code.
+    Second, tell what the gotchas of the code are.
     Is there something one could really *stumble over*?
 
     Keep your explanation *brief* and *concise*.