Ase Meta Diff

@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md

$ARGUMENTS

Procedure

1. 1. Determine the diff details by running the corresponding command (taken exactly as given) and capturing the full diff output into for the subsequent analysis:

      git diff --cached HEAD

   2. Determine the diff statistics by running the corresponding command (taken exactly as given) and capturing the full stat output into for the subsequent analysis:

      git diff --cached --numstat HEAD

2. 2. Analyze the and and synthesize a concise narrative of WHAT changed and WHY, grouped by intent rather than by file. Honor the following intents:

      • FEATURE: new functionality or configuration
      • IMPROVEMENT: improved functionality or configuration
      • BUGFIX: corrected functionality or configuration
      • UPDATE: updated functionality or configuration
      • CLEANUP: cleaned up functionality or configuration
      • REFACTOR: refactored functionality or configuration

   3. <template>
      
      <ase-tpl-bullet-normal/> **CHANGE INTENT REPORT**:
      
      </template>
      

      2. Render a three-column table with one row per discovered intent group present in the . Output the following table header :

      3. For each discovered intent group, emit the following row , where is the intent label, is the total number of lines changed per intent group in format +N/-M, is the list of affected file references, and is a brief one-to-two-sentence narrative of what changed and why:

         In the part of the second column, markup all file references as code (with backticks), prepend them with ▢ , append [+N/-M] (based on the information in ) to them, and separate them with , (a comma and space). Do not repeat file references in the .

         Keep the overall report concise and brief. Try to keep the number of intent groups (table rows) in the range of 1-10. Do not output any further explanation.

3. 1. From the same captured and , reconstruct the single intended change as a thesis - the one logical, coherent purpose the diff as a whole is trying to accomplish.

      If the 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 .

   2. Walk every hunk in the and classify each one as either serving or not serving it. A hunk does not serve the thesis when it is one of the following 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 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 in .

   4. Emit the following header :

      CHANGE COHERENCE THESIS:

      CHANGE COHERENCE REPORT: Verdict:

   5. For each flagged hunk, repeat the third line, where is the deviation kind label, is the affected file reference, and is a brief one-sentence note on why the hunk does not serve and what to do with it (e.g. split into its own commit, drop the debug residue).

      In the column, markup all file references as code (with backticks), prepend them with ▢ and append [+N/-M] (based on the information in ) to them.

      Keep the overall texts in very concise and brief. Do not output any further explanation.

      Deviation	Location	Why it does not serve the thesis?

4. 1. Score the same captured and 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 by a one-line grounded in the actual hunks or the read-only repository probe.

      Probe the repository read-only and heuristically (via git grep / grep / git ls-files, restricted to first-party code) only as needed to substantiate the Coupling and Coverage axes (e.g. who imports a touched module, whether touched code has adjacent tests). Do not output anything during the probe.

   2. Score each axis against these anchors:

      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. 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. 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. 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).

   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.

   4. Emit the following , 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' - 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 and texts concise and ultra brief. Do not output any further explanation.

      In markup all file references as code (with backticks), prepend them with ▢ and append [+N/-M] (based on the information in ) to them.

      CHANGE RISK REPORT: Overall: (/5)

      Axis	Score	Findings
      	/5	● EVIDENCE: ● MITIGATION:

5. 1. From the same captured and , extract the touched modules - the distinct changed source files (or their enclosing modules/ packages, according to the language idiom).

   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.

   3. Then build a blast-radius graph and render it as a diagram:

      1. Build a Mermaid specification for a flowchart TB whose touched modules are the origin nodes and whose reverse-dependency edges fan out to the dependent modules (origin → dependent).

         Flag each touched node as a problem node per the 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).

      2. Dispatch the rendering to the ase-meta-diagram sub-agent by calling the tool Agent(name: "ase-meta-diagram", description: "Diagram Rendering", subagent_type: "ase:ase-meta-diagram", prompt: "<mermaid-spec/>") and capture its returned text field as .

   4. Then emit the following , showing and appending a brief impact summary of bullets, where each is a touched module and is a one-sentence note on what depends on it and how far the blast reaches.

      In and , markup all file references as code (with backticks), prepend them with ▢ and append [+N/-M] (based on the information in ) to them.

      Keep the overall report concise and brief. Do not output any further explanation.

      CHANGE BLAST RADIUS MAP:

      <diagram/>
      

      BLAST: ⚑ :

      BLAST: ⚑ :

      [...]