@rse/ase 0.9.54 → 0.9.56

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

@@ -5,12 +5,16 @@ Task
 Every *task* uses a strict and fixed format:
 
 <format>
+---
+Id:         <task-id/>
+Created:    <timestamp-created/>
+Modified:   <timestamp-modified/>
+Status:     <task-status/>
+Properties: <task-properties/>
+Kind:       <task-kind/>
+---
 
-#   TASK <task-id/>: <title/>
-
-⎈   Created:  <timestamp-created/>
-⚙   Modified: <timestamp-modified/>
-☯   Kind:     <task-kind/>
+#   TASK: <title/>
 
 ##  CONTEXT
 
@@ -34,8 +38,19 @@ Every *task* uses a strict and fixed format:
 
 You *MUST* honor the following hints on this *task* format:
 
--   You *MUST* always keep the first empty line and the last empty line.
-    If one of them is missing, add it back.
+-   The content *MUST* begin with the `---` opening delimiter of the
+    *Markdown frontmatter* as its very *first* line -- there is *no*
+    leading empty line, as any line before the `---` would degrade the
+    frontmatter into ordinary Markdown. You *MUST* always keep the empty
+    line between the closing `---` delimiter and the `#` heading, and
+    always keep the last empty line. If one of them is missing, add it
+    back.
+
+-   The *frontmatter* carries the keys `Id`, `Created`, `Modified`,
+    `Status`, `Properties`, and `Kind`, in exactly this order, with their
+    values being *unquoted* plain scalars and vertically aligned one
+    space after the longest key. Only `Id` is *mandatory* -- every other
+    key is *optional* and, when absent, falls back to its default value.
 
 -   In all descriptions, highlight *code* as
     <template>`<code/>`</template> and *key aspects* as
@@ -47,36 +62,91 @@ You *MUST* honor the following hints on this *task* format:
     is changed, what benefit results or what the rationale is behind the
     change.
 
--   The <task-id/> has to be substituted with the current value of
-    <ase-task-id/> in the current session context.
-
--   The `☯   Kind:` line states the *kind of change* the task plan
+-   The <task-id/> of the `Id:` frontmatter key has to be substituted
+    with the current value of <ase-task-id/> in the current session
+    context.
+
+-   The `Status:` frontmatter key states the current *lifecycle state*
+    of the task plan. The key is *optional* and defaults to `DRAFTED`:
+    an *absent* key reads as `DRAFTED`, and a *newly created* plan
+    carries `DRAFTED` explicitly. The <task-status/> value is *strictly*
+    one of the following eight states:
+
+    -   `DRAFTED`: plan exists but is still provisional and not yet
+        cleared for implementation.
+    -   `REJECTED`: plan was reviewed and refused, and has to be reworked
+        before it can be approved.
+    -   `APPROVED`: plan is accepted as authoritative and cleared for
+        implementation, but no work has begun.
+    -   `DEFERRED`: plan is approved and unobstructed, but its start was
+        deliberately postponed.
+    -   `STARTED`: implementation of the plan is actively underway.
+    -   `BLOCKED`: implementation is halted by an impediment which
+        someone has to remove before it can resume.
+    -   `COMPLETED`: plan was implemented in full and reached its
+        intended outcome.
+    -   `CANCELLED`: plan was terminated before completion, because it
+        failed, was called off, or became obsolete.
+
+-   The eight states form a *state machine*. Whoever sets the `Status:`
+    key *MUST* only move along one of the following transitions, whereby
+    a *single* operation *MAY* traverse *several* transitions at once if
+    it performs the corresponding stages in one go:
+
+    ```text
+    DRAFTED   ──reject───▶ REJECTED      STARTED   ──block────▶ BLOCKED
+    REJECTED  ──redraft──▶ DRAFTED       BLOCKED   ──unblock──▶ STARTED
+    DRAFTED   ──approve──▶ APPROVED      STARTED   ──complete─▶ COMPLETED
+    APPROVED  ──defer────▶ DEFERRED
+    DEFERRED  ──resume───▶ APPROVED      any non-terminal state
+    APPROVED  ──start────▶ STARTED       ──cancel───▶ CANCELLED
+    ```
+
+    `COMPLETED` and `CANCELLED` are the two *terminal* states: a plan
+    which reached one of them is *finished* and leaves the state machine.
+
+-   The `Properties:` frontmatter key states which *stages* the task
+    plan already passed through. The <task-properties/> value is
+    *strictly* either `none` or a comma-separated list of the values
+    `grilled`, `preflighted`, `implemented`, and `verified`, listed in
+    exactly this order, each at most once. The key is *optional* and
+    defaults to `none`: an *absent* key reads as `none`, and a *newly
+    created* plan carries `none` explicitly. The list only ever
+    *accumulates*: a skill *adds* its own value if still absent and
+    *MUST NOT* drop any value already present, except when a plan is
+    *recreated from scratch*, which resets it to `none`.
+
+-   The `Kind:` frontmatter key states the *kind of change* the task plan
     describes, and hence which *operation-specific tenet set* of the
     **ASE Tenets** a subsequent preflight or implementation has to
     honor. The <task-kind/> value is *strictly* one of `CRAFTING`,
-    `REFACTORING`, or `RESOLVING`, and the line is column-aligned with
-    the `⎈   Created:` and `⚙   Modified:` lines above it.
+    `REFACTORING`, or `RESOLVING`.
 
--   The `☯   Kind:` line is *optional*: a skill *authoring* or
-    *updating* a task plan *CAN* update an already present line or pass
+-   The `Kind:` frontmatter key is *optional*: a skill *authoring* or
+    *updating* a task plan *CAN* update an already present key or pass
     it through *verbatim* and *MAY* create a missing one by *inferring*
     the kind from the plan content (defaulting to `CRAFTING`). A
-    `--dry` run *never* drops this line, as `--dry` only omits the
+    `--dry` run *never* drops this key, as `--dry` only omits the
     `##  VERIFICATION` section.
 
--   The <timestamp-created/> is the timestamp when this task plan was
-    created. The <timestamp-modified/> is the timestamp when this
+-   A skill *writing* an optional key which is still *absent* inserts it
+    at its position in the key order above and re-aligns the values of
+    the whole frontmatter block.
+
+-   The <timestamp-created/> of the `Created:` frontmatter key is the
+    timestamp when this task plan was created. The <timestamp-modified/>
+    of the `Modified:` frontmatter key is the timestamp when this
     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.54",
+    "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*.