@rse/ase 0.0.38 → 0.0.39

package/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "http://github.com/rse/ase",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "http://github.com/rse/ase/issues" },
-    "version":                              "0.0.38",
+    "version":                              "0.0.39",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",

package/plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.0.38",
+    "version":     "0.0.39",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/.github/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.0.38",
+    "version":     "0.0.39",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "http://github.com/rse/ase",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "http://github.com/rse/ase/issues" },
-    "version":                              "0.0.38",
+    "version":                              "0.0.39",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",

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

@@ -74,7 +74,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         <feature><text/></feature> and <ase-task-id><id/></ase-task-id>
         and call the `task_id(id: <ase-task-id/>, session:
         <ase-session-id/>)` tool from the `ase` MCP service to
-        implicitly switch the task.
+        implicitly switch the task. Do not output anything.
 
     3.  If <feature/> is empty,
         ask the user interactively, without a special tool, for the
@@ -92,7 +92,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         which consists of two lower-case words concatenated with a
         `-` character. Then call the `task_id(id: <ase-task-id/>,
         session: <ase-session-id/>)` tool from the `ase` MCP service to
-        implicitly switch the task.
+        implicitly switch the task. Do not output anything.
         </if>
 
     5.  Report the task and feature with the following <template/>:
@@ -119,40 +119,12 @@ permitted way to persist artifacts is via `task_save(...)`.
 
     3.  Do not output anything in this step.
 
-3.  **Find Feature Crafting Approaches**:
+3.  **Internalize Crafting Tenets**:
 
-    1.  *Propose* corresponding *feature approach*, including optionally,
-        some *alternative* feature approaches.
-
-    2.  Annotate the approach you recommend with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`.
-
-    3.  Report each approach with the following <template/>:
-
-        <template>
-        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
-        - [...]
-        - [...]
-        - [...]
-        <optional-diagram/>
-        </template>
-
-        Hints:
-
-        -   Give a short one-sentence <summary/> of the feature approach plus
-            *precise* and *brief* feature information. Try to keep the
-            number of bullet points in the range of 1-4.
-
-        -   In case of a *complex feature situation* only, visualize it with
-            an optional diagram <optional-diagram/> by invoking the
-            `ase-meta-diagram` skill via the `Skill` tool. For *current vs.
-            proposed* comparisons, render each side as a *separate*
-            `ase-meta-diagram` invocation and stack the rendered blocks
-            *vertically* (labels `**Before:**` / `**After:**`); never
-            side-by-side. Omit <optional-diagram/> entirely for simple or
-            purely local situation.
+    Internalize and honor the following tenets.
+    Do not output anything.
 
-        *Recommended* Tenets (generic):
+    1.  *Recommended* Tenets (generic):
 
         -   **Surgical Changes**:
             Keep source code changes always as small as possible.
@@ -170,20 +142,69 @@ permitted way to persist artifacts is via `task_save(...)`.
             Strictly align with the existing code base by exactly following its
             coding style, its structure, its naming conventions, etc.
 
-        *Essential* Tenets (specific):
+    2.  *Essential* Tenets (feature crafting specific):
 
         -   **High Cohesion, Low Coupling**:
             Strike for a set of small, focused parts (high cohesion) connected by
             thin, explicit wires (low coupling).
 
-4.  **Choose Feature Crafting Approach**:
+4.  **Find Feature Crafting Approaches**:
+
+    You *MUST* perform the following sub-steps *internally* and *without
+    any output* until and including the recommendation decision. Only
+    sub-step 4 below is allowed to produce output.
+
+    1.  *Propose* corresponding *feature approach*, including optionally,
+        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.  *Now* report each approach with the following <template/>,
+        inlining its pros/cons derived in sub-step 2:
+
+        <template>
+        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
+        ● [...]
+        ● [...]
+        ● [...]
+        ⊕ *pro*: [...]
+        ⊖ *con*: [...]
+        <optional-diagram/>
+        </template>
+
+        Hints:
+
+        -   Give a short one-sentence <summary/> of the feature approach plus
+            *precise* and *brief* feature information. Try to keep the
+            number of bullet points (●) in the range of 1-4.
+
+        -   In case of a *complex feature situation* only, visualize it with
+            an optional diagram <optional-diagram/> by invoking the
+            `ase-meta-diagram` skill via the `Skill` tool. For *current vs.
+            proposed* comparisons, render each side as a *separate*
+            `ase-meta-diagram` invocation and stack the rendered blocks
+            *vertically* (labels `**Before:**` / `**After:**`); never
+            side-by-side. Omit <optional-diagram/> entirely for simple or
+            purely local situation.
+
+5.  **Choose Feature Crafting Approach**:
 
     1.  If <getopt-option-auto/> is equal `false`:
         Let the *user interactively choose* the preferred feature
         approach A<n/> with the help of the <user-dialog-tool/> tool.
-        Use the header `Select Approach` and *single-selection* only
-        and provide small *code change previews*. Mark your recommended
-        feature approach with ` ⚝ **RECOMMENDATION** ⚝` here again.
+        Use the header `Select Approach`, use `A<n/>: <short-summary/>`
+        for the option (where <short-summary/> is an ultra brief summary
+        of the approach A<n/>), and *single-selection* only and provide
+        small *code change previews*. Mark your recommended feature
+        approach with ` ⚝ **RECOMMENDATION** ⚝` here again.
 
     2.  If <getopt-option-auto/> is equal `true`:
         Set <n/> to the number of the feature approach A<n/> you recommend.
@@ -193,7 +214,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
         </template>
 
-5.  **Compose Feature Crafting Plan**:
+6.  **Compose Feature Crafting Plan**:
 
     1.  *Compose a feature plan* for the chosen feature A<n/> by
         closely aligning to the existing architecture and the existing
@@ -220,59 +241,9 @@ permitted way to persist artifacts is via `task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan created**
         </template>
 
-    5.  *Determine next step*:
-
-        -   If <getopt-option-next/> matches the regex `^(DONE|EDIT|PREFLIGHT|IMPLEMENT)$`:
-            Honor the pre-selection what to do as the next step.
-            Set <result><getopt-option-next/></result>.
-
-        -   If <getopt-option-next/> is equal to `none`:
-            Let the *user interactively choose* what to do as the next step.
-
-            <expand name="user-dialog">
-                Next Step: How would you like to proceed with the plan?
-                DONE: Stop processing.
-                EDIT: Hand processing off to editing.
-                PREFLIGHT: Hand processing off to preflighting.
-                IMPLEMENT: Hand processing off to implementation.
-            </expand>
-
-    6.  Check the tool <result/> and dispatch accordingly:
-
-        -   If <result/> is `DONE` or `CANCEL`:
-            Only output the following <template/> and then *STOP*.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **done**
-            </template>
-
-        -   If <result/> is `EDIT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-edit` skill in
-            order to edit the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to edit**
-            </template>
-
-        -   If <result/> is `PREFLIGHT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-preflight` skill in
-            order to preflight the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to preflight**
-            </template>
-
-        -   If <result/> is `IMPLEMENT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-implement` skill in
-            order to implement the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to implement**
-            </template>
+    5.  Directly pass-through control to the `ase:ase-task-edit` skill.
+        Set <args></args> (set args to empty). If <getopt-option-next/>
+        is not equal `none`, set <args><args/> --next
+        <getopt-option-next/></args> (append to args). Then call the
+        tool `Skill(skill: "ase:ase-task-edit", args: <args/>)`.
 

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

@@ -74,7 +74,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         <request><text/></request> and <ase-task-id><id/></ase-task-id>
         and call the `task_id(id: <ase-task-id/>, session:
         <ase-session-id/>)` tool from the `ase` MCP service to
-        implicitly switch the task.
+        implicitly switch the task. Do not output anything.
 
     3.  If <request/> is empty,
         ask the user interactively, without a special tool, for the
@@ -92,7 +92,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         which consists of two lower-case words concatenated with a
         `-` character. Then call the `task_id(id: <ase-task-id/>,
         session: <ase-session-id/>)` tool from the `ase` MCP service to
-        implicitly switch the task.
+        implicitly switch the task. Do not output anything.
         </if>
 
     5.  Report the task and request with the following <template/>:
@@ -119,41 +119,12 @@ permitted way to persist artifacts is via `task_save(...)`.
 
     3.  Do not output anything in this step.
 
-3.  **Find Refactoring Approaches**:
+3.  **Internalize Refactoring Tenets**:
 
-    1.  *Propose* corresponding *refactoring approach*, including
-        optionally, some *alternative* refactoring approaches.
-
-    2.  Annotate the approach you recommend with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`.
+    Internalize and honor the following tenets.
+    Do not output anything.
 
-    3.  Report each approach with the following <template/>
-        and do not output anything else in this step:
-
-        <template>
-        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
-        - [...]
-        - [...]
-        - [...]
-        <optional-diagram/>
-        </template>
-
-        Hints:
-
-        -   Give a short one-sentence <summary/> of the refactoring approach plus
-            *precise* and *brief* refactoring information. Try to keep the
-            number of bullet points in the range of 1-4.
-
-        -   In case of a *complex refactoring situation* only, visualize it with
-            an optional diagram <optional-diagram/> by invoking the
-            `ase-meta-diagram` skill via the `Skill` tool. For *current vs.
-            proposed* comparisons, render each side as a *separate*
-            `ase-meta-diagram` invocation and stack the rendered blocks
-            *vertically* (labels `**Before:**` / `**After:**`); never
-            side-by-side. Omit <optional-diagram/> entirely for simple or
-            purely local situation.
-
-        *Recommended* Tenets (generic):
+    1.  *Recommended* Tenets (generic):
 
         -   **Surgical Changes**:
             Keep source code changes always as small as possible.
@@ -171,7 +142,7 @@ permitted way to persist artifacts is via `task_save(...)`.
             Strictly align with the existing code base by exactly following its
             coding style, its structure, its naming conventions, etc.
 
-        *Essential* Tenets (specific):
+    2.  *Essential* Tenets (refactoring specific):
 
         -   **Boy Scout Rule**:
             After the refactoring, leave the code base cleaner than you found it.
@@ -180,16 +151,65 @@ permitted way to persist artifacts is via `task_save(...)`.
             Strike for a set of small, focused parts (high cohesion) connected by
             thin, explicit wires (low coupling).
 
-4.  **Choose Refactoring Approach**:
+4.  **Find Refactoring Approaches**:
+
+    You *MUST* perform the following sub-steps *internally* and *without
+    any output* until and including the recommendation decision. Only
+    sub-step 4 below is allowed to produce output.
+
+    1.  *Propose* corresponding *refactoring approach*, including
+        optionally, 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.  *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>
+        &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
+        ● [...]
+        ● [...]
+        ● [...]
+        ⊕ *pro*: [...]
+        ⊖ *con*: [...]
+        <optional-diagram/>
+        </template>
+
+        Hints:
+
+        -   Give a short one-sentence <summary/> of the refactoring approach plus
+            *precise* and *brief* refactoring information. Try to keep the
+            number of bullet points (●) in the range of 1-4.
+
+        -   In case of a *complex refactoring situation* only, visualize it with
+            an optional diagram <optional-diagram/> by invoking the
+            `ase-meta-diagram` skill via the `Skill` tool. For *current vs.
+            proposed* comparisons, render each side as a *separate*
+            `ase-meta-diagram` invocation and stack the rendered blocks
+            *vertically* (labels `**Before:**` / `**After:**`); never
+            side-by-side. Omit <optional-diagram/> entirely for simple or
+            purely local situation.
+
+5.  **Choose Refactoring Approach**:
 
     1.  If <getopt-option-auto/> is equal `false`:
         Let the *user interactively choose* the preferred refactoring
         approach A<n/> with the help of the <user-dialog-tool/> tool.
-        Use the header `Select Approach` and *single-selection* only
-        and provide small *code change previews*. Mark your recommended
-        refactoring approach with ` ⚝ **RECOMMENDATION** ⚝` here again.
-        Except for the interactive selection, do not output anything in
-        this step.
+        Use the header `Select Approach`, use `A<n/>: <short-summary/>`
+        for the option (where <short-summary/> is an ultra brief summary
+        of the approach A<n/>), and *single-selection* only and provide
+        small *code change previews*. Mark your recommended refactoring
+        approach with ` ⚝ **RECOMMENDATION** ⚝` here again. Except for
+        the interactive selection, do not output anything in this step.
 
     2.  If <getopt-option-auto/> is equal `true`:
         Set <n/> to the number of the refactoring approach A<n/> you recommend.
@@ -199,7 +219,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
         </template>
 
-5.  **Compose Refactoring Plan**:
+6.  **Compose Refactoring Plan**:
 
     1.  *Compose a refactoring plan* for the chosen refactoring A<n/> by
         closely aligning to the existing architecture and the existing
@@ -226,58 +246,9 @@ permitted way to persist artifacts is via `task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan created**
         </template>
 
-    5.  *Determine next step*:
-
-        -   If <getopt-option-next/> matches the regex `^(DONE|EDIT|PREFLIGHT|IMPLEMENT)$`:
-            Honor the pre-selection what to do as the next step.
-            Set <result><getopt-option-next/></result>.
-
-        -   If <getopt-option-next/> is equal to `none`:
-            Let the *user interactively choose* what to do as the next step.
-
-            <expand name="user-dialog">
-                Next Step: How would you like to proceed with the plan?
-                DONE: Stop processing.
-                EDIT: Hand processing off to editing.
-                PREFLIGHT: Hand processing off to preflighting.
-                IMPLEMENT: Hand processing off to implementation.
-            </expand>
-
-    6.  Check the tool <result/> and dispatch accordingly:
-
-        -   If <result/> is `DONE` or `CANCEL`:
-            Only output the following <template/> and then *STOP*.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **done**
-            </template>
-
-        -   If <result/> is `EDIT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-edit` skill in
-            order to edit the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to edit**
-            </template>
-
-        -   If <result/> is `PREFLIGHT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-preflight` skill in
-            order to preflight the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to preflight**
-            </template>
-
-        -   If <result/> is `IMPLEMENT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-implement` skill in
-            order to implement the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to implement**
-            </template>
+    5.  Directly pass-through control to the `ase:ase-task-edit` skill.
+        Set <args></args> (set args to empty). If <getopt-option-next/>
+        is not equal `none`, set <args><args/> --next
+        <getopt-option-next/></args> (append to args). Then call the
+        tool `Skill(skill: "ase:ase-task-edit", args: <args/>)`.
+

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

@@ -86,7 +86,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         <problem><text/></problem> and <ase-task-id><id/></ase-task-id>
         and call the `task_id(id: <ase-task-id/>, session:
         <ase-session-id/>)` tool from the `ase` MCP service to
-        implicitly switch the task.
+        implicitly switch the task. Do not output anything.
 
     4.  If <problem/> is empty,
         ask the user interactively, without a special tool, for the
@@ -104,7 +104,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         which consists of two lower-case words concatenated with a
         `-` character. Then call the `task_id(id: <ase-task-id/>,
         session: <ase-session-id/>)` tool from the `ase` MCP service to
-        implicitly switch the task.
+        implicitly switch the task. Do not output anything.
         </if>
 
     6.  Report the task and problem with the following <template/>:
@@ -130,9 +130,9 @@ permitted way to persist artifacts is via `task_save(...)`.
         <optional-diagram/>
 
         &#x1F7E0; **PROBLEM DETAILS**: *<summary/>*
-        - [...]
-        - [...]
-        - [...]
+        ● [...]
+        ● [...]
+        ● [...]
         </template>
 
         Hints:
@@ -142,7 +142,7 @@ permitted way to persist artifacts is via `task_save(...)`.
 
         - Give a short one-sentence <summary/> of the <problem/> plus *precise*
           but *brief* code processing information to understand the problem.
-          Try to keep the number of bullet points in the range of 1-4.
+          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*
@@ -163,22 +163,66 @@ permitted way to persist artifacts is via `task_save(...)`.
 
     3.  Do not output anything in this step.
 
-3.  **Find Problem Resolution Approaches**:
+3.  **Internalize Problem Resolution Tenets**:
+
+    Internalize and honor the following tenets.
+    Do not output anything.
+
+    1.  *Recommended* Tenets (generic):
+
+        -   **Surgical Changes**:
+            Keep source code changes always as small as possible.
+
+        -   **Separation of Concerns**:
+            Clearly separate all individual concerns as good as possible.
+
+        -   **Single Responsibility Principle**:
+            Every module, class, or function should have only one reason to change.
+
+        -   **Behavior Preservation**:
+            Refactoring changes only re-structure, never change any observable behavior.
+
+        -   **Align with Code Base**:
+            Strictly align with the existing code base by exactly following its
+            coding style, its structure, its naming conventions, etc.
+
+    2.  *Essential* Tenets (problem resolving specific):
+
+        -   **No Cleanups**:
+            Strictly focus on resolving the problem and do not mix this task
+            with any other necessary code cleanups, except they are really
+            necessary for resolving the task.
+
+4.  **Find Problem Resolution Approaches**:
+
+    You *MUST* perform the following sub-steps *internally* and *without
+    any output* until and including the recommendation decision. Only
+    sub-step 4 below is allowed to produce output.
 
     1.  *Propose* corresponding *resolution approach*, including optionally,
-        some *alternative* resolution approaches.
+        some *alternative* resolution approaches. Do *not* output anything
+        in this sub-step.
 
-    2.  Annotate the approach you recommend with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`.
+    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.  Report each approach with the following <template/>
-        and do not output anything else in this 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.  *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>
         &#x1F535; **APPROACH A<n/>**<annotation/>: *<summary/>*
-        - [...]
-        - [...]
-        - [...]
+        ● [...]
+        ● [...]
+        ● [...]
+        ⊕ *pro*: [...]
+        ⊖ *con*: [...]
         <optional-diagram/>
         </template>
 
@@ -186,7 +230,7 @@ permitted way to persist artifacts is via `task_save(...)`.
 
         -   Give a short one-sentence <summary/> of the resolution approach plus
             *precise* and *brief* resolution information. Try to keep the
-            number of bullet points in the range of 1-4.
+            number of bullet points (●) in the range of 1-4.
 
         -   Focus on resolution approaches for *practically relevant* cases and do *not*
             investigate on theoretical or fictive cases. This is especially the case
@@ -208,39 +252,16 @@ permitted way to persist artifacts is via `task_save(...)`.
             side-by-side. Omit <optional-diagram/> entirely for simple or
             purely local situation.
 
-        *Recommended* Tenets (generic):
-
-        -   **Surgical Changes**:
-            Keep source code changes always as small as possible.
-
-        -   **Separation of Concerns**:
-            Clearly separate all individual concerns as good as possible.
-
-        -   **Single Responsibility Principle**:
-            Every module, class, or function should have only one reason to change.
-
-        -   **Behavior Preservation**:
-            Refactoring changes only re-structure, never change any observable behavior.
-
-        -   **Align with Code Base**:
-            Strictly align with the existing code base by exactly following its
-            coding style, its structure, its naming conventions, etc.
-
-        *Essential* Tenets (specific):
-
-        -   **No Cleanups**:
-            Strictly focus on resolving the problem and do not mix this task
-            with any other necessary code cleanups, except they are really
-            necessary for resolving the task.
-
-4.  **Choose Problem Resolution Approach**:
+5.  **Choose Problem Resolution Approach**:
 
     1.  If <getopt-option-auto/> is equal `false`:
         Let the *user interactively choose* the preferred resolution
         approach A<n/> with the help of the <user-dialog-tool/> tool.
-        Use the header `Select Approach` and *single-selection* only
-        and provide small *code change previews*. Mark your recommended
-        resolution approach with ` ⚝ **RECOMMENDATION** ⚝` here again.
+        Use the header `Select Approach`, use `A<n/>: <short-summary/>`
+        for the option (where <short-summary/> is an ultra brief summary
+        of the approach A<n/>), and *single-selection* only and provide
+        small *code change previews*. Mark your recommended resolution
+        approach with ` ⚝ **RECOMMENDATION** ⚝` here again.
 
     2.  If <getopt-option-auto/> is equal `true`:
         Set <n/> to the number of the resolution approach A<n/> you recommend.
@@ -250,7 +271,7 @@ permitted way to persist artifacts is via `task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
         </template>
 
-5.  **Compose Problem Resolution Plan**:
+6.  **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
@@ -284,58 +305,9 @@ permitted way to persist artifacts is via `task_save(...)`.
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan created**
         </template>
 
-    6.  *Determine next step*:
-
-        -   If <getopt-option-next/> matches the regex `^(DONE|EDIT|PREFLIGHT|IMPLEMENT)$`:
-            Honor the pre-selection what to do as the next step.
-            Set <result><getopt-option-next/></result>.
-
-        -   If <getopt-option-next/> is equal to `none`:
-            Let the *user interactively choose* what to do as the next step.
-
-            <expand name="user-dialog">
-                Next Step: How would you like to proceed with the plan?
-                DONE: Stop processing.
-                EDIT: Hand processing off to editing.
-                PREFLIGHT: Hand processing off to preflighting.
-                IMPLEMENT: Hand processing off to implementation.
-            </expand>
-
-    7.  Check the tool <result/> and dispatch accordingly:
-
-        -   If <result/> is `DONE` or `CANCEL`:
-            Only output the following <template/> and then *STOP*.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **done**
-            </template>
-
-        -   If <result/> is `EDIT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-edit` skill in
-            order to edit the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to edit**
-            </template>
-
-        -   If <result/> is `PREFLIGHT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-preflight` skill in
-            order to preflight the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to preflight**
-            </template>
-
-        -   If <result/> is `IMPLEMENT`:
-            Only output the following <template/> and then use the
-            `Skill` tool to invoke the `ase:ase-task-implement` skill in
-            order to implement the plan. Immediately stop processing the
-            current skill once the `Skill` tool was used.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **hand off to implement**
-            </template>
+    6.  Directly pass-through control to the `ase:ase-task-edit` skill.
+        Set <args></args> (set args to empty). If <getopt-option-next/>
+        is not equal `none`, set <args><args/> --next
+        <getopt-option-next/></args> (append to args). Then call the
+        tool `Skill(skill: "ase:ase-task-edit", args: <args/>)`.
+