svharness 0.8.0

package/templates/android-compose/skeleton/agent-env/skills/harness-android-cli/references/interact.md

@@ -0,0 +1,83 @@
+# Tools
+Run `android layout --help` and `android screen --help`.
+
+## UI Dump
+`android layout`  returns a flat JSON list of the UI elements on screen.
+`android layout --diff` returns a flat JSON list of the UI elements that have changed since the last call to `layout` or `layout --diff`
+
+Each JSON object represents a UI element in the Android app. The following properties may be present:
+- `text` - any literal text the element contains
+- `resourceId` - the Android resource id used to refer to the element
+- `contentDesc` - a description of a UI element for use by accessibility tools
+- `interactions` - the set of user interactions the element supports. May contain one or more of: `checkable`, `clickable`, `focusable`, `scrollable`, `long-clickable`, `password`
+- `state` - the set of states the element is in. May contain one or more of `checked`, `focused`, `selected`
+- `bounds` - the screen coordinates of the bounding rectangle of the element, in the format `[min X,min Y][max X, max Y]`
+- `center` - the screen coordinates of the center of the element, in the format `[x,y]`
+- `off-screen` - if true, the element is in the UI hierarchy but not visible; it may require scrolling to view.
+
+Use `layout` as a primary means of examining an Android app. Use `layout --diff` to focus on changes and to keep your context small.
+Example: When entering digits into a calculator, use `layout --diff` to output only the digit readout element.
+
+`layout` may fail due to the app displaying a WebView or animation; in these cases, use `android screen --annotate` to inspect the app.
+This failure will likely resolve after navigating away from the current screen.
+
+## Screenshot
+`android screen capture -o <file path>` saves a PNG of the current device screen to `<file path>`
+
+Use `screen capture` as a secondary means of examining an Android app
+Examples:
+- Understanding the content of an on-screen image
+- Looking at a `WebView` (web content does not always appear in the ui dump)
+- Trying to find a UI element by its visual appearance
+
+**IMPORTANT**: Always *VISUALLY* examine the PNG image returned from `android screen` BEFORE doing anything else.
+
+## Annotated Screenshot
+`android screen capture --annotate -o <file path>`
+`android screen resolve --screen <path> --string <string>`
+
+The `--annotate` command adds numerical labels and bounding boxes around UI elements. Use this command to locate UI elements that cannot
+be located in the `layout` output.
+
+**IMPORTANT**: When using `android screen --annotate`, always *VISUALLY* examine the resulting PNG file.
+
+To refer to these labels in input commands, use `screen resolve` to convert labels into coordinates:
+
+`android screen resolve --screen <file path> --string "#3"` returns `<x coord of region 3> <y coord of region 3>`
+
+To save turns, you can combine shell commands:
+
+`adb shell input $(android screen resolve --screen screen.png --string "tap #34")`
+
+This command taps on region #34 from `screen.png`
+
+## Input
+Use `adb shell input` for interacting with Android devices.
+Refer to the `"interactions"` property of an element for what interactions can be performed on a particular element.
+
+Interact with UI elements with their `center` coordinate or their `bounds` coordinates:
+```json
+{
+  "key": -248568265,
+  "class": "android.widget.Button",
+  "bounds": "[138,9][167,38]",
+  "center": "[152,23]"
+}
+```
+To tap on this button, you would execute `adb shell input tap 152 23`. This taps the center.
+
+```json
+{
+  "key": 12487234,
+  "class": "com.example.ui.ScrollableList",
+  "bounds": "[100,200][400,600]",
+  "center": "[250,400]"
+}
+```
+To scroll down on this list, you would execute `adb shell input swipe 250 400 600 500`. This swipes from the center to the bottom over 500ms.
+
+# Android Interaction Rules
+1. Always ensure text input fields have `"focused"` in their `"state"` list before entering text
+2. If an element has `"scrollable"` in its `"interactions"` list, try scrolling it when looking for missing UI elements
+2. Always scroll slowly when executing scroll inputs. The 5th argument to `adb shell input swipe` controls scroll duration.
+3. Content may take time to load; if a `layout` is missing information after you take an action, wait a few seconds, then perform `layout --diff` to see if anything changes.

package/templates/android-compose/skeleton/agent-env/skills/harness-android-cli/references/journeys.md

@@ -0,0 +1,97 @@
+A journey is an XML-specified test of an Android app's behavior. It consists of a list of `<action>` elements. For example:
+```xml
+<journey name="My Journey">
+   <description>
+      A sample journey to illustrate the format
+   </description>
+   <actions>
+     <action>
+       Tap the "Home" icon
+     </action>
+     <action>
+       Verify that the app is on its Home screen
+     </action>
+   </actions>
+</journey>
+```
+
+Evaluate a journey by proceeding through the `<actions>` list in sequential order. Evaluate each `<action>` block individually.
+A journey succeeds if all elements in the `<actions>` list succeed.
+
+A journey is a test case for an app. The journey XML is the source of truth; if the app disagrees with the journey, the app has failed.
+Additionally, if the app exits, crashes, or freezes, journey evaluation stops and the journey fails.
+
+**IMPORTANT** - Execute each step EXACTLY as written, and independently of other steps! If an action says to `"tap the first search result"`,
+you MUST find the search results and tap the first one. Do this even if you believe you know the intent behind the action.
+
+## Taking Actions
+Some `<action>` elements specify UI interactions to perform on the running Android app. Perform the interaction and verify that the app does 
+not crash or behave in an unexpected manner. This is the *only* verification you should perform for an `<action>`.
+
+If the interaction cannot be performed as specified, the journey fails. 
+Example: 
+```<action>Click the red button</action>```
+If you determine a red button is not present in the UI, the journey fails. 
+
+If the text of an `<action>` specifies a list of actions, break it into sub-actions and evaluate them individually: 
+Example:
+```<action>Search for soda and add the first result to the cart</action>```
+This should be evaluated as:
+```
+<action>Search for soda</action>
+<action>Add the first result to the cart</action>
+```
+
+If an `<action>` contains something that is not a specification for a UI interaction, alert the user that the journey is malformed and exit
+early, specifying the error in question.
+
+## Verifying Expectations
+`<action>` elements that begin with "check" or "verify" specify expectations for the current state of the Android app. Determine the current
+state of the app and check if the expectations are met.
+
+Determine the current state of the app by inspecting the current screen of the device without interacting with it.
+Example:
+```<action>Check if "Switch 2" is visible on the screen</action>```
+This requires only inspecting the current screen, not scrolling or interacting. If "Switch 2" is not currently visible, the action fails.
+
+If the expectations are not met, mark the `<action>` as a failure and the journey evaluation ends. A single `<action>` may contain
+multiple expectations.
+Example:
+```<action>Verify that the app is on the Home screen, the Home icon is blue, and the temperature is displayed</action>```
+This `<action>` fails if ANY of the following are false:
+- The app is on the Home screen
+- There is a Home icon, and it is blue
+- A temperature is displayed
+
+## Handling failure 
+When running a journey, evaluate it as a test. Failure is acceptable, and often expected. Proper reporting of failures is the priority.
+
+Keep debugging and troubleshooting to a minimum; assume that tools are showing you the correct output every time. The goal is to determine 
+if the *current* Android app can correctly handle the *current* steps outlined in the journey. Suggestions for bug fixes, clarification, or 
+other improvements should be kept to journey evaluation summary at the end.
+
+## Summarizing
+For each `<action>` you evaluated, output JSON describing the results.
+
+```
+{
+  "journey:", The name of the journey
+  "results:" [
+    {
+      // A string containing the full text of the <action> 
+      "action": "Click the blue button,
+      // "PASSED" if the instruction was evaluated, "FAILED" if the instruction could not be evaluated, or "SKIPPED" if journey evaluation ended early because an instruction failed 
+      "status": "PASSED", 
+      // A list of the ADB commands executed while evaluating the instruction,
+      "commands": [ "adb input swipe 490 200 500 500 500", "adb input tap 45 920" ],  
+      // Failure reasons, feedback, or other useful information 
+      "comment": "The journey step doesn't specify that the button requires scrolling to see", 
+    },
+    {
+      "action": "The home screen is shown", 
+      "status": "FAILED", 
+      "comment": "The settings page was shown",   
+    },
+  ]
+}
+```

package/templates/android-compose/skeleton/agent-env/skills/harness-compose-audit/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: harness-compose-audit
+description: 审计 Android Jetpack Compose 仓库的性能、状态管理、副作用和可组合函数 API 质量。扫描源代码，对每个类别进行 0-10 评分，编写严格的 markdown 报告，并总结最重要的修复建议。在审查 Compose 代码库、评估仓库质量、检查重组/状态问题或运行 Compose 审计时使用。
+allowed-tools: Read, Glob, Grep, Write, Bash, Agent
+argument-hint: "[仓库路径或模块路径]"
+---
+
+# Jetpack Compose 审计
+
+本技能以严格的、基于证据的报告审计 Android Jetpack Compose 仓库。
+
+**评分标准版本：** v1 — 当前版本日期 2026-04-13。Compose 版本：Kotlin 2.0.20+ / Compose Compiler 1.5.4+（强跳过模式默认开启）。
+
+本技能专注于四个类别：
+
+- 性能
+- 状态管理
+- 副作用
+- 可组合函数 API 质量
+
+本技能在 v1 版本中**不**对设计或 Material 3 合规性评分。如果审计发现可能的设计系统问题，建议使用 `material-3` 技能进行后续审计（参考实现：<https://github.com/hamen/material-3-skill>）。
+
+## v1 版本不包含的内容
+
+有意的范围选择 — 在报告中说明限制，而不是默默地提供薄弱的覆盖：
+
+- Material 3 合规性、主题、颜色/排版标记 — 推迟到 `material-3` 技能处理。
+- 无障碍评分（`semantics`、内容描述、触摸目标大小）— 将明显的差距作为注释标出，不评分。
+- UI 测试覆盖率和 Compose 测试规则模式 — 注明存在/不存在，不评分。
+- Compose Multiplatform 特定规则（`expect`/`actual`、目标特定代码路径）。
+- Wear OS / TV / Auto / Glance 界面。
+- 构建性能（增量编译、KSP/KAPT 选择）。
+
+## 何时使用
+
+当用户要求以下内容时使用此技能：
+
+- 审计 Jetpack Compose 仓库
+- 审查 Compose 架构或质量
+- 对代码库进行评分
+- 检查重组、状态或副作用问题
+- 识别现有仓库中的 Compose 最佳实践违规
+
+典型触发短语：
+
+- "审计这个 Compose 仓库"
+- "对这个 Jetpack Compose 代码库评分"
+- "审查状态提升和副作用"
+- "检查 Compose 性能"
+- "评估这个仓库"
+
+## 预期输出
+
+同时生成：
+
+- 一个名为 `COMPOSE-AUDIT-REPORT.md` 的仓库报告文件
+- 一个简短的聊天摘要，包含总分、类别得分、最严重的问题和首要修复建议
+
+## 审计原则
+
+- 严格，但基于证据。
+- 不要仅从搜索命中进行评分。在判断类别之前阅读代表性文件。
+- 在报告中为每个重要的扣分引用具体的文件路径。
+- **为每个扣分引用官方文档 URL。** 评分标准将每条规则映射到 `references/canonical-sources.md` 中的权威来源。报告模板要求每个发现都有 `References:` 行。
+- 优先使用官方 Android 指导而非道听途说。
+- 将性能视为重要，但不是唯一的角度。
+- 不要因为应用代码未通过公共库纯度测试而惩罚它。主要对可复用的内部组件、设计系统片段和共享 UI 构建块应用 API 质量检查。
+- 将 `0-3` 分保留给重复或系统性问题，而非孤立错误。
+- 除非仓库在类别中持续表现强劲，否则不授予 `9-10` 分。
+
+## 流程
+
+### 1. 确认范围
+
+识别目标路径，确认 Compose 确实存在（快速失败）：在 `build.gradle*` 或 `libs.versions.toml` 中 grep `androidx.compose`，在 `src/` 下 grep `setContent {` 或 `@Composable`。
+
+### 2. 映射仓库
+
+在评分之前识别：Gradle 模块、Android 应用和功能模块、Compose 源根目录、共享 UI/组件包、主题或设计系统包、状态持有者或 ViewModel 区域、测试和预览位置。
+
+### 3. 构建 Compose 表面映射
+
+查找 `@Composable` 函数、可复用 UI 组件、屏幕和路由、`ViewModel` 使用、`remember`/`rememberSaveable`/`mutableStateOf`、`collectAsStateWithLifecycle`/`collectAsState`、`LaunchedEffect`/`DisposableEffect`/`SideEffect`、`LazyColumn`/`LazyRow`/`items`。
+
+### 4. 生成 Compose 编译器报告（自动）
+
+**不要**要求用户编辑 `build.gradle` 或自己运行命令。该技能使用捆绑的 Gradle 初始化脚本运行构建：
+
+1. 定位 `scripts/compose-reports.init.gradle`
+2. 检查目标中的 Gradle wrapper
+3. 选择编译目标（优先 `compileReleaseKotlinAndroid`）
+4. 运行构建：`./gradlew <task> --init-script <path> --no-daemon --quiet`（600 秒超时）
+5. 收集报告：`find <target> -path '*/build/compose_audit/*'`
+6. 如果构建失败，回退到源代码推断的稳定性发现，降低置信度
+
+### 5. 审计四个类别
+
+使用 `references/scoring.md` 中的评分标准和 `references/search-playbook.md` 中的启发式方法。
+
+**性能**：组合中的昂贵工作、可避免的重组、懒列表键、错误的状态读取时机、不稳定或过于宽泛的读取、向后写入。
+
+**状态管理**：提升正确性、单一数据源、可复用的无状态接缝、`remember` 与 `rememberSaveable` 的正确使用、生命周期感知的可观察收集。
+
+**副作用**：在组合中错误执行的副作用、正确的副作用 API 选择、副作用键、过期的 lambda 捕获、清理正确性。
+
+**可组合函数 API 质量**：`modifier` 存在性和位置、参数顺序、显式优于隐式配置、有意义的默认值、避免在可复用 API 中使用 `MutableState<T>` 参数。
+
+### 6. 验证发现
+
+在扣分之前阅读问题出现的文件，确保模式是真实的而非误报，区分一次性错误和系统性模式。
+
+### 7. 评分
+
+为每个类别分配 `0-10` 分（0-3 不合格、4-6 需要改进、7-8 良好、9-10 优秀）。
+
+**测量上限是强制性的。** 基于 `skippable%` 和不稳定参数计数定义上限，在报告中显示计算过程。
+
+### 8. 编写报告
+
+使用 `references/report-template.md`。报告必须包含：总分、类别得分表、关键发现、逐类别推理、证据文件路径、优先修复列表。
+
+### 9. 返回简短摘要
+
+包含：总分、每个类别的单行判断、编译器报告亮点、**前三项可操作修复**（具体更改、文件路径和行号、官方文档 URL、预期影响）。
+
+## 证据规则
+
+- 优先使用多个示例而非一个戏剧性示例。
+- 也使用正面证据，不仅仅是失败。
+- 不要推断无法从代码中证明的运行时问题。
+- 当规则基于官方指导但应用级权衡可能证明偏离合理时，将其称为权衡。
+
+## 大型仓库策略
+
+先映射模块，每个模块选择代表性文件，并行化类别扫描，将重复发现合并为系统性问题。
+
+## 应避免的事项
+
+- 不要生成没有仓库证据的通用检查清单。
+- 不要仅因为应用使用 Compose 就虚高性能分数。
+- 不要在 v1 中对设计评分。
+- 不要单独标记 `LaunchedEffect(Unit)` — "运行一次"模式是惯用的。
+- 不要跨类别重复计算相同的根本原因。
+
+## 参考资料
+
+- `references/scoring.md` — 每条规则的评分标准及内联引用
+- `references/search-playbook.md` — 搜索模式和红旗启发式
+- `references/report-template.md` — `COMPOSE-AUDIT-REPORT.md` 的必需结构
+- `references/canonical-sources.md` — 每个扣分必须引用的官方 URL
+- `references/diagnostics.md` — 可复制粘贴的 Gradle/代码片段
+- `scripts/compose-reports.init.gradle` — 自动生成编译器报告的 Gradle 初始化脚本
+
+---
+
+## 必须遵守的约束规则
+
+> rules 引用路径：`../rules/<rule-name>.mdc`
+
+- harness-compose-mandatory
+- harness-mvi-layering
+- harness-coroutines-scope

package/templates/android-compose/skeleton/agent-env/skills/harness-compose-audit/references/canonical-sources.md

@@ -0,0 +1,116 @@
+# Canonical Sources
+
+Use these as the source of truth for v1 scoring and guidance. **Every deduction in the audit report must cite at least one of these URLs** (or one of their officially-linked sub-pages) — see `report-template.md` for the citation format.
+
+## Primary Sources
+
+### Performance
+
+- Android Developers: `Follow best practices`  
+  `https://developer.android.com/develop/ui/compose/performance/bestpractices`
+- Android Developers: `Jetpack Compose Performance`  
+  `https://developer.android.com/develop/ui/compose/performance`
+- Android Developers: `Compose phases`  
+  `https://developer.android.com/develop/ui/compose/performance/phases`
+- Android Developers: `Stability`  
+  `https://developer.android.com/develop/ui/compose/performance/stability`
+- Android Developers: `Diagnose stability problems`  
+  `https://developer.android.com/develop/ui/compose/performance/stability/diagnose`
+- Android Developers: `Fix stability issues`  
+  `https://developer.android.com/develop/ui/compose/performance/stability/fix`
+- Android Developers: `Strong Skipping Mode`  
+  `https://developer.android.com/develop/ui/compose/performance/stability/strongskipping`
+- Android Developers: `Performance tooling` (Compose Compiler reports / metrics)  
+  `https://developer.android.com/develop/ui/compose/performance/tooling`
+- Android Developers: `Baseline profiles`  
+  `https://developer.android.com/develop/ui/compose/performance/baseline-profiles`
+
+These ground:
+
+- `remember` for expensive work
+- lazy list keys
+- `derivedStateOf`
+- deferred state reads
+- lambda modifiers
+- backwards writes
+- stability annotations (`@Stable`, `@Immutable`), `kotlinx.collections.immutable`, `compose_compiler_config.conf`
+- Strong Skipping Mode (default since Kotlin 2.0.20), `@NonSkippableComposable`, `@DontMemoize`
+- Compose Compiler reports / metrics as the primary diagnostic for skippability and stability
+- performance mindset and baseline-profile awareness
+
+### State
+
+- Android Developers: `State and Jetpack Compose`  
+  `https://developer.android.com/develop/ui/compose/state`
+- Android Developers: `State hoisting`  
+  `https://developer.android.com/develop/ui/compose/state-hoisting`
+- Android Developers: `Architecting your Compose UI`  
+  `https://developer.android.com/develop/ui/compose/architecture`
+- Android Developers: `Lists and grids` (lazy keys, `contentType`)  
+  `https://developer.android.com/develop/ui/compose/lists`
+
+These ground:
+
+- state hoisting rules
+- stateful vs stateless composables
+- `remember` vs `rememberSaveable`
+- observable vs non-observable mutable state
+- lifecycle-aware collection of observable state
+- plain state-holder classes
+- ViewModel as screen-level source of truth and the rules around `viewModel()` placement
+- lazy-list `key` and `contentType` semantics
+
+### Side Effects
+
+- Android Developers: `Side-effects in Compose`  
+  `https://developer.android.com/develop/ui/compose/side-effects`
+
+This grounds:
+
+- side-effect-free composition
+- `LaunchedEffect`
+- `DisposableEffect`
+- `SideEffect`
+- `rememberUpdatedState`
+- `produceState`
+- lifecycle-aware effect behavior
+
+### Composable API Quality
+
+- Android Developers: `Style guidelines for Jetpack Compose APIs`  
+  `https://developer.android.com/develop/ui/compose/api-guidelines`
+- AndroidX component guidelines: `API Guidelines for @Composable components in Jetpack Compose`  
+  `https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-component-api-guidelines.md`
+- AndroidX general guidelines: `API Guidelines for Jetpack Compose`  
+  `https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-api-guidelines.md`
+- Android Developers: `Custom modifiers` (`Modifier.Node`, `composed { }` discouraged)  
+  `https://developer.android.com/develop/ui/compose/custom-modifiers`
+- Android Developers: `Locally scoped data with CompositionLocal`  
+  `https://developer.android.com/develop/ui/compose/compositionlocal`
+- Android Developers: `Navigation with Compose`  
+  `https://developer.android.com/develop/ui/compose/navigation`
+
+These ground:
+
+- `modifier` conventions
+- parameter order
+- explicit vs implicit dependencies
+- meaningful defaults
+- component layering
+- avoiding `MutableState<T>` and `State<T>` in reusable APIs when better shapes exist
+- custom modifier authoring with `Modifier.Node` over the discouraged `composed { }` factory
+- when `CompositionLocal` is appropriate (tree-scoped data with sensible defaults) vs when explicit parameters are required
+- navigation patterns and where navigation calls belong
+
+## Supplemental Sources
+
+These are useful for extra examples and ecosystem framing, but they do **not** override the primary sources. Community blog posts age fast — when the supplemental and primary sources disagree, the primary AndroidX/Android docs win:
+
+- `https://github.com/skydoves/compose-performance`
+- `https://medium.com/@idaoskooei/building-better-uis-with-jetpack-compose-best-practices-and-techniques-a1c8953bc5b8`
+
+## Adjacent Skill Pattern
+
+This skill intentionally pairs well with the `material-3` skill, which covers Material 3 design and design-system audit concerns. The reference implementation lives at `https://github.com/hamen/material-3-skill`, but recommend it by skill name (`material-3`) so the reference does not rot if the URL moves.
+
+This Compose audit skill should mention `material-3` as a follow-up when visual or design-system problems are suspected, but should not score design in v1.

package/templates/android-compose/skeleton/agent-env/skills/harness-compose-audit/references/diagnostics.md

@@ -0,0 +1,182 @@
+# Diagnostics
+
+Copy-pasteable Gradle and code snippets the auditor can recommend (or run themselves) to back findings with measured evidence rather than source inference. Every snippet is anchored to an official source — cite the same URL in the report.
+
+## 1. Compose Compiler Reports & Metrics
+
+The single highest-leverage diagnostic. Generates per-composable skippability and per-class stability reports, plus aggregate metrics.
+
+**Reference:** <https://developer.android.com/develop/ui/compose/performance/tooling>, <https://developer.android.com/develop/ui/compose/performance/stability/diagnose>
+
+### Primary path — automatic (what the skill actually does)
+
+The skill ships a Gradle init script at `scripts/compose-reports.init.gradle`. SKILL.md Step 4 runs it against the target without modifying any of the user's files:
+
+```bash
+cd <target> && ./gradlew <compile-task> \
+    --init-script <skill-dir>/scripts/compose-reports.init.gradle \
+    --no-daemon --quiet
+```
+
+The init script targets every module that applies the Compose Compiler plugin and writes reports to each module's `build/compose_audit/` directory. No `build.gradle.kts` edits are required on the target.
+
+### Fallback path — manual edit (only when the init-script flow is blocked)
+
+If the auditor (human or skill) cannot use `--init-script` — for example, a locked-down CI that rejects unknown init scripts — ask the user to add this block to the module's `build.gradle.kts`:
+
+```kotlin
+composeCompiler {
+    reportsDestination = layout.buildDirectory.dir("compose_compiler")
+    metricsDestination = layout.buildDirectory.dir("compose_compiler")
+}
+```
+
+(Requires the Compose Compiler Gradle plugin, default since Kotlin 2.0. On older toolchains use `kotlinOptions.freeCompilerArgs += ["-P", "plugin:androidx.compose.compiler.plugins.kotlin:reportsDestination=..."]`.)
+
+### Reading the output
+
+Run a release-variant build, then inspect:
+
+- `*-classes.txt` — stability inference per class (`stable` / `unstable` / `runtime`)
+- `*-composables.txt` — per-composable `skippable` / `restartable` / `readonly` flags
+- `*-composables.csv` — same data, machine-readable
+- `*-module.json` — aggregate counts
+
+**Use in the audit:** when a Performance or State finding alleges an unstable param or non-skippable composable, cite the relevant line of `*-classes.txt` or `*-composables.txt`. Without these reports, stability claims are *inferred* — say so explicitly in the report's Notes And Limits.
+
+## 2. `compose_compiler_config.conf` — Marking Third-Party Types Stable
+
+When unstable types come from modules without the Compose compiler (e.g. third-party data classes), mark them stable from outside.
+
+**Reference:** <https://developer.android.com/develop/ui/compose/performance/stability/fix>
+
+Create `compose_compiler_config.conf` at the project root (one fully-qualified class per line, glob patterns allowed):
+
+```conf
+# Mark third-party types stable so Compose can skip composables that take them
+com.example.thirdparty.Money
+com.example.thirdparty.User
+com.example.thirdparty.events.*
+java.time.*
+```
+
+Wire it into the module's `build.gradle.kts`:
+
+```kotlin
+composeCompiler {
+    stabilityConfigurationFiles.add(
+        rootProject.layout.projectDirectory.file("compose_compiler_config.conf")
+    )
+}
+```
+
+**Use in the audit:** if a project consumes third-party types in widely reused composables and skipping is broken, recommend a stability config file before recommending wrapper UI models.
+
+## 3. Baseline Profile Module Skeleton
+
+Improves cold start and frame timing by precompiling hot paths. The presence of a baseline profile module + `ProfileInstaller` in the consumer is a positive Performance signal.
+
+**Reference:** <https://developer.android.com/develop/ui/compose/performance/baseline-profiles>, <https://developer.android.com/topic/performance/baselineprofiles/overview>
+
+Module `:baselineprofile` (a `com.android.test` module) `build.gradle.kts`:
+
+```kotlin
+plugins {
+    id("com.android.test")
+    id("org.jetbrains.kotlin.android")
+    id("androidx.baselineprofile")
+}
+
+android {
+    targetProjectPath = ":app"
+    defaultConfig { minSdk = 28 }
+}
+
+dependencies {
+    implementation("androidx.test.ext:junit:1.2.1")
+    implementation("androidx.test.uiautomator:uiautomator:2.3.0")
+    implementation("androidx.benchmark:benchmark-macro-junit4:1.3.4")
+}
+```
+
+Generator class:
+
+```kotlin
+@RunWith(AndroidJUnit4::class)
+class BaselineProfileGenerator {
+    @get:Rule val rule = BaselineProfileRule()
+
+    @Test
+    fun generate() = rule.collect(packageName = "com.example.app") {
+        startActivityAndWait()
+        // exercise the user-critical journey
+    }
+}
+```
+
+In the consumer (`:app`):
+
+```kotlin
+plugins {
+    id("androidx.baselineprofile")
+}
+
+dependencies {
+    "baselineProfile"(project(":baselineprofile"))
+    implementation("androidx.profileinstaller:profileinstaller:1.4.1")
+}
+```
+
+**Use in the audit:** check for a `baseline-prof.txt` artifact and a `ProfileInstaller` initializer. Their absence on a mature app is worth flagging; their presence is positive evidence.
+
+## 4. R8 / Minify Hygiene
+
+Compose performance assumes release-mode R8. Debug builds run unoptimized — never benchmark them.
+
+**Reference:** <https://developer.android.com/develop/ui/compose/performance> ("Run in Release Mode with R8")
+
+In `:app/build.gradle.kts`:
+
+```kotlin
+android {
+    buildTypes {
+        release {
+            isMinifyEnabled = true
+            isShrinkResources = true
+            proguardFiles(
+                getDefaultProguardFile("proguard-android-optimize.txt"),
+                "proguard-rules.pro",
+            )
+        }
+    }
+}
+```
+
+**Use in the audit:** quick grep — `rg -n 'isMinifyEnabled' -g '*.gradle*'`. If the release block has `isMinifyEnabled = false`, that's a release-hygiene deduction on its own.
+
+## 5. Strong Skipping Mode Confirmation
+
+Strong Skipping is on by default at Kotlin 2.0.20+. Below that, stability matters more aggressively and the rubric should weight unstable-param findings higher.
+
+**Reference:** <https://developer.android.com/develop/ui/compose/performance/stability/strongskipping>
+
+Confirm the project's Kotlin version:
+
+```bash
+rg -n 'kotlin\s*=\s*"' -g '*.toml'
+rg -n 'org\.jetbrains\.kotlin' -g '*.gradle*'
+```
+
+If the project explicitly opts a module *out* of Strong Skipping, look for `enableStrongSkippingMode = false` in any `composeCompiler { ... }` block — flag and require justification.
+
+## 6. Quick Triage Recipe
+
+When you arrive at a Compose repo, run these in order before scoring:
+
+1. `rg -n 'androidx\.compose' -g '*.gradle*' -g '*.toml'` — confirm Compose presence (fast-fail).
+2. `rg -n 'kotlin\s*=\s*"' -g '*.toml'` — record Kotlin version (Strong Skipping baseline).
+3. `rg -n 'isMinifyEnabled' -g '*.gradle*'` — release hygiene.
+4. Run Step 4 of SKILL.md — the init script generates compiler reports automatically. If the build fails, read any existing `composeCompiler { reportsDestination ... }` output the project already produces; otherwise note the fallback in the report.
+5. `rg -l 'baselineProfile|ProfileInstaller' -g '*.gradle*' -g '*.kt'` — baseline-profile presence.
+
+These five greps tell you what kind of evidence is available before any rubric-level reading.