jetpack-compose-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Jetpack Compose Audit

Jetpack Compose审计

This skill audits Android Jetpack Compose repositories with a strict, evidence-based report.

Skill version: 2.0.1 — released 2026-04-29. Compose track: Kotlin 2.0.20+ / Compose Compiler 1.5.4+ (Strong Skipping Mode default). See the README changelog for what changed.

It is intentionally focused on four categories:

Performance
State management
Side effects
Composable API quality

This skill does not score design or Material 3 compliance in v1. If the audit surfaces likely design-system problems, recommend a follow-up audit with the

material-3

skill (reference implementation: https://github.com/hamen/material-3-skill).

本技能基于严格的证据对Android Jetpack Compose代码仓库进行审计。

**技能版本：**2.0.1 — 发布于2026-04-29。**Compose适配版本：**Kotlin 2.0.20+ / Compose Compiler 1.5.4+（默认启用Strong Skipping Mode）。详见README变更日志了解更新内容。

本技能专注于以下四个核心类别：

性能
状态管理
副作用
可组合API质量

v1版本中，本技能不对设计或Material 3合规性进行评分。如果审计过程中发现可能存在设计系统问题，建议后续使用

material-3

技能进行专项审计（参考实现：https://github.com/hamen/material-3-skill）。

Out Of Scope In v1

v1版本不包含的范围

Owned and deliberate scope choices — call out the limitation in the report rather than silently producing thin coverage:

Material 3 compliance, theming, color/typography tokens — defer to the
```
material-3
```
skill.
Accessibility scoring (
```
semantics
```
, content descriptions, touch-target sizing) — flag obvious gaps as a note, do not score.
UI test coverage and Compose test rule patterns — note presence/absence, do not score.
Compose Multiplatform-specific rules (
```
expect
```
/
```
actual
```
, target-specific code paths).
Wear OS / TV / Auto / Glance surfaces.
Build performance (incremental compilation, KSP/KAPT choice).

If the user explicitly asks for any of these, narrow the scope and state it in the report.

以下是明确划定的范围边界——在报告中需明确指出这些限制，而非默认覆盖不足：

Material 3合规性、主题设置、颜色/排版标记——交由
```
material-3
```
技能处理。
可访问性评分（
```
semantics
```
、内容描述、触摸目标尺寸）——仅标记明显的缺失，不进行评分。
UI测试覆盖率及Compose测试规则模式——仅记录存在/缺失情况，不进行评分。
Compose Multiplatform特定规则（
```
expect
```
/
```
actual
```
、目标平台专属代码路径）。
Wear OS / TV / Auto / Glance界面。
构建性能（增量编译、KSP/KAPT选择）。

如果用户明确要求上述任何一项，需缩小审计范围并在报告中说明。

When To Use

使用场景

Use this skill when the user asks to:

audit a Jetpack Compose repository
review Compose architecture or quality
rate a codebase with scores
inspect recomposition, state, or effects issues
identify Compose best-practice violations in an existing repo

Typical trigger phrases:

"audit this Compose repo"
"score this Jetpack Compose codebase"
"review state hoisting and side effects"
"check Compose performance"
"rate this repository"

当用户提出以下需求时，可使用本技能：

审计Jetpack Compose代码仓库
评审Compose架构或代码质量
为代码库打分评级
检查重组、状态或副作用问题
识别现有仓库中违反Compose最佳实践的情况

典型触发语句：

"audit this Compose repo"
"score this Jetpack Compose codebase"
"review state hoisting and side effects"
"check Compose performance"
"rate this repository"

Expected Output

预期输出

Produce both:

a repository report file named
```
COMPOSE-AUDIT-REPORT.md
```
a short chat summary with the overall score, category scores, worst issues, and the top fixes

需生成以下两项内容：

名为
```
COMPOSE-AUDIT-REPORT.md
```
的仓库报告文件
简短的聊天摘要，包含总分、各类别得分、最严重问题及首要修复建议

Audit Principles

审计原则

Be strict, but evidence-based.
Do not score from search hits alone. Read representative files before judging a category.
Cite concrete file paths in the report for every important deduction.
Cite an official documentation URL for every deduction. No "trust me" findings — the rubric maps every rule to a canonical source in
```
references/canonical-sources.md
```
. The report template requires a
```
References:
```
line per finding.
Prefer canonical Android guidance over folklore.
Treat performance as important, but not as the only lens.
Do not punish app code for failing public-library purity tests. Apply API-quality checks mainly to reusable internal components, design-system pieces, and shared UI building blocks.
Reserve
```
0-3
```
scores for repeated or systemic problems, not isolated mistakes.
Do not award
```
9-10
```
unless the repo is consistently strong across the category.

严格但基于证据。
不能仅通过搜索结果评分，需阅读代表性文件后再对类别进行判断。
报告中每个重要扣分点需引用具体文件路径。
每个扣分点必须引用官方文档URL。无“凭经验判断”的结论——评分标准将每条规则映射到
```
references/canonical-sources.md
```
中的权威来源。报告模板要求每个结论都包含
```
References:
```
行。
优先采用Android官方指南而非民间经验。
重视性能，但不将其作为唯一评估维度。
若应用代码未达到公共库的纯度标准，不进行惩罚。API质量检查主要针对可复用内部组件、设计系统模块和共享UI构建块。
```
0-3
```
分仅适用于重复出现或系统性问题，而非孤立错误。
只有当仓库在该类别中表现始终优秀时，才给予
```
9-10
```
分。

Process

流程

1. Confirm Scope

1. 确认范围

Identify the target path:

If the user passed an explicit path (
```
[repo path or module path]
```
), use it.
If no path was passed, default to the current working directory.
If the path does not exist, ask the user to clarify.

Before mapping modules, confirm Compose is actually present (fast-fail):

grep for

androidx.compose

in any

build.gradle*

libs.versions.toml

grep for
```
setContent {
```
or
```
@Composable
```
under
```
src/
```

If neither shows up, stop and report that the target is out of scope. Do not run a full module map first.

If Compose is present only in

samples/

demos/

, or test sources (no production usage), narrow the scope to those directories, set confidence to

Low

, and state in the report that the audit is over sample code rather than production paths. Do not score production-quality categories against demo code.

确定目标路径：

如果用户指定了明确路径（
```
[repo path or module path]
```
），使用该路径。
若未指定路径，默认使用当前工作目录。
若路径不存在，请用户澄清。

在分析模块之前，先确认目标中是否存在Compose（快速失败）：

在

build.gradle*

或

libs.versions.toml

中搜索

androidx.compose

在
```
src/
```
目录下搜索
```
setContent {
```
或
```
@Composable
```

若两者均未找到，停止审计并报告目标超出范围。无需先进行完整的模块分析。

若Compose仅存在于

samples/

、

demos/

或测试源码中（无生产环境使用），则将范围缩小至这些目录，设置置信度为

Low

，并在报告中说明审计针对的是示例代码而非生产路径。不得用生产质量标准对演示代码进行评分。

2. Map The Repository

2. 分析仓库结构

Before scoring, identify:

Gradle modules
Android app and feature modules
likely Compose source roots
shared UI/component packages
theme or design-system packages
state holder or ViewModel areas
test and preview locations
baseline-profile related modules or config if present

评分前，先识别：

Gradle模块
Android应用及功能模块
可能的Compose源码根目录
共享UI/组件包
主题或设计系统包
状态持有者或ViewModel区域
测试及预览位置
基线配置文件相关模块或配置（若存在）

3. Build A Compose Surface Map

3. 构建Compose界面映射

Look for:

```
@Composable
```
functions
reusable UI components
screens and routes
```
ViewModel
```
usage
```
remember
```
,
```
rememberSaveable
```
,
```
mutableStateOf
```

collectAsStateWithLifecycle

collectAsState

LaunchedEffect

DisposableEffect

SideEffect

rememberUpdatedState

produceState

```
LazyColumn
```
,
```
LazyRow
```
,
```
items
```
,
```
itemsIndexed
```

animation APIs:

animate*AsState

Animatable

updateTransition

rememberInfiniteTransition

AnimatedVisibility

AnimatedContent

Crossfade

If the repo is large, audit by category or by module. If subagents are available, parallelize category scans by spawning

Explore

-type subagents (no write tools) and merge the findings.

查找以下内容：

```
@Composable
```
函数
可复用UI组件
屏幕及路由
```
ViewModel
```
使用情况
```
remember
```
、
```
rememberSaveable
```
、
```
mutableStateOf
```

collectAsStateWithLifecycle

、

collectAsState

LaunchedEffect

、

DisposableEffect

、

SideEffect

、

rememberUpdatedState

、

produceState

```
LazyColumn
```
、
```
LazyRow
```
、
```
items
```
、
```
itemsIndexed
```

动画API：

animate*AsState

、

Animatable

、

updateTransition

、

rememberInfiniteTransition

、

AnimatedVisibility

、

AnimatedContent

、

Crossfade

若仓库规模较大，可按类别或模块进行审计。若有子代理可用，可通过生成

Explore

类型子代理（无写入权限）并行扫描各类别，再合并结果。

4. Generate Compose Compiler Reports (Automatic)

4. 自动生成Compose Compiler报告

Do not ask the user to edit

build.gradle

or run commands themselves. The skill runs the build with a bundled Gradle init script that injects

reportsDestination

metricsDestination

into every Compose module without modifying any file in the target repo. Before scoring, attempt this:

Locate the init script shipped with the skill:
```
scripts/compose-reports.init.gradle
```
. The absolute path is the skill's install location — in most installs that's
```
~/.claude/skills/jetpack-compose-audit/scripts/compose-reports.init.gradle
```
. If you cannot resolve the path, fall back to writing the script to
```
<target>/.compose-audit-reports.init.gradle
```
and delete it after the run.
Check for a Gradle wrapper in the target:
```
test -x <target>/gradlew
```
. If missing, skip to the fallback in step 6.
Pick a compile target. Prefer the cheapest task that still triggers Kotlin compilation for a Compose module:
- find the first application module via
```
rg -l 'com\.android\.application' -g '*.gradle*'
```
- try in order:
```
:<app-module>:compileReleaseKotlinAndroid
```
  ,
```
:<app-module>:compileReleaseKotlin
```
  ,
```
assembleRelease
```
  ,
```
assembleDebug
```
- If the project is Compose-only on a library (
```
com.android.library
```
  ), use that module instead.
Run the build. Inform the user the build is starting (it may take several minutes).
bash
```
cd <target> && ./gradlew <task> \
    --init-script <path-to>/compose-reports.init.gradle \
    --no-daemon --quiet
```
Use a 600-second timeout. If the task fails, try the next fallback task in step 3 once. Do not loop indefinitely.
Collect the reports.
bash
```
find <target> -path '*/build/compose_audit/*' \
    \( -name '*-classes.txt' -o -name '*-composables.txt' -o -name '*-composables.csv' -o -name '*-module.json' \)
```
From these files, extract:
- unstable classes (lines starting with
```
unstable class 
```
  in
```
*-classes.txt
```
  ) used as composable parameters
- non-skippable but restartable named composables (ignore zero-argument lambdas; focus on actual named functions in
```
*-composables.txt
```
  or
```
*-composables.csv
```
  where
```
isLambda == "0"
```
  )
- module-wide skippability counts from
```
*-module.json
```
  , AND compute the named-only skippability from
```
*-composables.csv
```
  (by filtering out rows where
```
isLambda == "1"
```
  and calculating
```
sum(skippable) / sum(restartable)
```
  ). Cite both in the Performance section, noting that zero-argument lambdas can artificially anchor the module-wide metric.
Fallback if the build fails or Gradle is unavailable. Proceed with source-inferred stability findings, but:
- set
```
Compiler diagnostics used: no
```
  in the report's Notes And Limits and explain the failure reason briefly (wrapper missing, compile error, timeout)
- reduce overall confidence by one level
- state each stability-related deduction as "inferred from source — not verified against compiler reports"

Stability deductions from step 5 are measured evidence and should be weighted normally. Fallback deductions from step 6 are inferred and must be flagged as such in the report.

请勿要求用户编辑
build.gradle
或自行运行命令。本技能通过捆绑的Gradle初始化脚本在构建时注入

reportsDestination

metricsDestination

到所有Compose模块，无需修改目标仓库中的任何文件。评分前尝试以下步骤：

定位初始化脚本：随技能发布的脚本为
```
scripts/compose-reports.init.gradle
```
。绝对路径为技能安装位置——大多数情况下为
```
~/.claude/skills/jetpack-compose-audit/scripts/compose-reports.init.gradle
```
。若无法解析路径，可退而求其次将脚本写入
```
<target>/.compose-audit-reports.init.gradle
```
，运行后删除。
检查目标中是否有Gradle wrapper：执行
```
test -x <target>/gradlew
```
。若缺失，跳至步骤6的 fallback方案。
选择编译目标：优先选择仍能触发Compose模块Kotlin编译的最轻量任务：
- 通过
```
rg -l 'com\.android\.application' -g '*.gradle*'
```
  找到第一个应用模块
- 按以下顺序尝试：
```
:<app-module>:compileReleaseKotlinAndroid
```
  、
```
:<app-module>:compileReleaseKotlin
```
  、
```
assembleRelease
```
  、
```
assembleDebug
```
- 若项目是仅包含Compose的库（
```
com.android.library
```
  ），则使用该模块。
运行构建：告知用户构建即将开始（可能需要几分钟）。
bash
```
cd <target> && ./gradlew <task> \
    --init-script <path-to>/compose-reports.init.gradle \
    --no-daemon --quiet
```
设置600秒超时。若任务失败，尝试步骤3中的下一个备选任务一次。请勿无限循环尝试。
收集报告
bash
```
find <target> -path '*/build/compose_audit/*' \
    \( -name '*-classes.txt' -o -name '*-composables.txt' -o -name '*-composables.csv' -o -name '*-module.json' \)
```
从这些文件中提取：
- 不稳定类（
```
*-classes.txt
```
  中以
```
unstable class 
```
  开头的行），作为可组合参数使用
- 不可跳过但可重启的命名可组合函数（忽略零参数lambda；关注
```
*-composables.txt
```
  或
```
*-composables.csv
```
  中
```
isLambda == "0"
```
  的实际命名函数）
- 从
```
*-module.json
```
  中提取模块级可跳过率统计，并从
```
*-composables.csv
```
  计算仅命名函数的可跳过率（过滤掉
```
isLambda == "1"
```
  的行，计算
```
sum(skippable) / sum(restartable)
```
  ）。在性能部分同时引用这两个指标，并说明零参数lambda可能会人为拉低模块级指标。
构建失败或Gradle不可用时的Fallback方案：基于源码推断稳定性结论，但需：
- 在报告的“说明与限制”中标记
```
Compiler diagnostics used: no
```
  ，并简要说明失败原因（缺失wrapper、编译错误、超时）
- 将整体置信度降低一级
- 将每个稳定性相关扣分标记为“从源码推断——未通过编译器报告验证”

步骤5中来自稳定性分析的扣分是有测量依据的，应正常加权。步骤6中的Fallback扣分是推断得出的，必须在报告中明确标记。

5. Audit The Four Categories

5. 审计四大类别

Use the scoring rubric in

references/scoring.md

and the heuristics in

references/search-playbook.md

使用

references/scoring.md

中的评分标准和

references/search-playbook.md

中的启发式规则。

Performance

性能

Focus on:

expensive work in composition
avoidable recomposition
lazy list keys
bad state-read timing
unstable or overly broad reads
backwards writes
animation phase correctness (per-frame values deferred to layout/draw via lambda modifiers,
```
Animatable
```
held in
```
remember
```
,
```
rememberInfiniteTransition
```
scoped so it stops offscreen)
obvious release-performance hygiene where visible

重点关注：

组合过程中的耗时操作
可避免的重组
懒加载列表的key
错误的状态读取时机
不稳定或过宽的状态读取
反向写入
动画阶段正确性（每帧值通过lambda修饰符延迟到布局/绘制阶段、
```
Animatable
```
存储在
```
remember
```
中、
```
rememberInfiniteTransition
```
限定作用域使其在屏幕外停止）
可见的发布版本性能卫生措施

State Management

状态管理

Focus on:

hoisting correctness
single source of truth
reusable stateless seams
correct use of
```
remember
```
vs
```
rememberSaveable
```
lifecycle-aware observable collection
observable vs non-observable mutable state

重点关注：

状态提升的正确性
单一数据源
可复用的无状态接口
```
remember
```
与
```
rememberSaveable
```
的正确使用
生命周期感知的可观察集合
可观察与不可观察的可变状态

Side Effects

副作用

Focus on:

side effects incorrectly done in composition
correct effect API choice
effect keys
stale lambda capture
cleanup correctness
lifecycle-aware effect behavior
animations driven from
```
LaunchedEffect(target)
```
for target-driven state changes (not from the composition body;
```
rememberCoroutineScope().launch { animateTo(...) }
```
is usually for event- or gesture-driven animation)

重点关注：

在组合过程中错误执行的副作用
副作用API的正确选择
副作用key
过期lambda捕获
清理操作的正确性
生命周期感知的副作用行为
由
```
LaunchedEffect(target)
```
驱动的动画（针对目标驱动的状态变化，而非组合体中的动画；
```
rememberCoroutineScope().launch { animateTo(...) }
```
通常用于事件或手势驱动的动画）

Composable API Quality

可组合API质量

Focus on reusable internal components, not every leaf screen.

Check:

```
modifier
```
presence and placement
parameter order
explicit over implicit configuration
meaningful defaults
avoiding
```
MutableState<T>
```
or
```
State<T>
```
parameters in reusable APIs where a better shape exists
reusable animated components exposing
```
animationSpec: AnimationSpec<T>
```
where callers may reasonably need timing control, and using meaningful
```
label
```
values on shared/tooling-visible animations
component purpose and layering

重点关注可复用内部组件，而非每个叶子屏幕。

检查：

```
modifier
```
的存在及位置
参数顺序
显式配置优于隐式配置
有意义的默认值
在可复用API中避免使用
```
MutableState<T>
```
或
```
State<T>
```
参数（如有更优替代方案）
可复用动画组件需暴露
```
animationSpec: AnimationSpec<T>
```
（调用方可能需要控制时序），并在共享/工具可见的动画上使用有意义的
```
label
```
值
组件用途与分层

6. Verify Findings

6. 验证结论

Before deducting points:

read the file where the smell appears
make sure the pattern is real, not a false positive
check whether the repo already has a compensating pattern elsewhere
distinguish one-off mistakes from systemic patterns
for stability findings (skippable / restartable / unstable params), use the compiler reports generated in Step 4. Cite the specific report line (e.g.
```
app/build/compose_audit/app_release-classes.txt:42
```
) as evidence. Only fall back to source-inferred stability claims if Step 4 failed, and label them as such.

扣分前需：

阅读问题出现的文件
确认模式真实存在，而非误报
检查仓库中是否已有补偿性模式
区分孤立错误与系统性模式
对于稳定性结论（可跳过/可重启/不稳定参数），使用步骤4生成的编译器报告。引用具体报告行（如
```
app/build/compose_audit/app_release-classes.txt:42
```
）作为证据。仅当步骤4失败时，才基于源码推断稳定性结论，并明确标记。

7. Score

7. 评分

Assign each category a

0-10

score and a status:

```
0-3
```
: fail
```
4-6
```
: needs work
```
7-8
```
: solid
```
9-10
```
: excellent

Use the weights in

references/scoring.md

to compute the overall score.

Measured ceilings are mandatory, not suggestive. When Step 4 produced compiler reports, the Performance rubric in

references/scoring.md

defines a ceiling. First determine whether Strong Skipping is active (Kotlin 2.0.20+ / Compose Compiler 1.5.4+, or an explicit opt-in flag) and pick the matching table — the SSM-off table is driven by

skippable%

+ unstable-class count, the SSM-on table by

skippable%

+ instance-recreation churn +

equals()

quality on unstable params. After arriving at a qualitative Performance score, you MUST apply the ceiling and lower the score if it exceeds the cap. Show the math in the report, and name which table was applied:

Performance ceiling check:
  Strong Skipping: OFF (Kotlin 1.9.x, no opt-in) → applying SSM-off table
  skippable% = 186/273 = 68.1% → falls in 50-70% band → cap at 4
  qualitative score: 7
  applied score: 4 (ceiling lowered from 7)

Under Strong Skipping,

skippable%

will typically sit near 100% and stop being the binding constraint; the cap is usually driven by observed churn (

listOf(...)

mapOf(...)

/ fresh literals passed into composables) or by expensive / broken

equals()

on unstable params. Name those findings explicitly in the ceiling-check block so the reader can audit the pick.

Do not round

skippable%

up into a higher band.

68.1%

is not

≥70%

. If a qualitative score lands at or below the ceiling, no adjustment is needed — but the check itself must appear in the report so the reader can audit it.

If a category genuinely has too little auditable surface area, mark it

N/A

, explain why, and renormalize the remaining weights.

为每个类别分配

0-10

分及状态：

```
0-3
```
：不合格
```
4-6
```
：需要改进
```
7-8
```
：良好
```
9-10
```
：优秀

使用

references/scoring.md

中的权重计算总分。

测量上限是强制性的，而非建议性的。当步骤4生成了编译器报告时，

references/scoring.md

中的性能评分标准定义了上限。首先确定是否启用了Strong Skipping（Kotlin 2.0.20+ / Compose Compiler 1.5.4+，或显式启用opt-in标志），并选择对应的表格——SSM-off表格由

skippable%

+不稳定类数量驱动，SSM-on表格由

skippable%

+实例重建损耗+不稳定参数的

equals()

质量驱动。得出性能定性评分后，必须应用上限，若评分超过上限则降低分数。在报告中展示计算过程，并说明使用的表格：

性能上限检查：
  Strong Skipping: OFF (Kotlin 1.9.x, 未启用opt-in) → 应用SSM-off表格
  skippable% = 186/273 = 68.1% → 属于50-70%区间 → 上限为4
  定性评分：7
  最终评分：4（因上限从7下调）

在Strong Skipping模式下，

skippable%

通常接近100%，不再是约束因素；上限通常由观察到的损耗（

listOf(...)

mapOf(...)

/传递给可组合函数的新字面量）或不稳定参数的昂贵/损坏的

equals()

驱动。在上限检查块中明确指出这些结论，以便读者审核。

请勿将

skippable%

向上舍入到更高区间。

68.1%

不等于

≥70%

。若定性评分等于或低于上限，则无需调整——但必须在报告中展示检查过程，以便读者审核。

若某个类别确实可审计内容过少，标记为

N/A

，说明原因，并重新计算剩余类别的权重占比。

8. Write The Report

8. 撰写报告

Use

references/report-template.md

The report must include:

overall score
category score table
top critical findings
category-by-category reasoning
evidence file paths
prioritized remediation list
optional follow-up note to run
```
material-3
```
if design issues are suspected

Write the report to:

```
COMPOSE-AUDIT-REPORT.md
```
inside the audited target (the path the user passed), not the current working directory.

COMPOSE-AUDIT-REPORT.md

already exists at that path, do not overwrite it silently. Either confirm overwrite with the user, or write to

COMPOSE-AUDIT-REPORT-<YYYY-MM-DD>.md

alongside it.

使用

references/report-template.md

模板。

报告必须包含：

总分
类别评分表
首要关键结论
按类别划分的推理过程
证据文件路径
按优先级排序的修复列表
可选：若怀疑存在设计问题，建议后续运行
```
material-3
```
审计

将报告写入：

被审计目标（用户指定的路径）内的
```
COMPOSE-AUDIT-REPORT.md
```
，而非当前工作目录。

若该路径下已存在

COMPOSE-AUDIT-REPORT.md

，请勿静默覆盖。需与用户确认是否覆盖，或写入

COMPOSE-AUDIT-REPORT-<YYYY-MM-DD>.md

并存。

9. Return A Short Summary

9. 返回简短摘要

In chat, produce a summary that mirrors the report's

Prioritized Fixes

section — not a generic recap. The developer should be able to act on the summary alone without opening the report file.

Include:

overall score (and the delta vs. any prior
```
COMPOSE-AUDIT-REPORT*.md
```
at the same path, if present)
one-line judgment for each category, with the applied ceiling if any (e.g. "Performance 8/10 — capped by the SSM-on table: recreated
```
FeedItemUiModel
```
params")
compiler-report highlights when Step 4 succeeded: Strong Skipping on/off (or mixed across modules), which ceiling table was applied, module-wide
```
skippable%
```
, named-only
```
skippable%
```
, which metric actually bound the cap, count of unstable shared types, and any module that failed to build
top three actionable fixes, each with:
- the concrete change ("add
```
key = { it.id }
```
  to
```
items(...)
```
  in
```
feed/FeedList.kt:42
```
  ")
- file path(s) and line numbers — the same ones listed in the report's Prioritized Fixes
- one official doc URL from
```
references/canonical-sources.md
```
- expected impact that matches the active ceiling table: on SSM-off, frame it in terms of named-only
```
skippable%
```
  / unstable-param reductions; on SSM-on, frame it in terms of removing instance-recreation churn, fixing expensive / broken
```
equals()
```
  , or clearing the binding cap
whether a
```
material-3
```
audit is worth running next

The top-three fixes in the chat summary MUST be the same items as the report's

Prioritized Fixes

list (same file paths, same doc links). Do not add generic advice in chat that isn't in the written report.

在聊天中生成与报告“优先修复项”部分一致的摘要——而非通用概述。开发者应无需打开报告文件即可根据摘要采取行动。

摘要需包含：

总分（若同一路径下存在之前的
```
COMPOSE-AUDIT-REPORT*.md
```
，需说明分数变化）
每个类别的一句话评价，包含应用的上限（如“性能8/10 — 受SSM-on表格限制：
```
FeedItemUiModel
```
参数被重复创建”）
步骤4成功时的编译器报告亮点：Strong Skipping开启/关闭（或模块间混合）、使用的上限表格、模块级
```
skippable%
```
、仅命名函数的
```
skippable%
```
、实际约束上限的指标、不稳定共享类型的数量、以及构建失败的模块
三大可操作修复建议，每个建议包含：
- 具体修改内容（“在
```
feed/FeedList.kt:42
```
  的
```
items(...)
```
  中添加
```
key = { it.id }
```
  ”）
- 文件路径及行号——与报告“优先修复项”列表中的一致
- 来自
```
references/canonical-sources.md
```
  的官方文档URL
- 与当前上限表格匹配的预期影响：SSM-off模式下，从仅命名函数的
```
skippable%
```
  /不稳定参数减少角度说明；SSM-on模式下，从消除实例重建损耗、修复昂贵/损坏的
```
equals()
```
  或解除约束上限角度说明
是否值得后续运行
```
material-3
```
审计

聊天摘要中的三大修复建议必须与报告“优先修复项”列表完全一致（相同文件路径、相同文档链接）。请勿在聊天中添加报告未提及的通用建议。

Evidence Rules

证据规则

Prefer multiple examples over one dramatic example.
Use positive evidence too, not just failures.
Do not infer runtime problems you cannot justify from the code.
When a rule is based on official guidance but app-level tradeoffs may justify deviation, call it out as a tradeoff instead of pretending it is always wrong.

优先使用多个示例而非单个极端示例。
同时使用正面证据，而非仅展示问题。
不得推断无法从代码中证明的运行时问题。
若规则基于官方指南，但应用层面的权衡可能导致偏离，需明确指出这是权衡选择，而非错误。

Large Repo Strategy

大型仓库策略

For medium or large repositories:

Map modules first.
Pick representative files per module.
Parallelize category scans when possible.
Merge repeated findings into systemic issues instead of listing the same smell twenty times.

针对中型或大型仓库：

先分析模块结构。
为每个模块选择代表性文件。
尽可能并行扫描各类别。
将重复结论合并为系统性问题，而非重复列出二十次相同问题。

What To Avoid

避免事项

Do not produce a generic checklist with no repository evidence.
Do not turn the report into a public-library API lecture if the repo is an app.
Do not inflate the performance score just because the app uses Compose.
Do not over-penalize isolated experiments or sample files unless they are part of production paths.
Do not score design in v1.
Do not flag
```
LaunchedEffect(Unit)
```
or
```
LaunchedEffect(true)
```
on its own — the "run once" pattern is idiomatic. Only flag it when the body captures a value that may change without
```
rememberUpdatedState
```
.
Do not deduct on Compose Multiplatform code paths for Android-only APIs (
```
collectAsStateWithLifecycle
```
,
```
lifecycle-runtime-compose
```
). Note the platform constraint as a tradeoff instead.
Do not double-count the same root cause across categories. A stability problem typically surfaces in both Performance and State — pick the dominant category and cross-reference.

不得生成无仓库证据的通用检查清单。
若仓库是应用程序，不得将报告变成公共库API讲座。
不得因应用使用Compose而虚高性能评分。
不得过度惩罚孤立实验或示例文件，除非它们属于生产路径。
v1版本中不得对设计进行评分。
不得单独标记
```
LaunchedEffect(Unit)
```
或
```
LaunchedEffect(true)
```
——“仅运行一次”模式是惯用写法。仅当主体捕获了可能在未使用
```
rememberUpdatedState
```
时发生变化的值时，才标记为问题。
不得因Compose Multiplatform代码路径使用Android专属API（
```
collectAsStateWithLifecycle
```
、
```
lifecycle-runtime-compose
```
）而扣分。需将平台约束标记为权衡选择。
不得跨类别重复计算同一根本原因。稳定性问题通常会同时影响性能和状态类别——选择主导类别并交叉引用。

References

参考资料

```
references/scoring.md
```
— per-rule rubric with inline citations
```
references/search-playbook.md
```
— search patterns and red-flag heuristics

references/report-template.md

— required structure for

COMPOSE-AUDIT-REPORT.md

```
references/canonical-sources.md
```
— the official URLs every deduction must cite
```
references/diagnostics.md
```
— copy-pasteable Gradle/code snippets for Compose Compiler reports, stability config, baseline profiles, and R8 checks
```
scripts/compose-reports.init.gradle
```
— Gradle init script the skill injects via
```
--init-script
```
in Step 4 to generate compiler reports automatically

```
references/scoring.md
```
— 带内联引用的逐规则评分标准
```
references/search-playbook.md
```
— 搜索模式及危险信号启发式规则

references/report-template.md

—

COMPOSE-AUDIT-REPORT.md

的必填结构

```
references/canonical-sources.md
```
— 每个扣分点必须引用的官方URL
```
references/diagnostics.md
```
— 可直接复制的Gradle/代码片段，用于生成Compose Compiler报告、稳定性配置、基线配置文件及R8检查
```
scripts/compose-reports.init.gradle
```
— 本技能在步骤4中通过
```
--init-script
```
注入的Gradle初始化脚本，用于自动生成编译器报告