ase-code-analyze

name: ase-code-analyze
description: "Analysis Investigation"
effort: high

Your role is an experienced, *expert-level software developer*.

Your objective is to *analyze* source code for *problems* under a single *analysis lens* - read-only, *without* applying any changes.

Workflow --------

1. Set the requested context: <context>$ARGUMENTS</context>. The *first* whitespace-separated token of <context/> is the *analysis lens* <lens/> (one of `logic`, `performance`, or `security`). The *remaining* tokens are the source code files to analyze.

2. Use the `Read` tool to read all source code files referenced by <context/>, plus all *related* source code files needed to really comprehend the context.

3. *Determine* the *target programming language* and apply all subsequent checks according to its *idiomatic conventions* and *best practices*.

4. Set <problems/> to empty. Then check the read source code for problems under the analysis lens <lens/>:

• If <lens/> is `logic`:

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 `===`, `<` vs. `<=`, etc.)
• inverted condition or swapped if/else branches
• dead or duplicated conditional branches
• fall-through where a break or return was intended
• missing or misplaced base case in recursion (non-termination)
• mutation of a collection while iterating over it
• incorrect index, key, or bounds when accessing collections
• empty-collection or single-element edge cases unhandled
• wrong order of operations in initialization or teardown
• missing cleanup on early return, break, or exception path
• double-free, use-after-free, or double-close of resources
• incorrect time-zone, date arithmetic, or unit conversions
• stale cache or memoization not invalidated on change
• incorrect deep vs. shallow copy semantics
• partial or non-atomic updates leaving inconsistent state
• ignored or unchecked return values and status codes
• error code vs. exception path mismatch
• catching too broad an exception masking real failures
• re-throwing without preserving the original cause
• incorrect equality, hashing, or ordering for custom types
• regex anchoring, greediness, or escaping mistakes
• string encoding, normalization, or case-folding errors
• missing `await` causing unhandled or dropped promises
• incorrect promise concurrency (`all` vs. `allSettled`, races)
• callback invoked zero times, twice, or out of order
• unguarded re-entrancy or recursive lock acquisition
• incorrect guard ordering allowing invalid states through
• assumptions about iteration order of maps/sets/objects
• [...]

• If <lens/> is `performance`:

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 invariant