@rse/ase 0.9.2 → 0.9.4

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-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>
@@ -226,7 +234,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

@@ -8,6 +8,7 @@
 `ase-code-lint`
     [`--help`|`-h`]
     [`--auto`|`-a`]
+    [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
     *source-reference*
 
 ##  DESCRIPTION
@@ -20,7 +21,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
@@ -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`,