메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | krit-kaa-benchmarking |
| description | 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 this workflow for cold/warm Kotlin Analysis API benchmarking on a representative target repository.
Build a fresh Krit binary and verify the KAA helper artifact exists:
go build -o krit ./cmd/krit/
test -f tools/krit-types/build/libs/krit-types.jar
Record the Krit revision and target revision in prose when reporting results.
Set a target path explicitly:
TARGET=/path/to/project
If the target config is not discovered from the scan root, pass --config.
Use the checked-in benchmark script when possible. It clears the oracle cache for each run and uses cache-disabling flags appropriate for cold KAA measurement.
KRIT="$PWD/krit" scripts/benchmark-oracle.sh "$TARGET"
Report phase timings and oracle workload fields from JSON output, especially:
After a cold run has populated oracle artifacts, measure warm behavior while disabling the incremental findings cache:
./krit -no-cache -perf -f json -q -o /tmp/krit_kaa_warm.json "$TARGET" || true
Warm KAA should avoid a JVM analyze phase when the oracle cache is valid. If total runtime is high, inspect rule execution, cross-file analysis, Android/Gradle project analysis, and config before blaming KAA.
When KAA cost regresses:
NeedsOracle, oracle call targets, declaration needs, or oracle diagnostics.-no-type-oracle -perf -perf-rules.Always include:
Do not treat cached warm findings as behavioral truth after rule or config changes; use cache-disabling flags for correctness checks.
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.