@rse/ase 0.9.1 → 0.9.3

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

@@ -0,0 +1,159 @@
+---
+name: ase-meta-steelman
+argument-hint: "[--help|-h] <thesis>"
+description: >
+    Build the strongest possible case for a thesis by playing
+    "Steelman" (Latin spirit: "Advocatus Dei"). Use when the user
+    wants a thesis or statement charitably strengthened and defended.
+user-invocable: true
+disable-model-invocation: false
+effort: xhigh
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+
+<skill name="ase-meta-steelman">
+    Build the "Steelman" Argument
+</skill>
+
+<objective>
+    Build the "Steelman" argument by constructing the strongest
+    possible case for the thesis: <thesis>$ARGUMENTS</thesis>
+</objective>
+
+1.  **Repeat Thesis**:
+
+    Output the thesis with the following <template/>:
+
+    <template>
+    <ase-tpl-bullet-secondary/> **THESIS**: <thesis/>
+    </template>
+
+2.  **Determine Pro-Theses**:
+
+    Reason on the thesis in <thesis/> by playing *Steelman* (Latin
+    spirit: "Advocatus Dei") - building the strongest possible case
+    *for* it - by charitably strengthening and defending it with the
+    help of the following tenets:
+
+    -   **Charitable Interpretation**:
+        Defend the strongest ("steelman") interpretation of the
+        <thesis/>, not the weakest ("strawman"), because the most
+        generous reading is the one worth defending and the one a fair
+        critic must ultimately confront.
+
+    -   **Strengthen the Fundamentals**:
+        Identify the soundest fundamental ideas behind the thesis and
+        make them explicit, because a position rests on the strength of
+        its foundation and a solid foundation carries everything built
+        on top of it.
+
+    -   **Credit Claims, Not Person**:
+        Support the thesis, the assumption, the evidence - never appeal
+        to the proponent's authority or reputation, because a case that
+        leans on who said it instead of what was said is no stronger
+        than its weakest argument.
+
+    -   **Make the Enabling Assumptions Explicit**:
+        Surface the reasonable assumptions the thesis depends on and
+        show they hold, because most strong arguments gain their force
+        from premises that are sound once stated out loud.
+
+    -   **Supply Evidence Proportional to Claim**:
+        Ask "How do we know this?" and "What best supports it?", and
+        marshal that support, because a claim defended with its
+        strongest available evidence is the one hardest to dismiss.
+
+    -   **Seek the Confirming Case**:
+        Actively hunt for the supporting example, the favourable
+        scenario, the precedent where the position succeeds, because
+        one solid confirming case anchors the argument in reality.
+
+    -   **Merit Identification**:
+        Focus on the genuine strengths of the thesis with the highest
+        potential value only, because marginal merits are not worth the
+        explicit discussion.
+
+    -   **Push the Logic to its Best Conclusion**:
+        Ask "If we accept this, then what follows?" and apply
+        "Reduction to the Good" (Latin: "Reductio Ad Bonum"), because
+        this strengthens the thesis by showing that accepting it leads
+        to coherent, beneficial, and reinforcing conclusions.
+
+    -   **Surface the Upside and Leverage**:
+        Name the opportunity gained, the compounding benefit, the
+        problem dissolved, because every choice in the thesis unlocks
+        possibilities that a fair appraisal must count.
+
+    -   **Stay Falsifiable and Concrete**:
+        Frame each supporting point so it can be checked and confirmed
+        with facts, because vague enthusiasm ("I just like it") adds no
+        strength to the case.
+
+    -   **Argue in Good Faith**:
+        Make clear you are building the best honest case, not
+        overselling, because the goal of the objective is a better
+        final decision, not a sales pitch.
+
+    -   **Concede the Real Weaknesses**:
+        Acknowledging where the thesis genuinely falls short is what
+        makes the defence credible, because a Steelman who can never
+        admit a flaw is just an apologist.
+
+    -   **Pre-Parade Thinking**:
+        Imagine success scenarios of the thesis, because envisioning
+        how it wins clarifies the conditions worth securing in advance.
+
+    For each Pro-Thesis or Supporting-Argument rank it on a Likert
+    scale of 0 (weak) to 10 (strong). Repeat the process of finding
+    more Pro-Theses or Supporting-Arguments until you EITHER have found
+    at least 10 Pro-Theses or Supporting-Arguments with at least a rank
+    of 7 OR you have already checked a total of 50 Pro-Theses or
+    Supporting-Arguments.
+
+    Then, for the top-10 highest-ranked Pro-Theses or
+    Supporting-Arguments, sort them by their rank from highest to lowest,
+    store each in <prothesis-N/> with the format `**<aspect-N/>**
+    (rank: <rank-N/>/10): <statement-N/>` (where <aspect-N/> is a short
+    1-3 word summary of <statement-N/>, <rank-N/> is the determined
+    rank on the Likert scale, and <statement-N/> is a single-sentence
+    statement of not more than 40 words), and then output the following
+    <template/>:
+
+    <template>
+    <ase-tpl-bullet-signal/> **PRO-THESIS**: <prothesis-N/>
+    </template>
+
+3.  **Consolidating Reasoning**:
+
+    Following the consolidation of...
+
+        *Thesis* + *Pro-Theses* → *Fortification*
+
+    ...with...
+
+    -   *Thesis*: the initial statement, claim, or position. It is asserted
+        as true, but on its own it is under-developed: it captures part of the
+        truth while leaving its own strongest support implicit, unstated, or
+        unproven.
+
+    -   *Pro-Theses*: the reinforcing forces. They are the corroboration,
+        evidence, or supporting positions that the thesis invites - precisely
+        the role a Steelman played. The pro-theses make explicit what the
+        thesis assumed or left unsaid.
+
+    -   *Fortification*: the consolidation. Not an uncritical "cheerleading"
+        of the thesis, and not a mere restatement of it, but a stronger
+        position that consolidates everything that genuinely strengthens it
+        while honestly bounding where it holds. The fortification reinforces
+        the position by sharpening it.
+
+    ...finally derive a strong single-sentence (not more than 40 words)
+    fortification of the <thesis/> and all found <prothesis-N/> - the
+    strongest defensible form of the thesis - store it in <fortification/>,
+    and then finally output the following <template/>:
+
+    <template>
+    <ase-tpl-bullet-normal/> **FORTIFICATION**: <fortification/>
+    </template>

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

@@ -0,0 +1,60 @@
+
+##  NAME
+
+`ase-meta-steelman` - Build the "Steelman" Argument
+
+##  SYNOPSIS
+
+`ase-meta-steelman`
+    [`--help`|`-h`]
+    *thesis*
+
+##  DESCRIPTION
+
+The `ase-meta-steelman` skill builds the strongest possible case
+*for* a supplied *thesis* - the constructive mirror of its adversarial
+counterpart `ase-meta-diaboli`. It applies a disciplined set of
+constructive-thinking tenets - charitable interpretation, strengthening
+the fundamentals, surfacing the enabling assumptions, supplying
+proportional evidence, seeking confirming cases, *Reductio Ad Bonum*,
+surfacing the upside, and pre-parade thinking - while crediting the
+claim rather than the proponent's authority and conceding where the
+thesis genuinely falls short.
+
+The skill iterates until it has found at least ten pro-theses
+(supporting arguments) each ranked at least 7 on a 0 (weak) to 10
+(strong) Likert scale, reports the top ten sorted from strongest to
+weakest, and finally consolidates them (*Thesis* + *Pro-Theses* →
+*Fortification*) to derive a single-sentence *FORTIFICATION* that
+consolidates everything genuinely strengthening the thesis while
+honestly bounding where it holds.
+
+The intent is constructive: building the best honest case for the
+thesis to arrive at a better final decision, not overselling or merely
+cheerleading.
+
+##  ARGUMENTS
+
+*thesis*:
+    The statement, claim, or position to be charitably strengthened.
+    It may be technical, factual, or opinion-based; the skill defends
+    its strongest ("steelman") interpretation.
+
+##  EXAMPLES
+
+Strengthen a technology-choice claim:
+
+```text
+❯ /ase-meta-steelman HAPI is the best REST framework
+```
+
+Build the case for a design decision:
+
+```text
+❯ /ase-meta-steelman We should rewrite the service in Rust.
+```
+
+##  SEE ALSO
+
+`ase-meta-diaboli`, `ase-meta-why`, `ase-meta-evaluate`,
+`ase-meta-quorum`.

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

@@ -13,7 +13,7 @@
 
 The `ase-meta-why` skill applies the *Five-Whys* *root-cause
 analysis* technique to the supplied *fact*. The skill iteratively
-asks "why" — up to five times — to drill down from surface symptoms
+asks "why" - up to five times - to drill down from surface symptoms
 to the underlying root cause, considering technical, domain-specific,
 process-related, and organizational causes. After identifying the
 root cause it proposes a *SOLUTION* that addresses it, optionally

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

@@ -127,21 +127,21 @@ explicitly requested by this procedure via outputs based on a <template/>!
             -   *Drop* filler ("just", "really", "basically", "simply"),
                 pleasantries, and hedging ("I think", "maybe", "perhaps").
             -   *Use* shorter synonyms and common abbreviations.
-            -   *Use* `→` for causality and `—` for short subsequent facts.
+            -   *Use* `→` for causality and `-` for short subsequent facts.
             -   *Drop* articles ("a", "an", "the") and *replace*
                 conjunctions with short separate clauses where this
                 shortens the text without introducing ambiguity.
             -   *Re-wrap* the shortened free-text to the ~120-character-
                 per-line convention.
             -   *Merge* genuinely-redundant bullets (the same aspect
-                restated) and *drop* pure duplication — but *only* when
+                restated) and *drop* pure duplication - but *only* when
                 truly redundant; *never* lose a distinct aspect.
 
         3.  *Persona override*: this condense ruleset *always wins* for
             the plan content. This ruleset-based compression is applied
             *regardless* of the currently active session persona style.
 
-        4.  *Hard guardrail — semantics preserved EXACTLY*: condensing
+        4.  *Hard guardrail - semantics preserved EXACTLY*: condensing
             *only* shortens wording. It *MUST NOT* drop, merge (except
             truly-redundant bullets per sub-item 2), reorder, or alter
             *any* factual claim, requirement, file path, rule, or

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

@@ -16,7 +16,7 @@ The `ase-task-implement` skill performs the *final implementation*
 of a task plan by modifying the corresponding *artifacts* with a
 complete *change set*. The plan is loaded from
 `.ase/tasks/`*id*`/plan.md`, and any optional `IMPLEMENTATION DRAFT`
-section produced by `ase-task-preflight` is used as a hint — the
+section produced by `ase-task-preflight` is used as a hint - the
 plain plan content always overrules the draft.
 
 If the task plan deliberately *omits* the `※ VERIFICATION` section

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

@@ -1,199 +0,0 @@
-
-Architecture Decision Record (ADR)
-==================================
-
-An *Architecture Decision Record (ADR)* records
-a major decision related to the architecture.
-
-FORMAT
-------
-
-Every ADR uses a strict and fixed format:
-
-<format>
-
-# ✪ <id/> - **<title/>**
-
-✳ created:  **<timestamp-created/>**
-✎ modified: **<timestamp-modified/>**
-▶ status:   <status/>
-
-## ※ WHEN (Context)
-
-<context/>
-
-## ※ WHAT (Decision)
-
-<decision/>
-
-## ※ WHY (Rationale)
-
-<rationale/>
-
-## ※ NOTES (Background)
-
-<notes/>
-
-</format>
-
-You *MUST* honor the following hints on this *ADR* format:
-
--   The <id/> is `ADR-<N/>-<slug/>` where <N/> is a 3-digit zero-padded
-    unique number, <slug/> is a unique "slug" of always 2 lower-cased
-    words (concatenated with "-" characters and in total not longer than
-    30 characters, and derived from the <decision/>).
-
--   The <title/> is a short summary of the <decision/>, not longer than
-    80 characters.
-
--   The <timestamp-created/> is the timestamp when this ADR
-    was created. The <timestamp-modified/> is the timestamp when this
-    ADR was last modified. Both use an ISO-style format value. The value
-    of both can be determined by a call to the `ase_timestamp(format:
-    "yyyy-LL-dd HH:mm")` tool of the `ase` MCP server and use the `text`
-    field of its response.
-
--   The <status/> is `proposed`, `accepted`, `deprecated` or `superseded
-    by ADR-NNN-xxx-yyy`)
-
--   The <context/> captures the situation that forces the <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 <context/>:
-
-    -   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. These are often competing and that tension is the whole point.
-    -   Relevant facts — current architecture, prior decisions,
-        assumptions, what's known and what's uncertain.
-    -   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 reader should
-    be able to read the <context/>, pause, and arrive at the decision
-    themselves because the forces make it (nearly) inevitable.
-
--   The <decision/> states what you are actually going to do — 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 <decision/>:
-
-    -   The choice itself — clearly and unambiguously.
-    -   The essence of how — enough of the approach to make the choice
-        concrete (the mechanism, pattern, or technology), but not a full
-        implementation specification.
-
-    The <decision/> is a declaration, not a deliberation. The
-    <decision/> usually uses the wording "We use..." or "We do..."
-    and is active, definite, owning the choice. In <decision/> avoid
-    hedging ("we might", "we could consider"). The deliberation already
-    happened, the ADR records the verdict.
-
--   The <rationale/> is the reasoning that justifies the <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 <context/> states the forces and <decision/>
-    states the choice, <rationale/> is the logical connective tissue
-    between them — it shows that the <decision/> actually follows from
-    the <context/>.
-
-    The following usually goes in <rationale/>:
-
-    -   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 you optimized for and what you
-        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."
-    -   Assumptions and evidence — benchmarks, prior experience,
-        constraints, or principles the reasoning rests on.
-
--   The <notes/> section is *OPTIONAL* and can be omitted
-    when it does not add genuine value. Most ADRs won't need it.
-
-    The following usually goes in <notes/>:
-
-    -   Information of the decision *process* like e.g.
-        weighted decision matrix of considered alternatives.
-    -   Consequences of the <decision/> — but only when non-obvious downstream
-        effects need to be called out.
-    -   Links to strongly related ADRs.
-
--   For the relationship between <context/>, <decision/> and <rationale/>
-    good checks are:
-
-    -   The "litmus test" is:
-        -   <context/>   = forces
-        -   <decision/>  = response to those forces,
-        -   <rationale/> = why <decision/> answers the forces in <context/>.
-
-    -   The <decision/> should feel like the natural, 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 the
-        <decision/> suddenly looks arbitrary, the <rationale/> was
-        doing its job. So, the <rationale/> is the justification that
-        ties the <decision/> back to the pressures in <context/>.
-
--   The <context/>, <decision/> and <rationale/> all are just a
-    single paragraph of concise and brief prose text, usually comprised
-    of just 1 to 3 sentences. The paragraphs break all lines with a
-    newline character after about 120 characters per line. The value of
-    an ADR is in recording *that* a decision was made and *why* — not in
-    filling out sections of a document.
-
-TENETS
-------
-
-For an ADR, all of the following three tenets must be true:
-
--   **Hard to Reverse**: the cost of changing it later is meaningful
-    ("Oh my god, this would result in a dramatic refactoring!"). So,
-    if a decision is easy to reverse, just skip it.
-
--   **Surprising without Context**: a future architect will look at
-    the code and wonder ("Why on earth did they do it this way?").
-    So, if a decision is not surprising, nobody will wonder why.
-
--   **Result of a Real Trade-Off**: there were genuine alternatives
-    and one was picked for specific reasons ("We deliberately chose
-    this, because..."). So, if there was no real alternative,
-    there's nothing to record beyond "we did the obvious thing."
-
-For an ADR, the following qualify:
-
--   **Architectural shape.** "We're using a monorepo." "The write
-    model is event-sourced, the read model is projected into PostgreSQL."
-
--   **Integration patterns between contexts.** "Ordering and Billing
-    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
-    ones that would take a quarter to swap out.
-
--   **Boundary and scope decisions.** "Customer data is owned by the
-    Customer context; other contexts reference it by ID only." The explicit
-    no-s are as valuable as the yes-s.
-
--   **Deliberate deviations from the obvious path.** "We're using
-    manual SQL instead of an ORM because X." Anything where a reasonable
-    reader would assume the opposite. These stop the next engineer from
-    "fixing" something that was deliberate.
-
--   **Constraints not visible in the code.** "We can't use AWS because
-    of compliance requirements." "Response times must be under 200ms because
-    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 —
-    otherwise someone will suggest GraphQL again in six months.
-