/ase-code-analyze

name: ase-code-analyze
argument-hint: "[--help|-h] [--performance|-p] [--security|-s] [--severity|-S=(LOW|MEDIUM|HIGH)] <source-reference>"
description: >
    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
allowed-tools:
    - "Agent"
    - "Glob"

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

<purpose name="ase-code-analyze"> Analyze Source Code </purpose>

<expand name="getopt" arg1="ase-code-analyze" arg2="--performance|-p --security|-s --severity|-S=(LOW|MEDIUM|HIGH) --prefix|-P="> $ARGUMENTS </expand>

<objective> *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: 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* the entire flow (do not perform any further steps):

<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">

<if condition="<ase-project-boxing/> is equal `black`">

The project source artifacts are classified as a *black box*, so the user does *not* want them inspected or their problems surfaced. *Skip* the entire investigation and analysis: do *not* invoke any `Glob` or `Agent` tool and do *not* read any source, only output the following <template/> and then *SKIP* the remaining step STEP 3:

<template> <ase-tpl-bullet-normal/> **CODE ANALYSIS**: *suppressed* (`project.boxing` is `black`) </template>

</if>

First, use the following <template/> to give a hint on this step:

<template> <ase-tpl-bullet-secondary/> **ANALYSIS INVESTIGATION** </template>

Dispatch the investigation to *sub-agents* via the `Agent` tool so that *no* investigation details leak into the user-visible transcript. The sub-agents perform the silent reading and checking; only their final structured return values are consumed here.

For this, first determine the *analysis lens* <lens/>: set <lens>performance</lens> if <getopt-option-performance/> is equal `true`, set <lens>security</lens> if <getopt-option-security/> is equal `true`, and set <lens>logic</lens> otherwise.

Then *silently* resolve `<getopt-arguments/>` to the list <sources/> of individual source code files, expanding any directory or wildcard references with the `Glob` tool. Then partition <sources/>, preserving order, into at most *eight* batches of roughly equal size (a single file yields a single batch), and invoke the following tool once per batch, emitting *all* invocations *in one single message* so they run in *parallel*:

        Agent(
            description:       "Analysis Investigation (<batch-index/>/<batch-count/>)",
            subagent_type:     "ase:ase-code-analyze",
            prompt:            "<lens/> <batch/>",
            run_in_background: false
        )

Here <batch/> is the space-separated list of the source code file paths of the corresponding batch, <batch-index/> is the 1-based index of that batch, and <batch-count/> is the total number of batches, so that each parallel invocation is distinguishable in the progress display.

Parse the result message of each `Agent` tool invocation as a JSON array and concatenate all those arrays. Then *deduplicate* the combined list: when two problems share the same `file` and `line`, *silently drop* all but the first one (sub-agents may have read overlapping *related* files for comprehension). Finally sort the list by `file` and then numerically by `line`, and set <problems/> to that list.

You *MUST* *NOT* output anything at all in this STEP 2 beyond the `Glob` and `Agent` tool invocations.

</step>

3. <step id="STEP 3: Show Results">

Before reporting, determine the *problem id prefix* <id-prefix/>: set <id-prefix><getopt-option-prefix/>-</id-prefix> if <getopt-option-prefix/> is *not* empty, and set <id-prefix></id-prefix> (set to empty) otherwise. Every reported problem id and every persisted key below carries this <id-prefix/>, so that analyses run under *distinct* prefixes occupy *distinct* id namespaces and hence do not overwrite each other.

Before reporting, 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).

Then *apply the effective severity floor* <floor/>: *Keep* a detected problem if and only if its `severity` field is `ACCEPTED` *or* `rank(severity)` is greater than or equal to `rank(<floor/>)`; *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 sort the surviving problems in <problems/> by their `severity` field from highest to lowest in the fixed order `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`, so the reporting s