@rse/ase 0.9.2 → 0.9.3

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

@@ -122,46 +122,46 @@ interface quality, quality attributes, and architecture governance.
     task into appropriate chunks.
 
     *Determine* the *target programming language* and the *declared
-    architecture style* (if any) — e.g., Layered, Hexagonal
+    architecture style* (if any) - e.g., Layered, Hexagonal
     (Ports & Adapters), Onion, Clean, CQRS, Microservices,
-    Event-Driven, Modular Monolith — from code, project documentation,
+    Event-Driven, Modular Monolith - from code, project documentation,
     README files, or folder structure.
 
     Investigate the following architecture quality aspects across
     7 thematic blocks:
 
-    **Block 1 — Component Boundaries**:
+    **Block 1 - Component Boundaries**:
 
     - **SA01 COMPONENT-RESPONSIBILITY**: each component (module,
-      class, package) addresses exactly *one single concern* —
+      class, package) addresses exactly *one single concern* -
       i.e., has exactly *one reason to change*.
     - **SA02 COMPONENT-GRANULARITY**: components have *appropriate
-      size* — neither monolithic nor fragmented.
+      size* - neither monolithic nor fragmented.
     - **SA03 COMPONENT-HIERARCHY**: components placed at the *correct
       level* of the component hierarchy (system / program / module /
       class / function).
 
-    **Block 2 — Structural Organization**:
+    **Block 2 - Structural Organization**:
 
     - **SA04 LAYERING**: *layers* (horizontal cuts) clearly
       separated, named, and ranked; no upward dependencies.
-    - **SA05 SLICING**: *slices* (vertical cuts — e.g., feature
+    - **SA05 SLICING**: *slices* (vertical cuts - e.g., feature
       modules, bounded contexts) clearly separated and *cycle-free*.
     - **SA06 DEPENDENCY-DIRECTION**: dependencies flow in exactly
       *one direction*; no *circular dependencies*.
-    - **SA07 REFERENCE-ARCHITECTURE**: *declared-style conformance* —
+    - **SA07 REFERENCE-ARCHITECTURE**: *declared-style conformance* -
       the chosen architecture style (see STEP 1 intro for the
       recognized style list) is applied *consistently* throughout
       the codebase, without accidental mixing of styles.
 
-    **Block 3 — Architecture Principles**:
+    **Block 3 - Architecture Principles**:
 
-    - **SA08 COUPLING**: *loose data coupling* between components —
+    - **SA08 COUPLING**: *loose data coupling* between components -
       no *concrete-type dependencies* where abstractions exist, no
       shared data structures leaking across boundaries, communication
       via defined ports / facades / DTOs. (Runtime coupling such as
       races and shared mutable state is covered by SA17.)
-    - **SA09 COHESION**: *strong cohesion* within each component —
+    - **SA09 COHESION**: *strong cohesion* within each component -
       internal parts (functions, fields, methods) are *tightly
       related*, *co-change*, and share data or behavior; scattered
       helpers that merely coexist by accident are flagged.
@@ -175,7 +175,7 @@ interface quality, quality attributes, and architecture governance.
       behind a simple interface that *shields* its implementation
       details.
 
-    **Block 4 — Interface Quality**:
+    **Block 4 - Interface Quality**:
 
     - **SA13 INTERFACE-SIZE**: each interface *proportional in size*
       to its functionality.
@@ -186,20 +186,20 @@ interface quality, quality attributes, and architecture governance.
       *syntactic* and *semantic* contracts (pre/post-conditions,
       invariants, idempotency, thread-safety).
 
-    **Block 5 — Quality Attributes**:
+    **Block 5 - Quality Attributes**:
 
     - **SA16 TESTABILITY**: architectural *seams* enable testing in
-      isolation — dependency injection at component boundaries,
+      isolation - dependency injection at component boundaries,
       mockable interfaces, side effects (DB, filesystem, network,
       time, randomness) hidden behind abstractions.
     - **SA17 CONCURRENCY**: the *concurrency model* (event loop,
       threads, goroutines, async/await, actors, ...) is *explicitly
-      chosen* and applied *consistently*. *Runtime coupling* —
+      chosen* and applied *consistently*. *Runtime coupling* -
       thread-safety boundaries, shared mutable state, races, lock
-      hold times, async/sync boundaries — is explicit and localized;
+      hold times, async/sync boundaries - is explicit and localized;
       shared mutable state is protected.
 
-    **Block 6 — Architecture Governance**:
+    **Block 6 - Architecture Governance**:
 
     - **SA18 DECISION-RECORDS**: non-trivial architectural decisions
       are *documented* with rationale (Architecture Decision Records
@@ -207,10 +207,10 @@ interface quality, quality attributes, and architecture governance.
       The chosen style, deviations from defaults, and trade-offs are
       traceable.
 
-    **Block 7 — Package Cohesion**:
+    **Block 7 - Package Cohesion**:
 
     - **SA19 PACKAGE-COHESION**: each first-party package has a
-      coherent role *and* topical theme — its members serve a
+      coherent role *and* topical theme - its members serve a
       common purpose, share a dominant noun-cluster, and have
       non-trivial cross-package use. Flag:
       - *grab-bag*: members split into ≥3 unrelated topical
@@ -223,16 +223,16 @@ interface quality, quality attributes, and architecture governance.
         overlap with the package's dominant noun-cluster, or with
         its `package-info` / `README` declaration when present
     - **SA20 PACKAGE-CYCLE**: no *cyclic dependencies* between
-      first-party packages — neither direct (`A → B` and `B → A`)
+      first-party packages - neither direct (`A → B` and `B → A`)
       nor transitive (via *Tarjan SCC* or pairwise scan). Each
       cycle is reported with the exact import lines that close it.
     - **SA21 PACKAGE-SIZE**: package size and coupling shape are
-      justified — flag packages at either extreme:
-      - *god-package*: *incoming ≥ 5* and *outgoing ≥ 3* —
+      justified - flag packages at either extreme:
+      - *god-package*: *incoming ≥ 5* and *outgoing ≥ 3* -
         coordinator dumping ground that should be split along its
         internal topical clusters
       - *fragment*: 1–2 files under a sibling parent that share a
-        *name prefix* or *imported interface* with that sibling —
+        *name prefix* or *imported interface* with that sibling -
         consolidation candidate
 
     Hints:
@@ -253,7 +253,7 @@ interface quality, quality attributes, and architecture governance.
       any claim about *ordering*, *lock hold time*, *thread
       boundary*, or *call from context X*, trace the actual
       acquire/release and call order line-by-line. Do not
-      pattern-match on "loop inside method with lock" — verify
+      pattern-match on "loop inside method with lock" - verify
       which operations sit *between* the specific acquire and
       release in source order.
 
@@ -264,7 +264,7 @@ interface quality, quality attributes, and architecture governance.
       incoming/outgoing class-edge map (drives SA20, SA21) and
       the per-package noun-token frequency table extracted from
       class names in camelCase / snake_case (drives SA19 topical
-      analysis). No external NLP — pure tokens. Cite each finding
+      analysis). No external NLP - pure tokens. Cite each finding
       with the exact import lines or class-name evidence.
 
     - *Block 7 severity ladder*: SA20 (cycle) → HIGH; SA21
@@ -308,11 +308,11 @@ interface quality, quality attributes, and architecture governance.
       Because `!` and `?` are Mermaid special characters, *always
       quote* anomaly-bearing node labels:
 
-      -   *Problem node* — prefix label with `!` inside quotes:
+      -   *Problem node* - prefix label with `!` inside quotes:
           `A["!ComponentA"]`.
-      -   *Unclear node* — suffix label with `(?)` inside quotes:
+      -   *Unclear node* - suffix label with `(?)` inside quotes:
           `B["ComponentB (?)"]`.
-      -   *Cyclic edge* — annotate the *edge* (not a node) with a
+      -   *Cyclic edge* - annotate the *edge* (not a node) with a
           `cycle` label on a bidirectional arrow:
           `A <-- "cycle" --> B` (or two labelled one-way edges if
           the renderer rejects `<-->`).
@@ -325,11 +325,11 @@ interface quality, quality attributes, and architecture governance.
     Before reporting, classify every finding into one of three
     categories:
 
-    - *Unpaired* — single aspect violated, no partner in the
+    - *Unpaired* - single aspect violated, no partner in the
       tension matrix hit → emit `PROBLEM` template.
-    - *Paired* — exactly two aspects of a single tension pair hit
+    - *Paired* - exactly two aspects of a single tension pair hit
       → emit `TRADEOFF` template (cluster of size 2).
-    - *Clustered* — an aspect appears in *multiple* triggered
+    - *Clustered* - an aspect appears in *multiple* triggered
       tensions (e.g., SA10 hit against both SA12 and SA13) →
       collapse into *one* `TRADEOFF` with the recurring aspect
       as *focal aspect* and the others as *partners*. One
@@ -367,7 +367,7 @@ interface quality, quality attributes, and architecture governance.
     <template>
     <ase-tpl-bullet-normal/> **TRADEOFF** T<n/> (Severity: <severity/>): **<title/>**
 
-    - *Focal aspect*: <focal-aspect/> — <focal-state/>
+    - *Focal aspect*: <focal-aspect/> - <focal-state/>
     - *In tension with*: <partner-list/>
 
     **RECOMMENDED**: lean toward *<focal|partners/>*
@@ -396,7 +396,7 @@ interface quality, quality attributes, and architecture governance.
       (<description/>, <focal-state/>, partner-implications)
       are *very brief* but *precise*. <rationale/> is exactly
       *one sentence* grounded in the detected style, domain
-      constraints, or language idioms — never generic
+      constraints, or language idioms - never generic
       principles.
 
     - Highlight *code* as <template>`<code/>`</template>

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

@@ -226,7 +226,7 @@ related to a set of code quality aspects.
                 Generate a *new* proposal for the *same* <item/>
                 (incorporating the user's free-text hint from <result/> if
                 provided via the "OTHER" prefix) and loop back to substep 2
-                of this iteration. There is *no* cap on refinement rounds —
+                of this iteration. There is *no* cap on refinement rounds -
                 keep refining until the user picks `ACCEPT` or `REJECT`.
                 </if>
 

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

@@ -20,7 +20,7 @@ into the user-visible transcript.
 
 For each detected problem, the skill renders a unified-diff *SOLUTION*
 preview and either asks the user to `ACCEPT` or `REJECT` the proposed
-correction interactively or — with `--auto` — applies all corrections
+correction interactively or - with `--auto` - applies all corrections
 automatically.
 
 ##  OPTIONS

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

@@ -0,0 +1,158 @@
+---
+name: ase-docs-distill
+argument-hint: "[--help|-h] [--top|-t <N>] <document-reference>"
+description: >
+    Distill a provided document into a flat, importance-ranked list
+    of its key points, each with a salience rank, a rationale, and a
+    verbatim line-cited evidence snippet. Use when the user wants to
+    "distill", "summarize the key points", or "extract the essence" of a
+    document or pasted text.
+user-invocable: true
+disable-model-invocation: false
+effort: high
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
+
+<skill name="ase-docs-distill">
+    Distill Key Points
+</skill>
+
+<expand name="getopt"
+    arg1="ase-docs-distill"
+    arg2="--top|-t=5">
+    $ARGUMENTS
+</expand>
+
+<objective>
+    *Distill* the content `<getopt-arguments/>` into a *flat*,
+    *importance-ranked* list of its *key points* - each point an
+    *atomic* claim carrying a *0-10 salience rank*, a *one-line
+    rationale*, and a *verbatim, line-cited evidence* snippet - keeping
+    at most `<getopt-option-top/>` points.
+</objective>
+
+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/>!
+
+<flow>
+
+1.  <step id="STEP 1: Resolve Input">
+
+    Resolve the document source from <getopt-arguments/> using
+    *probe-as-file-first* semantics:
+
+    1.  <if condition="<getopt-arguments/> is empty">
+
+        Only output the following <template/> and then *STOP* immediately:
+
+        <template>
+        ⧉ **ASE**: ✪ skill: **ase-docs-distill**, ▶ status: **no document to distill**
+        </template>
+
+        </if>
+
+    2.  Treat the *entire* <getopt-arguments/> as a *file path*. If it
+        resolves to a *readable file*, read that file and capture its
+        content together with its *line numbers* into <source/>, and set
+        <origin/> to the file path.
+
+    3.  <if condition="<getopt-arguments/> does NOT resolve to a readable file">
+
+        Treat <getopt-arguments/> *verbatim* as *pasted text*, capture it
+        into <source/> numbering its lines from *1*, and set <origin/>
+        to empty (so locations are cited as `:Ls-Le`).
+
+        </if>
+
+    4.  <if condition="<source/> is empty">
+
+        Only output the following <template/> and then *STOP* immediately:
+
+        <template>
+        ⧉ **ASE**: ✪ skill: **ase-docs-distill**, ▶ status: **no document to distill**
+        </template>
+
+        </if>
+
+    You *MUST* *NOT* output anything in this STEP 1.
+
+    </step>
+
+2.  <step id="STEP 2: Distill Key Points">
+
+    Read <source/> and distill it into its *key points*.
+
+    1.  Extract the document's *key points*, where each point is *one
+        atomic, self-contained claim, decision, or fact* - *not* a
+        section-level summary that blends several claims.
+
+    2.  For each point, determine:
+
+        -   A <rank/> on a *0-10* salience scale reflecting its
+            *importance-to-the-reader* (impact, centrality, consequence)
+            - *not* its position in the document.
+
+        -   A one-line <rationale/> that justifies *why* the point earns
+            that <rank/>.
+
+        -   A <location/> citing the exact source line range as
+            `<origin/>:Ls-Le` (for a file) or `:Ls-Le` (for pasted text),
+            where `Ls` is the start line and `Le` is the end line.
+
+        -   A *verbatim* <evidence/> snippet, copied exactly from
+            <source/> (but with all newlines replaces with spaces
+            and multiple spaces collapsed into a single space), that
+            *proves* the point. The cited snippet *MUST* prove the
+            point verbatim. If it does not, *re-investigate and re-cite
+            correctly*.
+
+    3.  *Sort* the points by <rank/> from *highest to lowest*. Within the
+        same rank, keep the order of first appearance in <source/>.
+
+    4.  Apply the *top-bound* <getopt-option-top/> as an *upper bound
+        only*: keep at most `min(<getopt-option-top/>, number of salient
+        points)` points and *never pad* the list with filler to reach
+        the bound. If <getopt-option-top/> is *non-numeric* or *less
+        than or equal to 0*, use the default *10* instead.
+
+    You *MUST* *NOT* output anything in this STEP 2.
+
+    </step>
+
+3.  <step id="STEP 3: Report Ranked Points">
+
+    For each distilled point, emit the following <template/>,
+    where <rank/> is its salience rank, <point/> is the atomic claim,
+    <location/> is its line-range citation, <evidence/> is the
+    verbatim proving snippet, and <rationale/> is the one-line
+    salience justification:
+
+    <template>
+
+    <ase-tpl-bullet-normal/> **KEY POINT**: **<point/>**
+
+    ◯ LOCATION:  <location/>
+    ◯ EVIDENCE:  "`<evidence/>`"
+    ◯ RATIONALE: <rationale/>
+    ◯ RANK:      <rank/>/10
+
+    </template>
+
+    In the <location/>, markup the line-range reference as
+    code (with backticks) and prepend it with `▢ `.
+
+    Keep the overall report *concise* and *brief*. Do *not* output any
+    further explanation.
+
+    </step>
+
+</flow>

package/plugin/skills/ase-docs-distill/help.md

@@ -0,0 +1,76 @@
+
+##  NAME
+
+`ase-docs-distill` - Distill Document Key Points
+
+##  SYNOPSIS
+
+`ase-docs-distill`
+    [`--help`|`-h`]
+    [`--top`|`-t` *N*]
+    *document-reference*
+
+##  DESCRIPTION
+
+The `ase-docs-distill` skill reads a *provided document* and distills it
+into a *flat*, *importance-ranked* list of its *key points*. The
+*docs-reference* is resolved *probe-as-file-first*: if the argument names
+a *readable file* it is read from disk, otherwise the argument is taken
+*verbatim* as *pasted text*. The document is read *silently* - only the
+final ranked list is shown - so even a large document does not flood the
+transcript.
+
+Each emitted point is *one atomic claim, decision, or fact* (not a
+section-level summary) and carries four things: a *0-10 salience rank*
+reflecting its *importance to the reader* (impact and centrality, *not*
+its position in the document), a *one-line rationale* justifying *why* it
+earns that rank, an exact *line-range citation* (`file:Ls-Le`, or `:Ls-Le`
+for pasted text), and a *verbatim evidence* snippet copied from the source
+that *proves* the point. The points are emitted as a *bulleted list* -
+one block per point, each showing its *LOCATION*, *EVIDENCE*,
+*RATIONALE*, and *RANK* - sorted from highest to lowest salience, so the
+ranking is *auditable* rather than an opaque ordering.
+
+The `--top`/`-t` *N* option is a *length dial* that bounds the list to at
+most *N* points (default *10*). It is an *upper bound only*: when the
+document has fewer salient points than *N*, the skill emits only the
+points it found and *never pads* the list with filler; a `0`, negative, or
+non-numeric value falls back to the default *10*.
+
+##  ARGUMENTS
+
+`--top`, `-t` *N*:
+    Bound the ranked list to at most *N* key points (default *10*). The
+    bound is a *cap*, never a *quota* - fewer points are emitted when the
+    document does not contain *N* salient ones, and an invalid or
+    non-positive *N* reverts to the default.
+
+*docs-reference*:
+    The document to distill - either a *path* to a readable file or the
+    *text* itself pasted inline. If it resolves to a readable file the
+    file is read; otherwise it is treated verbatim as pasted text.
+
+##  EXAMPLES
+
+Distill the key points of a document file:
+
+```text
+❯ /ase-docs-distill doc/architecture.md
+```
+
+Distill only the top 5 key points:
+
+```text
+❯ /ase-docs-distill --top 5 doc/architecture.md
+```
+
+Distill a pasted block of text:
+
+```text
+❯ /ase-docs-distill The system shall accept payments in EUR and USD only.
+```
+
+##  SEE ALSO
+
+`ase-meta-search`, `ase-docs-proofread`, `ase-meta-why`.
+

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

@@ -175,7 +175,7 @@ Analyze documents for spelling, punctuation, or grammar errors
                 Generate a *new* proposal for the *same* <item/>,
                 incorporating the user's free-text hint from <result/>
                 after the "OTHER:" prefix, and loop back to substep 2 of
-                this iteration. There is *no* cap on refinement rounds —
+                this iteration. There is *no* cap on refinement rounds -
                 keep refining until the user picks `ACCEPT` or `REJECT`.
 
                 </if>

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

@@ -20,7 +20,7 @@ the user-visible transcript.
 
 For each detected problem, the skill renders a unified-diff
 *CORRECTION* preview and either asks the user to `ACCEPT` or `REJECT`
-the proposed correction interactively or — with `--auto` — applies
+the proposed correction interactively or - with `--auto` - applies
 all corrections automatically.
 
 ##  OPTIONS

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

@@ -33,8 +33,8 @@ Guiding Tenets
 Honor the following tenets throughout the brainstorming:
 
 -   **No Assumption of Simplicity**:
-    Every topic goes through the full process — a one-line config
-    change as much as a new subsystem — because the simplest-looking
+    Every topic goes through the full process - a one-line config
+    change as much as a new subsystem - because the simplest-looking
     topics often hide the most harmful assumptions.
 
 -   **Explore Intent First**:
@@ -83,9 +83,15 @@ Honor the following tenets throughout the brainstorming:
 
     Before generating any ideas, *explore the project context* (review
     relevant existing files, documentation, and recent changes) and
-    determine the <m/> *essential unknowns* about the topic — the
-    purpose, constraints, scope boundaries, and success criteria that
-    must be pinned down for the brainstorming to be reasonably grounded.
+    determine the <m/> (<m/>=1-3) *essential unknowns* about the topic
+    - the purpose, constraints, scope boundaries, and success criteria
+    that must be pinned down for the brainstorming to be reasonably
+    grounded.
+
+    Notice: you are intentionally constraint to just 1-3 unknowns,
+    as too much upfront intent clarification kills the brainstorming
+    of ideas later. So, you *MUST* reduce the clarifications of the
+    unknowns to the absolute minimum!
 
     For each essential unknown, derive a short 1-3 word facet <facet-M/>
     and a corresponding question <question-M/> whose answer materially
@@ -139,10 +145,10 @@ Honor the following tenets throughout the brainstorming:
     <topic/> within the constraints established by the answers
     <answer-M/>.
 
-    Deliberately pursue *diverse angles* — e.g. the minimal/MVP-first
+    Deliberately pursue *diverse angles* - e.g. the minimal/MVP-first
     angle, the robustness/risk-first angle, the user-experience-first
     angle, the reuse-existing-machinery angle, the coolness angle, and
-    the unconventional/wildcard angle — because variety in origin yields
+    the unconventional/wildcard angle - because variety in origin yields
     variety in outcome.
 
     Do still *not* judge, rank, or prune ideas in this step. Generate
@@ -177,7 +183,7 @@ Honor the following tenets throughout the brainstorming:
         statement of not more than 40 words):
 
         <template>
-        <ase-tpl-bullet-secondary/> **IDEA CLUSTER <C/>/<c/>**: <cluster-C/> — <cluster-summary-C/>,
+        <ase-tpl-bullet-secondary/> **IDEA CLUSTER <C/>/<c/>**: <cluster-C/> - <cluster-summary-C/>,
         **IDEAS**: <N/>, <M/>[, ...]
         </template>
 
@@ -191,7 +197,7 @@ Honor the following tenets throughout the brainstorming:
         3-4 options, sorted by rank from highest to lowest.
 
         For this, draw the shortlist from *distinct* clusters <cluster-C/>
-        wherever possible — prefer a diverse shortlist spanning different
+        wherever possible - prefer a diverse shortlist spanning different
         clusters over several high-ranked variations of the same cluster,
         unless one cluster clearly dominates on rank.
 
@@ -205,9 +211,9 @@ Honor the following tenets throughout the brainstorming:
         <ase-tpl-bullet-normal/> **DISTILLED IDEA <N/>**: <option-N/>
         </template>
 
-    4.  Finally, derive a single *recommended idea* — the highest-ranked
+    4.  Finally, derive a single *recommended idea* - the highest-ranked
         option, or a principled synthesis of the option shortlist that preserves
-        what is strongest in each — store its one-sentence rationale (not
+        what is strongest in each - store its one-sentence rationale (not
         more than 40 words) in <recommendation/>, and output the following
         <template/>:
 

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

@@ -14,7 +14,7 @@
 The `ase-meta-brainstorm` skill guides a collaborative ideation
 session on a *topic* *before* any implementation begins. It first
 *clarifies intent* by exploring the project context and interviewing
-the user — one grounded, multiple-choice question at a time — about
+the user - one grounded, multiple-choice question at a time - about
 purpose, constraints, scope, and success criteria. It then *diverges*
 into a broad space of candidate ideas pursued from deliberately diverse
 angles (MVP-first, risk-first, UX-first, reuse-first, and wildcard),
@@ -23,8 +23,8 @@ without judging them.
 Next it *converges* by clustering the ideas into coherent themes,
 pruning speculative or out-of-scope ones via *YAGNI*, and scoring the
 survivors on a 0-10 fit scale (keeping only those ranked 7 or higher).
-Finally it distills a *shortlist* of the top 3-4 directions — drawn from
-distinct clusters wherever possible — and derives a single
+Finally it distills a *shortlist* of the top 3-4 directions - drawn from
+distinct clusters wherever possible - and derives a single
 *RECOMMENDATION*, being either the highest-ranked option or a principled
 synthesis of the shortlist.
 
@@ -35,7 +35,7 @@ recommended direction off to the `ase-task-edit`, `ase-code-craft`, or
 ##  ARGUMENTS
 
 *topic*:
-    The subject to brainstorm — a feature, component, behavior, or
+    The subject to brainstorm - a feature, component, behavior, or
     design question to explore *what* to build before *how*.
 
 ##  EXAMPLES

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

@@ -30,9 +30,9 @@ effort: xhigh
     <ase-tpl-bullet-secondary/> **THESIS**: <thesis/>
     </template>
 
-2.  **Determine Anti-Thesis**:
+2.  **Determine Anti-Theses**:
 
-    Reason on the thesis in <thesis/> by playing *Devil’s Advocate*
+    Reason on the thesis in <thesis/> by playing *Devil's Advocate*
     (latin: *Advocatus Diaboli*) by relentlessly challenging or
     criticising it with the help of the following tenets:
 
@@ -47,7 +47,7 @@ effort: xhigh
         of polish on the surface can save what is built on top of it.
 
     -   **Target Claims, Not Person**:
-        Critique the thesis, the assumption, the evidence — never the
+        Critique the thesis, the assumption, the evidence - never the
         proponent's competence or motives, because the moment it gets
         personal, the inquiry dies.
 
@@ -133,7 +133,7 @@ effort: xhigh
         while ignoring its own limits, gaps, or internal tensions.
 
     -   *Antithesis*: the opposing force. It is the contradiction,
-        objection, or counter-position that the thesis provokes — precisely
+        objection, or counter-position that the thesis provokes - precisely
         the role a Devil's Advocate played. The antithesis exposes what the
         thesis omitted or got wrong.
 

package/plugin/skills/ase-meta-diaboli/help.md

@@ -14,10 +14,10 @@
 The `ase-meta-diaboli` skill plays *Devil's Advocate* (latin:
 *Advocatus Diaboli*) by relentlessly challenging or criticising a
 supplied *thesis*. It applies a disciplined set of critical-thinking
-tenets — steelmanning, stress-testing fundamentals, surfacing implicit
+tenets - steelmanning, stress-testing fundamentals, surfacing implicit
 assumptions, demanding proportional evidence, seeking disconfirming
 cases, *Reductio Ad Absurdum*, exposing hidden costs, and pre-mortem
-thinking — while targeting the claim rather than its proponent and
+thinking - while targeting the claim rather than its proponent and
 yielding where the argument genuinely holds.
 
 The skill iterates until it has found at least ten anti-theses