@rse/ase 0.9.20 → 0.9.22

package/dst/ase-diagram.js

@@ -5,7 +5,7 @@
 */
 import fs from "node:fs";
 import { InvalidArgumentError } from "commander";
-import { renderMermaidASCII } from "beautiful-mermaid";
+import { renderMermaidASCII, renderMermaidSVG } from "beautiful-mermaid";
 import { z } from "zod";
 /*  custom argument parser for Commander: non-negative integer  */
 const parseInteger = (name) => (value) => {
@@ -20,6 +20,12 @@ const parseColorMode = (name) => (value) => {
         throw new InvalidArgumentError(`${name} must be "none", "ansi16", or "ansi256"`);
     return value;
 };
+/*  custom argument parser for Commander: output format  */
+const parseFormat = (name) => (value) => {
+    if (value !== "ascii" && value !== "svg")
+        throw new InvalidArgumentError(`${name} must be "ascii" or "svg"`);
+    return value;
+};
 /*  scan a CSI escape sequence starting at line[i] (where line[i]===ESC and
     line[i+1]==="["); return the index just past the terminating letter, or
     -1 if the sequence is unterminated within the line  */
@@ -135,8 +141,14 @@ export class Diagram {
         return mode;
     }
     /*  pure rendering helper: turn a Mermaid source string plus options into
-        a rendered Unicode/ASCII diagram string. Throws on render failure.  */
+        a rendered Unicode/ASCII diagram string, or an SVG document string
+        when "svg" format is requested. Throws on render failure.  */
     static render(src, opts) {
+        /*  render as a self-contained SVG document using the library's
+            themed defaults (the ANSI "colorMode" and the terminal
+            clipping below are meaningful only for ASCII art)  */
+        if (opts.format === "svg")
+            return renderMermaidSVG(src);
         /*  create diagram rendering  */
         let out = renderMermaidASCII(src, {
             useAscii: opts.ascii,
@@ -216,8 +228,9 @@ export default class DiagramCommand {
     register(program) {
         program
             .command("diagram")
-            .description("Render Mermaid diagram specification as Unicode/ASCII art")
+            .description("Render Mermaid diagram specification as Unicode/ASCII art or SVG")
             .option("-i, --input <file>", "read Mermaid source from file instead of stdin")
+            .option("-f, --format <format>", "output format (\"ascii\" or \"svg\")", parseFormat("--format"), "ascii")
             .option("-a, --ascii", "emit plain ASCII (+-|) instead of Unicode box-drawing", false)
             .option("-c, --color-mode <mode>", "force color mode (\"none\", \"ansi16\", or \"ansi256\")", parseColorMode("--color-mode"), Diagram.detectColorMode())
             .option("--node-margin-x <n>", "horizontal margin between nodes of <n> characters", parseInteger("--node-margin-x"), 3)
@@ -242,6 +255,7 @@ export default class DiagramCommand {
             let out;
             try {
                 out = Diagram.render(src, {
+                    format: opts.format,
                     ascii: opts.ascii ?? false,
                     colorMode: opts.colorMode,
                     nodeMarginX: opts.nodeMarginX,
@@ -270,7 +284,7 @@ export class DiagramMCP {
     register(mcp) {
         mcp.registerTool("ase_diagram", {
             title: "ASE diagram render",
-            description: "Render a Mermaid diagram as Unicode/ASCII art. " +
+            description: "Render a Mermaid diagram as Unicode/ASCII art or SVG. " +
                 "Use for visualizing " +
                 "structure/layout/components/dependencies as a Flowchart, " +
                 "control-flow/branching/concurrency as a Flowchart, " +
@@ -280,10 +294,12 @@ export class DiagramMCP {
                 "data-model/entities/relationships as an ER Diagram, or " +
                 "metrics/distributions/time-series as an XY-Chart. " +
                 "Pass the Mermaid diagram specification as `diagram`. " +
-                "Returns the rendered art as `text`.",
+                "Returns the rendered art (or SVG document, for `format` \"svg\") as `text`.",
             inputSchema: {
                 diagram: z.string()
                     .describe("Mermaid diagram specification"),
+                format: z.enum(["ascii", "svg"]).default("ascii")
+                    .describe("output format: \"ascii\" for Unicode/ASCII art, \"svg\" for an SVG document"),
                 ascii: z.boolean().default(false)
                     .describe("emit plain ASCII (+-|) instead of Unicode box-drawing characters"),
                 colorMode: z.enum(["none", "ansi16", "ansi256"]).default("none")
@@ -306,6 +322,7 @@ export class DiagramMCP {
         }, async (args) => {
             try {
                 const out = Diagram.render(args.diagram, {
+                    format: args.format,
                     ascii: args.ascii,
                     colorMode: args.colorMode,
                     nodeMarginX: args.nodeMarginX,

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.9.20",
+    "version":                              "0.9.22",
     "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.9.20",
+    "version":     "0.9.22",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

package/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
     "name":        "ase",
-    "version":     "0.9.20",
+    "version":     "0.9.22",
     "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.9.20",
+    "version":     "0.9.22",
     "description": "Agentic Software Engineering (ASE)",
     "keywords":    [ "agentic", "software", "engineering" ],
     "homepage":    "https://ase.tools",

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

@@ -9,10 +9,11 @@ and the "how" of the Software Engineering project.
 
 Each **Artifact** of the **Artifact Set**
 **Architecture (ARCH)** is stored under
-`docs/arch/ARCH-<artifact-no/>-<artifact-id/>-<artifact-slug/>.md`,
-relative to the project root directory, with <artifact-no/> being the
-zero-padded, two-digit sequence number of the **Artifact** (starting at
-`01`) according to the order of the **Artifact** list below, and with
+`<basedir/>/ARCH-<artifact-no/>-<artifact-id/>-<artifact-slug/>.md`,
+relative to the project root directory, with <basedir/> being the
+`project.artifact.arch.basedir` config variable, <artifact-no/> being
+the zero-padded, two-digit sequence number of the **Artifact** (starting
+at `01`) according to the order of the **Artifact** list below, and with
 <artifact-slug/> being derived from <artifact-name/> (see below) by
 Pascal-casing each word (upper-casing its first letter) and using `-`
 characters instead of spaces (e.g. `Context-View`).
@@ -74,6 +75,12 @@ distinct **Artifact**s (listed under their <artifact-name/> and their
     The major decisions related to the architecture, each recording the
     forces at play, the chosen response, and the reasoning that justifies it.
 
+10. **Technology Stack (TS)**:
+    The concrete technology products the solution is built upon, organized
+    by tier and lifecycle phase, recording for each component its chosen
+    product, its purpose, and the alternatives that were considered but not
+    chosen.
+
 The **Artifact**s have the following cross-references:
 
 ```text
@@ -89,6 +96,8 @@ ARCH-08-QP Quality Perspectives ──(affects)─►    ARCH-02-FV Functionalit
 ARCH-08-QP Quality Perspectives ──(affects)─►    ARCH-06-DP Deployment View
 ARCH-09-DR Decision Record      ──(affects)─►    ARCH-02-FV Functionality View
 ARCH-09-DR Decision Record      ──(affects)─►    ARCH-06-DP Deployment View
+ARCH-10-TS Technology Stack     ──(realizes)─►   ARCH-02-FV Functionality View
+ARCH-10-TS Technology Stack     ──(realizes)─►   ARCH-06-DP Deployment View
 ```
 
 Context View (CV)
@@ -897,3 +906,274 @@ forces at play, the chosen response, and the reasoning that justifies it.
     -   **Rejected alternatives when the rejection is non-obvious.** If
         you considered GraphQL and picked REST for subtle reasons, record it -
         otherwise someone will suggest GraphQL again in six months.
+
+Technology Stack (TS)
+---------------------
+
+The concrete technology products the solution is built upon, organized by
+tier and lifecycle phase, recording for each component its chosen product,
+its purpose, and the alternatives that were considered but not chosen.
+
+-   Format:
+
+    <format>
+
+    #   ARCHITECTURE: TECHNOLOGY STACK (ARCH-TS)
+
+    ✳   Created:  **<timestamp-created/>**
+    ✎   Modified: **<timestamp-modified/>**
+
+    <arch-ts-component/>
+    <arch-ts-component/>
+    [...]
+
+    </format>
+
+-   <arch-ts-component/> format:
+
+    <format>
+
+    ##  COMPONENT: <arch-ts-component-name/> <a id="ARCH-TS-<arch-ts-component-id/>"></a>
+
+    -   Product:      <arch-ts-component-product/>
+    -   Alternatives: <arch-ts-component-alternative/>[, ...]
+    -   Coverage:     <arch-ts-component-coverage/>
+    -   Realizes:     <arch-ts-component-element/>[, ...]
+    -   Tier:         <arch-ts-component-tier/>
+    -   When:         <arch-ts-component-when/>
+
+    <arch-ts-component-description/>,
+    **BECAUSE** <arch-ts-component-rationale/>.
+
+    </format>
+
+-   <arch-ts-component/> details:
+
+    -   <arch-ts-component-id/>: per-artifact unique "slug" of always 1-3
+        lower-cased words (concatenated with "-" characters and
+        in total not longer than 30 characters), derived from
+        <arch-ts-component-name/>.
+
+    -   <arch-ts-component-name/> is a short (2-5 word) summary of the
+        technology component (e.g. `UI Framework`, `Web Server`, `Relational
+        Database`).
+
+    -   <arch-ts-component-product/> is the concrete product, library, or
+        framework chosen for this component (e.g. `VueJS`, `Node.js`,
+        `PostgreSQL`).
+
+    -   <arch-ts-component-alternative/> is a product that would also fit
+        this component but was not chosen (e.g. `React`, `Svelte`).
+
+    -   <arch-ts-component-coverage/> is either one or more of the
+        *Client Aspects* or one or more of the *Server Aspects* defined
+        below. The general goal is to achieve a maximum coverage of all
+        aspects per <arch-ts-component-tier/> with the minimum total
+        number of <arch-ts-component-product/>.
+
+    -   <arch-ts-component-element/> is an `ARCH-FV-<arch-fv-component-id/>`
+        or `ARCH-DP-<arch-dp-node-id/>` reference to the functional element
+        or deployment node this product realizes.
+
+    -   <arch-ts-component-tier/> is the architectural tier the component
+        belongs to, one of:
+
+        -   `Client`: Runs on the client side (e.g. browser, desktop, mobile).
+        -   `Server`: Runs on the server side (e.g. backend, application, API).
+
+    -   <arch-ts-component-when/> is the lifecycle phase in which the
+        component is relevant, one of:
+
+        -   `Build-Time`: Used during development, compilation, or packaging.
+        -   `Run-Time`:   Used while the solution executes in production.
+
+    -   <arch-ts-component-description/> is a concise paragraph (1-3
+        sentences) of prose describing how the product is used within the
+        solution and how it fits into the overall technology stack.
+
+    -   <arch-ts-component-rationale/> is the 1-sentence rationale ("why")
+        for choosing this product over the alternatives.
+
+    -   In case the element reference is not present, the
+        entire `-   Realizes:` bullet point is omitted.
+
+    -   In case no alternatives were considered, the
+        entire `-   Alternatives:` bullet point is omitted.
+
+    -   In case the rationale is not present, the
+        entire `, **BECAUSE** [...]` clause is omitted.
+
+-   The known *Client Aspects* which usually have to covered (at least for
+    clients in a Rich-Client architecture):
+
+    -   **Interface Theme**:
+        Style Reset, Shape, Color, Gradient, Shadow, Font, Icon.
+
+    -   **Interface Widgets**:
+        Icon, Label, Text Paragraph, Image, Form, Text-Field, Text-Area,
+        Date Picker, Toggle, Radio Button, Checkbox, Select List, Slider,
+        Progress Bar, Hyperlink, Popup Menu, Dropdown Menu, Toolbar, Tooltip,
+        Tab, Pill, Breadcrumb, Pagination, Badge, Alert, Panel, Modal, Table,
+        Scrollbar, Carousel.
+
+    -   **Interface Layouting**:
+        Responsive Design, Media Query, Frame, Grid, Padding, Border,
+        Margin, Alignment, Force, Magnetism.
+
+    -   **Interface Effects**:
+        Transition, Transformation, Keyframes, Easing Function, Sound
+        Effect, Physics.
+
+    -   **Interface Interactions**:
+        Mouse, Keyboard, Touchscreen, Gesture, Clipboard, Drag & Drop.
+
+    -   **Interface States**:
+        Rendered, Enabled, Visible, Focused, Warning, Error, Floating.
+
+    -   **Interface Mask**:
+        Markup Loading, Markup Generation, Virtual DOM, Text, Bitmaps,
+        Vectors, 2D/3D Canvas, Accessibility.
+
+    -   **Interface Internationalization**:
+        Text Internationalization (I18N).
+
+    -   **Data Conversion**:
+        Value Formatting, Value Parsing, Localization (L10N).
+
+    -   **Data Binding**:
+        Reactive, Observer, Unidirectional, Bidirectional, Incremental.
+
+    -   **Presentation Model**:
+        Parameter Value, Command Value, State Value, Data Value, Event
+        Value, Value Validation, Presentation Logic.
+
+    -   **Dialog Navigation**:
+        Deep Linking, Routing, Dialog Flow.
+
+    -   **Dialog Automation**:
+        Dialog Macros, Click-Through, Smoke Testing.
+
+    -   **Dialog Communication**:
+        Service, Event, Model, Socket, Hooks.
+
+    -   **Dialog Life-Cycle**:
+        Component States, Component State Transitions.
+
+    -   **Dialog Structure**:
+        Component, Model/View/Controller Roles, Hierarchical Composition.
+
+    -   **State Persistence**:
+        Local Storage, Cookies, Caching.
+
+    -   **Business Model**:
+        Entity, Field, Relationship, Universally Unique Identifiers (UUID).
+
+    -   **Use-Case Authorization**:
+        User Experience, Dialog Restriction, User, Group, Role, Use-Case,
+        Data, Access.
+
+    -   **Client Networking**:
+        Request/Response, Synchronization, Push, Pull, Pulled-Push,
+        REST, GraphQL, Authentication, Session.
+
+    -   **Environment Detection**:
+        Runtime Detection, Feature Detection.
+
+-   The known *Server Aspects* which usually have to covered (at least for
+    servers, sometimes called Thin-Servers, in a Rich-Client architecture):
+
+    -   **Environment Detection**:
+        Detect the run-time environment, like underlying operating
+        system, execution platform, network topology, feature toggles, etc.
+
+    -   **Argument Parsing**:
+        Parse options and arguments of the Command-Line Interface (CLI)
+        to bootstrap application parameters.
+
+    -   **Configuration Parsing**:
+        Load and parse directives from configuration file to bootstrap
+        application parameters.
+
+    -   **Process Daemonizing**:
+        Detach from the startup terminal and host process in order to run
+        fully independently.
+
+    -   **Process Management**:
+        (Pre-)fork child processes and/or threads of execution and monitor
+        and control them during the life-cycle of the application.
+
+    -   **Component Management**:
+        Structure the code into components, instantiate them under run-time
+        and manage them in a stateful component life-cycle.
+
+    -   **Component Communication**:
+        Provide inter-component communication mechanisms like events, hooks,
+        registry, etc.
+
+    -   **Server Networking**:
+        Listen to network sockets, accept connections and manage
+        request/response and message communication.
+
+    -   **Peer Information**:
+        Determine unique identification and add-on information about the
+        client peer.
+
+    -   **Session Handling**:
+        Manage secured per-connection sessions to keep state between
+        communication requests and/or client sessions.
+
+    -   **User Authentication**:
+        Determine and validate the unique identity of the user communicating
+        over the current network connection.
+
+    -   **Request Validation**:
+        Validate the syntactical and semantical compliance of the requests
+        and sanitize the requests.
+
+    -   **Request Processing**:
+        Process the request by dispatching execution according to the
+        provided request and determined context information.
+
+    -   **Role Authorization**:
+        Determine whether the role of the current user is allowed to execute
+        the current request.
+
+    -   **Client Networking**:
+        Provide mechanisms to connect to peers over the network and perform
+        request/response and/or publish/subscribe communication.
+
+    -   **Task Scheduling**:
+        Schedule and execute recurring tasks independent of regular I/O
+        operations.
+
+    -   **Execution Tracing**:
+        Provide mechanisms for tracing the execution by logging event and
+        measurement information at certain points of interest.
+
+    -   **Database Access**:
+        Map in-memory domain entities onto data store dependent persistent
+        data structure.
+
+    -   **Database Connectivity**:
+        Locally or remotely connect the database access layer to the
+        underlying data store.
+
+    -   **Database Schema**:
+        Create, update or downgrade the data schema inside the underlying
+        data store.
+
+    -   **Database Bootstrapping**:
+        Create, update or downgrade both mandatory bootstrapping and optional
+        domain-specific data inside the underlying data store.
+
+-   Export: `export.md`
+
+    The components rendered as a single, compact Markdown table -- one
+    row per <arch-ts-component/>, sorted by <arch-ts-component-tier/>
+    then <arch-ts-component-when/> -- with the columns:
+
+    -   `Component`     (<arch-ts-component-name/>)
+    -   `Product`       (**<arch-ts-component-product/>**)
+    -   `Tier`          (<arch-ts-component-tier/>)
+    -   `When`          (<arch-ts-component-when/>)
+    -   `Coverage`      (*<arch-ts-component-coverage/>*)

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

@@ -56,3 +56,35 @@ Artifact Meta Information
     unique "slug" of always 1-3 lower-cased words (concatenated with "-"
     characters and in total not longer than 30 characters). An example
     is `user-login`.
+
+An **Artifact** *MAY* additionally declare an **Export** -- a derived,
+ready-to-consume rendering of (part of) its content, materialized as a
+*side-by-side* file next to the **Artifact** itself. An **Artifact**
+without an `-   Export:` bullet is *not* exported.
+
+An **Export** is declared by a single `-   Export:` bullet point in the
+**Artifact**'s format definition (see `ase-format-spec.md` and
+`ase-format-arch.md`), of the following format:
+
+<format>
+
+-   Export: `<export-name/>.<export-ext/>`
+    <export-transform/>
+
+</format>
+
+with the following details:
+
+-   <export-ext/> is the file-name extension (without the leading dot,
+    e.g. `svg`, `md`) of the exported file, which also implies its
+    target format.
+
+-   <export-transform/> is a description of *how* the **Artifact**'s
+    content is transformed into the exported file (e.g. "the entities,
+    attributes, and relations rendered as a Mermaid `classDiagram` and
+    converted to SVG").
+
+The exported file is stored *side-by-side* with the **Artifact** under
+the path:
+
+`<basedir/>/<artifact-set-id/>-<artifact-no/>-<artifact-id/>-<artifact-slug/>-<export-name/>.<export-ext/>`

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

@@ -9,10 +9,11 @@ and the "what" of the Software Engineering project.
 
 Each **Artifact** of the **Artifact Set**
 **Specification (SPEC)** is stored under
-`docs/spec/SPEC-<artifact-no/>-<artifact-id/>-<artifact-slug/>.md`,
-relative to the project root directory, with <artifact-no/> being the
-zero-padded, two-digit sequence number of the **Artifact** (starting at
-`01`) according to the order of the **Artifact** list below, and with
+`<basedir/>/SPEC-<artifact-no/>-<artifact-id/>-<artifact-slug/>.md`,
+relative to the project root directory, with <basedir/> being the
+`project.artifact.spec.basedir` config variable, <artifact-no/> being
+the zero-padded, two-digit sequence number of the **Artifact** (starting
+at `01`) according to the order of the **Artifact** list below, and with
 <artifact-slug/> being derived from <artifact-name/> (see below) by
 Pascal-casing each word (upper-casing its first letter) and using `-`
 characters instead of spaces (e.g. `Customer-Journey`).
@@ -629,6 +630,59 @@ manages, defining how information is organized and connected.
     -   In case any rationale is not present, the
         entire `, **BECAUSE** [...]` clause is omitted.
 
+-   Export: `export.md`
+
+    The entities, their attributes and their relations
+    are rendered as Markdown tables.
+
+    For this, each <spec-dm-entity/> becomes:
+
+    <format>
+
+    ##  ENTITY: <a id="SPEC-DM-<spec-dm-entity-id/>"><spec-dm-entity-name/></a>
+
+    <spec-dm-entity-description/>,
+    **BECAUSE** <spec-dm-entity-rationale/>.
+
+    ### ATTRIBUTES
+
+    <export-table-1/>
+
+    ### RELATIONS
+
+    <export-table-2/>
+
+    </format>
+
+    With:
+
+    -    <export-table-1/> is a Markdown table for the attributes with one
+         row per <spec-dm-attribute-id/>, sorted by <spec-dm-attribute-id/>
+         -- with the columns:
+
+         -   `Attribute`     (`**<spec-dm-attribute-id/>**`)
+         -   `Type`          (`<spec-dm-attribute-qualifier/><spec-dm-attribute-type/>`)
+         -   `Description`   (`<spec-dm-relation-description/>, **BECAUSE** <spec-dm-relation-rationale/>.`)
+
+    -    <export-table-2/> is a Markdown table for the relation with one
+         row per <spec-dm-relation-id/>, sorted by <spec-dm-relation-id/> --
+         with the columns:
+
+         -   `Relation`      (`**<spec-dm-relation-id/>**`)
+         -   `Target`        (`[<spec-dm-relation-target/>](#<spec-dm-relation-target-id/>) (<spec-dm-relation-cardinality/>)`)
+         -   `Description`   (`<spec-dm-relation-description/>, **BECAUSE** <spec-dm-relation-rationale/>.`)
+
+-   Export: `export.svg`
+
+    The entities, their attributes and their relations are
+    rendered as a Mermaid `classDiagram` UML diagram and
+    converted to SVG. For this, each <spec-dm-entity/> becomes
+    a class whose members are the `<spec-dm-attribute-id/>:
+    <spec-dm-attribute-qualifier/><spec-dm-attribute-type/>` attributes,
+    and each <spec-dm-relation/> becomes a directed association
+    labeled with its <spec-dm-relation-id/> and annotated with its
+    <spec-dm-relation-cardinality/> at the target end.
+
 State Model (SM)
 ----------------
 

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.9.20",
+    "version":                              "0.9.22",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",

package/plugin/skills/ase-arch-discover/SKILL.md

@@ -44,9 +44,10 @@ for the technology stack to *provide* the *needed functionality*
         enough, let the *user interactively choose* the intended
         functionality.
 
-        In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-        tool! Instead, you *MUST* just show a custom output, let the
-        user enter input, and then you set the result accordingly.
+        In the following, you *MUST* *NOT* use your built-in
+        <user-dialog-tool/> tool! Instead, you *MUST* just show a
+        custom dialog according to the expanded `custom-dialog`
+        definition. You *MUST* closely follow this definition:
 
         <expand name="custom-dialog" arg1="--no-other">
             Functionality: Which functionality should the components provide?

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

@@ -188,9 +188,10 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
     7.  <if condition="<getopt-option-auto/> is not equal `true`">
 
-        In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-        tool! Instead, you *MUST* just show a custom output, let the
-        user enter input, and then you set the result accordingly.
+        In the following, you *MUST* *NOT* use your built-in
+        <user-dialog-tool/> tool! Instead, you *MUST* just show a
+        custom dialog according to the expanded `custom-dialog`
+        definition. You *MUST* closely follow this definition.
 
         Let the user choose the preferred approach A<n/> by raising
         a question with the following custom dialog, where per

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

@@ -253,9 +253,10 @@ related to a set of code quality aspects.
 
         6.  <if condition="<getopt-option-auto/> is not 'true'">
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--other">
                 CORRECTION: How would you like to proceed with this proposed correction?

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

@@ -188,9 +188,10 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
     7.  <if condition="<getopt-option-auto/> is not `true`">
 
-        In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-        tool! Instead, you *MUST* just show a custom output, let the
-        user enter input, and then you set the result accordingly.
+        In the following, you *MUST* *NOT* use your built-in
+        <user-dialog-tool/> tool! Instead, you *MUST* just show a
+        custom dialog according to the expanded `custom-dialog`
+        definition. You *MUST* closely follow this definition.
 
         Let the user choose the preferred approach A<n/> by raising
         a question with the following custom dialog, where per

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

@@ -242,9 +242,10 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
     7.  <if condition="<getopt-option-auto/> is not `true`">
 
-        In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-        tool! Instead, you *MUST* just show a custom output, let the
-        user enter input, and then you set the result accordingly.
+        In the following, you *MUST* *NOT* use your built-in
+        <user-dialog-tool/> tool! Instead, you *MUST* just show a
+        custom dialog according to the expanded `custom-dialog`
+        definition. You *MUST* closely follow this definition.
 
         Let the user choose the preferred approach A<n/> by raising
         a question with the following custom dialog, where per

package/plugin/skills/ase-docs-proofread/SKILL.md

@@ -185,9 +185,10 @@ Analyze documents for spelling, punctuation, or grammar errors
 
         4.  <if condition="<getopt-option-auto/> is not 'true'">
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--other">
                 CORRECTION: How would you like to proceed with this proposed correction?

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

@@ -117,15 +117,16 @@ Honor the following tenets throughout the brainstorming:
             <answer-M-K/> (K={1,2,3,4}) from the code base, the documented
             context, and your world knowledge.
 
-        3.  Use an interactive user dialog with header <facet-M/> and
-            question <question-M/>, and let the user select the
-            <answer-M/> out of the candidate answers <answer-M-K/> (leave
-            out the answer lines of those candidate answers you have
-            not determined).
+        3.  In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition.
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            For this interactive dialog, use header <facet-M/> and
+            question <question-M/>, and let the user select the
+            <answer-M/> out of the candidate answers <answer-M-K/>
+            (leave out the answer lines of those candidate answers you
+            have not determined):
 
             <expand name="custom-dialog" arg1="--other">
                 <facet-M/>: <question-M/>

package/plugin/skills/ase-sync-export/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: ase-sync-export
+argument-hint: "[--help|-h] [--source|-s <source>[,...]] [<filter>]"
+description: >
+    Export artifact content into side-by-side, ready-to-consume files,
+    one per artifact that declares an export. Use when the user wants to
+    "export", "render", or "materialize" artifacts like SPEC or ARCH into
+    derived files such as diagrams or tables.
+user-invocable: true
+disable-model-invocation: false
+effort: xhigh
+allowed-tools:
+    - Write
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
+
+<skill name="ase-sync-export">
+    Export Artifact Set to Side-by-Side Files
+</skill>
+
+<expand name="getopt"
+    arg1="ase-sync-export"
+    arg2="--source|-s=SPEC,ARCH">
+    $ARGUMENTS
+</expand>
+
+<objective>
+    *Export* the *source* artifact kinds (optionally filtered by
+    <hint/>) into side-by-side files, by reading the source artifacts
+    and materializing, for every artifact that declares an export,
+    the corresponding derived file next to the artifact itself.
+    <hint><getopt-arguments/></hint>.
+</objective>
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-meta.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-spec.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-format-arch.md
+
+Procedure
+---------
+
+<flow>
+
+1.  <step id="STEP 1: Determine Source">
+
+    1.  The recognized artifact kinds are the seven tokens `TASK`,
+        `SPEC`, `ARCH`, `CODE`, `DOCS`, `INFR`, and `OTHR`. Parse
+        <getopt-source/> as the comma-separated <source/> kind list.
+        Upper-case and trim every parsed kind token. Do not output
+        anything.
+
+    2.  <if condition="<source/> is empty">
+
+        Only output the following <template/> and then immediately *STOP*
+        processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-sync-export**, ▶ ERROR: empty source artifact list
+        </template>
+
+        </if>
+
+    3.  If any token in <source/> is *not* one of the seven recognized
+        kinds, only output the following <template/> (with <kind/> set to
+        the first offending token) and then immediately *STOP* processing
+        the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-sync-export**, ▶ ERROR: unknown artifact kind: **<kind/>**
+        </template>
+
+    4.  Report the resolved source with the following <template/>:
+
+        <template>
+        <ase-tpl-bullet-signal/> **SOURCE**: <source/>
+        </template>
+
+    </step>
+
+2.  <step id="STEP 2: Resolve and Read Artifacts">
+
+    1.  Do not output anything in this STEP 2.
+
+    2.  For all kinds in <source/>, call the `ase_artifact_list(kind: [
+        ... ])` tool of the `ase` MCP server *once*, passing the
+        lower-cased `kind` tokens, and read the returned `artifacts`
+        array of `{ kind, files }` objects to obtain the project-relative
+        file list per kind.
+
+    3.  <if condition="<hint/> is not empty">
+
+        Honor the filtering <hint/> to reduce the source artifacts
+        and/or the aspects of those artifacts you should take into
+        account.
+
+        </if>
+
+    4.  Internalize and honor the artifact-format conventions:
+
+        -   the artifact-set/artifact/aspect/export meta information (`ase-format-meta.md`),
+        -   the `SPEC` format (`ase-format-spec.md`),
+        -   the `ARCH` format (`ase-format-arch.md`).
+
+        In particular, internalize the generic *Artifact Export*
+        contract of `ase-format-meta.md` (the `-   Export:` bullet, the
+        side-by-side file-name convention, and the rule that an artifact
+        without an `-   Export:` bullet is *not* exported), and which
+        artifacts declare an export in the `SPEC` and `ARCH` formats.
+
+    5.  Read all resolved source artifacts and build a precise
+        understanding of the content of each artifact that declares an
+        export.
+
+    </step>
+
+3.  <step id="STEP 3: Materialize Exports">
+
+    1.  For *each* read source artifact that declares an `-   Export:`
+        bullet in its format definition, *materialize* the declared
+        export:
+
+        -   *Build* the derived rendering exactly as described by the
+            artifact's <export-transform/>, faithfully reflecting the
+            artifact's current content -- no more, no less. Honor **No
+            Fabrication**: never invent content the artifact does not
+            support.
+
+        -   For an export whose <export-transform/> is a *Mermaid
+            diagram converted to SVG*, build the Mermaid specification
+            from the artifact content and render it to an SVG document by
+            calling the `ase_diagram(diagram: "<mermaid-spec/>", format:
+            "svg")` tool of the `ase` MCP server, using its `text` output
+            field as the SVG document. For a textual export (e.g. a
+            Markdown table), build the content directly. For Markdown
+            *tables*, honor the table-alignment rule of `ase-skill.md`.
+
+        -   *Determine* the side-by-side target file name
+            <export-filename/>
+            as `<basedir/>/<artifact-set-id/>-<artifact-no/>-<artifact-id/>-<artifact-slug/>-<export-name/>.<export-ext/>`
+            and resolve it to a project-relative path inside the
+            artifact's own base directory by calling the
+            `ase_artifact_name(filename: "<file-name/>", kind:
+            "<export-filename/>")` tool of the `ase` MCP server.
+
+        -   *Write* the derived rendering to that resolved path via the
+            `Write` tool, overwriting any pre-existing export file of the
+            same name.
+
+    2.  Report the materialized exports with the following <template/>,
+        listing one bullet line per written file (with <file/> its
+        project-relative path and <note/> an ultra-brief description of
+        what was exported):
+
+        <template>
+        <ase-tpl-bullet-signal/> **EXPORTED ARTIFACTS**:
+
+        -   `<file/>`: <note/>
+        [...]
+        </template>
+
+        <if condition="no source artifact declares an export">
+
+        Only output the following <template/>:
+
+        <template>
+        <ase-tpl-bullet-normal/> **EXPORTED ARTIFACTS**: none -- no source artifact declares an export
+        </template>
+
+        </if>
+
+    </step>
+
+</flow>

package/plugin/skills/ase-sync-export/help.md

@@ -0,0 +1,60 @@
+
+##  NAME
+
+`ase-sync-export` - Export Artifact Set to Side-by-Side Files
+
+##  SYNOPSIS
+
+`ase-sync-export`
+    [`--help`|`-h`]
+    [`--source`|`-s` *source*[,...]]
+
+##  DESCRIPTION
+
+The `ase-sync-export` skill exports the content of a set of artifact
+kinds (the *source*) into *derived*, ready-to-consume files placed
+*side-by-side* with the artifacts themselves. For every source artifact
+that declares an *export* in its format definition, the skill builds the
+declared rendering and writes it to a sibling file.
+
+The *source* is a comma-separated list over the seven recognized
+artifact kinds `SPEC` (Specification), `ARCH` (Architecture), `CODE`
+(Source Code), `DOCS` (Documentation), `TASK` (Task Plans), `INFR`
+(Infrastructure), and `OTHR` (catch-all). The file lists for the
+involved kinds are resolved via the `ase_artifact_list` MCP tool of the
+`ase` MCP server.
+
+An *export* is declared by a `-   Export:` bullet point in an artifact's
+format definition (see `ase-format-meta.md`, `ase-format-spec.md`, and
+`ase-format-arch.md`); an artifact *without* such a bullet is *not*
+exported. Each exported file is named
+`YYYY-MM-DD-<set>-<slug>-<id>.<ext>` and stored in the artifact's own
+base directory. Initially, the *Data Model* (`SPEC-DM`) exports as a
+Mermaid UML diagram converted to SVG, and the *Technology Stack*
+(`ARCH-TS`) exports as a compact Markdown table.
+
+##  OPTIONS
+
+`--source`|`-s` *source*[,...]:
+    The comma-separated list of artifact kinds to export. Defaults to
+    `SPEC,ARCH` (the skill errors out on an empty source).
+
+##  EXAMPLES
+
+Export the specification and architecture artifacts to their
+side-by-side files (the default):
+
+```text
+❯ /ase-sync-export
+```
+
+Export only the specification artifacts:
+
+```text
+❯ /ase-sync-export -s SPEC
+```
+
+##  SEE ALSO
+
+[`ase-sync-reconcile`](../ase-sync-reconcile/help.md),
+[`ase-sync-import`](../ase-sync-import/help.md)

package/plugin/skills/ase-sync-import/help.md

@@ -77,4 +77,5 @@ Import a pasted feature description into a task plan:
 ##  SEE ALSO
 
 [`ase-sync-reconcile`](../ase-sync-reconcile/help.md),
+[`ase-sync-export`](../ase-sync-export/help.md),
 [`ase-task-implement`](../ase-task-implement/help.md)

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

@@ -204,9 +204,10 @@ Procedure
 
         -   If <getopt-option-next/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--no-other">
                 Next Step: How would you like to proceed with the plan?

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

@@ -225,9 +225,10 @@ Set <content-dirty>true</content-dirty>.
 
         -   If <getopt-option-plan/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--other">
                 Previous Plan: Should the previous plan content be overwritten, refined, or preserved?
@@ -377,9 +378,10 @@ Set <content-dirty>true</content-dirty>.
 
         -   If <getopt-option-next/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--other">
                 Next Step: How would you like to proceed with the plan?

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

@@ -175,10 +175,10 @@ Procedure
                 alternative answers <answer-N-K/> (K={2,3,4}), so there
                 are between two and four answer options in total.
 
-            3.  In the following, you *MUST* *NOT* use the
+            3.  In the following, you *MUST* *NOT* use your built-in
                 <user-dialog-tool/> tool! Instead, you *MUST* just show a
-                custom output, let the user enter input, and then you set
-                the result accordingly.
+                custom dialog according to the expanded `custom-dialog`
+                definition. You *MUST* closely follow this definition.
 
                 Let the user select the <answer-N/> out of the answer
                 alternatives <answer-N-K/> by raising a question with the
@@ -258,9 +258,10 @@ Procedure
 
         -   If <getopt-option-next/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--no-other">
                 Next Step: How would you like to proceed with the plan?

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

@@ -183,9 +183,10 @@ Procedure
 
         -   If <getopt-option-next/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--no-other">
                 Next Step: How would you like to proceed with the plan?

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

@@ -196,9 +196,10 @@ Procedure
 
         -   If <getopt-option-next/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--no-other">
                 Next Step: How would you like to proceed with the plan?

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

@@ -193,9 +193,10 @@ Procedure
 
         -   If <getopt-option-next/> is equal to `none`:
 
-            In the following, you *MUST* *NOT* use the <user-dialog-tool/>
-            tool! Instead, you *MUST* just show a custom output, let the
-            user enter input, and then you set the result accordingly.
+            In the following, you *MUST* *NOT* use your built-in
+            <user-dialog-tool/> tool! Instead, you *MUST* just show a
+            custom dialog according to the expanded `custom-dialog`
+            definition. You *MUST* closely follow this definition:
 
             <expand name="custom-dialog" arg1="--no-other">
                 Next Step: How would you like to proceed with the plan?