@rse/ase 0.0.37 → 0.0.39

package/dst/ase-hello.js

@@ -4,9 +4,9 @@
 **  Licensed under GPL 3.0 <https://spdx.org/licenses/GPL-3.0-only>
 */
 import { Chalk } from "chalk";
-/*  forced-color chalk instance: stdout may be a pipe, so chalk
-    auto-detection would yield level 0; force level 1 to keep
-    emitting ANSI sequences as in "ase statusline"  */
+/*  forced-color chalk instance: stdout is a pipe under Claude Code,
+    so chalk auto-detection would yield level 0; force level 1 to keep
+    emitting ANSI sequences as the original implementation did  */
 const c = new Chalk({ level: 1 });
 /*  command-line handling  */
 export default class HelloCommand {
@@ -20,7 +20,7 @@ export default class HelloCommand {
             .command("hello")
             .description("print a colored greeting message")
             .option("-s, --subject <name>", "subject to greet", "Universe")
-            .action((opts) => {
+            .action(async (opts) => {
             process.stdout.write(`${c.red(`${opts.subject} World!`)}\n`);
         });
     }

package/dst/ase-setup.js

@@ -3,6 +3,7 @@
 **  Copyright (c) 2025-2026 Dr. Ralf S. Engelschall <rse@engelschall.com>
 **  Licensed under GPL 3.0 <https://spdx.org/licenses/GPL-3.0-only>
 */
+import fs from "node:fs/promises";
 import path from "node:path";
 import { fileURLToPath } from "node:url";
 import { execa } from "execa";
@@ -24,6 +25,74 @@ export default class SetupCommand {
             throw new Error(`mandatory tool "${tool}" not found in $PATH`);
         });
     }
+    /*  determine whether a global "npm" operation requires "sudo" by
+        checking whether the npm global install root is writable by the
+        current user; on Windows or when already running as root, no
+        elevation is needed  */
+    async npmGlobalNeedsSudo() {
+        /*  Windows has no "sudo" concept here  */
+        if (process.platform === "win32")
+            return false;
+        /*  already running as root  */
+        const getuid = process.getuid;
+        if (typeof getuid === "function" && getuid.call(process) === 0)
+            return false;
+        /*  determine the npm global prefix and probe writability of the
+            directories that "npm -g" actually mutates  */
+        let prefix = "";
+        try {
+            const result = await execa("npm", ["prefix", "-g"], { stdio: "pipe" });
+            prefix = result.stdout.trim();
+        }
+        catch {
+            /*  if we cannot determine the prefix, fall back to "no sudo"  */
+            return false;
+        }
+        if (prefix === "")
+            return false;
+        const candidates = [
+            prefix,
+            path.join(prefix, "bin"),
+            path.join(prefix, "lib", "node_modules")
+        ];
+        for (const dir of candidates) {
+            try {
+                await fs.access(dir, fs.constants.W_OK);
+            }
+            catch {
+                /*  directory exists but not writable, or does not exist
+                    inside a non-writable parent: require sudo  */
+                try {
+                    await fs.access(dir, fs.constants.F_OK);
+                    return true;
+                }
+                catch {
+                    /*  directory does not exist: check parent writability  */
+                    try {
+                        await fs.access(path.dirname(dir), fs.constants.W_OK);
+                    }
+                    catch {
+                        return true;
+                    }
+                }
+            }
+        }
+        return false;
+    }
+    /*  build the (cmd, args) pair for an "npm" invocation, prefixing
+        with "sudo" when necessary for global operations  */
+    async npmCmd(args, global) {
+        if (global && await this.npmGlobalNeedsSudo()) {
+            const sudo = await which("sudo").catch(() => "");
+            if (sudo !== "") {
+                this.log.write("info", "setup: npm global install root not writable: using \"sudo\"");
+                return { cmd: "sudo", args: ["npm", ...args] };
+            }
+            this.log.write("warning", "setup: npm global install root is not writable by current user " +
+                "and \"sudo\" not found in $PATH: attempting without elevation");
+        }
+        return { cmd: "npm", args };
+    }
     /*  run a sub-process, suppressing output on success and emitting it on failure  */
     async run(cmd, args, opts = {}) {
         const { cwd, quiet = false, retries = 1, ignoreError } = opts;
@@ -118,7 +187,8 @@ export default class SetupCommand {
             }
             /*  update ASE CLI tool  */
             this.log.write("info", `setup: update: updating ASE CLI tool: ${current} -> ${latest}`);
-            await this.run("npm", ["update", "-g", "@rse/ase"]);
+            const updateCmd = await this.npmCmd(["update", "-g", "@rse/ase"], true);
+            await this.run(updateCmd.cmd, updateCmd.args);
             /*  update ASE plugin  */
             this.log.write("info", `setup: update: updating ASE ${spec.label} plugin`);
             await this.run(spec.cli, ["plugin", "marketplace", "update", "ase"]);
@@ -165,7 +235,8 @@ export default class SetupCommand {
         /*  uninstall ASE CLI tool (non-development only)  */
         if (!dev) {
             this.log.write("info", "setup: uninstall: uninstalling ASE CLI tool (origin: remote)");
-            await this.run("npm", ["uninstall", "-g", "@rse/ase"]);
+            const uninstallCmd = await this.npmCmd(["uninstall", "-g", "@rse/ase"], true);
+            await this.run(uninstallCmd.cmd, uninstallCmd.args);
         }
         return 0;
     }

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.37",
+    "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.37",
+    "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.37",
+    "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.37",
+    "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
@@ -84,19 +84,30 @@ permitted way to persist artifacts is via `task_save(...)`.
 
         Then set <feature/> to the response of the user.
 
-    4.  Report the task and feature with the following <template/>:
+    4.  <if condition="
+            <ase-task-id/> is equal `default` and
+            <feature/> is not empty
+        ">
+        Set <ase-task-id/> to a unique task id, derived from <feature/>,
+        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. Do not output anything.
+        </if>
+
+    5.  Report the task and feature with the following <template/>:
 
         <template>
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**
         ⧉ **ASE**: ⇌ feature: **<feature/>**
         </template>
 
-    5.  Figure out what the requested <feature/> to be crafted is about.
+    6.  Figure out what the requested <feature/> to be crafted is about.
 
-    6.  Ask the user for clarification if the goal of this crafting is too
+    7.  Ask the user for clarification if the goal of this crafting is too
         unclear.
 
-    7.  Do not output anything in this step, except you asked the user.
+    8.  Do not output anything in this step, except you asked the user.
 
 2.  **Investigate Code Base**:
 
@@ -108,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**:
-
-    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:
+3.  **Internalize Crafting Tenets**:
 
-        -   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.
+    Internalize and honor the following tenets.
+    Do not output anything.
 
-        -   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.
-
-        *Recommended* Tenets (generic):
+    1.  *Recommended* Tenets (generic):
 
         -   **Surgical Changes**:
             Keep source code changes always as small as possible.
@@ -159,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.
@@ -182,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
@@ -209,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
@@ -84,19 +84,30 @@ permitted way to persist artifacts is via `task_save(...)`.
 
         Then set <request/> to the response of the user.
 
-    4.  Report the task and request with the following <template/>:
+    4.  <if condition="
+            <ase-task-id/> is equal `default` and
+            <request/> is not empty
+        ">
+        Set <ase-task-id/> to a unique task id, derived from <request/>,
+        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. Do not output anything.
+        </if>
+
+    5.  Report the task and request with the following <template/>:
 
         <template>
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**
         ⧉ **ASE**: ⇌ request: **<request/>**
         </template>
 
-    5.  Figure out what the artifact refactoring <request/> is about.
+    6.  Figure out what the artifact refactoring <request/> is about.
 
-    6.  Ask the user for clarification if the goal of this refactoring is
+    7.  Ask the user for clarification if the goal of this refactoring is
         too unclear.
 
-    7.  Do not output anything in this step, except you asked the user.
+    8.  Do not output anything in this step, except you asked the user.
 
 2.  **Investigate Code Base**:
 
@@ -108,41 +119,12 @@ permitted way to persist artifacts is via `task_save(...)`.
 
     3.  Do not output anything in this step.
 
-3.  **Find Refactoring Approaches**:
-
-    1.  *Propose* corresponding *refactoring approach*, including
-        optionally, some *alternative* refactoring approaches.
-
-    2.  Annotate the approach you recommend with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`.
-
-    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:
+3.  **Internalize Refactoring Tenets**:
 
-        -   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.
+    Internalize and honor the following tenets.
+    Do not output anything.
 
-        -   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.
@@ -160,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.
@@ -169,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.
@@ -188,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
@@ -215,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

@@ -56,12 +56,13 @@ permitted way to persist artifacts is via `task_save(...)`.
 1.  **Reason About Problem**:
 
     1.  If <problem/> matches the regexp `^[PT]\d+$` (i.e. a bare issue
-        identifier like `P1`, `P2`, `T1`, `T2`, ...), set
-        <problem-id><problem/></problem-id>, call the `task_id(id:
-        <ase-task-id/>, session: <ase-session-id/>)` tool from the `ase`
-        MCP service to implicitly switch the task, and then call the
-        `kv_get(key: "ase-issue-<problem-id/>")` tool
-        of the `ase` MCP service to retrieve the previously persisted
+        identifier like `P1`, `P2`, `T1`, `T2`, ...),
+        set <problem-id><problem/></problem-id> and
+        <ase-task-id><problem/></ase-task-id>, call the `task_id(id:
+        <ase-task-id/>, session: <ase-session-id/>)` tool from the
+        `ase` MCP service to implicitly switch the task, and then
+        call the `kv_get(key: "ase-issue-<problem-id/>")` tool of
+        the `ase` MCP service to retrieve the previously persisted
         problem description. If the returned `text` is non-empty, set
         <problem><text/></problem>, otherwise complain to the user that
         no analyzer result exists for <problem-id/> and stop processing.
@@ -85,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
@@ -95,21 +96,32 @@ permitted way to persist artifacts is via `task_save(...)`.
 
         Then set <problem/> to the response of the user.
 
-    5.  Report the task and problem with the following <template/>:
+    5.  <if condition="
+            <ase-task-id/> is equal `default` and
+            <problem/> is not empty
+        ">
+        Set <ase-task-id/> to a unique task id, derived from <problem/>,
+        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. Do not output anything.
+        </if>
+
+    6.  Report the task and problem with the following <template/>:
 
         <template>
         ⧉ **ASE**: ◉ task: **<ase-task-id/>**
         ⧉ **ASE**: ⇌ problem: **<problem/>**
         </template>
 
-    6.  Figure out what the requested <problem/> is about.
+    7.  Figure out what the requested <problem/> is about.
 
-    7.  Ask the user for clarification if the goal of this resolution is
+    8.  Ask the user for clarification if the goal of this resolution is
         too unclear.
 
-    8.  Do not output anything in this step, except you asked the user.
+    9.  Do not output anything in this step, except you asked the user.
 
-    9.  Investigate and *figure out details* related to this problem.
+    10. Investigate and *figure out details* related to this problem.
         Report those details with the following <template/>:
 
         <template>
@@ -118,9 +130,9 @@ permitted way to persist artifacts is via `task_save(...)`.
         <optional-diagram/>
 
         &#x1F7E0; **PROBLEM DETAILS**: *<summary/>*
-        - [...]
-        - [...]
-        - [...]
+        ● [...]
+        ● [...]
+        ● [...]
         </template>
 
         Hints:
@@ -130,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*
@@ -151,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>
 
@@ -174,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
@@ -196,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.
@@ -238,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
@@ -272,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/>)`.
+

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

@@ -21,8 +21,10 @@ Evaluate Alternatives
 Evaluate Alternatives
 </skill>
 
+<role>
 Your role is an experienced, *expert-level assistant*,
 specialized in *evaluating alternatives*.
+</role>
 
 <objective>
 *Evaluate* *alternatives* through a weighted
@@ -73,10 +75,11 @@ multi-*criteria* decision matrix.
         over) is its single most distinguishing perspective, and remember
         this as an <info-K/> (K=1-N) formatted like `<type/>: <hint/>` where
         <type/> is one of `USP`, `Crux`, or `Gotcha` and <hint/> is a 1-6
-        word hint.
+        word hint. Do not output anything.
 
     -   For the set of alternatives, decide what the 1-6 word long
         name of the *class of alternatives* <class-of-alternatives/> is.
+        Do not output anything.
 
     -   For each alternative <alternative-K/> (K=1-N), decide whether
         it is a genuine member of <class-of-alternatives/>. If any
@@ -178,16 +181,16 @@ multi-*criteria* decision matrix.
     -   The best alternative <alternative-K/> (K=1-N) is the alternative
         whose *raw, unrounded* <rating-K/> (i.e. the product-sum from STEP
         4, *before* the display-only rounding) is the maximum rating value
-        across all alternatives.
+        across all alternatives. Do not output anything.
 
     -   The second best alternative <alternative-X/> (X=1-N, X != K) is
         the alternative whose *raw, unrounded* <rating-X/> is the second
-        largest rating value across all alternatives.
+        largest rating value across all alternatives. Do not output anything.
 
     -   If multiple alternatives share the second-largest raw rating, pick
         any one of them as <alternative-X/>; the resulting <distance/> and
         <percentage/> are unaffected by the choice, so the downstream output
-        is deterministic.
+        is deterministic. Do not output anything.
 
     -   Determine rating distance <distance/> between <alternative-K/> and
         <alternative-X/> from their *raw, unrounded* ratings by calculating:
@@ -203,6 +206,7 @@ multi-*criteria* decision matrix.
         (so a true zero tie with <distance/> = 0 falls into the
         *MULTIPLE BEST* branch below, and a non-zero gap with zero
         best falls into the *small distance* branch below).
+        Do not output anything.
 
     -   By construction, <rating-K/> is the maximum rating across
         all alternatives, so <distance/> >= 0 always holds; using
@@ -210,7 +214,7 @@ multi-*criteria* decision matrix.
         regimes. Note that when <rating-K/> itself is negative, the
         denominator anchors to a poor best rating and small gaps can
         appear large; the all-negative regime is surfaced as a dedicated
-        warning branch below.
+        warning branch below. Do not output anything.
 
     -   If <percentage/> is less than 0.01 (i.e. <distance/> is
         effectively zero relative to abs(<rating-K/>)), stop the flow after