What it does
Runs the configured analyzers/linters (or analyzes manually), measures cyclomatic complexity, nesting, size and parameter count against thresholds, surfaces control-/data-flow and coding-standard/security concerns, ranks findings by severity and risk area, and recommends testability-improving refactors.
When to use it
Assess code quality and find defect-prone units early (shift-left); distinct from reviewing the test basis (static-review).
Prerequisites
qa.config.yml (paths.reports_dir/docs_dir, tooling.security.sast, gates/limits, risk_areas) — inferred from the repo if absent; a path/module, or empty to default to risk_areas.critical source.
Output
Static Analysis Report (static-analysis findings record; scores ISO/IEC 25010 maintainability) -> reports/STATIC-ANALYSIS.md.
Mechanics
How it works
- Read config and set scope from $ARGUMENTS (default to critical source)
- Run the configured analyzer(s)/linters present in the repo, or analyze manually
- Measure per-unit metrics (complexity, nesting, size, params) against thresholds
- Surface control-/data-flow concerns and coding-standard/security patterns
- Prioritize findings by severity and risk area; recommend concrete refactors
- Write the report with metrics and findings tables; read-only on the code
Why it works
The theory behind it
Static analysis is a form of static testing where code is analyzed not executed (CTFL v4.0 §3.1; CTAL-TTA control-/data-flow/complexity techniques). Shift-left for code (Principle 3); defects cluster in complex units (Principle 4). Scores ISO/IEC 25010 maintainability sub-characteristics.
CTFL v4.0 §3.1 · CTAL-TTA · ISO/IEC 25010 (maintainability)
Example
See it in use
> /qa:static-analysis src/checkout✓ Correct when It reports cyclomatic complexity/maintainability per unit, cites file:line evidence, and modifies no files.
Related commands
Used by