/ase-meta-review
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.
$ npx -y skills add rse/ase --skill ase-meta-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/ase-meta-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
ase-meta-review.SKILL.mdname: ase-meta-review
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
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 @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
<purpose name="ase-meta-review"> Review Staged Changes </purpose>
<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 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 ---------
<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">
<if condition="<ase-project-boxing/> is equal `black`">
The project source artifacts are classified as a *black box*, so the user does *not* want the staged changes scrutinized or their findings surfaced. *Skip* the entire review investigation: do *not* invoke the `Agent` tool and do *not* read any change, set <findings/> to the *empty* list, set <verdict/> to `SKIPPED (boxing: black)`, set <summary/> to a *one-line* neutral restatement of the change intent derived solely from STEP 1, and proceed *directly* to STEP 3.
</if>
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:
Agent(
description: "Review Investigation",
subagent_type: "ase:ase-meta-review",
prompt: "Review the staged changes.",
run_in_background: false
)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`. The verdict is derived *before* the severity floor below, so the floor only affects which findings are *rendered*, never the verdict.
Then determine the *effective severity floor* <floor/>: define the ordinal rank `LOW`=1, `MEDIUM`=2, `HIGH`=3, start from <floor><getopt-option-severity/></floor> (default `LOW`), and - if <ase-project-boxing/> is equal `grey` - raise <floor/> to `MEDIUM` whenever its current rank is below `rank(MEDIUM)` (grey boxing surfaces only *material* findings of severity `MEDIUM` and above). The floor affects only which findings are *rendered*, never the <verdict/> derived above.
Then *apply the effective severity floor* <floor/>: *Keep* a finding in <findings/> if and only if its `severity` field is `ACCEPTED` *or* `rank(severity)` is greater than or equal to `rank(<floor/>)`; *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.
</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.1.
2. <if condition="<findings/> is empty"> Only output the following <template/> and then *SKIP* the remainder of this STEP 3 (an empty finding list implies the `APPROVE` verdict, so the closing hint of substep 4 would expand into nothing anyway):
<template>
<ase-tpl-bullet-normal/> **NO FINDINGS**: the change is clean, nothing to flag.
</template> </if>
Read more
name: ase-meta-review
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
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 @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
<purpose name="ase-meta-review"> Review Staged Changes </purpose>
<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 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 ---------
<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">
<if condition="<ase-project-boxing/> is equal `black`">
The project source artifacts are classified as a *black box*, so the user does *not* want the staged changes scrutinized or their findings surfaced. *Skip* the entire review investigation: do *not* invoke the `Agent` tool and do *not* read any change, set <findings/> to the *empty* list, set <verdict/> to `SKIPPED (boxing: black)`, set <summary/> to a *one-line* neutral restatement of the change intent derived solely from STEP 1, and proceed *directly* to STEP 3.
</if>
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:
Agent(
description: "Review Investigation",
subagent_type: "ase:ase-meta-review",
prompt: "Review the staged changes.",
run_in_background: false
)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`. The verdict is derived *before* the severity floor below, so the floor only affects which findings are *rendered*, never the verdict.
Then determine the *effective severity floor* <floor/>: define the ordinal rank `LOW`=1, `MEDIUM`=2, `HIGH`=3, start from <floor><getopt-option-severity/></floor> (default `LOW`), and - if <ase-project-boxing/> is equal `grey` - raise <floor/> to `MEDIUM` whenever its current rank is below `rank(MEDIUM)` (grey boxing surfaces only *material* findings of severity `MEDIUM` and above). The floor affects only which findings are *rendered*, never the <verdict/> derived above.
Then *apply the effective severity floor* <floor/>: *Keep* a finding in <findings/> if and only if its `severity` field is `ACCEPTED` *or* `rank(severity)` is greater than or equal to `rank(<floor/>)`; *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.
</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.1.
2. <if condition="<findings/> is empty"> Only output the following <template/> and then *SKIP* the remainder of this STEP 3 (an empty finding list implies the `APPROVE` verdict, so the closing hint of substep 4 would expand into nothing anyway):
<template>
<ase-tpl-bullet-normal/> **NO FINDINGS**: the change is clean, nothing to flag.
</template> </if>
Showing the first part of this file.
Repo: rse/ase
Other skills on ase.
- /hello
Show a nice greeting message with a timestamp. Use this, when the user wants to greet or say hello, optionally to a certain subject <subject> and in a certain language <language>.
Open skill - /ase-arch-analyze
Review software architecture, including package cohesion and inter-package coupling
Open skill - /ase-arch-discover
Discover additional, third-party components (libraries/frameworks) for the technology stack to provide needed functionality.
Open skill - /ase-code-analyze
Analyze the source code for problems in either the logic and semantics and its related control flow, performance and efficiency, or security.
Open skill - /ase-code-craft
Craft Source Code: Use when user wants to "create", "add", or "craft" a new feature from scratch.
Open skill - /ase-code-dissect
Dissect the current Git change set, treated as an epic, domain-wise and logically into cohesive parts and materialize each part in its own dedicated Git WorkTree. Use when the user calls to "dissect", "split", "break up", or "decompose" a large change set into atomic, separately
Open skill

