ase-code-analyze

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: $ARGUMENTS. The first whitespace-separated token of is the analysis 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 , 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 to empty. Then check the read source code for problems under the analysis lens :

   • If 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
     • [...]