@rse/ase 0.9.2 → 0.9.3

package/dst/ase-hello.js

@@ -0,0 +1,24 @@
+/*
+**  Agentic Software Engineering (ASE)
+**  Copyright (c) 2025-2026 Dr. Ralf S. Engelschall <rse@engelschall.com>
+**  Licensed under GPL 3.0 <https://spdx.org/licenses/GPL-3.0-only>
+*/
+import chalk from "chalk";
+/*  CLI command "ase hello"  */
+export default class HelloCommand {
+    log;
+    constructor(log) {
+        this.log = log;
+    }
+    /*  register commands  */
+    register(program) {
+        /*  register CLI top-level command "ase hello"  */
+        program
+            .command("hello")
+            .description("Show \"Hello World!\"")
+            .action(() => {
+            process.stdout.write(chalk.blue("Hello World!") + "\n");
+            process.exit(0);
+        });
+    }
+}

package/dst/ase-statusline.js

@@ -96,9 +96,19 @@ const formatHoursMinutes = (ms) => {
     const mins = totalMin % 60;
     return `${hours}hr ${mins}m`;
 };
-/*  format an ISO timestamp as a remaining-time relative to now (e.g. 4hr 27m, 6d 12hr 7m)  */
-const formatTimeUntil = (iso) => {
-    const target = Date.parse(iso);
+/*  format an ISO timestamp or numeric Unix timestamp as a remaining-time relative to now (e.g. 4hr 27m, 6d 12hr 7m)  */
+const formatTimeUntil = (when) => {
+    let target;
+    if (typeof when === "number") {
+        if (!Number.isFinite(when))
+            return "";
+        /*  values below 1e12 are Unix seconds, otherwise milliseconds  */
+        target = when < 1e12 ? when * 1000 : when;
+    }
+    else if (typeof when === "string")
+        target = Date.parse(when);
+    else
+        return "";
     if (!Number.isFinite(target))
         return "";
     const delta = target - Date.now();
@@ -360,7 +370,7 @@ export default class StatuslineCommand {
                         emit(`${prefix("⏲", "session-usage")}${c.bold(`${pct5h.toFixed(1)}%`)}`);
                 },
                 D: () => {
-                    const until5h = data.rate_limits?.five_hour?.resets_at ?? "";
+                    const until5h = data.rate_limits?.five_hour?.resets_at;
                     const s = formatTimeUntil(until5h);
                     if (s !== "")
                         emit(`${prefix("⏱", "session-resets")}${c.bold(s)}`);
@@ -371,7 +381,7 @@ export default class StatuslineCommand {
                         emit(`${prefix("⏲", "weekly-usage")}${c.bold(`${pctWk.toFixed(1)}%`)}`);
                 },
                 Q: () => {
-                    const untilWk = data.rate_limits?.seven_day?.resets_at ?? "";
+                    const untilWk = data.rate_limits?.seven_day?.resets_at;
                     const s = formatTimeUntil(untilWk);
                     if (s !== "")
                         emit(`${prefix("⏱", "weekly-resets")}${c.bold(s)}`);

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.2",
+    "version":                              "0.9.3",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -30,7 +30,7 @@
         "nodemon":                          "3.1.14",
         "shx":                              "0.4.0",
 
-        "@types/node":                      "25.9.1",
+        "@types/node":                      "25.9.2",
         "@types/luxon":                     "3.7.1",
         "@types/which":                     "3.0.4",
         "@types/update-notifier":           "6.0.8",

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

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

package/plugin/agents/ase-meta-review.md

@@ -0,0 +1,188 @@
+---
+name: ase-meta-review
+description: "Review Investigation"
+effort: high
+---
+
+Your role is an experienced, *expert-level software reviewer* performing
+a holistic, human-style review of a concrete set of staged Git changes —
+the way a thorough reviewer would judge a pull request before approving it.
+
+Your objective is to *reconstruct the change's intent* and *critique the
+staged diff as a whole* against a fixed set of reviewer dimensions,
+producing *prioritized*, *severity-tagged*, *line-cited* findings.
+
+Workflow
+--------
+
+1.  Capture the *staged change set* by running the following command
+    (taken exactly as given), capturing the full diff output into <diff/>:
+
+    `git diff --cached HEAD`
+
+2.  Use the `Read` tool to read *every* file touched by <diff/> in its
+    *full current form* (not just the hunks), plus all *related* files
+    needed to really comprehend the change — callers of changed
+    functions, the interfaces/contracts they implement, and adjacent
+    code that establishes the surrounding idiom. A diff cannot be
+    reviewed from the hunks alone.
+
+3.  *Probe the repository read-only and heuristically* (via `git grep`,
+    `grep`, `git ls-files`, restricted to first-party code) only as
+    needed to substantiate findings — e.g. who imports a touched module,
+    whether a changed contract has other call sites, whether touched code
+    has adjacent tests. Do not modify anything.
+
+4.  Read the project's *documented conventions* — the AI guidance files
+    (`AGENTS.md`, or similar) and any referenced format/meta documents
+    — so the `CONVENTION` dimension can be judged against the project's
+    *own* stated rules (code style, plan/spec/arch formats) rather than
+    generic taste.
+
+5.  *Reconstruct the intent*: determine the *single*, *coherent* purpose
+    the diff *as a whole* is trying to accomplish, and capture it as a
+    *single* crisp sentence in <summary/>. If the diff genuinely spans
+    several unrelated purposes, pick the *dominant* one (the residue will
+    surface as an `INTENT` finding below).
+
+6.  Set <findings/> to empty.
+    Then critique the change across the following fixed *dimensions*
+    (each finding is tagged with exactly one `dimension`):
+
+    -   **INTENT**:
+        Hunks that do *not* serve the reconstructed intent — scope creep
+        (an unrelated feature or drive-by refactor riding along), stray
+        debug/diagnostic residue (debug prints, commented-out code,
+        disabled tests, `TODO`/`FIXME` scaffolding), or an incomplete
+        change that does not fully achieve its own stated purpose.
+
+    -   **CORRECTNESS**:
+        Latent bugs introduced or left by the change — wrong logic,
+        unhandled edge cases, off-by-one and boundary errors, broken
+        control or data flow, incorrect assumptions about inputs or state.
+
+    -   **DESIGN**:
+        Poor fit with the surrounding architecture — wrong abstraction
+        level, misplaced responsibility, leaky or broken interface
+        contracts, poor naming, or a simpler/more idiomatic shape the
+        change overlooked.
+
+    -   **CLARITY**:
+        Readability and self-documentation problems for a *future
+        reader* — confusing constructs, misleading names, missing
+        rationale for a non-obvious choice, or unnecessary complexity.
+
+    -   **ROBUSTNESS**:
+        Missing, incorrect, or inconsistent error handling; resource
+        allocation/deallocation imbalance; and concurrency or
+        asynchronicity hazards introduced by the change.
+
+    -   **SECURITY**:
+        Vulnerabilities or missing essential validations introduced by
+        the change — injection, unsafe input handling, secret exposure,
+        privilege or trust-boundary mistakes, unsafe edge cases in value
+        ranges.
+
+    -   **PERFORMANCE**:
+        Efficiency risks introduced by the change — non-constant/
+        non-linear hot paths, redundant work, or avoidable allocations
+        on a path the change clearly exercises.
+
+    -   **CONVENTION**:
+        Conformance to the *project's own documented conventions* — the
+        code style and the plan/spec/arch artifact formats stated in the
+        project's AI guidance and meta documents. Judge against what the
+        project *documents*, not against generic preference.
+
+    -   **TESTING**:
+        Inadequate test coverage for the change — new logic or fixed
+        behavior left untested, adjacent tests not updated to match the
+        new behavior, or existing tests silently broken, disabled, or
+        weakened by the change.
+
+    -   **DOCUMENTATION**:
+        User- or developer-facing documentation left stale by the change
+        — `README`, `CHANGELOG`, help text, or AI guidance/meta documents
+        that no longer match the change's new behavior, options, or
+        formats.
+
+    Be *holistic* and *synthesizing*: prefer a *few* high-signal findings
+    that a human reviewer would actually raise over an exhaustive
+    mechanical list. Be *conservative* — only report clear, well-grounded
+    concerns, and think twice to avoid *false positives*. Be *focused* —
+    only report concerns about the *staged change* itself; ignore
+    pre-existing issues in unchanged code that the diff merely sits next
+    to.
+
+    For *each* finding:
+
+    1.  Set <dimension/> to exactly one of `INTENT`, `CORRECTNESS`,
+        `DESIGN`, `CLARITY`, `ROBUSTNESS`, `SECURITY`, `PERFORMANCE`,
+        `CONVENTION`, `TESTING`, or `DOCUMENTATION`.
+
+    2.  Set <severity/> to one of `HIGH`, `MEDIUM`, `LOW`, or `ACCEPTED`:
+
+        -   `HIGH`: a blocking concern a reviewer would require fixed
+            before approval (a real bug, a security hole, a broken contract,
+            a hard convention violation).
+
+        -   `MEDIUM`: a concern worth addressing but not strictly
+            blocking.
+
+        -   `LOW`: a minor nit or suggestion.
+
+        -   `ACCEPTED`: a concern that *is* explicitly addressed by
+            a contract, docstring, or documented project priority (a
+            hot-path/allocation/latency tradeoff, or "contractually
+            addressed") — kept visible for traceability rather than dropped.
+
+        *Documented-context alignment* is mandatory: cross-check each
+        finding against interface contracts, docstrings, adjacent
+        comments, and the project AI guidance files. If the concern is
+        already addressed there, mark it `ACCEPTED` with the reason in
+        the finding text rather than reporting it as a defect; if a
+        fix would violate a documented priority, weaken it or mark it
+        `ACCEPTED` ("priority-conflict accepted").
+
+    3.  Set <location/> to the *relative* filename path of the affected
+        file, with the affected 1-based line number `N` appended as `:N`
+        or the 1-based line range appended as `:N-M`. *Evidence-grounded*
+        citation is mandatory — the cited lines MUST prove the finding
+        verbatim; if they do not, re-investigate and re-cite, and drop
+        the finding only if *no* location in the changed files proves it.
+
+    4.  Set <finding/> to an *ultra-brief*, *concise* Markdown-formatted
+        statement combining *what* the concern is and *why* it matters
+        (and, for `ACCEPTED`, *where* it is addressed). Mark up all
+        referenced verbatim identifiers or keywords <words/> from the
+        code as quoted monospaced strings based on the following
+        <template/>: <template>"`<words/>`"</template>. Keep it to a
+        single sentence wherever possible.
+
+    5.  If <findings/> is not empty, set
+        <findings><findings/>,</findings> (append a comma).
+        Then append the following <template/> to <findings/>:
+
+        <template>
+            {
+                "dimension": <dimension/>,
+                "severity":  <severity/>,
+                "location":  <location/>,
+                "finding":   <finding/>
+            }
+        </template>
+
+7.  Return *exclusively* a single fenced JSON block (no prose, no
+    preamble, no summary) of the following shape:
+
+    ```json
+    {
+        "summary": <summary/>,
+        "findings": [
+            <findings/>
+        ]
+    }
+    ```
+
+8.  You *MUST* *NOT* propose, apply, or render any code or document
+    changes yourself.

package/plugin/etc/eslint.mjs

@@ -0,0 +1,25 @@
+/*
+**  Agentic Software Engineering (ASE)
+**  Copyright (c) 2025-2026 Dr. Ralf S. Engelschall <rse@engelschall.com>
+**  Licensed under GPL 3.0 <https://spdx.org/licenses/GPL-3.0-only>
+*/
+
+import { defineConfig } from "eslint/config"
+import markdown         from "@eslint/markdown"
+import md               from "eslint-markdown"
+
+export default defineConfig([
+    // markdown.configs.recommended,
+    md.configs.recommended,
+    {
+        files: [
+            "meta/*.md",
+            "skills/**/*.md"
+        ],
+        rules: {
+            "md/no-double-space":     "off",
+            "md/code-lang-shorthand": "off"
+        }
+    }
+])
+

package/plugin/etc/markdownlint.yaml

@@ -6,16 +6,18 @@
 
 no-multiple-blanks:
     maximum: 2
-no-inline-html:     false
-line-length:        false
-ol-prefix:          false
-list-marker-space:  false
-first-line-heading: false
-no-space-in-code:   false
-ul-indent:          false
-ol-indent:          false
-heading-style:      false
+no-inline-html:        false
+line-length:           false
+ol-prefix:             false
+list-marker-space:     false
+first-line-heading:    false
+no-space-in-code:      false
+ul-indent:             false
+ol-indent:             false
+heading-style:         false
 no-multiple-space-atx: false
-blanks-around-tables: false
-code-block-style:   false
+blanks-around-tables:  false
+code-block-style:      false
+no-duplicate-heading:  false
+link-fragments:        false
 

package/plugin/etc/stx.conf

@@ -6,7 +6,8 @@
 
 #   [plugin] lint project
 lint
-    markdownlint-cli2 --config etc/markdownlint.yaml skills/**/*.md
+    markdownlint-cli2 --config etc/markdownlint.yaml meta/*.md skills/**/*.md && \
+    eslint --config etc/eslint.mjs meta skills
 
 #   [plugin] build project
 build : lint

package/plugin/meta/ase-control.md

@@ -32,11 +32,16 @@ Control Flow Constructs
     Do not output anything else.
 
 -   *IMPORTANT*: You *MUST* honor the following control flow construct:
-    <step id="<id/>"><step-body/></step>:
+    <step id="<id/>" [condition="<step-condition/>"]><step-body/></step>:
 
     This specifies a distinct *single step* in a <flow/>.
     This construct is expanded to its <step-body/>.
-    Do not output anything else.
+    The optional `condition` attribute *enables* the step only if
+    <step-condition/> is met: if <step-condition/> is met, this construct
+    is expanded to its <step-body/>; if <step-condition/> is *not* met,
+    the entire step is silently *skipped* and this construct is expanded
+    to the empty string. When the `condition` attribute is *absent*, the
+    step is *always* enabled. Do not output anything else.
 
 -   *IMPORTANT*: You *MUST* honor the following control flow construct:
     <if condition="<if-condition/>"><if-body/></if>:

package/plugin/meta/ase-dialog.md

@@ -132,6 +132,8 @@ Let the *user interactively choose* an answer.
                 (prefix result with "OTHER").
 
             Do not output anything in this step!
+
         </if>
+
 </define>
 

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

@@ -219,11 +219,11 @@ at runtime.
         Processor`, `Notification Dispatcher`).
 
     -   <arch-fv-component-kind/> is one of:
-        -   `Component`:  Cohesive unit of functionality with a defined interface.
-        -   `Service`:    Independently deployable provider of functionality.
-        -   `Module`:     Logical grouping of related functionality within a component.
-        -   `Connector`:  Mediator that conveys interactions between components (e.g. bus, gateway).
-        -   `Subsystem`:  Larger composite grouping several components.
+        -   `Component`: Cohesive unit of functionality with a defined interface.
+        -   `Service`:   Independently deployable provider of functionality.
+        -   `Module`:    Logical grouping of related functionality within a component.
+        -   `Connector`: Mediator that conveys interactions between components (e.g. bus, gateway).
+        -   `Subsystem`: Larger composite grouping several components.
 
     -   <arch-fv-component-responsibility/> is the 1-sentence statement of
         the single, primary responsibility the component owns.
@@ -377,11 +377,11 @@ communicate.
 
     -   <arch-co-unit-kind/> is one of:
 
-        -   `Process`:    An independent OS process with its own address space.
-        -   `Thread`:     A thread of execution within a process.
-        -   `Pool`:       A managed group of interchangeable workers.
-        -   `Queue`:      An asynchronous buffer decoupling producers and consumers.
-        -   `EventLoop`:  A single-threaded cooperative scheduler of tasks.
+        -   `Process`:   An independent OS process with its own address space.
+        -   `Thread`:    A thread of execution within a process.
+        -   `Pool`:      A managed group of interchangeable workers.
+        -   `Queue`:     An asynchronous buffer decoupling producers and consumers.
+        -   `EventLoop`: A single-threaded cooperative scheduler of tasks.
 
     -   <arch-co-unit-element/> is an `ARCH-FV-<arch-fv-component-id/>`
         reference to a functional component that runs inside this
@@ -518,12 +518,12 @@ elements to the runtime platform, hardware, and network topology.
 
     -   <arch-dp-node-kind/> is one of:
 
-        -   `Server`:     A physical or virtual machine.
-        -   `Container`:  A containerized runtime (e.g. Docker, OCI).
-        -   `Cluster`:    A managed group of nodes (e.g. Kubernetes cluster).
-        -   `Function`:   A serverless / function-as-a-service runtime.
-        -   `Device`:     An edge or client device.
-        -   `Managed`:    A managed cloud service (e.g. managed database, queue).
+        -   `Server`:    A physical or virtual machine.
+        -   `Container`: A containerized runtime (e.g. Docker, OCI).
+        -   `Cluster`:   A managed group of nodes (e.g. Kubernetes cluster).
+        -   `Function`:  A serverless / function-as-a-service runtime.
+        -   `Device`:    An edge or client device.
+        -   `Managed`:   A managed cloud service (e.g. managed database, queue).
 
     -   <arch-dp-node-platform/> is the runtime platform of the node
         (e.g. `Linux x86-64`, `Kubernetes 1.30`, `AWS Lambda (Node.js)`).
@@ -764,50 +764,50 @@ forces at play, the chosen response, and the reasoning that justifies it.
         as the **Artifact**'s own timestamps.
 
     -   <arch-dr-decision-context/> captures the situation that forces the
-        decision — the "why are we even talking about this" part. It
+        decision - the "why are we even talking about this" part. It
         describes the situation as it is, before the decision is made. The
         following usually goes into it: the problem or need (what's broken,
         missing, or about to change that requires a decision); the forces at
         play (technical constraints, business requirements, deadlines, team
-        skills, existing systems, regulatory/compliance pressures — often
+        skills, existing systems, regulatory/compliance pressures - often
         competing, and that tension is the whole point); relevant facts
         (current architecture, prior decisions, assumptions, what's known
         and what's uncertain); and scope/boundaries (what this decision is
         and isn't about). It is written neutrally and factually. It should
-        not contain the decision itself, nor advocate for an option — a
+        not contain the decision itself, nor advocate for an option - a
         reader should be able to read it, pause, and arrive at the decision
         themselves because the forces make it (nearly) inevitable.
 
     -   <arch-dr-decision-decision/> states what is actually going to be
-        done — the chosen response to the forces laid out in the context. It
+        done - the chosen response to the forces laid out in the context. It
         is written in active, assertive voice, in the present or imperative
         tense, as a committed position rather than a discussion. The
         following usually goes into it: the choice itself (clearly and
         unambiguously) and the essence of how (enough of the approach to
-        make the choice concrete — the mechanism, pattern, or technology —
+        make the choice concrete - the mechanism, pattern, or technology -
         but not a full implementation specification). It is a declaration,
         not a deliberation, usually using the wording "We use..." or "We
         do...", active, definite, owning the choice. Avoid hedging ("we
-        might", "we could consider") — the deliberation already happened,
+        might", "we could consider") - the deliberation already happened,
         the decision records the verdict.
 
     -   <arch-dr-decision-rationale/> is the reasoning that justifies the
-        decision — the bridge that explains why this choice, given those
+        decision - the bridge that explains why this choice, given those
         forces. It answers "Of all the things we could have done, why was
         this the right one?". Where the context states the forces and the
         decision states the choice, the rationale is the logical connective
-        tissue between them — it shows that the decision actually follows
+        tissue between them - it shows that the decision actually follows
         from the context. The following usually goes into it: the deciding
         factors (which forces from the context carried the most weight, and
         how the chosen option satisfies them best); the trade-off reasoning
-        (what was optimized for and what was knowingly sacrificed — naming
+        (what was optimized for and what was knowingly sacrificed - naming
         the trade-off is the heart of rationale); why the alternatives lost
         (the comparative argument: "option B failed on X, option C cost too
         much on Y"); and assumptions and evidence (benchmarks, prior
         experience, constraints, or principles the reasoning rests on).
 
     -   <arch-dr-decision-notes/> is *OPTIONAL* and can be omitted when it
-        does not add genuine value — most decisions won't need it. The
+        does not add genuine value - most decisions won't need it. The
         following usually goes into it: information of the decision *process*
         (e.g. a weighted decision matrix of considered alternatives);
         consequences of the decision (but only when non-obvious downstream
@@ -818,16 +818,16 @@ forces at play, the chosen response, and the reasoning that justifies it.
         <arch-dr-decision-rationale/> are each just a single paragraph of
         concise and brief prose text, usually comprised of just 1 to 3
         sentences. The value of a decision is in recording *that* a decision
-        was made and *why* — not in filling out sections of a document.
+        was made and *why* - not in filling out sections of a document.
 
     -   For the relationship between context, decision, and rationale, good
         checks are: the "litmus test" is that context = forces, decision =
         response to those forces, rationale = why the decision answers the
         forces in the context. The decision should feel like the natural,
-        almost inevitable answer to the context — if a reader is surprised
+        almost inevitable answer to the context - if a reader is surprised
         by the decision, either the context is missing a force, or the
         decision is under-justified. The rationale should make the decision
-        feel earned, not asserted — if you would delete the rationale and
+        feel earned, not asserted - if you would delete the rationale and
         the decision suddenly looks arbitrary, the rationale was doing its
         job.
 
@@ -861,7 +861,7 @@ forces at play, the chosen response, and the reasoning that justifies it.
         communicate via domain events, not synchronous HTTP."
 
     -   **Technology choices that carry lock-in.** Database, message bus,
-        auth provider, deployment target. Not every library — just the
+        auth provider, deployment target. Not every library - just the
         ones that would take a quarter to swap out.
 
     -   **Boundary and scope decisions.** "Customer data is owned by the
@@ -878,5 +878,5 @@ forces at play, the chosen response, and the reasoning that justifies it.
         of the partner API contract."
 
     -   **Rejected alternatives when the rejection is non-obvious.** If
-        you considered GraphQL and picked REST for subtle reasons, record it —
+        you considered GraphQL and picked REST for subtle reasons, record it -
         otherwise someone will suggest GraphQL again in six months.

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

@@ -230,8 +230,8 @@ capturing their goals, needs, behaviors, and context.
 
     -   <spec-pe-persona-role/>: the role of the persona.
 
-    -   <spec-pe-persona-quote/>: a short and bold, first-person statement —
-        written in the persona's own voice — that captures their core
+    -   <spec-pe-persona-quote/>: a short and bold, first-person statement -
+        written in the persona's own voice - that captures their core
         attitude, motivation, frustration, or need in a single memorable line.
         It's sometimes called the persona's "tagline," "mantra," or "defining
         statement."
@@ -1138,7 +1138,7 @@ master-detail dialog).
 
     -   <spec-dp-pattern-rationale/>: the 1-sentence justification for why
         the structure in <spec-dp-pattern-description/> is the right
-        response — the benefit it secures or the trade-off it wins.
+        response - the benefit it secures or the trade-off it wins.
         Unlike <spec-dp-pattern-problem/> (which states *why the pattern
         is needed*, independent of any solution), the rationale states
         *why this particular solution is worth adopting*.

package/plugin/meta/ase-getopt.md

@@ -87,5 +87,6 @@ set placeholders into the context as a side-effect.
     <template>
     ⧉ **ASE**: ✪ skill: **<getopt-skill/>**, ▶ options: <getopt-info/>
     </template>
+
 </define>
 

package/plugin/meta/ase-persona.md

@@ -33,7 +33,7 @@ Persona Ruleset Levels
 -   You *MUST* *use* arrows for causality
     ("X → Y").
 -   You *MUST* *use* em-dashes for short subsequent facts
-    ("X — Y").
+    ("X - Y").
 -   You *MUST* *drop* articles
     ("a", "an", "the", etc).
 -   You *MUST* *use* short separate sentences instead of conjunctions

package/plugin/meta/ase-skill.md

@@ -26,7 +26,7 @@ Skill Output
     to the currently defined persona style.
 
 -   *IMPORTANT*: The active *persona style* (see `ase-persona.md`) *MUST* be applied
-    to all *free-text placeholders* within <template/> sections — i.e. any placeholder
+    to all *free-text placeholders* within <template/> sections - i.e. any placeholder
     whose content you author yourself (such as `<description/>`, `<title/>`, `<objective/>`,
     `<summary/>`, `<explanation/>`, etc.). The *structure* of the template (fixed keywords,
     punctuation, labels) remains unchanged; only the *authored content* inside free
@@ -51,7 +51,7 @@ Skill Output
         padding, draw the top edge to that width, then keep every
         inner line (including annotations like `!`, `?`, `*`)
         within it. Count columns and verify before emitting; a
-        one-space drift is a defect — re-render.
+        one-space drift is a defect - re-render.
 
 -   *IMPORTANT*: For *Findings* (problems, tradeoffs, warnings
     emitted by analysis skills):
@@ -61,18 +61,18 @@ Skill Output
         snippet must prove the claim *verbatim*. If the cited
         lines do not prove the claim, *re-investigate and
         re-cite correctly*. Drop the finding *only* if no code
-        location in the scanned files proves it — never drop
+        location in the scanned files proves it - never drop
         due to sloppy citation alone.
 
     -   *Documented-context alignment*: cross-check each
-        finding against documented context — interface
+        finding against documented context - interface
         contracts, docstrings (Javadoc, JSDoc, Python
         docstring, ...), adjacent code comments, and
         project-level AI guidance files (`CLAUDE.md`,
         `AGENTS.md`, `GEMINI.md`, `MEMORY.md`,
         `.github/copilot-instructions.md`, `.cursor/rules/`,
         or similar). Two cases resolve via the same
-        mechanism — do *not* drop, keep the finding visible
+        mechanism - do *not* drop, keep the finding visible
         for traceability:
 
         -   *Problem already addressed*: the finding's
@@ -136,7 +136,7 @@ MCP Tool Calls
         error), output the following and stop immediately:
 
         <template>
-        ⧉ **ASE**: **ERROR:** MCP server not running — please start it via `ase service start` and reconnect via `/mcp`, then retry.
+        ⧉ **ASE**: **ERROR:** MCP server not running - please start it via `ase service start` and reconnect via `/mcp`, then retry.
         </template>
 
     -   If the call fails for any other reason (timeout, transport error,

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.2",
+    "version":                              "0.9.3",
     "license":                              "GPL-3.0-only",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -16,7 +16,10 @@
     "devDependencies": {
         "@rse/stx":                         "1.1.5",
         "markdownlint":                     "0.40.0",
-        "markdownlint-cli2":                "0.22.1"
+        "markdownlint-cli2":                "0.22.1",
+        "eslint":                           "10.4.1",
+        "@eslint/markdown":                 "8.0.2",
+        "eslint-markdown":                  "0.10.0"
     },
     "engines": {
         "npm":                              ">=10.0.0",