@rse/ase 0.0.38 → 0.0.40

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

@@ -11,6 +11,7 @@ allowed-tools:
     - "Skill"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
@@ -74,7 +75,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 +93,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 +120,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** ⚝`.
-
-    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>
+    Internalize and honor the following tenets.
+    Do not output anything.
 
-        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 +143,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 +152,69 @@ 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 building a Mermaid specification <mermaid-spec/>
+            (e.g. `flowchart TB`, `stateDiagram-v2`, `sequenceDiagram`,
+            `classDiagram`, or `erDiagram`, depending on intent) and
+            invoking the `ase-meta-diagram` skill by calling the tool
+            `Skill(skill: "ase:ase-meta-diagram", args: <mermaid-spec/>)`.
+            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 +224,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 +251,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

@@ -11,6 +11,7 @@ allowed-tools:
     - "Skill"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
@@ -86,7 +87,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 +105,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 +131,9 @@ permitted way to persist artifacts is via `task_save(...)`.
         <optional-diagram/>
 
         &#x1F7E0; **PROBLEM DETAILS**: *<summary/>*
-        - [...]
-        - [...]
-        - [...]
+        ● [...]
+        ● [...]
+        ● [...]
         </template>
 
         Hints:
@@ -142,7 +143,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*
@@ -150,7 +151,11 @@ permitted way to persist artifacts is via `task_save(...)`.
           transitions, etc), complex *data flow* (actors, messages, etc), or
           complex *data structure* (classes, entities, relationships, etc),
           visualize it with an optional diagram <optional-diagram/> by
-          invoking the `ase-meta-diagram` skill via the `Skill` tool. Omit
+          building a Mermaid specification <mermaid-spec/> (e.g. `flowchart
+          TB`, `stateDiagram-v2`, `sequenceDiagram`, `classDiagram`, or
+          `erDiagram`, depending on intent) and invoking the
+          `ase-meta-diagram` skill by calling the tool `Skill(skill:
+          "ase:ase-meta-diagram", args: <mermaid-spec/>)`. Omit
           <optional-diagram/> entirely for simple or purely local situation.
 
 2.  **Investigate Code Base**:
@@ -163,22 +168,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 +235,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
@@ -199,48 +248,29 @@ permitted way to persist artifacts is via `task_save(...)`.
             or unexpected* errors, they *should* be handled in parent scopes to
             avoid cluttering the source code with too much error handling at all.
 
-        -   In case of a *complex resolution 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):
-
-        -   **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**:
+        -   In case of a *complex resolution situation* only,
+            visualize it with an optional diagram <optional-diagram/>
+            by building a Mermaid specification <mermaid-spec/>
+            (e.g. `flowchart TB`, `stateDiagram-v2`, `sequenceDiagram`,
+            `classDiagram`, or `erDiagram`, depending on intent) and
+            invoking the `ase-meta-diagram` skill by calling the tool
+            `Skill(skill: "ase:ase-meta-diagram", args: <mermaid-spec/>)`.
+            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 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 +280,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 +314,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-changes/SKILL.md

@@ -14,6 +14,7 @@ allowed-tools:
     - "Edit"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

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

@@ -18,6 +18,7 @@ allowed-tools:
     - "Agent"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

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

@@ -10,6 +10,7 @@ allowed-tools:
     - "Bash(git diff *)"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

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

@@ -11,6 +11,7 @@ disable-model-invocation: false
 effort: high
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

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

@@ -49,4 +49,5 @@ Persona Configuration
 Apply Persona
 -------------
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md

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

@@ -11,6 +11,7 @@ allowed-tools:
     - "TaskCreate"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

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

@@ -15,6 +15,7 @@ allowed-tools:
     - "Task"
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

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

@@ -8,6 +8,7 @@ disable-model-invocation: false
 effort: medium
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

package/plugin/skills/ase-task-delete/SKILL.md

@@ -10,6 +10,7 @@ disable-model-invocation: false
 effort: low
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 

package/plugin/skills/ase-task-edit/SKILL.md

@@ -12,6 +12,7 @@ disable-model-invocation: false
 effort: high
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
@@ -344,8 +345,8 @@ explicitly requested by this procedure via outputs based on a <template/>!
         -   If <result/> is `IMPLEMENT`:
 
             *Break* out of the *loop*, only output the following
-            <template/> and then use the `Skill` tool to invoke the
-            `ase:ase-task-implement` skill in order to *apply* the finalized
+            <template/> and then call the `Skill(skill:
+            "ase:ase-task-implement")` tool to *apply* the finalized
             plan.
 
             <template>
@@ -355,8 +356,8 @@ explicitly requested by this procedure via outputs based on a <template/>!
         -   If <result/> is `PREFLIGHT`:
 
             *Break* out of the *loop*, only output the following
-            <template/> and then use the `Skill` tool to invoke the
-            `ase:ase-task-preflight` skill in order to *apply* the finalized
+            <template/> and then call the `Skill(skill:
+            "ase:ase-task-preflight")` tool to *apply* the finalized
             plan.
 
             <template>
@@ -412,3 +413,4 @@ explicitly requested by this procedure via outputs based on a <template/>!
             <template>
             ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan refinement cancelled**
             </template>
+

package/plugin/skills/ase-task-id/SKILL.md

@@ -10,6 +10,7 @@ disable-model-invocation: false
 effort: low
 ---
 
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md