ase-code-lint

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

Your objective is to analyze and fix the source code for potential problems related to a set of code quality aspects.

Workflow

1. Set the requested context: $ARGUMENTS. The first whitespace-separated token of is the comma-separated aspect set (a non-empty subset of the aspect ids A01...A21). The remaining tokens are the source code files to check.

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 the following aspects (each aspect is uniquely identified by its aspect id A01 - XXX...`A21

   • XXX`), but strictly limited to those aspects whose id is contained in the aspect set -- all other aspects are not checked and their problems are never reported:

   • A01 - FORMATTING: Check for inconsistently formatted code and badly vertically aligned code on subsequent lines.

     For vertical alignment, prefer to align on operators. For continuous code blocks (those without any blank lines at all), ensure that they always start with a blank line and a comment (usually just a single-line one).

   • A02 - COMPREHENSION: Check for bad readability, bad maintainability, or bad self-documentation on identifiers.

     For identifiers, prefer single-letter ones for short loops and accept that identifier length correlates to the identifier scope, i.e., longer identifiers are acceptable for larger scopes. For all identifiers, prefer the idiomatic naming convention of the target programming language (e.g., camelCase for TypeScript/Java, snake_case for Python/Rust, mixedCaps for Go).

   • A03 - CLEANLINESS: Check for unclean code and inconsistent code.

     For unclean code, especially detect outdated code construct patterns. For inconsistent code, especially detect code variations for equal intentions.

   • A04 - SPELLING: Check for typos, spelling errors, or incorrect grammar in identifiers, string literals and comments.

     Especially, for comments ensure English language only and prefer short, very brief one-line descriptions.

   • A05 - COMPLEXITY: Check for extremely long functions and deeply nested code constructs.

     Especially, for functions prefer fewer than 100 lines, and for nested constructs prefer fewer than 10 nesting levels.

   • A06 - REDUNDANCY: Check for redundant code through duplications of identical or near-identical code. Apply graded severity by block size, occurrence count, and locality across the following sub-aspects:

     • R1 LARGE-BLOCK (>=10 lines, near-identical): 2 occurrences → MEDIUM; 3+ occurrences or cross-file → HIGH.

     • R2 MEDIUM-BLOCK (6-9 lines, near-identical): 2+ occurrences → MEDIUM; cross-file at any count → MEDIUM.

     • R3 SMALL-PATTERN (<6 lines, near-identical): 3+ occurrences → LOW. Flag as a smell; note that mechanical extraction usually does not pay off below the 6-line threshold, so prefer parameterization or leave a comment explaining the intentional duplication.

     • R4 STRUCTURAL-DUPLICATION: copy-pasted control structures with only literal/identifier substitutions (validation chains, error-handling boilerplate, mapping/transformation code) → at least MEDIUM, regardless of line count.