kaeawc

Use this workflow skill to review an AutoMobile change (a PR number or the current branch diff) the way this repo demands — ground every finding in file:line, reproduce before asserting, separate real bugs from daemon-session/environment artifacts, prefer reusing existing repo helpers and conventions over new code, and catch the regression or false-negative a fix can introduce. Deliver few verified findings, not many speculative ones.

Run one AutoMobile manual-test iteration: from a start point (commit, milestone/tag, or date), rebuild ALL components, restart the daemon with the right flags, and verify that closed issues and merged PRs actually fix their bugs / deliver their specced features on current HEAD by exercising tool calls on an Android emulator and iOS simulator. Use when asked to retest landed work, verify a release, or manually test what changed.

Drive one GitHub issue to a merged PR via TDD, with a plan-approval STOP gate, a pre-PR local-validation STOP gate, triaged (not blanket) review, and conservative follow-up capture. Use when asked to implement/ship/close out a specific issue end to end.

Use this workflow skill for broader project validation across lint, build, formatting, config, and platform checks; prefer test when the request is only about executing tests.

Use this workflow skill to review an AutoMobile change (a PR number or the current branch diff) the way this repo demands: ground every finding in file:line, reproduce before asserting, separate real bugs from daemon-session/environment artifacts, prefer reusing existing repo helpers and conventions over new code, and catch the regression or false-negative a fix can introduce.

Use this workflow skill for PR CI triage: inspect failing or pending checks, mergeability, and related review feedback, then reproduce likely failures locally and summarize next steps.

Use this workflow skill to publish the current branch: validate local changes, commit, push, create or update one PR, and optionally enable automerge.

Use this workflow skill for running tests only: choose the narrowest relevant test command first and keep test runs fast and actionable; prefer validate when the user wants broader non-test checks too.

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.