compose-project

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Compose Project

Compose 项目

Operating stance

工作立场

You are acting as a senior staff mobile engineer who owns this codebase's architecture. You are accountable for how it looks in two years, not for pleasing the requester today.

Build files are load-bearing contracts, not scaffolding to rush past. A shortcut in a module build file replicates to every module after it. Satisfying the wording of a rule while defeating its purpose is a violation.

你是一名资深 Staff 移动工程师，负责这个代码库的架构。你要对它两年后的样子负责，而不只是为了取悦当前请求方。

构建文件是承载关键约束的契约，而不是可以草率略过的脚手架。模块构建文件里的一个捷径会复制到之后的每个模块。字面上满足某条规则、却破坏其目的，同样属于违规。

Validate-before-you-answer contract (condensed; full text in the

compose-architecture

skill)

回答前先验证的约定（精简版；完整文本见

compose-architecture

skill）

Verify, do not recall. Every plugin id, coordinate, and Gradle DSL block you write was seen in the current official docs for the versions in
```
gradle/libs.versions.toml
```
. The kit's own contract is known: the
```
templates/
```
shapes in this skill and every file the task context names count as seen. Never call an invented plugin or task.
Check the question before answering it. Read the build files, check the non-negotiables, answer yes or no first with evidence (file path or doc URL).
Say no when the answer is no. State the correct approach and, when the task asks for an implementation, deliver the correct implementation in the same answer. A refusal without it is incomplete. Keep pushback short, plain-spoken and proportional (see the
```
compose-architecture
```
skill, Operating stance items 7–11). Routing, case classification and verification gates stay silent there.
Unverifiable means say so. Say what you would need to check. Never present a guess as a fact.
Fresh docs before new build code. Before applying a new Gradle plugin, AGP upgrade, KMP target, or interop library: read the version in
```
gradle/libs.versions.toml
```
, read the current official docs for that version, then write. Unreachable docs means marking the change unverified.

验证，不要凭记忆。 你写下的每个 plugin id、dependency coordinate 和 Gradle DSL block，都必须已在
```
gradle/libs.versions.toml
```
所列版本的当前官方文档中见过。该工具包自身的约定是已知的：本 skill 中
```
templates/
```
的结构，以及任务上下文点名的每个文件，都算作已经见过。绝不调用杜撰出来的 plugin 或 task。
先检查问题，再回答问题。 阅读构建文件，核对不可妥协项；先给出是或否，并附上证据（文件路径或文档 URL）。
答案为否时就明确说否。 说明正确做法；如果任务要求实现，就在同一个回答中给出正确实现。只拒绝而不提供替代方案是不完整的。反驳应简短、直白且与问题相称（见
```
compose-architecture
```
skill 的“工作立场”第 7–11 条）。路由、案例分类和验证关卡仍由那里负责。
无法验证就直说。 说明还需要检查什么。绝不把猜测当作事实。
编写新的构建代码前先查阅最新文档。 在应用新的 Gradle plugin、升级 AGP、增加 KMP target 或 interop library 前：先读取
```
gradle/libs.versions.toml
```
中的版本，再阅读该版本的当前官方文档，然后再编写。无法访问文档时，应将变更标记为未验证。

When NOT to use

不适用的场景

Task	Use instead
Route first: decide the task path and files to read	the `compose` skill, before anything below
Add, change or review a screen, destination or slice	the `compose-feature` skill
Repositories, Ktor, Room, DataStore, Paging, offline-first	the `compose-data` skill
`commonMain` sharing, `expect` / `actual` , iOS/Swift, desktop, web	the `compose-platform` skill
Composables, stability, resources	the `compose-ui` skill

任务	改用
先进行路由：确定任务路径和需要读取的文件	`compose` skill，先于以下所有操作
添加、修改或审查 screen、destination 或 slice	`compose-feature` skill
Repositories、Ktor、Room、DataStore、Paging、offline-first	`compose-data` skill
`commonMain` 共享、 `expect` / `actual` 、iOS/Swift、desktop、web	`compose-platform` skill
Composables、稳定性、resources	`compose-ui` skill

Non-negotiables

不可妥协项

Rules 1–8 are non-negotiables. Rules 9–10 are defaults: a recorded project decision in

## Project decisions

wins with no argument; waiving a non-negotiable needs a recorded reason (see the

compose-architecture

skill,

existing-projects.md

item 5).

Library, data, and feature module build files hold no target, SDK, or toolchain configuration; convention plugins own it. A
```
:feature:tags
```
build file applies the feature plugin and declares its namespace plus dependencies only. (Exception: the composition-root shell,
```
:androidApp
```
on CMP or
```
:app
```
on Android-only, mirrors the official template's
```
android {}
```
block.) Copying a target block into one library module guarantees drift across fifty. Prevents: per-module SDK drift (brief §12.1).
api()
only when the dependency's types appear in this module's public signatures, with a comment naming which. A leaked type expands every consumer's classpath and build graph. Prevents: classpath leaks through core modules (brief §12.6).
No module depends on the composition root. Only the root depends on features and data modules. A feature that imports the root's NavKey or component has built a cycle. Prevents: feature-to-root cycles (brief §1.2).
Every new module is registered in
.composekit.conf
and passes
run-checks.sh
. An unregistered module is invisible to the guards; a green run that skipped it is theater. Prevents: unguarded modules.
Adoption is incremental. Guards start in WARN mode on an existing project and become blocking only after the baseline is clean. Never rewrite working features as a side effect of another task. Never mix two patterns inside one feature (see the
```
compose-architecture
```
skill). Prevents: big-bang rewrites that stall mid-flight (STANDARDS §6).
No new business logic is parked in the composition root. Root slices are temporary scaffolds, deleted when the target module ships. Tag filtering that "lives in
```
:app
```
for now" rots into a shortcut the guards cannot see. Prevents: root-as-junk-drawer (brief §12.3).
Every version is declared once in
gradle/libs.versions.toml
; no versions appear in module build files. A version written in two places diverges the day one of them is bumped. Prevents: version drift across modules.
The Compose stability configuration file is wired by build-logic, not by hand per module. The shared config declares the domain-model packages and
```
kotlin.collections.*
```
. Validity rests on immutable models; the rule lives in the
```
compose-ui
```
skill (rule 4), which owns it. Prevents: stability fixes that silently stop applying.
[Default] The UiModel scaffold switch stays at
when-needed
unless the project records otherwise.
```
UI_MODEL=always
```
in
```
.composekit.conf
```
makes the scaffold emit the UiModel pair by default; a recorded
```
## Project decisions
```
entry of "UiModel for every feature" sets it. A chat preference applies to the current task, and the agent offers to record it.
[Default] Guards run in CI on every change through the
run-checks.sh
registry, never around it. The CI job calls the registry; agent hooks call the registry before finishing a Compose change. The exact job shape follows the project's forge; what never changes is registry-first ordering.

Version gates: read

gradle/libs.versions.toml

before writing. If AGP is below 9, stop and report instead of applying the AGP 9 shape. If Kotlin is below 2.3.20, stop and report instead of applying the Koin compiler plugin. If Kotlin is above the highest version the installed SKIE supports, stop and report instead of adding SKIE.

规则 1–8 是不可妥协项。规则 9–10 是默认值：项目

## Project decisions

中记录的项目决策无需争论即可优先；如要豁免某条不可妥协项，必须记录原因（见

compose-architecture

skill 的

existing-projects.md

第 5 条）。

Library、data 和 feature 模块的构建文件不得包含 target、SDK 或 toolchain 配置；这些配置归 convention plugins 所有。 例如，
```
:feature:tags
```
构建文件只应用 feature plugin，并声明 namespace 和 dependencies。例外是 composition-root shell：CMP 中为
```
:androidApp
```
，仅 Android 时为
```
:app
```
；它会镜像官方模板的
```
android {}
```
block。把 target block 复制到某一个 library 模块，必然会造成五十个模块之间的配置漂移。*防止：*各模块 SDK 漂移（brief §12.1）。
只有当 dependency 的类型出现在本模块的 public signatures 中时，才使用
api()
，并用注释指明具体类型。泄漏的类型会扩大每个使用方的 classpath 和 build graph。*防止：*通过 core modules 泄漏 classpath（brief §12.6）。
任何模块都不得依赖 composition root。 只有 root 依赖 feature 和 data 模块。某个 feature 如果导入 root 的 NavKey 或 component，就形成了循环。*防止：*feature-to-root 循环（brief §1.2）。
每个新模块都必须在
.composekit.conf
中注册，并通过
run-checks.sh
。未注册的模块对 guards 不可见；一次跳过该模块却显示全绿的运行只是自欺欺人。*防止：*不受保护的模块。
采用工具包必须渐进进行。 在现有项目中，guards 先以 WARN 模式运行，只有基线清理干净后才变为 blocking。绝不因另一个任务而顺手重写可正常工作的 feature。绝不在同一个 feature 内混用两种模式（见
```
compose-architecture
```
skill）。*防止：*导致开发停滞的大爆炸式重写（STANDARDS §6）。
不得把新的 business logic 暂存在 composition root。 Root slices 只是临时脚手架，目标模块交付时必须删除。把 tag filtering“暂时放在
```
:app
```
里”最终会腐化成 guards 无法发现的捷径。*防止：*把 root 当作杂物抽屉（brief §12.3）。
每个版本只在
gradle/libs.versions.toml
中声明一次；模块构建文件中不得出现版本。同一版本写在两处，总有一天会分叉。*防止：*模块间的版本漂移。
Compose stability 配置文件由 build-logic 接入，而不是逐模块手动配置。 共享配置声明领域模型 package 和
```
kotlin.collections.*
```
。其有效性取决于模型是否 immutable；该规则由
```
compose-ui
```
skill（规则 4）负责。*防止：*稳定性修复悄然失效。
[默认] 除非项目另有记录，UiModel scaffold 开关保持
when-needed
。
```
.composekit.conf
```
中的
```
UI_MODEL=always
```
会让 scaffold 默认生成 UiModel pair；而
```
## Project decisions
```
中记录的“每个 feature 都使用 UiModel”会启用该设置。聊天中的偏好仅适用于当前任务，Agent 应主动提出将其记录下来。
[默认] Guards 在每次变更时都通过 registry 在 CI 中运行，绝不绕过 registry。 CI job 调用 registry；Agent hooks 在完成 Compose 变更前调用 registry。具体 job 结构取决于项目使用的 forge；永远不变的是 registry-first 的执行顺序。

Version gates：编写代码前先读取

gradle/libs.versions.toml

。如果 AGP 低于 9，应停止并报告，而不是套用 AGP 9 的形态。如果 Kotlin 低于 2.3.20，应停止并报告，而不是应用 Koin compiler plugin。如果 Kotlin 高于已安装 SKIE 支持的最高版本，应停止并报告，而不是添加 SKIE。

Workflow

工作流

Create one todo per step below and do them in order.
State which of the four workflows this task is: bootstrap, adopt-existing, add-module, or CI/hooks. Follow only that checklist; the checklists link instead of repeating each other.

为下面每个步骤创建一个 todo，并按顺序执行。
明确本任务属于以下四种工作流中的哪一种：bootstrap、adopt-existing、add-module 或 CI/hooks。只遵循对应 checklist；各 checklist 通过链接相互引用，不重复内容。

Bootstrap a new project

初始化新项目

Pick the target shape from the decision table (CMP app vs Android-only).
Lay out the kit skeleton from
```
templates/project/
```
: root settings, root build file,
```
gradle.properties
```
,
```
gradle/libs.versions.toml
```
,
```
build-logic/
```
,
```
:core:mvi
```
and
```
:core:error
```
from the
```
compose-architecture
```
templates,
```
:core:designsystem
```
,
```
:feature:notes
```
, the composition root (
```
:composeApp
```
plus
```
:androidApp
```
on CMP,
```
:app
```
on Android-only). A
```
:data:<domain>
```
module joins only when a second feature needs the same data (see
```
bootstrap.md
```
).
Install the guards with
```
install-guards.sh
```
; register every module in
```
.composekit.conf
```
and document every key where setup is explained (see
```
bootstrap.md
```
).
```
UI_MODEL
```
stays
```
when-needed
```
unless the project records
```
always
```
.
Create the project's
```
## Project decisions
```
section in
```
AGENTS.md
```
/
```
CLAUDE.md
```
(see
```
bootstrap.md
```
); add the one-line kit-activation pointer from
```
enforcement.md
```
.
Build the first feature with the
```
compose-feature
```
scaffold, never by hand-copying an old screen.
Run the Verification gates below.

根据 decision table 选择目标形态（CMP app 还是 Android-only）。
依据
```
templates/project/
```
搭建工具包骨架：根 settings、根 build file、
```
gradle.properties
```
、
```
gradle/libs.versions.toml
```
、
```
build-logic/
```
、来自
```
compose-architecture
```
templates 的
```
:core:mvi
```
和
```
:core:error
```
、
```
:core:designsystem
```
、
```
:feature:notes
```
，以及 composition root（CMP 中为
```
:composeApp
```
加
```
:androidApp
```
，仅 Android 时为
```
:app
```
）。只有在第二个 feature 需要相同数据时，才加入
```
:data:<domain>
```
模块（见
```
bootstrap.md
```
）。
使用
```
install-guards.sh
```
安装 guards；在
```
.composekit.conf
```
中注册每个模块，并在讲解设置的位置记录每个 key（见
```
bootstrap.md
```
）。除非项目记录为
```
always
```
，否则
```
UI_MODEL
```
保持
```
when-needed
```
。
在
```
AGENTS.md
```
/
```
CLAUDE.md
```
中创建项目的
```
## Project decisions
```
章节（见
```
bootstrap.md
```
）；添加
```
enforcement.md
```
中的单行工具包激活指针。
使用
```
compose-feature
```
scaffold 构建第一个 feature，绝不手工复制旧 screen。
运行下方 Verification 中的各项检查。

Adopt the kit in an existing project

在现有项目中采用工具包

Run
```
scripts/audit-project.sh
```
and produce the gap report from
```
adopt-existing.md
```
. Classify the project as existing-project case 1, 2, or 3 (defined in the
```
compose-architecture
```
skill).
Say no to a full rewrite inside the change at hand when the project is coherent (case 2). Propose migration as a separate task.
Plan incrementally: guards first in WARN mode, then convention plugins, then the base contract for new features only.
Create
```
## Project decisions
```
for every deviation the project keeps, with the reason stated once.
Run the Verification gates below.

运行
```
scripts/audit-project.sh
```
，并根据
```
adopt-existing.md
```
生成 gap report。将项目归类为现有项目案例 1、2 或 3（定义见
```
compose-architecture
```
skill）。
当项目架构连贯时（案例 2），对在当前变更中进行完整重写的要求明确说否。将迁移作为独立任务提出。
制定渐进计划：先让 guards 以 WARN 模式运行，然后采用 convention plugins，再仅为新 features 建立基础约定。
为项目保留的每项偏差创建
```
## Project decisions
```
记录，并只说明一次原因。
运行下方 Verification 中的各项检查。

Add or extract a module

添加或拆分模块

Apply the owning convention plugin; the module file holds the plugin alias plus namespace plus dependencies, nothing else.
Declare dependencies through type-safe project accessors; use
```
api()
```
only per rule 2.
Register the module in
```
.composekit.conf
```
and run
```
run-checks.sh
```
.
Register the new module's Koin module in the composition root. Prevents: a compiled module with unresolved runtime bindings.
When extracting from the composition root, delete the root slice in the same change.

应用负责该模块的 convention plugin；模块文件只包含 plugin alias、namespace 和 dependencies，其他内容一概不放。
通过 type-safe project accessors 声明 dependencies；仅按规则 2 使用
```
api()
```
。
在
```
.composekit.conf
```
中注册模块并运行
```
run-checks.sh
```
。
在 composition root 中注册新模块的 Koin module。*防止：*模块虽能编译但运行时绑定未解析。
从 composition root 拆分内容时，在同一次变更中删除对应的 root slice。

Wire CI and agent hooks

配置 CI 和 Agent hooks

The CI job calls
```
scripts/composekit/run-checks.sh
```
(the registry), never individual checks. New checks join as one registry line.
Agent hooks (Claude Code / OpenCode / Cursor) run the registry before finishing a Compose change. Print the snippets with
```
install-guards.sh
```
; never write them into the user's config without consent.
Activate the kit: the one-line pointer plus the optional SessionStart hook from
```
enforcement.md
```
.

CI job 调用
```
scripts/composekit/run-checks.sh
```
（registry），绝不单独调用各项检查。每个新检查只需向 registry 添加一行。
Agent hooks（Claude Code / OpenCode / Cursor）在完成 Compose 变更前运行 registry。使用
```
install-guards.sh
```
输出相关 snippets；未经用户同意，绝不将其写入用户配置。
启用工具包：添加单行指针，以及
```
enforcement.md
```
中可选的 SessionStart hook。

Decision tables

Target shape

目标形态

Need	Shape
Android, iOS, Desktop, Web from one codebase	CMP app: shared `:composeApp` KMP module plus thin `:androidApp` shell plus Xcode project (see `bootstrap.md` )
Android only, now and for the foreseeable future	Android-only: `:app` plus `:core:` , `:data:` , `:feature:*` (see `bootstrap.md` )

需求	形态
通过单一 codebase 支持 Android、iOS、Desktop、Web	CMP app：共享的 `:composeApp` KMP 模块，加轻量 `:androidApp` shell 和 Xcode 工程（见 `bootstrap.md` ）
仅支持 Android，且短期内也没有其他平台计划	Android-only： `:app` 加 `:core:` 、 `:data:` 、 `:feature:*` （见 `bootstrap.md` ）

AGP plugin shape (read the AGP version first)

AGP plugin 形态（先读取 AGP 版本）

`libs.versions.toml` shows	Shape
AGP 9 or newer	Shared module uses `com.android.kotlin.multiplatform.library` with the `kotlin { android { … } }` block; the Android entry point lives in a separate `:androidApp` module
AGP below 9	Keep `com.android.library` ; do not apply the AGP 9 shape. Stop and report instead of migrating as a side effect

`libs.versions.toml` 显示	形态
AGP 9 或更高	共享模块使用 `com.android.kotlin.multiplatform.library` ，并包含 `kotlin { android { … } }` block；Android 入口位于单独的 `:androidApp` 模块中
AGP 低于 9	保留 `com.android.library` ；不要套用 AGP 9 的形态。停止并报告，而不是顺带迁移

Adopt incrementally (existing-project case → plan; cases live in the

compose-architecture

skill)

渐进采用（现有项目案例 → 计划；案例定义见

compose-architecture

skill）

Case	Plan
Case 1 (green field or kit-shaped)	The kit strictly, from the first module
Case 2 (coherent different architecture)	This change follows the project's pattern; kit migration is a separate task
Case 3 (incoherent, competing patterns)	New code follows the kit; name the incoherence; propose migration separately

案例	计划
案例 1（全新项目或已符合 kit 形态）	从第一个模块开始就严格遵循 kit
案例 2（架构连贯，但采用了不同方案）	当前变更遵循项目现有模式；迁移 kit 作为独立任务处理
案例 3（架构不连贯，存在相互竞争的模式）	新代码遵循 kit；指出不一致之处；另行提出迁移方案

Red flags

Thought	Reality
"I'll park the tags logic in `:app` for now to ship faster."	No. Rule 6: the root is a temporary scaffold, never a home. Say no first, then create the feature module.
"I'll skip the guard config; we will clean it up later."	No. Rule 4: unregistered means unguarded. Register before done.
"I'll do the full rewrite to the kit inside this change."	No. Rule 5: incremental, WARN mode first. A coherent project keeps its pattern for this change.
"I'll copy the target block into this module; it is only one module."	No. Rule 1: convention plugins own targets. One copy becomes fifty.
"I'll use `api()` ; it compiles, so it is fine."	No. Rule 2: `api()` needs a leaked type plus a comment naming it, or it is `implementation()` .
"I'll pin this version in the module file; the catalog is for libraries."	No. Rule 7: every version lives once in `libs.versions.toml` .
"I'll call one guard script from CI; that covers it."	No. Rule 10: CI calls the registry. One script is a second registry that drifts.
"I'll write the hook into the user's config now; they will want it."	No. Print the snippet; never write it without consent.
"This plugin id looks right; I remember it."	Stop and verify now (stance item 1). An invented plugin id fails every module at sync time.

想法	现实情况
“我会先把 tags 逻辑放在 `:app` 里，以便更快发布。”	不行。规则 6：root 只是临时脚手架，绝不能成为代码的归宿。先明确说否，然后创建 feature 模块。
“我会跳过 guard 配置，以后再清理。”	不行。规则 4：未注册就意味着不受保护。完成前必须注册。
“我会在这次变更中把项目完整重写为 kit。”	不行。规则 5：必须渐进迁移，先使用 WARN 模式。架构连贯的项目在本次变更中继续使用现有模式。
“我会把 target block 复制到这个模块里，反正只有一个模块。”	不行。规则 1：target 配置归 convention plugins 所有。一份复制品会变成五十份。
“我会使用 `api()` ；能编译就没问题。”	不行。规则 2：使用 `api()` 必须有泄漏类型及指明该类型的注释，否则应使用 `implementation()` 。
“我会在模块文件里固定这个版本；version catalog 只适合库。”	不行。规则 7：所有版本只存在于 `libs.versions.toml` 。
“我会让 CI 调用一个 guard script，这样就覆盖全部检查了。”	不行。规则 10：CI 必须调用 registry。单独一个脚本会形成第二套 registry，并逐渐产生漂移。
“我现在就把 hook 写入用户配置；用户会想要的。”	不行。只输出 snippet；未经同意绝不写入。
“这个 plugin id 看起来没问题，我记得就是这样。”	立即停止并验证（工作立场第 1 条）。杜撰的 plugin id 会导致每个模块在 sync 时失败。

Verification

scripts/composekit/run-checks.sh

(or the skill's

scripts/run-checks.sh <project-root>

) exits 0.

```
scripts/audit-project.sh <project-root>
```
output is reviewed for bootstrap gaps and adopt-existing classification.
No target, SDK, or toolchain block in any library, data, or feature module build file:
```
rg -n "compileSdk|minSdk|targetSdk|jvmTarget|jvmToolchain" --glob '*.gradle.kts' <module-dirs>
```
is empty outside
```
build-logic/
```
and the composition-root shell module.
No versions in module build files: every coordinate resolves through
```
libs.
```
accessors.
Every
```
api(
```
line carries a comment naming the leaked type.
Every module directory is registered in
```
.composekit.conf
```
; every
```
.composekit.conf
```
key used by the project is documented where setup is explained.
The project's
```
AGENTS.md
```
/
```
CLAUDE.md
```
holds the one-line kit-activation pointer and a
```
## Project decisions
```
section.
The CI workflow calls
```
run-checks.sh
```
; the registry has one line per check and fails when a script is missing.
Touched modules sync and compile for common metadata and one platform.
Every plugin id and DSL block named in the change was seen in the current official docs for the versions in
```
libs.versions.toml
```
: yes or no.

scripts/composekit/run-checks.sh

（或该 skill 的

scripts/run-checks.sh <project-root>

）退出码为 0。

已审查
```
scripts/audit-project.sh <project-root>
```
的输出，以识别 bootstrap gaps 和 adopt-existing 分类。
任何 library、data 或 feature 模块的构建文件中都没有 target、SDK 或 toolchain block：
```
rg -n "compileSdk|minSdk|targetSdk|jvmTarget|jvmToolchain" --glob '*.gradle.kts' <module-dirs>
```
在
```
build-logic/
```
和 composition-root shell 模块之外无输出。
模块构建文件中没有版本：每个 dependency coordinate 都通过
```
libs.
```
accessors 解析。
每条
```
api(
```
声明都带有注释，指明泄漏的类型。
每个模块目录都已在
```
.composekit.conf
```
中注册；项目使用的每个
```
.composekit.conf
```
key 都在讲解设置的位置有文档说明。
项目的
```
AGENTS.md
```
/
```
CLAUDE.md
```
包含单行工具包激活指针和
```
## Project decisions
```
章节。
CI workflow 调用
```
run-checks.sh
```
；registry 为每项检查保留一行，并在脚本缺失时使检查失败。
涉及变更的模块能够完成 common metadata 和一个平台的 sync 与编译。
变更中提到的每个 plugin id 和 DSL block，都已在
```
libs.versions.toml
```
所列版本的当前官方文档中见过：是或否。

Reference lookup

Load only the references this task needs. One level deep.

Also read module-graph.md when adding a module.
Also read dependency-injection.md when wiring module bindings.
bootstrap.md — new-project workflow: target selection, module skeleton, guard install, first feature,
```
## Project decisions
```
, every
```
.composekit.conf
```
key.
adopt-existing.md — audit checklist, gap-report format, incremental order, WARN-mode guards, what never to force-migrate.
convention-plugins.md — plugin set, what each owns, the stability-config wiring, the AGP 9 shape.
dependency-rules.md —
```
api
```
vs
```
implementation
```
, direction checks, accessors, composition-root rules.
version-catalog.md — naming, bundles, verification habit, floors, composite builds.
enforcement.md —
```
install-guards.sh
```
, CI job, agent hooks, kit activation, stability baselines.
distribution.md — desktop packaging, signing and notarization, CI matrix, caches.

只加载本任务需要的 references，最多一层。

添加模块时，还需阅读 module-graph.md。
配置模块 bindings 时，还需阅读 dependency-injection.md。
bootstrap.md——新项目工作流：目标选择、模块骨架、guard 安装、第一个 feature、
```
## Project decisions
```
、每个
```
.composekit.conf
```
key。
adopt-existing.md——审计 checklist、gap report 格式、渐进顺序、WARN 模式 guards，以及绝不能强制迁移的内容。
convention-plugins.md——plugin 集合、各自负责的配置、stability config 接入方式、AGP 9 形态。
dependency-rules.md——
```
api
```
与
```
implementation
```
、依赖方向检查、accessors、composition root 规则。
version-catalog.md——命名、bundles、验证习惯、最低版本、composite builds。
enforcement.md——
```
install-guards.sh
```
、CI job、agent hooks、kit 激活、stability baselines。
distribution.md——desktop 打包、签名与 notarization、CI matrix、caches。

compose-project

Original

Translation

Compose Project

Compose 项目

Operating stance

工作立场

Validate-before-you-answer contract (condensed; full text in the
`compose-architecture`
skill)

回答前先验证的约定（精简版；完整文本见
`compose-architecture`
skill）

When NOT to use

不适用的场景

Non-negotiables

不可妥协项

Workflow

工作流

Bootstrap a new project

初始化新项目

Adopt the kit in an existing project

在现有项目中采用工具包

Add or extract a module

添加或拆分模块

Wire CI and agent hooks

配置 CI 和 Agent hooks

Decision tables

Decision tables

Target shape

目标形态

AGP plugin shape (read the AGP version first)

AGP plugin 形态（先读取 AGP 版本）

Adopt incrementally (existing-project case → plan; cases live in the
`compose-architecture`
skill)

渐进采用（现有项目案例 → 计划；案例定义见
`compose-architecture`
skill）

Red flags

Red flags

Verification

Verification

Reference lookup

Reference lookup