Ase Code Analyze

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

Analyze Source Code

$ARGUMENTS

Analyze the source code of , 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.

is equal true and is equal true">

Only output the following and then STOP the entire flow (do not perform any further steps):

⧉ ASE: ✪ skill: ase-code-analyze, ▶ ERROR: options --performance and --security are mutually exclusive

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 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 or apply any change.

• Lens Focus:

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
• N+1 query patterns (1 parent query, N child queries)
• missing caching/memoization of stable results
• blocking/synchronous calls on hot paths
• unbounded growth (memory leaks, ever-growing collections)
• inefficient string building/concatenation in loops
• premature or repeated serialization/parsing
• lack of batching/pagination for bulk operations
• excessive logging or instrumentation overhead
• chatty network protocols (no connection pooling/keep-alive)
• lock contention and overly coarse-grained locking
• eager/over-fetching of data that is never used
• missing database indexes
• repeated regex (re)compilation in hot paths
• busy-waiting/polling instead of event-driven waits
• transferring uncompressed or overly verbose payloads
• missing short-circuit evaluation in expensive conditions
• recomputing invariants inside loops (loop-invariant code)
• suboptimal batch sizes (too small = overhead, too large = latency)
• inefficient algorithms for sorting/searching already-ordered data
• redundant validation/sanitization of trusted internal data
• missing connection/resource reuse (open-close per operation)
• [...]

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
• injection flaws
• cross-site scripting (XSS) and output-encoding gaps
• cross-site request forgery (CSRF) and missing anti-forgery tokens
• insecure direct object references (IDOR)
• server-side request forgery (SSRF)
• insecure or missing transport encryption (TLS)
• weak session management (fixation, predictable tokens)
• missing rate limiting/anti-automation controls
• overly permissive CORS or file permissions
• verbose error messages leaking internals
• unsafe randomness for security-sensitive values
• mass assignment / over-binding of request parameters
• security misconfiguration (default credentials, debug modes, exposed admin endpoints)
• missing or misconfigured security headers (CSP, HSTS, X-Frame-Options)
• improper certificate/hostname validation (TLS verification disabled)
• insufficient logging and monitoring of security events
• race conditions / TOCTOU (time-of-check to time-of-use) flaws
• integer overflow/underflow and buffer overflows
• use-after-free and memory-safety violations
• privilege escalation through improper privilege dropping
• insecure file upload handling (unrestricted type/size, executable storage)
• unsafe handling of untrusted regular expressions (ReDoS)
• caching of sensitive data in shared or client-side caches
• secrets or sensitive data leaking into logs, traces, or telemetry
• insecure default-deny failures (fail-open instead of fail-closed)
• missing integrity verification (unsigned updates, no subresource integrity)
• excessive data exposure in API responses (returning more fields than needed)
• improper resource cleanup leading to exhaustion (connection/file-descriptor leaks)
• business-logic flaws (bypassable workflows, negative quantities, replay)
• [...]

is NOT equal true and 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
• race conditions and unsynchronized shared state
• resource leaks (unclosed files, handles, connections)
• inverted or swapped function arguments
• incorrect loop termination or accumulator initialization
• shadowed or reassigned variables changing intent
• incomplete switch/case or enum coverage
• silent exception swallowing
• floating-point comparison and rounding errors
• integer overflow/underflow or truncating division
• sign and modulo errors with negative operands
• reference vs. value semantics (aliasing, shared mutable defaults)
• incorrect short-circuit evaluation or operator precedence
• logical vs. bitwise operator confusion
• negation mistakes in compound predicates
• wrong comparison operator (== instead of ===, `

You MUST not output anything in this STEP 2.

Before reporting, apply the severity floor selected via (default LOW): define the ordinal rank LOW=1, MEDIUM=2, HIGH=3. Keep a detected problem if and only if its is ACCEPTED or rank(severity) is greater than or equal to rank(); 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 with = 1, 2, ... in the original ordering. If all problems are dropped, skip the per-problem report but still purge any stale persisted problems with a single ase_kv_batch call to the ase MCP server with transactional set to true and a commands parameter array holding exactly one { command: "clear", prefix: "ase-issue-" } entry, and still emit the final hint below.

In this STEP 3, for EVERY surviving problem, immediately report it with the following output , based on concise bullet points.

is equal true">

PROBLEM (Severity: **): P: **

⊙ EVIDENCE: ⊖ TRADEOFF:

is NOT equal true">

PROBLEM (Severity: **): P: **

Hints:

• For the final results, do not output anything else, especially do

not give any further explanations or information.

• Uniquely identify the problems with P where is 1, 2, ...

• In , use ultra brief but still as precise as

possible problem descriptions.

• In , highlight code as ``

and key aspects as **.

• In , add inline references to the related

code positions in the form of either (:), (:-) or (#).

• In , classify the problem with a

of LOW, MEDIUM, HIGH, or ACCEPTED, ranked by the estimated impact of the problem. Use ACCEPTED when the problem is a deliberate, justified trade-off that should remain on record but is never dropped by the severity floor (see STEP 3).

• For ultra-compress the to a concise,

short, single sentence. Keep one inline reference to the code position which is most relevant to the problem.

• is equal true">

In , 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.

• is equal true">

In , 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.

• Additionally, persist all reported problems in a single

ase_kv_batch call to the ase MCP server with transactional set to true. The commands parameter array of this call starts with one { command: "clear", prefix: "ase-issue-" } entry (which removes only the previously persisted ase-issue-* keys, leaving any unrelated keys in the shared store intact), followed by one { command: "set", key: "ase-issue-P", val: ": " } entry per reported problem.

Finally, output the following to give a final hint:

⧉ ASE: ☻ skill: **, ▶ 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.**

You MUST not output anything else in this STEP 3, especially not any further explanations.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rse
• Source: rse/ase
• License: Apache-2.0
• Homepage: https://ase.tools

Install and usage instructions live in the source repository linked above.