@rse/ase 0.0.30 → 0.0.31

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

@@ -0,0 +1,299 @@
+---
+name: ase-code-resolve
+argument-hint: "[<task-id>:] <problem>"
+description: >
+    Resolve Problem:
+    Use when user wants a bug fixed or problem resolved.
+user-invocable: true
+disable-model-invocation: false
+effort: high
+allowed-tools:
+    - "Skill"
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
+
+Resolve Problem
+===============
+
+<skill name="ase-code-resolve">
+Resolve Problem
+</skill>
+
+<role>
+Your role is an experienced, *expert-level software developer*.
+</role>
+
+<objective>
+*Resolve* the following problem:
+<problem>$ARGUMENTS</problem>
+</objective>
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-plan.md
+
+Procedure
+---------
+
+You *MUST* follow the following numbered items *strictly* *sequentially*!
+You *MUST* not skip any numbered item during processing!
+
+You *MUST* *NOT* output anything in this entire procedure, *except* when
+explicitly requested by this procedure via outputs based on a <template/>!
+
+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
+        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.
+
+    2.  <if condition="
+            <problem/> matches the regexp `^[a-zA-Z][a-zA-Z0-9_-]*$`
+        ">
+        Set <ase-task-id><problem/></ase-task-id> (set task id to problem)
+        and <problem></problem> (set problem empty), call the
+        `task_id(id: <ase-task-id/>, session: <ase-session-id/>)` tool
+        from the `ase` MCP service to switch the task, and then only
+        output the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **task given**
+        </template>
+        </if>
+
+    3.  If <problem/> has the format `<id/>: <text/>` where <id/> matches
+        the regexp `^[a-zA-Z][a-zA-Z0-9_-]+$`, then set
+        <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.
+
+    4.  If <problem/> is empty,
+        ask the user interactively, without a special tool, for the
+        initial problem with a single question:
+
+        `**No problem details known yet. What is the problem you want to resolve?**`
+
+        Then set <problem/> to the response of the user.
+
+    5.  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.  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.  Investigate and *figure out details* related to this problem.
+        Report those details with the following <template/>:
+
+        <template>
+        &#x1F7E0; **PROBLEM CONTEXT**: *<context/>*
+        <affected-code-excerpt/>
+        <optional-diagram/>
+
+        &#x1F7E0; **PROBLEM DETAILS**: *<summary/>*
+        - [...]
+        - [...]
+        - [...]
+        </template>
+
+        Hints:
+
+        - Give a short one-sentence <context/> of the <problem/> plus
+          a short excerpt of the affected code <affected-code-excerpt/>.
+
+        - 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.
+
+        - In case of a *complex context situation* with complex *structure*
+          (layout, components, dependencies, etc), complex *control flow*
+          (branching, concurrency, etc), complex *state machine* (states,
+          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
+          <optional-diagram/> entirely for simple or purely local situation.
+
+2.  **Investigate Code Base**:
+
+    1.  Check the existing source files for all code which is related to the
+        requested <problem/> resolution.
+
+    2.  Check the architecture of the existing code base to understand the
+        overall structures and dynamics.
+
+    3.  Do not output anything in this step.
+
+3.  **Find Problem Resolution Approaches**:
+
+    1.  *Propose* corresponding *resolution approach*, including optionally,
+        some *alternative* resolution 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:
+
+        -   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.
+
+        -   Focus on resolution approaches for *practically relevant* cases and do *not*
+            investigate on theoretical or fictive cases. This is especially the case
+            for error handling cases and race condition cases.
+
+        -   In case of resolution approaches for problems related to *obvious or
+            expected* errors, they *should* be handled *near the origin*.
+
+        -   In case of resolution approaches for problems related to *theoretical
+            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**:
+
+    1.  Let the *user interactively choose* the preferred resolution approach A<n/>
+        with the help of the <user-dialog-tool/> tool. Use *single-selection* only
+        and provide small *code change previews*. Mark your recommended
+        resolution approach with ` ⚝ **RECOMMENDATION** ⚝` here again.
+
+5.  **Write Problem Resolution Plan**:
+
+    1.  *Write a plan* with code references, a precise description of the
+        problem, the chosen resolution approach, a preview of the *unified
+        diff* of the necessary code changes, and a possible way to verify
+        the success of the resolution, by using the <format/> defined for a
+        task plan. Store the resulting task plan in <content/>.
+
+    2.  Call the `timestamp(format: "yyyy-LL-dd HH:mm")` tool of the
+        `ase` MCP service and use the `text` field of its response for
+        <timestamp-created/> and <timestamp-modified/> information. Then
+        insert the current <ase-task-id/>, <timestamp-created/>, and
+        <timestamp-modified/> information and calculate the number of
+        words <words/> of <content/>.
+
+    3.  You then *MUST* *save* the resulting plan content with the
+        `task_save(id: <ase-task-id/>, text: <content/>)`.
+
+    4.  If <problem-id/> is set (i.e. the <problem/> was retrieved from
+        `kv_get` in STEP 1.3 via key `ase-issue-<problem-id/>`),
+        you *MUST* additionally call the `kv_delete(key:
+        "ase-issue-<problem-id/>")` tool of the `ase` MCP
+        service to remove the now-resolved analyzer result from the
+        in-memory key/value store.
+
+    5.  Output a hint with the following <template/>:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan created**
+        </template>
+
+    6.  *Ask user*: 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>

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

@@ -0,0 +1,95 @@
+---
+name: ase-meta-changes
+argument-hint: ""
+description: >
+    Update changes entries in CHANGELOG.md files
+user-invocable: true
+disable-model-invocation: false
+effort: medium
+allowed-tools:
+    - "Bash(git log *)"
+    - "Bash(git status *)"
+    - "Bash(git show *)"
+    - "Write"
+    - "Edit"
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+
+Update ChangeLog Entries
+========================
+
+Your role is an experienced, *expert-level software developer*,
+specialized in *Git version control*.
+
+<objective>
+Help to complete, consolidate and sort *ChangeLog* entries,
+based on underling *Git* commit messages.
+</objective>
+
+For this, understand that ChangeLog entries are
+are always formatted `<prefix/>: <summary/>` where
+the <prefix/> is one of the following tags
+and their usual related changes...
+
+    -   `FEATURE`: new functionality or configuration
+    -   `IMPROVEMENT`: improved functionality or configuration
+    -   `BUGFIX`: corrected functionality or configuration
+    -   `UPDATE`: updated functionality or configuration
+    -   `CLEANUP`: cleaned up functionality or configuration
+    -   `REFACTOR`: refactored functionality or configuration
+
+...and <summary/> is not longer than about 60-80 characters.
+The ChangeLog entries for a single product release version
+are also grouped and sorted according to the above <prefix/>es.
+
+<flow>
+1. <step id="STEP 1: Locate and read existing ChangeLog entries">
+   The *ChangeLog* file `CHANGELOG.md` contains sections
+   with headers in the style `N.M.K (YYYY-MM-DD)`.
+   The `CHANGELOG.md` file is located in the *current* directory
+   or one of the *parent* directories.
+   </step>
+
+2. <step id="STEP 2: Read corresponding Git commit log messages">
+   *Ignore* the current Git *index* and Git *stash* and use the Git *commits* only.
+   For finding the corresponding Git commits, use the `N.M.K`
+   from the *second* header in the *ChangeLog* file as
+   the corresponding Git tag and then check all Git commits
+   between `HEAD` and this tag.
+   </step>
+
+3. <step id="STEP 3: Complete ChangeLog entries">
+   Without immediately modifying `CHANGELOG.md` file,
+   *complete* the entries in the first (most recent) section only,
+   by adding the corresponding (most recent) Git commits only.
+   For each Git commit, reduce the Git commit messages to a single
+   short sentence.
+   </step>
+
+4. <step id="STEP 4: Consolidate ChangeLog entries">
+   Without immediately modifying `CHANGELOG.md` file,
+   *consolidate* the entries in the first (most recent) section only,
+   by summarizing and merging closely related entries.
+   Perform the entry consolidation per prefix group only.
+   If a changelog <summary/> is too short or is too less comprehensible
+   because of too less context, add some context, especially references
+   to the class/module/package, etc.
+   </step>
+
+5. <step id="STEP 5: Sort ChangeLog entries">
+   Without immediately modifying `CHANGELOG.md` file,
+   *sort* the entries in the first (most recent) section only.
+   Instead of the chronological commit order, group the entries
+   by the prefixes.
+   </step>
+
+6. <step id="STEP 6: Write modified ChangeLog entries">
+   Finally, *update* the `CHANGELOG.md` file with the
+   completed, consolidated and sorted *ChangeLog* entries.
+   Also, update the date `YYYY-MM-DD` in the `N.M.K (YYYY-MM-DD)`
+   headline of the *first* (most recent) section.
+   </step>
+</flow>
+

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

@@ -0,0 +1,58 @@
+---
+name: ase-meta-chat
+argument-hint: "<llm> <query>"
+description: >
+    Query foreign LLM for Chat.
+    Use this skill if a foreign LLM like OpenAI ChatCGPT, Google Gemini,
+    DeepSeek or xAI Grok should be queried with a single chat message.
+user-invocable: true
+disable-model-invocation: false
+context: fork
+effort: low
+allowed-tools:
+    - "mcp__chat-openai-chatgpt"
+    - "mcp__chat-google-gemini"
+    - "mcp__chat-deepseek"
+    - "mcp__chat-xai-grok"
+    - "Task"
+    - "Agent"
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+
+Query Foreign LLMs for Chat
+===========================
+
+Your role is to act as a proxy to query a foreign LLM for a single chat message.
+
+<objective>
+Query foreign LLM for: <query>$ARGUMENTS</query>
+</objective>
+
+<flow>
+1.  <step id="STEP 1: Select LLMs">
+    Use the *first word* of the following <query/> for selecting the
+    foreign LLMs to query, and their corresponding MCP servers, from the
+    following list:
+
+    - **OpenAI ChatGPT**: via MCP server `chat-openai-chatgpt`
+    - **Google Gemini**:  via MCP server `chat-google-gemini`
+    - **DeepSeek**:       via MCP server `chat-deepseek`
+    - **xAI Grok**:       via MCP server `chat-xai-grok`
+    </step>
+
+2.  <step id="STEP 2: Spawn Agents">
+    Spawn a *sub-task* with the companion `ase-meta-chat` *agent* for
+    the selected foreign LLMs, and pass the *second and all remaining*
+    words of the following <query/> as the query for the selected LLM.
+    </step>
+
+3.  <step id="STEP 3: Return Responses">
+    Return the *plain response* of the `ase-meta-chat` agent 1:1 and
+    *without any modifications*. Especially, do *NOT* add or remove any
+    text from the agent response on your own and do not interpret the
+    result in any way.
+    </step>
+</flow>
+

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

@@ -0,0 +1,64 @@
+---
+name: ase-meta-commit
+argument-hint: ""
+description: >
+    Determine commit message for staged Git changes.
+user-invocable: true
+disable-model-invocation: false
+effort: medium
+allowed-tools:
+    - "Bash(git diff *)"
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-persona.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+
+Git Commit
+==========
+
+Your role is an experienced, *expert-level software developer*,
+specialized in *Git commit messages*.
+
+<objective>
+Help to *craft* a *consise commit message* for the
+currently staged Git changes.
+</objective>
+
+<flow>
+1.  <step id="STEP 1: Find out staged changes">
+    Run the following command to find out details
+    of what changes are currently staged for commit:
+
+    `git diff --staged`
+    </step>
+
+2.  <step id="STEP 2: Craft a consolidated commit message">
+    Craft a commit <message/> in the following format:
+
+    `<type/>: <summary/>`
+
+    The known <type/>s and their usual corresponding kind of change are:
+    -   `FEATURE`: new functionality or configuration
+    -   `IMPROVEMENT`: improved functionality or configuration
+    -   `BUGFIX`: corrected functionality or configuration
+    -   `UPDATE`: updated functionality or configuration
+    -   `CLEANUP`: cleaned up functionality or configuration
+    -   `REFACTOR`: refactored functionality or configuration
+
+    The rules for generating <summary/> are:
+    -   Use a maximum of 70 characters
+    -   Use imperative mood ("add" not "added")
+    -   Use *no* period at the end
+    -   Use *no* Markdown formatting
+
+    Output this crafted commit message with the following <template/>:
+
+    <template>
+    Commit Message:
+    **<message/>**
+    </template>
+
+    Do *not* output any further explanation.
+    </step>
+</flow>
+

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

@@ -0,0 +1,101 @@
+---
+name: ase-meta-diagram
+description: >
+    Render diagrams via the `diagram` tool of the `ase` MCP service.
+    *Always use* when you have to *visualize*
+    structure/layout/components/dependencies as Flowchart,
+    control-flow/branching/concurrency as Flowchart,
+    state-machine/states/transitions as an UML State Diagram,
+    data-flow/actors/messages/protocols as an UML Sequence Diagram,
+    data-structure/classes/methods as an UML Class Diagram
+    data-model/entities/relationships as an ER Diagram, or
+    metrics/distributions/time-series as XY-Charts.
+user-invocable: false
+disable-model-invocation: false
+effort: low
+allowed-tools:
+    - "mcp__plugin_ase_ase__diagram"
+---
+
+Render Diagrams
+===============
+
+Your role is to render *every* diagram in the current session, with
+*deterministic* and *clean* output. For this, your objective is to
+produce a beautifully rendered diagram that the user can read directly
+in the response text, derived from a *Mermaid* diagram specification,
+which is rendered with the `diagram` tool of the `ase` MCP service.
+
+Rules
+-----
+
+-   WHEN NOT:
+    You *MUST* *NEVER* hand-draw diagrams under any circumstances!
+
+    Box-drawing characters (`┌`, `│`, `└`, `┐`, `┘`, `─`, `┼`, `├`,
+    `┤`, `┬`, `┴`, `╭`, `╰`), ASCII surrogates (`+`, `-`, `|`), or any
+    other attempt to draw a framed shape token-by-token are *forbidden*
+    as your own diagram output.
+
+-   WHEN:
+    You *MUST* always use the `diagram` tool from the `ase` MCP service,
+    whenever a diagram should be drawn!
+
+    Every diagram in the output *MUST* originate from a `diagram`
+    MCP tool call, with Mermaid diagram specification passed in the
+    `diagram` field, made in the *same* session response turn. Also,
+    pass a `colorMode` of `none` to always get monochrome renderings.
+
+-   INPUT:
+    For describing the diagrams, you *MUST* use the *Mermaid* diagram
+    specification language!
+
+    Use the following Mermaid diagram types per intent:
+
+    -   *structure / layout / components / dependencies* → `flowchart`
+    -   *control flow / branching / concurrency*         → `flowchart`
+    -   *state machine / states / transitions*           → `stateDiagram-v2`
+    -   *data flow / actors / messages / protocols*      → `sequenceDiagram`
+    -   *data structure / classes / methods*             → `classDiagram`
+    -   *data model / entities / relationships*          → `erDiagram`
+    -   *metrics / distributions / time series*          → `xychart-beta`
+
+    Other Mermaid diagram types are *not* supported by the renderer
+    and hence should *not* be specified!
+
+-   OUTPUT:
+    You *MUST* reproduce the `text` output of the `diagram` tool from
+    the `ase` MCP service in the response text! Do not produce any other
+    output, especially no explanations.
+
+    In other words, after the `diagram` tool call completes, the
+    skill *MUST* copy the tool's `text` result *verbatim* into a
+    Markdown-fenced code block (triple backticks), directly placed
+    in the response text immediately after the MCP tool call -— the
+    user reads the Markdown fenced block in the response, not the
+    (truncated) tool call display. Emitting only the tool call without
+    the reproduction of the `text` output is a defect: the diagram is
+    then effectively invisible.
+
+-   NOTICE 1:
+    You *MUST* *NEVER* emit the plain Mermaid diagram specification, as
+    it is just an intermediate format for driving the rendering process!
+
+-   NOTICE 2:
+    You *SHOULD* keep diagrams narrow!
+
+    The renderer's horizontal extent scales with siblings per row, node
+    label lengths, and inter-node padding. Limit *≤6 siblings per row*
+    and group further items into nested `subgraph` hierarchies; keep
+    *node labels* *≤20 chars* (abbreviate long names, drop adjectives).
+
+-   NOTICE 3:
+    You *SHOULD* stack diagrams vertically!
+
+    For *comparison diagrams* (e.g., *current vs. proposed*, *before
+    vs. after*), render each side as a *separate* Mermaid diagram
+    specification via the `diagram` tool from the `ase` MCP service, and
+    then stack the two rendered blocks *vertically* -— each preceded by
+    a bold label (`**BEFORE:**` / `**AFTER:**`, or similar). Do *not*
+    attempt side-by-side layout.
+