@rse/ase 0.9.3 → 0.9.4

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

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

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

@@ -1,8 +1,10 @@
 ---
 name: ase-code-analyze
-argument-hint: "[--help|-h] <source-reference>"
+argument-hint: "[--help|-h] [--performance|-p] [--security|-s] [--severity|-S=(LOW|MEDIUM|HIGH)] <source-reference>"
 description: >
-    Analyze the source code for problems in the logic and semantics and its related control flow.
+    Analyze the source code for problems in either the logic and
+    semantics and its related control flow, performance and efficiency,
+    or security.
 user-invocable: true
 disable-model-invocation: false
 effort: high
@@ -12,50 +14,174 @@ allowed-tools:
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
 
 <skill name="ase-code-analyze">
 Analyze Source Code
 </skill>
 
+<expand name="getopt"
+    arg1="ase-code-analyze"
+    arg2="--performance|-p --security|-s --severity|-S=(LOW|MEDIUM|HIGH)">
+    $ARGUMENTS
+</expand>
+
 <objective>
-*Analyze* the source code of $ARGUMENTS, and its directly related source
-code, for problems in its *logic* and *semantics* and its related
-*control flow*.
+*Analyze* the source code of <getopt-arguments/>, and its directly
+related source code, for problems - read-only, *without* applying any
+changes. The *analysis lens* depends on the selected options: problems
+in its *logic* and *semantics* and its related *control flow*, or
+problems in *performance* and *efficiency*, or problems in *security*.
 </objective>
 
 <flow>
 
-1.  <step id="STEP 1: Investigate Code Base">
-    In this STEP 1, investigate on the code. If the code base is large,
+1.  <step id="STEP 1: Sanity Check Usage">
+
+    <if condition="<getopt-option-performance/> is equal `true` and <getopt-option-security/> is equal `true`">
+
+    Only output the following <template/> and then *STOP* immediately:
+
+    <template>
+    ⧉ **ASE**: ✪ skill: **ase-code-analyze**, ▶ ERROR: options `--performance` and `--security` are mutually exclusive
+    </template>
+
+    </if>
+
+    </step>
+
+2.  <step id="STEP 2: Investigate Code Base">
+
+    In this STEP 2, investigate on the code. If the code base is large,
     you *MUST* use the `Agent` tool (not inline work) to create multiple
     sub-agents to split the investigation task into appropriate chunks.
 
     Tenets:
 
     -   **Quiet Operation**:
-        During investigation in this STEP 1, do *not* output anything else,
+
+        During investigation in this STEP 2, do *not* output anything else,
         especially do not give any further explanations or information.
 
     -   **Practical Relevance Only**:
+
         Focus on *practically relevant* cases and especially do *not*
         investigate theoretical or fictive cases.
 
     -   **Problem Focus Only**:
+
         Still focus on the *problem only* and do *not* already
-        investigate any possible *solution*.
+        investigate any possible *solution* or apply any *change*.
+
+    -   **Lens Focus**:
+
+        <if condition="<getopt-option-performance/> is equal `true`">
+
+        Focus on *performance* and *efficiency* only - and do *not*
+        investigate logic, semantics, control flow, or security
+        problems.
+
+        Analysis Hints (not exhaustive, just indicators):
+        -   high algorithmic complexity
+        -   needless resource allocations/copies
+        -   redundant recomputation
+        -   many I/O and query round-trips
+        -   concurrency bottlenecks
+        -   mismatched data structures
+        -   [...]
+
+        </if>
+
+        <if condition="<getopt-option-security/> is equal `true`">
+
+        Focus on *security* only - and do *not* investigate logic,
+        semantics, performance, or efficiency problems.
+
+        Analysis Hints (not exhaustive, just indicators):
+        -   unsafe data deserialization
+        -   missing input data validation/sanitization
+        -   broken authentication/authorization
+        -   sensitive-data exposure
+        -   path traversal
+        -   unsafe cryptography
+        -   hard-coded secrets
+        -   vulnerable dependencies
+        -   [...]
+
+        </if>
+
+        <if condition="<getopt-option-performance/> is NOT equal `true` and <getopt-option-security/> is NOT equal `true`">
+
+        Focus on problems in the *logic* and *semantics* and the related
+        *control flow* only - and do *not* investigate performance,
+        efficiency, or security problems.
+
+        Analysis Hints (not exhaustive, just indicators):
+        -   incorrect conditionals and boolean logic
+        -   off-by-one and boundary errors
+        -   operator misuse
+        -   mishandled edge cases
+        -   broken or missing error handling
+        -   incorrect async/await/promise handling
+        -   control-flow defects (unreachable code, missing breaks, wrong early returns)
+        -   state-mutation bugs
+        -   incorrect default values
+        -   null/undefined mishandling
+        -   type-coercion bugs
+        -   faulty parsing or merge/override semantics
+        -   [...]
+
+        </if>
+
+    You *MUST* not output anything in this STEP 2.
+
     </step>
 
-2.  <step id="STEP 2: Show Results">
-    In this STEP 2, for every detected problem, immediately report it
-    with the following output <template/>, based on concise bullet
+3.  <step id="STEP 3: Show Results">
+
+    Before reporting, *apply the severity floor* selected via
+    <getopt-option-severity/> (default `LOW`): define the ordinal rank
+    `LOW`=1, `MEDIUM`=2, `HIGH`=3. *Keep* a detected problem if and only
+    if its <severity/> is `ACCEPTED` *or* `rank(severity)` is greater
+    than or equal to `rank(<getopt-option-severity/>)`; *silently drop*
+    all other problems (they are neither reported nor persisted). With
+    the default floor `LOW`, all problems are kept. `ACCEPTED` problems
+    are *never* dropped. Then renumber the surviving problems
+    contiguously as `P<n/>` with <n/> = 1, 2, ... in the original
+    ordering. If *all* problems are dropped, skip the per-problem report
+    but still emit the final hint <template/> below.
+
+    In this STEP 3, for *EVERY* surviving problem, immediately report
+    it with the following output <template/>, based on concise bullet
     points.
 
+    <if condition="<getopt-option-performance/> is equal `true`">
+
     <template>
-    <ase-tpl-bullet-signal/> PROBLEM (Severity: **<severity/>**): **P<n/>**: **<title/>**
+
+    <ase-tpl-bullet-signal/> **PROBLEM** (Severity: **<severity/>**): **P<n/>**: **<title/>**
+
+    <description/>
+
+    ⊙ EVIDENCE: <evidence/>
+    ⊖ TRADEOFF: <trade-off/>
+
+    </template>
+
+    </if>
+
+    <if condition="<getopt-option-performance/> is NOT equal `true`">
+
+    <template>
+
+    <ase-tpl-bullet-signal/> **PROBLEM** (Severity: **<severity/>**): **P<n/>**: **<title/>**
 
     <description/>
+
     </template>
 
+    </if>
+
     Hints:
 
     -   For the final results, do *not* output anything else, especially do
@@ -77,7 +203,23 @@ code, for problems in its *logic* and *semantics* and its related
 
     -   In <description/>, classify the problem with a <severity/>
         of <template>LOW</template>, <template>MEDIUM</template> or
-        <template>HIGH</template>.
+        <template>HIGH</template>, ranked by the estimated *impact* of the
+        problem.
+
+    -   <if condition="<getopt-option-performance/> is equal `true`">
+        In <evidence/>, ground the finding by citing either the inferred
+        *Big-O* time/space complexity (e.g. `O(n²)` reducible to `O(n)`)
+        with the exact driving loop or recursion, or the matched
+        performance *anti-pattern* (e.g. N+1 query, sync-in-loop, repeated
+        recompute, string concat in loop), with an inline code reference.
+        </if>
+
+    -   <if condition="<getopt-option-performance/> is equal `true`">
+        In <trade-off/>, state the *cost* of the optimization (e.g.
+        readability, additional memory for speed, added complexity), so
+        the user can make an informed decision; use *none* if there is no
+        meaningful trade-off.
+        </if>
 
     -   *Additionally*, persist all reported problems in a *single*
         `ase_kv_batch` call to the `ase` MCP server with `transactional`
@@ -85,17 +227,19 @@ code, for problems in its *logic* and *semantics* and its related
         starts with one `{ command: "clear" }` entry, followed by one
         `{ command: "set", key: "ase-issue-P<n/>", val: "<title/>:
         <description/>" }` entry per reported problem.
-    </step>
 
-3.  <step id="STEP 3: Give Final Hint">
-    Finally, in this STEP 3, output the following <template/> to give a
-    final hint:
+    Finally, output the following <template/> to give a final hint:
 
     <template>
     ⧉ **ASE**: ☻ skill: **<skill-name/>**, ▶ status: **skill finished**
     ⧉ **ASE**: ↪ hint: **For deeper analysis, suggestions on solution approaches and then final problem resolution, use `/ase-code-resolve P{n}` in the same or even a different session.**
     </template>
+
+    You *MUST* not output anything else in this STEP 3,
+    especially not any further explanations.
+
     </step>
 
 </flow>
 
+</output>

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

@@ -7,19 +7,41 @@
 
 `ase-code-analyze`
     [`--help`|`-h`]
+    [`--performance`|`-p`]
+    [`--security`|`-s`]
+    [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
     *source-reference*
 
 ##  DESCRIPTION
 
 The `ase-code-analyze` skill analyzes the source code of the referenced
-location, and its directly related source code, for problems in its
-*logic*, *semantics*, and related *control flow*.
+location, and its directly related source code, for problems. It is
+*read-only* and advisory: it reports problems but applies *no* changes.
+
+The *analysis lens* depends on the selected options:
+
+- **default** (neither `--performance` nor `--security`): problems in
+  its *logic*, *semantics*, and related *control flow*.
+
+- `--performance`|`-p`: problems in *performance* and *efficiency*.
+
+- `--security`|`-s`: problems in *security*.
+
+The `--performance` and `--security` options are *mutually exclusive*.
+
+The `--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`) option sets a *severity
+floor* (default `LOW`): problems below the chosen threshold are silently
+suppressed (neither reported nor persisted), ordered `LOW` < `MEDIUM` <
+`HIGH`. The default `LOW` keeps all problems; `ACCEPTED` problems are
+never suppressed. Surviving problems are renumbered contiguously as
+`P<n>`.
 
 The skill investigates the code base silently, reports each detected
-problem as a `PROBLEM` entry with severity (`LOW`, `MEDIUM`, `HIGH`),
-inline file/line references, and persists results in the `ase` MCP
-key/value store as `ase-issue-P<n>` entries so they can later be
-resolved via `ase-code-resolve P<n>`.
+problem as a `PROBLEM` entry with severity (`LOW`, `MEDIUM`, `HIGH`) and
+inline file/line references (in the performance lens, each entry
+additionally carries an *evidence* and a *trade-off* line), and persists
+results in the `ase` MCP key/value store as `ase-issue-P<n>` entries so
+they can later be resolved via `ase-code-resolve P<n>`.
 
 ##  ARGUMENTS
 
@@ -29,7 +51,7 @@ resolved via `ase-code-resolve P<n>`.
 
 ##  EXAMPLES
 
-Analyze a specific source file:
+Analyze a specific source file for logic/semantic problems:
 
 ```text
 ❯ /ase-code-analyze src/server.ts
@@ -41,6 +63,24 @@ Analyze a directory of code:
 ❯ /ase-code-analyze src/handlers/
 ```
 
+Analyze a source file for performance/efficiency opportunities only:
+
+```text
+❯ /ase-code-analyze --performance src/server.ts
+```
+
+Analyze a source file for security aspects only:
+
+```text
+❯ /ase-code-analyze -s src/handlers/
+```
+
+Analyze a directory, reporting only `MEDIUM` and `HIGH` problems:
+
+```text
+❯ /ase-code-analyze -S MEDIUM src/handlers/
+```
+
 ##  SEE ALSO
 
 `ase-code-resolve`, `ase-code-refactor`, `ase-code-lint`,

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

@@ -1,6 +1,6 @@
 ---
 name: ase-code-lint
-argument-hint: "[--help|-h] [--auto|-a] <source-reference>"
+argument-hint: "[--help|-h] [--auto|-a] [--severity|-S=(LOW|MEDIUM|HIGH)] <source-reference>"
 description: >
     Lint source code for potential code quality problems.
     Use when the user wants to "lint" or "check" source code.
@@ -20,7 +20,7 @@ Lint Source Code
 
 <expand name="getopt"
     arg1="ase-code-lint"
-    arg2="--auto|-a">
+    arg2="--auto|-a --severity|-S=(LOW|MEDIUM|HIGH)">
     $ARGUMENTS
 </expand>
 
@@ -59,6 +59,14 @@ related to a set of code quality aspects.
     Parse the single result message of the `Agent` tool as a JSON array
     and set <problems/> to that list.
 
+    Then *apply the severity floor* selected via <getopt-option-severity/>
+    (default `LOW`): define the ordinal rank `LOW`=1, `MEDIUM`=2,
+    `HIGH`=3. *Keep* a problem in <problems/> if and only if its
+    `severity` field is `ACCEPTED` *or* `rank(severity)` is greater than
+    or equal to `rank(<getopt-option-severity/>)`; *silently drop* all
+    other problems. With the default floor `LOW`, all problems are kept.
+    `ACCEPTED` problems are *never* dropped.
+
     You *MUST* *NOT* output anything else in this step 1.
 
     </step>

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

@@ -8,6 +8,7 @@
 `ase-code-lint`
     [`--help`|`-h`]
     [`--auto`|`-a`]
+    [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
     *source-reference*
 
 ##  DESCRIPTION
@@ -29,6 +30,12 @@ automatically.
     Automatically apply every proposed correction without asking the
     user via the interactive dialog.
 
+`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`):
+    Set the *severity floor* (default `LOW`): findings below the chosen
+    threshold are silently suppressed, ordered `LOW` < `MEDIUM` <
+    `HIGH`. The default `LOW` keeps all findings; `ACCEPTED` findings are
+    never suppressed.
+
 ##  ARGUMENTS
 
 *source-reference*:
@@ -48,6 +55,12 @@ Lint a directory and automatically apply all corrections:
 ❯ /ase-code-lint --auto src/handlers/
 ```
 
+Lint a directory, reporting only `MEDIUM` and `HIGH` findings:
+
+```text
+❯ /ase-code-lint -S MEDIUM src/handlers/
+```
+
 ##  SEE ALSO
 
 `ase-code-analyze`, `ase-code-resolve`, `ase-code-refactor`,

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

@@ -109,7 +109,7 @@ explicitly requested by this procedure via outputs based on a <template/>!
             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
+            <source/> (but with all newlines replaced 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

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

@@ -1,6 +1,6 @@
 ---
 name: ase-meta-brainstorm
-argument-hint: "[--help|-h] <topic>"
+argument-hint: "[--help|-h] [--count|-c=12] <topic>"
 description: >
     Collaboratively brainstorm a topic by diverging on ideas, converging
     through clustering and scoring, and distilling a shortlist with
@@ -15,13 +15,20 @@ effort: high
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
 
 <skill name="ase-meta-brainstorm">
 Collaboratively Brainstorm a Topic
 </skill>
 
+<expand name="getopt"
+    arg1="ase-meta-brainstorm"
+    arg2="--count|-c=12">
+    $ARGUMENTS
+</expand>
+
 <objective>
-Collaboratively brainstorm the topic <topic>$ARGUMENTS</topic> by first
+Collaboratively brainstorm the topic <topic><getopt-arguments/></topic> by first
 *diverging* into a broad space of candidate ideas, then *converging*
 through clustering and scoring, and finally distilling a *shortlist*
 with a single recommended direction.
@@ -88,7 +95,7 @@ Honor the following tenets throughout the brainstorming:
     that must be pinned down for the brainstorming to be reasonably
     grounded.
 
-    Notice: you are intentionally constraint to just 1-3 unknowns,
+    Notice: you are intentionally constrained 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!
@@ -152,8 +159,9 @@ Honor the following tenets throughout the brainstorming:
     variety in outcome.
 
     Do still *not* judge, rank, or prune ideas in this step. Generate
-    ideas until you either reach at least 12 distinct candidate ideas or
-    have clearly exhausted the meaningfully distinct space.
+    ideas until you either reach at least <getopt-option-count/> distinct
+    candidate ideas or have clearly exhausted the meaningfully distinct
+    space.
 
     Store each candidate idea in <idea-N/> with the format
     `**<idea-name-N/>**: <idea-statement-N/>` (where <idea-name-N/> is a

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

@@ -7,6 +7,7 @@
 
 `ase-meta-brainstorm`
     [`--help`|`-h`]
+    [`--count`|`-c=12`]
     *topic*
 
 ##  DESCRIPTION
@@ -16,9 +17,9 @@ 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
 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),
-without judging them.
+into a broad space of candidate ideas (at least `--count`, default 12)
+pursued from deliberately diverse angles (MVP-first, risk-first,
+UX-first, reuse-first, and wildcard), 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
@@ -32,6 +33,13 @@ On completion the skill offers a *next step*: stop, or hand the
 recommended direction off to the `ase-task-edit`, `ase-code-craft`, or
 `ase-task-preflight` skills.
 
+##  OPTIONS
+
+`--count`|`-c=12`:
+    The *minimum* number of candidate ideas to generate in the *diverge*
+    phase before converging (default: 12). Raise it for a broader idea
+    space, lower it for a quicker, narrower session.
+
 ##  ARGUMENTS
 
 *topic*:
@@ -46,6 +54,12 @@ Brainstorm an approach for a new feature:
 ❯ /ase-meta-brainstorm an offline-first sync layer for the mobile app
 ```
 
+Brainstorm with a broader idea space of at least 20 candidates:
+
+```text
+❯ /ase-meta-brainstorm --count 20 an offline-first sync layer
+```
+
 ##  SEE ALSO
 
 `ase-meta-evaluate`, `ase-meta-quorum`, `ase-meta-diaboli`

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

@@ -1,6 +1,6 @@
 ---
 name: ase-meta-diaboli
-argument-hint: "[--help|-h] <thesis>"
+argument-hint: "[--help|-h] [--count|-c <count>] <thesis>"
 description: >
     Challenge a thesis by playing "Devil’s Advocate" (latin: "Advocatus
     Diaboli"). Use when the user wants a thesis or statement
@@ -12,25 +12,40 @@ effort: xhigh
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
 
 <skill name="ase-meta-diaboli">
     Play "Devil's Advocate"
 </skill>
 
+<expand name="getopt"
+    arg1="ase-meta-diaboli"
+    arg2="--count|-c=10">
+    $ARGUMENTS
+</expand>
+
 <objective>
     Play "Devil’s Advocate" (latin: "Advocatus Diaboli") by relentlessly
-    challenging or criticising the thesis: <thesis>$ARGUMENTS</thesis>
+    challenging or criticising the thesis: <thesis><getopt-arguments/></thesis>
 </objective>
 
-1.  **Repeat Thesis**:
+Determine the minimum number of *anti-theses* to surface: set <count/>
+to <getopt-option-count/>; if <getopt-option-count/> is *non-numeric* or
+*less than or equal to 0*, use the default *10* instead.
+
+<flow>
+
+1.  <step id="STEP 1: Repeat Thesis">
 
     Output the thesis with the following <template/>:
 
     <template>
-    <ase-tpl-bullet-secondary/> **THESIS**: <thesis/>
+    <ase-tpl-bullet-normal/> **THESIS**: <thesis/>
     </template>
 
-2.  **Determine Anti-Theses**:
+    </step>
+
+2.  <step id="STEP 2: Determine Anti-Theses">
 
     Reason on the thesis in <thesis/> by playing *Devil's Advocate*
     (latin: *Advocatus Diaboli*) by relentlessly challenging or
@@ -103,11 +118,11 @@ effort: xhigh
     For each Anti-Thesis or Counter-Argument rank it on a Likert scale
     of 0 (weak) to 10 (strong). Repeat the process of finding more
     Anti-Theses or Counter-Arguments until you EITHER have found at
-    least 10 Anti-Theses or Counter-Arguments with at least a rank
-    of 7 OR you have already checked a total of 50 Anti-Theses or
-    Counter-Arguments.
+    least <count/> Anti-Theses or Counter-Arguments with at least a rank
+    of 7 OR you have already checked a total of <count/> x 5 Anti-Theses
+    or Counter-Arguments.
 
-    Then, for the top-10 highest-ranked Anti-Theses or
+    Then, for the top-<count/> highest-ranked Anti-Theses or
     Counter-Arguments, sort them by their rank from highest to lowest,
     store each in <antithesis-N/> with the format `**<aspect-N/>**
     (rank: <rank-N/>/10): <statement-N/>` (where <aspect-N/> is a short
@@ -120,7 +135,9 @@ effort: xhigh
     <ase-tpl-bullet-signal/> **ANTITHESIS**: <antithesis-N/>
     </template>
 
-3.  **Dialectical Reasoning**:
+    </step>
+
+3.  <step id="STEP 3: Dialectical Reasoning">
 
     Following the Hegelian dialectics of...
 
@@ -150,3 +167,9 @@ effort: xhigh
     <ase-tpl-bullet-normal/> **SYNTHESIS**: <synthesis/>
     </template>
 
+    Do not output any further explanations.
+
+    </step>
+
+</flow>
+

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

@@ -7,6 +7,7 @@
 
 `ase-meta-diaboli`
     [`--help`|`-h`]
+    [`--count`|`-c` *count*]
     *thesis*
 
 ##  DESCRIPTION
@@ -20,20 +21,31 @@ cases, *Reductio Ad Absurdum*, exposing hidden costs, and pre-mortem
 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
+The skill iterates until it has found at least *count* anti-theses
 (counter-arguments) each ranked at least 7 on a 0 (weak) to 10
-(strong) Likert scale, reports the top ten sorted from strongest to
+(strong) Likert scale, reports the top *count* sorted from strongest to
 weakest, and finally applies *Hegelian dialectics* (*Thesis* +
 *Antithesis* → *Synthesis*) to derive a single-sentence *SYNTHESIS*
 that preserves what is true in both the thesis and its antitheses
 while discarding what is false.
 
+The `--count`/`-c` *count* option sets the minimum number of strong
+anti-theses to surface (default *10*), raising or lowering the floor of
+counter-arguments hunted for, sorted, and reported in the single
+challenge pass. A `0`, negative, or non-numeric value falls back to the
+default *10*.
+
 The intent is constructive: stress-testing the thesis in good faith to
 arrive at a better final decision, not obstructing or merely being
 contrarian.
 
 ##  ARGUMENTS
 
+`--count`, `-c` *count*:
+    Surface at least *count* strong anti-theses (default *10*) before
+    sorting and reporting the top *count* and deriving the *SYNTHESIS*. An
+    invalid or non-positive *count* reverts to the default *10*.
+
 *thesis*:
     The statement, claim, or position to be relentlessly challenged.
     It may be technical, factual, or opinion-based; the skill attacks
@@ -53,6 +65,12 @@ Stress-test a design decision:
 ❯ /ase-meta-diaboli We should rewrite the service in Rust.
 ```
 
+Surface at least fifteen anti-theses:
+
+```text
+❯ /ase-meta-diaboli --count 15 We should rewrite the service in Rust.
+```
+
 ##  SEE ALSO
 
 `ase-meta-why`, `ase-meta-evaluate`, `ase-meta-quorum`,

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

@@ -1,6 +1,6 @@
 ---
 name: ase-meta-review
-argument-hint: "[--help|-h]"
+argument-hint: "[--help|-h] [--severity|-S=(LOW|MEDIUM|HIGH)]"
 description: >
     Perform a holistic, human-reviewer-style critique of the currently
     staged Git changes and emit an approve/reject verdict with
@@ -17,11 +17,19 @@ allowed-tools:
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
 
 <skill name="ase-meta-review">
 Review Staged Changes
 </skill>
 
+<expand name="getopt"
+    arg1="ase-meta-review"
+    arg2="--severity|-S=(LOW|MEDIUM|HIGH)">
+    $ARGUMENTS
+</expand>
+
 <objective>
 Review the currently staged Git changes the way an *experienced human
 reviewer* would - judging them *holistically* against the change's *own
@@ -98,7 +106,17 @@ explicitly requested by this procedure via outputs based on a <template/>!
     Then *derive* the overall <verdict/> from <findings/>: set
     <verdict/> to `REJECT - DEMANDS CHANGES` if *any* finding in
     <findings/> has a `severity` field of `HIGH`; otherwise set
-    <verdict/> to `APPROVE`.
+    <verdict/> to `APPROVE`. The verdict is derived *before* the
+    severity floor below, so a suppressed `HIGH` finding still drives the
+    verdict.
+
+    Then *apply the severity floor* selected via <getopt-option-severity/>
+    (default `LOW`): define the ordinal rank `LOW`=1, `MEDIUM`=2,
+    `HIGH`=3. *Keep* a finding in <findings/> if and only if its
+    `severity` field is `ACCEPTED` *or* `rank(severity)` is greater than
+    or equal to `rank(<getopt-option-severity/>)`; *silently drop* all
+    other findings. With the default floor `LOW`, all findings are kept.
+    `ACCEPTED` findings are *never* dropped.
 
     You *MUST* *NOT* output anything else in this STEP 2.
 

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

@@ -6,6 +6,8 @@
 ##  SYNOPSIS
 
 `ase-meta-review`
+    [`--help`|`-h`]
+    [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
 
 ##  DESCRIPTION
 
@@ -51,10 +53,20 @@ inspects *logic and semantics*, `ase-meta-diff` narrates *what changed*
 `ase-meta-review` renders a *reviewer's judgement* on a concrete diff
 before it is committed.
 
+##  OPTIONS
+
+`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`):
+    Set the *severity floor* (default `LOW`): findings below the chosen
+    threshold are silently suppressed, ordered `LOW` < `MEDIUM` <
+    `HIGH`. The default `LOW` keeps all findings; `ACCEPTED` findings are
+    never suppressed. The floor only affects the rendered findings table;
+    the overall *verdict* is still derived from all findings, so a
+    suppressed `HIGH` finding still yields a *REJECT* verdict.
+
 ##  ARGUMENTS
 
-The `ase-meta-review` skill takes no arguments; it always reviews the
-currently *staged* Git changes.
+The `ase-meta-review` skill takes no positional arguments; it always
+reviews the currently *staged* Git changes.
 
 ##  EXAMPLES
 
@@ -64,6 +76,12 @@ Review the currently staged changes before committing:
 ❯ /ase-meta-review
 ```
 
+Review the staged changes, reporting only `MEDIUM` and `HIGH` findings:
+
+```text
+❯ /ase-meta-review -S MEDIUM
+```
+
 ##  SEE ALSO
 
 `ase-meta-diff`, `ase-meta-commit`, `ase-code-lint`, `ase-code-analyze`,

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

@@ -1,6 +1,6 @@
 ---
 name: ase-meta-steelman
-argument-hint: "[--help|-h] <thesis>"
+argument-hint: "[--help|-h] [--count|-c <count>] [--rounds|-r <rounds>] <thesis>"
 description: >
     Build the strongest possible case for a thesis by playing
     "Steelman" (Latin spirit: "Advocatus Dei"). Use when the user
@@ -12,25 +12,57 @@ effort: xhigh
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
 @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
 
 <skill name="ase-meta-steelman">
     Build the "Steelman" Argument
 </skill>
 
+<expand name="getopt"
+    arg1="ase-meta-steelman"
+    arg2="--count|-c=10 --rounds|-r=1">
+    $ARGUMENTS
+</expand>
+
 <objective>
     Build the "Steelman" argument by constructing the strongest
-    possible case for the thesis: <thesis>$ARGUMENTS</thesis>
+    possible case for the thesis: <thesis><getopt-arguments/></thesis>
 </objective>
 
-1.  **Repeat Thesis**:
+Determine the number of *rounds* to perform: set <rounds/> to
+<getopt-option-rounds/>; if <getopt-option-rounds/> is *non-numeric* or
+*less than or equal to 0*, use the default *1* instead.
+
+Determine the minimum number of *pro-theses* to surface: set <count/>
+to <getopt-option-count/>; if <getopt-option-count/> is *non-numeric* or
+*less than or equal to 0*, use the default *10* instead.
+
+<flow>
+
+1.  <step id="STEP 1: Repeat Thesis">
+
+    Begin a *round* of fortification and consolidating reasoning. On
+    the first visit, set <i>1</i> (set round counter to one); on each
+    subsequent visit (via the jump back in the last step), <i/> has
+    already been incremented.
+
+    <if condition="<rounds/> is greater than 1">
+    Indicate the current round with the following <template/>:
+
+    <template>
+    <ase-tpl-bullet-secondary/> **ROUND**: <i/>/<rounds/>
+    </template>
+    </if>
 
     Output the thesis with the following <template/>:
 
     <template>
-    <ase-tpl-bullet-secondary/> **THESIS**: <thesis/>
+    <ase-tpl-bullet-normal/> **THESIS**: <thesis/>
     </template>
 
-2.  **Determine Pro-Theses**:
+    </step>
+
+2.  <step id="STEP 2: Determine Pro-Theses">
 
     Reason on the thesis in <thesis/> by playing *Steelman* (Latin
     spirit: "Advocatus Dei") - building the strongest possible case
@@ -108,11 +140,11 @@ effort: xhigh
     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.
+    at least <count/> Pro-Theses or Supporting-Arguments with at least a
+    rank of 7 OR you have already checked a total of <count/> x 5
+    Pro-Theses or Supporting-Arguments.
 
-    Then, for the top-10 highest-ranked Pro-Theses or
+    Then, for the top-<count/> 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
@@ -124,8 +156,9 @@ effort: xhigh
     <template>
     <ase-tpl-bullet-signal/> **PRO-THESIS**: <prothesis-N/>
     </template>
+    </step>
 
-3.  **Consolidating Reasoning**:
+3.  <step id="STEP 3: Consolidating Reasoning">
 
     Following the consolidation of...
 
@@ -149,7 +182,7 @@ effort: xhigh
         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)
+    ...then 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/>:
@@ -157,3 +190,21 @@ effort: xhigh
     <template>
     <ase-tpl-bullet-normal/> **FORTIFICATION**: <fortification/>
     </template>
+
+    Finally, decide whether to perform a further round:
+
+    <if condition="<i/> is less than <rounds/>">
+    Carry the result forward to the next round: set
+    <thesis><fortification/></thesis> (the fortification becomes the
+    thesis to be strengthened next), set <i/> to <i/> + 1 (increment the
+    round counter), and then *CONTINUE* the *LOOP* at **STEP 1**!
+    </if>
+
+    <if condition="<i/> is greater than or equal to <rounds/>">
+    All <rounds/> rounds are complete; *STOP* the loop here.
+    Do not output any further explanations.
+    </if>
+
+    </step>
+
+</flow>

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

@@ -7,6 +7,8 @@
 
 `ase-meta-steelman`
     [`--help`|`-h`]
+    [`--count`|`-c` *count*]
+    [`--rounds`|`-r` *rounds*]
     *thesis*
 
 ##  DESCRIPTION
@@ -21,20 +23,44 @@ 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
+The skill iterates until it has found at least *count* 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
+(strong) Likert scale, reports the top *count* 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 `--rounds`/`-r` *rounds* option turns the single defense pass into an
+*iterative chain* of *rounds* rounds (default *1*): each round's
+*FORTIFICATION* becomes the *thesis* of the next round, so the position
+is progressively re-fortified and sharpened. A `0`, negative, or
+non-numeric value falls back to the default *1*; with a single round the
+output is identical to running without the option.
+
+The `--count`/`-c` *count* option sets the minimum number of strong
+pro-theses to surface (default *10*), raising or lowering the floor of
+supporting arguments hunted for, sorted, and reported in each defense
+pass. A `0`, negative, or non-numeric value falls back to the default
+*10*.
+
 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
 
+`--count`, `-c` *count*:
+    Surface at least *count* strong pro-theses (default *10*) per defense
+    pass before sorting and reporting the top *count* and deriving the
+    *FORTIFICATION*. An invalid or non-positive *count* reverts to the
+    default *10*.
+
+`--rounds`, `-r` *rounds*:
+    Run *rounds* iterative defense rounds (default *1*), feeding each
+    round's *FORTIFICATION* in as the next round's *thesis*. An invalid
+    or non-positive *rounds* reverts to the default *1*.
+
 *thesis*:
     The statement, claim, or position to be charitably strengthened.
     It may be technical, factual, or opinion-based; the skill defends
@@ -54,6 +80,12 @@ Build the case for a design decision:
 ❯ /ase-meta-steelman We should rewrite the service in Rust.
 ```
 
+Strengthen across five iterative rounds:
+
+```text
+❯ /ase-meta-steelman --rounds 5 We should rewrite the service in Rust.
+```
+
 ##  SEE ALSO
 
 `ase-meta-diaboli`, `ase-meta-why`, `ase-meta-evaluate`,

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

@@ -1,6 +1,6 @@
 ---
 name: ase-meta-why
-argument-hint: "[--help|-h] <fact>"
+argument-hint: "[--help|-h] [--depth|-d <N>] <fact>"
 description: >
     Five-Whys Root-Cause Analysis.
 user-invocable: true
@@ -10,16 +10,23 @@ 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-meta-why">
 Five-Whys Root-Cause Analysis
 </skill>
 
+<expand name="getopt"
+    arg1="ase-meta-why"
+    arg2="--depth|-d=5">
+    $ARGUMENTS
+</expand>
+
 <objective>
 Apply the *Five-Whys* *root-cause analysis* technique to investigate
 the following problem:
 
-<problem>Why $ARGUMENTS?</problem>
+<problem>Why <getopt-arguments/>?</problem>
 
 For this, iteratively ask "why" to drill down from symptoms to the root-cause.
 This helps to identify the fundamental reason behind a problem rather than just
@@ -39,20 +46,26 @@ addressing surface-level symptoms.
     Find the root-cause of <problem/> by following the following iteration cycle.
     Start with a <question/> set equal to the <problem/>.
 
-    <for items="1 2 3 4 5">
+    Determine the *maximum chain length* from <getopt-option-depth/>: if
+    <getopt-option-depth/> is *non-numeric* or *less than or equal to 0*,
+    use the default *5* instead.
+
+    Start with <n>1</n> (set iteration counter to one).
+    <while condition="<n/> is less than or equal to <getopt-option-depth/>">
         Ask <question/> and document the answer in <answer/> with the following template:
         Don't stop at symptoms, keep digging for systemic issues.
         Multiple root-causes may exist -- explore different branches.
         Consider technical, domain-specific, process-related, or organizational causes.
 
         <template>
-        <ase-tpl-bullet-secondary/> **WHY <item/>**: <answer/>
+        <ase-tpl-bullet-secondary/> **WHY <n/>**: <answer/>
         </template>
 
         Then, for the next iteration set <question/> now to be the last <answer/>.
-        The magic is NOT in exactly 5 "Why" -- you can <break/> the iteration
-        when you already reached the root-cause.
-    </for>
+        The magic is NOT in exactly <getopt-option-depth/> "Why" -- you can <break/>
+        the iteration when you already reached the root-cause.
+        Finally, set <n/> to <n/> + 1 (increment iteration counter).
+    </while>
     </step>
 
 3.  <step id="STEP 3: Report Solution">

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

@@ -7,20 +7,27 @@
 
 `ase-meta-why`
     [`--help`|`-h`]
+    [`--depth`|`-d` *N*]
     *fact*
 
 ##  DESCRIPTION
 
 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
-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
-including concrete source code changes.
+asks "why" - up to *N* times (see `--depth`, default five) - 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 including concrete source code changes.
 
 ##  ARGUMENTS
 
+`--depth`|`-d` *N*:
+    The *maximum* number of "why" iterations (the Five-Whys chain
+    length), acting as an *upper bound* only - the analysis still stops
+    early once the root cause is reached. Defaults to *5*. A non-numeric
+    or non-positive value falls back to the default.
+
 *fact*:
     The observed *fact* (symptom, problem, or surprising outcome)
     whose root cause should be investigated. The skill implicitly
@@ -34,6 +41,12 @@ Investigate the root cause of a build failure:
 ❯ /ase-meta-why the CI build is intermittently failing on macOS runners
 ```
 
+Drill down deeper with a tunable chain length of seven:
+
+```text
+❯ /ase-meta-why -d 7 the production latency spiked after the last deploy
+```
+
 ##  SEE ALSO
 
 `ase-code-analyze`, `ase-code-resolve`, `ase-arch-analyze`.

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

@@ -117,7 +117,7 @@ Procedure
 
     -   **Fuzzy Language**:
         When the user uses vague or overloaded terms instead of a precise
-        or canonical terms.
+        or canonical term.
 
     -   **Conflicting Terminology**:
         When the user uses a term that conflicts with the existing