krit

Use when running Krit against an external Kotlin/Android repo (metro, kotlin-corpus, playground, or any user-provided path) to harvest false positives, find missed positives, or validate that a rule change behaves correctly on real code. Produces a triage list of rule findings worth fixing vs ignoring vs deferring.

Use when adding a new built-in Krit rule end to end — picking the category and base, declaring capabilities, registering the rule, writing positive/negative fixtures, adding an autofix when applicable, and ensuring Java parity when the rule covers both languages. Covers precompile (kotlinc-mirror) rules as a Level-tagged variant of the same workflow.

Use when writing, broadening, or fixing a Krit autofix. Covers the FixCosmetic / FixIdiomatic / FixSemantic safety tiers, ktfmt-compatible output, comment and inline preservation, the fix-drift lint gate, and when to neuter an unsafe autofix rather than ship it.

Use when working on Krit's daemon mode, analysis pipeline, cross-file cache, bundle/findings cache, WorkspaceState residency, conservative delta planner, or invalidation semantics. Covers cold vs warm correctness, per-phase timings, and the cache flags used to verify behavior vs cached output.

Use when fixing a false positive (or a missed positive) in an existing Krit rule. Distilled from the "Rule Implementation Guardrails" section of CLAUDE.md. Drives the regression-fixture-first workflow: reproduce on a fixture, identify the missing evidence, lock the regression with a failing test, narrow the rule, re-run.

Use when deciding whether a Krit rule truly needs Kotlin Analysis API, NeedsTypeInfo, NeedsResolver, parsed files, cross-file analysis, or library model facts, and when moving rules off KAA by replacing oracle facts with AST, source type inference, imports, project indexes, or Gradle-derived library profile.

Use when benchmarking Krit's Kotlin Analysis API oracle on a large Kotlin/Android repo, comparing cold vs warm KAA behavior, or investigating KAA regressions, oracle filters, call-target filters, and rule-driven KAA workload.

Use when analyzing Krit findings in context of a project's Gradle version catalog, library dependencies, SDK versions, or project model. Covers understanding what the librarymodel package knows about a project, diagnosing rules that fire incorrectly due to absent/present library context, and deciding which rules should be guarded by profile facts.

Use when auditing Krit static-analysis rules for false positives, missing project context, library lookalikes, config mismatches, Java/Kotlin coverage gaps, or comparing findings against representative Kotlin/Java/Android projects. Covers both rule precision and Gradle/version-catalog false positives.