@rse/ase 0.9.2 → 0.9.3

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

@@ -1,11 +1,11 @@
 ---
 name: ase-meta-diff
-argument-hint: "[--help|-h] [--risk|-r] [--blast|-b]"
+argument-hint: "[--help|-h] [--coherence|-c] [--risk|-r] [--blast|-b]"
 description: >
     Summarize the currently staged Git changes as a human-readable,
     intent-grouped narrative. Use when the user wants a concise and
-    brief report of what changed and why. Optionally can show a risk and
-    blast radius report.
+    brief report of what changed and why. Optionally can check the diff
+    for intent coherence and show a risk and blast radius report.
 user-invocable: true
 disable-model-invocation: false
 effort: high
@@ -27,16 +27,18 @@ Summarize Diff
 
 <expand name="getopt"
     arg1="ase-meta-diff"
-    arg2="--risk|-r --blast|-b">
+    arg2="--coherence|-c --risk|-r --blast|-b">
     $ARGUMENTS
 </expand>
 
 <objective>
 Summarize the currently staged Git changes into a *concise*,
-*human-readable* narrative of what changed and why, *grouped by
-intent* rather than by file. Optionally *score* the diff against a
-*coupling-criticality-coverage- reversibility* rubric and emit a *graded
-risk report* with *mitigations*. Optionally render a *blast-radius map*.
+*human-readable* narrative of what changed and why, *grouped by intent*
+rather than by file. Optionally *reconstruct the change's single
+intended purpose* and *flag hunks that do not serve it*. Optionally
+*score* the diff against a *coupling-criticality-coverage-reversibility*
+rubric and emit a *graded risk report* with *mitigations*. Optionally
+render a *blast-radius map*.
 </objective>
 
 Procedure
@@ -129,19 +131,86 @@ explicitly requested by this procedure via outputs based on a <template/>!
 
     </step>
 
-3.  <step id="STEP 3: Score Against Risk Rubric (optional)">
+3.  <step id="STEP 3: Assess Intent Coherence"
+        condition="<getopt-option-coherence/> is equal `true` and <diff/> is NOT empty">
 
-    1.  <if condition="<getopt-option-risk/> is NOT equal `true`">
-        Silently *SKIP* this entire step.
-        </if>
+    1.  From the *same* captured <diff/> and <stat/>, *reconstruct the
+        single intended change* as a thesis - the one logical, coherent purpose
+        the diff *as a whole* is trying to accomplish.
 
-    2.  <if condition="<diff/> is empty">
-        Silently *SKIP* this entire step (STEP 2 already reported it).
-        </if>
+        If the <diff/> genuinely spans *several* unrelated purposes,
+        pick the *dominant* one as the thesis (the residue will surface
+        as flagged hunks below).
+
+        Multiple intents discovered in STEP 2 are a strong indicator of
+        incoherence. In this case, be very sceptical and do *NOT* form a
+        thesis which is just the superset of all those intents.
+
+        Finally, phrase the thesis as a *single* crisp sentence and
+        capture it as <thesis/>.
+
+    2.  Walk *every* hunk in the <diff/> and *classify* each one as
+        either *serving* <thesis/> or *not serving* it. A hunk does *not*
+        serve the thesis when it is one of the following <deviation/> kinds:
+
+        -   `SCOPE-CREEP`: an unrelated change riding along (e.g. a second
+            feature, a drive-by refactor, an opportunistic rename, a
+            reformatting sweep) that should be its own commit.
+
+        -   `STRAY-DEBUG`: leftover debug/diagnostic residue (e.g. debug
+            prints, `console.log`, commented-out code, temporary
+            logging, `TODO`/`FIXME` scaffolding, disabled tests), which
+            should be just removed and not part of any commit.
+
+    3.  A hunk that *serves* <thesis/> will be *not* reported. Only hunks that
+        do *not* serve it will be reported. If *every* hunk serves the thesis,
+        the diff is *coherent* and you report *no* flagged hunks.
+
+        Judge overall *coherence* from the flagged hunks: the diff
+        is `COHERENT` when there are *no* `SCOPE-CREEP` and *no*
+        `STRAY-DEBUG` deviations, otherwise it is `INCOHERENT`. Store
+        the result is <verdict/>.
+
+    4.  Emit the following header <template/>:
+
+        <template>
+
+        <ase-tpl-bullet-normal/> **CHANGE COHERENCE THESIS**: <thesis/>
 
-    3.  <if condition="<getopt-option-risk/> is equal `true` and <diff/> is NOT empty">
+        <ase-tpl-bullet-signal/> **CHANGE COHERENCE REPORT**: Verdict: **<verdict/>**
 
-        Score the *same* captured <diff/> and <stat/> information
+        </template>
+
+    5.  <if condition="<verdict/> is `INCOHERENT`">
+        Render a *three-column table* with one row per hunk, flagged
+        for *not serving* the <thesis/> above. Output the following table in <template/>.
+
+        For each flagged hunk, repeat the third line, where <deviation/>
+        is the deviation kind label, <location/> is the affected file
+        reference, and <reason/> is a *brief* one-sentence note on why
+        the hunk does not serve <thesis/> and what to do with it (e.g.
+        split into its own commit, drop the debug residue).
+
+        In the <location/> column, markup all file references as code
+        (with backticks), prepend them with `▢ ` and append ` [+N/-M]`
+        (based on the information in <stat/>) to them.
+
+        Keep the overall texts in <reason/> *very concise* and *brief*.
+        Do *not* output any further explanation.
+
+        <template>
+
+        | Deviation        | Location    | Why it does not serve the thesis? |
+        | ---------------- | ----------- | --------------------------------- |
+        | **<deviation/>** | <location/> | <reason/>                         |
+
+        </template>
+    </step>
+
+4.  <step id="STEP 4: Score Against Risk Rubric"
+        condition="<getopt-option-risk/> is equal `true` and <diff/> is NOT empty">
+
+    1.  Score the *same* captured <diff/> and <stat/> information
         against the four-axis rubric below. Each axis is scored on an
         integer scale of *1* (lowest risk) to *5* (highest risk) against
         the *fixed anchors* given, and *every* score *MUST* be backed
@@ -154,42 +223,42 @@ explicitly requested by this procedure via outputs based on a <template/>!
         axes (e.g. who imports a touched module, whether touched code has
         adjacent tests). Do not output anything during the probe.
 
-        Score each axis against these anchors:
+    2.  Score each axis against these anchors:
 
-        1.  **COUPLING** — how widely the touched code is depended upon.
+        1.  **COUPLING** - how widely the touched code is depended upon.
             *1*: self-contained, no first-party importers.
             *3*: a handful of dependent modules.
             *5*: a hub touched by many modules or a public interface.
 
-        2.  **CRITICALITY** — how essential the touched path is.
+        2.  **CRITICALITY** - how essential the touched path is.
             *1*: docs, comments, dead/peripheral code.
             *3*: ordinary feature logic.
             *5*: core/security/auth/data-integrity/money path.
 
-        3.  **COVERAGE** — how well the change is exercised by tests.
+        3.  **COVERAGE** - how well the change is exercised by tests.
             *1*: tests touched in this diff or directly covering the
             changed hunks.
             *3*: adjacent tests exist but are not clearly exercising the
             changed hunks.
             *5*: no tests anywhere near the touched code.
 
-        4.  **REVERSIBILITY** — how easily the change can be undone.
+        4.  **REVERSIBILITY** - how easily the change can be undone.
             *1*: pure code change, revert restores prior state.
             *3*: needs coordinated revert or a config rollback.
             *5*: irreversible-by-revert (schema/data migration, released
             artifact, external side effect).
 
-        Compute the *aggregate risk* as the *equal-weighted* mean of
+    3.  Compute the *aggregate risk* as the *equal-weighted* mean of
         the four risk contributions (Coupling, Criticality, Coverage,
         Reversibility), rounded to one decimal, and map it to a *graded
         band*: *1.0-1.9* → **LOW**, *2.0-2.9* → **MODERATE**, *3.0-3.9*
         → **HIGH**, *4.0-5.0* → **CRITICAL**.
 
-        Then emit the following <template/>, with the overall band and
+    4.  Emit the following <template/>, with the overall band and
         aggregate score, followed by a *three-column table* with one row
         per axis: column 1 is the *axis*, column 2 is the *score*, and
-        column 3 is the *evidence* (as a `●` bullet point) plus —
-        *only* if the axis reached the mitigation threshold of '>= 4' —
+        column 3 is the *evidence* (as a `●` bullet point) plus -
+        *only* if the axis reached the mitigation threshold of '>= 4' -
         the *mitigation* (as a second `●` bullet point). If an axis did
         not reach that threshold, omit the ` ● **MITIGATION**:
         <mitigation/>` part from its row. Keep the overall <evidence/>
@@ -204,49 +273,27 @@ explicitly requested by this procedure via outputs based on a <template/>!
 
         <ase-tpl-bullet-signal/> **CHANGE RISK REPORT**: Overall: **<band/>** (<aggregate/>/5)
 
-        | Axis | Score | Findings |
-        | ---- | ----- | -------- |
-        </template>
-
-        For each axis, emit the following row <template/>:
-
-        <template>
+        | Axis        | Score      | Findings                                                    |
+        | ----------- | ---------- | ----------------------------------------------------------- |
         | **<axis/>** | <score/>/5 | ● **EVIDENCE**: <evidence/> ● **MITIGATION**: <mitigation/> |
         </template>
-
-        Finally, output the following footer <template/>:
-
-        <template>
-
-        </template>
-
-        </if>
-
     </step>
 
-4.  <step id="STEP 4: Render Blast-Radius Map (optional)">
-
-    1.  <if condition="<getopt-option-blast/> is NOT equal `true`">
-        Silently *SKIP* this entire step.
-        </if>
-
-    2.  <if condition="<diff/> is empty">
-        Silently *SKIP* this entire step (STEP 2 already reported it).
-        </if>
+5.  <step id="STEP 5: Render Blast-Radius Map"
+        condition="<getopt-option-blast/> is equal `true` and <diff/> is NOT empty">
 
-    3.  <if condition="<getopt-option-blast/> is equal `true` and <diff/> is NOT empty">
-        From the *same* captured <diff/> and <stat/>, *extract the
-        touched modules* — the distinct changed source files (or their
+    1.  From the *same* captured <diff/> and <stat/>, *extract the
+        touched modules* - the distinct changed source files (or their
         enclosing modules/ packages, according to the language idiom).
 
-        Then, for each touched module, *scan its reverse dependencies*
-        — the other first-party files that *import* or *reference* it
+    2.  Then, for each touched module, *scan its reverse dependencies*
+        - the other first-party files that *import* or *reference* it
         across the current project (e.g. by the module's basename,
         exported symbol, or import path). Keep the scan *read-only*
         and *heuristic*; restrict it to first-party code within the
         repository. Do not output anything during the scan.
 
-        Then build a *blast-radius graph* and render it as a diagram:
+    3.  Then build a *blast-radius graph* and render it as a diagram:
 
         1.  Build a Mermaid specification <mermaid-spec/> for a `flowchart
             TB` whose *touched* modules are the origin nodes and whose
@@ -254,7 +301,7 @@ explicitly requested by this procedure via outputs based on a <template/>!
             (origin → dependent).
 
             Flag each *touched* node as a problem node per the
-            `ase-meta-diagram` anomaly convention — prefix its label
+            `ase-meta-diagram` anomaly convention - prefix its label
             with `⚑ ` inside quotes, e.g. `T1["⚑ src/core.ts"]`. Keep
             labels ultra short (basenames or module names only).
 
@@ -264,7 +311,7 @@ explicitly requested by this procedure via outputs based on a <template/>!
             "ase:ase-meta-diagram", prompt: "<mermaid-spec/>")` and capture
             its returned `text` field as <diagram/>.
 
-        Then emit the following <template/>, showing <diagram/> and
+    4.  Then emit the following <template/>, showing <diagram/> and
         appending a *brief impact summary* of bullets, where each
         <module/> is a *touched* module and <impact/> is a one-sentence
         note on *what depends on it* and *how far the blast reaches*.
@@ -273,8 +320,11 @@ explicitly requested by this procedure via outputs based on a <template/>!
         (with backticks), prepend them with `▢ ` and append ` [+N/-M]`
         (based on the information in <stat/>) to them.
 
+        Keep the overall report *concise* and *brief*. Do *not* output
+        any further explanation.
+
         <template>
-        <ase-tpl-head title="Hello World"/>
+        <ase-tpl-head title="CHANGE BLAST RADIUS"/>
 
         <ase-tpl-bullet-signal/> **CHANGE BLAST RADIUS MAP**:
 
@@ -291,10 +341,6 @@ explicitly requested by this procedure via outputs based on a <template/>!
         <ase-tpl-foot/>
         </template>
 
-        Keep the overall report *concise* and *brief*. Do *not* output
-        any further explanation.
-        </if>
-
     </step>
 
 </flow>

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

@@ -7,6 +7,7 @@
 
 `ase-meta-diff`
     [`--help`|`-h`]
+    [`--coherence`|`-c`]
     [`--risk`|`-r`]
     [`--blast`|`-b`]
 
@@ -18,12 +19,22 @@ intent* (such as *Feature*, *Improvement*, *Bugfix*, *Update*,
 *Cleanup*, or *Refactor*) rather than by file. It inspects the
 *staged* changes (`git diff --cached HEAD`). The result is a short
 bullet list, one bullet per intent group, each naming the affected
-files with their per-file `[+N/-M]` line counts — giving you the
+files with their per-file `[+N/-M]` line counts - giving you the
 essence of the changes at a glance.
 
+With `--coherence`, the skill additionally *reconstructs the single
+intended change* the diff is trying to accomplish - phrased as one crisp
+*thesis* sentence - and then walks *every* hunk to *flag those that do
+not serve it*: **scope creep** (an unrelated feature or drive-by refactor
+riding along), **stray debug** (leftover prints, commented-out code, or
+disabled tests), and **ripple** (mechanical fallout edits forced by the
+core change). It emits an overall **COHERENT** / **INCOHERENT** verdict
+plus a table of the flagged hunks with what to do with each - keeping the
+diff to a *single logical and coherent change* before it is committed.
+
 With `--risk`, the skill additionally *scores* the same diff against a
 four-axis **coupling-criticality-coverage-reversibility** rubric and
-emits a *graded risk report* — one bullet per axis (each scored *1*-*5*
+emits a *graded risk report* - one bullet per axis (each scored *1*-*5*
 with a one-line evidence justification drawn from the actual hunks), an
 overall risk band (**LOW**, **MODERATE**, **HIGH**, or **CRITICAL**),
 and one actionable *mitigation* per high-risk axis. The axes combine
@@ -31,18 +42,25 @@ with *equal weights*, and the rubric is deliberately *not tuned* to any
 specific project: every score is backed by cited evidence so it remains
 *overridable*, and the report is *decision support*, not a merge gate.
 
-With `--blast`, the skill additionally renders a *blast-radius map* — a
+With `--blast`, the skill additionally renders a *blast-radius map* - a
 Mermaid `flowchart` of the *touched modules* and their *reverse
 dependencies*, plus a *brief impact summary*. It *extracts the touched
 modules* from the changed files, *scans the repository* for the
 first-party code that *imports* or *references* those modules, builds a
 blast-radius graph (touched modules as origin nodes, dependents fanning
 out along the edges), dispatches the rendering to the `ase-meta-diagram`
-sub-agent, and appends a short bullet list of the per-module impact —
+sub-agent, and appends a short bullet list of the per-module impact -
 giving a visual sense of *what a diff endangers* before a deeper review.
 
 ##  ARGUMENTS
 
+`--coherence`, `-c`:
+    In addition to the intent-grouped summary, reconstruct the diff's
+    *single intended change* as one crisp *thesis* sentence and flag
+    *every* hunk that does *not* serve it - *scope creep*, *stray debug*,
+    or *ripple* fallout - then emit an overall **COHERENT** /
+    **INCOHERENT** verdict with a table of the flagged hunks.
+
 `--risk`, `-r`:
     In addition to the intent-grouped summary, score the diff against
     the *coupling-criticality-coverage-reversibility* rubric and emit a
@@ -52,8 +70,8 @@ giving a visual sense of *what a diff endangers* before a deeper review.
 
 `--blast`, `-b`:
     In addition to the intent-grouped summary, render a *blast-radius
-    map* — a Mermaid `flowchart` of the *touched modules* and their
-    *reverse dependencies* — plus a *brief impact summary* of what
+    map* - a Mermaid `flowchart` of the *touched modules* and their
+    *reverse dependencies* - plus a *brief impact summary* of what
     depends on the touched code and how far the blast reaches.
 
 ##  EXAMPLES
@@ -64,6 +82,12 @@ Summarize the currently staged changes:
 ❯ /ase-meta-diff
 ```
 
+Summarize the staged changes and append an intent-coherence report:
+
+```text
+❯ /ase-meta-diff --coherence
+```
+
 Summarize the staged changes and append a graded risk report:
 
 ```text

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

@@ -0,0 +1,166 @@
+---
+name: ase-meta-review
+argument-hint: "[--help|-h]"
+description: >
+    Perform a holistic, human-reviewer-style critique of the currently
+    staged Git changes and emit an approve/reject verdict with
+    prioritized, severity-tagged, line-cited findings. Use when the user
+    wants the staged diff "reviewed", "critiqued", or "code-reviewed"
+    before committing.
+user-invocable: true
+disable-model-invocation: false
+effort: high
+allowed-tools:
+    - "Bash(git diff *)"
+    - "Agent"
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+
+<skill name="ase-meta-review">
+Review Staged Changes
+</skill>
+
+<objective>
+Review the currently staged Git changes the way an *experienced human
+reviewer* would - judging them *holistically* against the change's *own
+intent* and against *correctness*, *design fit*, *clarity*, *robustness*,
+and *project-convention conformance* - and emit a single *approve /
+request-changes verdict* backed by *prioritized*, *severity-tagged*,
+*line-cited* findings. This is a *synthesizing critique*, not a mechanical
+scan: it complements `ase-code-lint` (mechanical quality), `ase-code-analyze`
+(logic/semantics), and `ase-meta-diff` (intent narrative and risk).
+</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: Determine Change Set">
+
+    1.  Determine *whether there are staged changes at all* by running the
+        corresponding command (taken exactly as given) and capturing its
+        output - the bare *list of staged file names* - into <diff/>. This
+        is a lightweight gate; the full diff is fetched by the sub-agent
+        in STEP 2, so capturing only the file-name list here is sufficient:
+
+        `git diff --cached --name-only HEAD`
+
+    2.  <if condition="<diff/> is empty">
+        Only output the following <template/> and then *STOP* immediately:
+
+        <template>
+        ⧉ **ASE**: ✪ skill: **ase-meta-review**, ▶ status: **no changes to review**
+        </template>
+        </if>
+
+    </step>
+
+2.  <step id="STEP 2: Review Investigation">
+
+    First, use the following <template/> to give a hint on this step:
+
+    <template>
+    <ase-tpl-bullet-secondary/> **REVIEW INVESTIGATION**
+    </template>
+
+    Dispatch the review investigation to a *sub-agent* via the `Agent`
+    tool so that *no* investigation details leak into the user-visible
+    transcript. The sub-agent performs the silent reading, the read-only
+    repository probing, and the critique; only its final structured return
+    value is consumed here.
+
+    For this, invoke *exactly once* the tool:
+
+    ```text
+        Agent(
+            name:          "ase:ase-meta-review",
+            description:   "Review Investigation",
+            subagent_type: "ase:ase-meta-review",
+            mode:          "plan",
+            prompt:        "Review the staged changes."
+        )
+    ```
+
+    Parse the single result message of the `Agent` tool as a JSON object,
+    set <summary/> to its `summary` field (a single crisp sentence
+    reconstructing the change's intent), and set <findings/> to its
+    `findings` field (a list).
+
+    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`.
+
+    You *MUST* *NOT* output anything else in this STEP 2.
+
+    </step>
+
+3.  <step id="STEP 3: Verdict and Findings">
+
+    1.  Use the following <template/> to output the overall review in
+        <verdict/> and the reconstructed intent <summary/>:
+
+        <template>
+
+        <ase-tpl-bullet-signal/> **REVIEW VERDICT**: **<verdict/>**
+
+        <ase-tpl-bullet-normal/> **CHANGE INTENT**: <summary/>
+
+        </template>
+
+        You *MUST* *NOT* output anything else in this STEP 3.
+
+    2.  <if condition="<findings/> is empty">
+        Only output the following <template/> and then *SKIP* the
+        remainder of this STEP 3:
+
+        <template>
+
+        <ase-tpl-bullet-normal/> **NO FINDINGS**: the change is clean, nothing to flag.
+
+        </template>
+        </if>
+
+    3.  <if condition="<findings/> is NOT empty">
+        Sort the findings by <severity/> from highest to lowest in the
+        fixed order `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`. Within the same
+        severity, keep the order returned by the sub-agent.
+
+        Then render a *three-column table* with one row per finding by
+        using the following output <template/>. For each finding, repeat
+        the third line, set <severity/> to its `severity` field, set
+        <dimension/> to its `dimension` field set <location/> to its
+        `location` field, and set <finding/> to its `finding` field.
+
+        In the <location/> column, markup the `file:line` reference
+        as code (with backticks) and prepend it with `▢ ` - keep the
+        sub-agent's own `:N` / `:N-M` line citation intact and do *not*
+        append any further line-count decoration.
+
+        Because the <finding/> text is free-form Markdown, *before*
+        emitting any row you *MUST* escape every literal `|` pipe
+        character inside <location/> and <finding/> as `\|` so it cannot
+        break the table column structure.
+
+        <template>
+        | Severity        | Dimension    | Finding                 |
+        | --------------- | ------------ | ----------------------- |
+        | **<severity/>** | <dimension/> | <location/>: <finding/> |
+        </template>
+
+        Keep the overall report *concise* and *brief*.
+        Do *not* output any further explanation.
+        </if>
+
+    </step>
+
+</flow>

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

@@ -0,0 +1,70 @@
+
+##  NAME
+
+`ase-meta-review` - Review Staged Changes
+
+##  SYNOPSIS
+
+`ase-meta-review`
+
+##  DESCRIPTION
+
+The `ase-meta-review` skill performs a *holistic*,
+*human-reviewer-style* critique of the *staged* Git changes and emits a
+single *approve* / *reject* **verdict** backed by *prioritized*,
+*severity-tagged*, *line-cited* **findings**. Rather than scanning the
+code mechanically, it first *reconstructs the change's own intent* and
+then judges the diff *as a whole* against that intent - the way an
+experienced reviewer would on a pull request.
+
+The critique spans a fixed set of reviewer *dimensions*: **intent**
+(does the diff do what it set out to, without scope creep or stray
+residue), **correctness** (latent bugs, edge cases, broken
+control/data flow), **design** (fit with the surrounding architecture,
+naming, abstraction level), **clarity** (readability and
+self-documentation for a future reader), **robustness** (error handling,
+resource and concurrency safety), **security** and **performance** (risks
+introduced by the change), **convention** (conformance to the
+project's documented conventions - code style and the plan/spec/arch
+formats described in `AGENTS.md` and the `ase-format-*` meta documents),
+**testing** (inadequate coverage for the change - new or fixed behavior
+left untested, adjacent tests not updated, or existing tests silently
+broken, disabled, or weakened), and **documentation** (user- or
+developer-facing docs - `README`, `CHANGELOG`, help text, or AI
+guidance/meta documents - left stale by the change).
+
+Each finding carries a *severity* - **HIGH**, **MEDIUM**, **LOW**, or
+**ACCEPTED** (a concern that is contractually addressed or accepted as a
+documented priority conflict) - and is *evidence-grounded*: it cites the
+exact `file:line` location it stems from. The overall verdict is
+**REJECT - DEMANDS CHANGES** when any *HIGH* finding remains, and
+**APPROVE** otherwise. The work is performed by a dedicated `ase-meta-review`
+sub-agent so that the silent reading and read-only repository probing
+never leak into the transcript; only the structured verdict and findings
+are rendered.
+
+The skill *complements* rather than duplicates its neighbours:
+`ase-code-lint` flags *mechanical* code-quality issues, `ase-code-analyze`
+inspects *logic and semantics*, `ase-meta-diff` narrates *what changed*
+(with optional coherence, risk, and blast-radius reports), and
+`ase-meta-diaboli` *adversarially challenges a thesis* - whereas
+`ase-meta-review` renders a *reviewer's judgement* on a concrete diff
+before it is committed.
+
+##  ARGUMENTS
+
+The `ase-meta-review` skill takes no arguments; it always reviews the
+currently *staged* Git changes.
+
+##  EXAMPLES
+
+Review the currently staged changes before committing:
+
+```text
+❯ /ase-meta-review
+```
+
+##  SEE ALSO
+
+`ase-meta-diff`, `ase-meta-commit`, `ase-code-lint`, `ase-code-analyze`,
+`ase-meta-diaboli`.