Question 1

How would you prepare an existing Android project for working with an agent?

Accepted Answer

Give a sequence and the why for each step: 1. Start with /init, then edit. The generated file is raw material — strip out what the agent can see anyway, like the directory listing. 2. Pin down the build commands. The biggest impact is here. Write a module-level table. 3. Set up permission rules. Everyday commands in allow (to cut prompts), signing keys and local.properties in deny. 4. Write the architecture rules — module boundaries, DI, state management. The things the agent breaks most often. 5. Verify — ask questions without having it write code. 6. Iterate — anything you correct twice belongs in CLAUDE.md. End with the important point: this is not one-off work. The setup is a living document that grows with the team's experience. The best signal is repeated corrections — collect them.

Question 2

In a large Android monorepo the agent doesn't focus on the right module. What do you do?

Accepted Answer

Frame it as a context problem, then fix it in layers: 1. At the task level — name the module. Not "on the orders screen" but "in the feature/orders/ module". 2. Module-level CLAUDE.md — each module gets its own instruction file. These load only when the agent works with files in that folder, so other teams' rules don't bloat your context. 3. Module-level skills — a .claude/skills/ folder inside the module. 4. Shorten the root file — only rules that apply to everyone. A long root file adds noise for every module. 5. Start the session in the module — run claude from the module directory, or move with /cd. End with a measurement: ask the agent "which modules will you look at for this task?". A wrong answer shows immediately which layer isn't working.

Question 3

Which Android-specific prohibitions belong in CLAUDE.md?

Accepted Answer

Choose prohibitions by a criterion: things the agent breaks repeatedly and that are expensive to undo. A typical list: "Don't add new XML layouts" — in a project moving to Compose the agent can fall back to the old pattern. "Don't change libs.versions.toml without asking" — a version bump affects the whole project. "Don't touch legacy/" — it has its own plan. "Don't add new dependencies" (or "ask first") — every library is APK size, licensing and a maintenance commitment. "Don't add permissions to AndroidManifest.xml" — privacy and store requirements apply. "Don't change ProGuard rules without asking" — mistakes only surface in release builds. Then add the nuance that matters: these are guidance, not technical gates. When real blocking is needed, use permissions.deny, a hook or a CI gate. Checking manifest changes in CI is more reliable than a line in CLAUDE.md.

Android-specific problem	Fix in CLAUDE.md
A full build takes minutes; the agent waits every iteration	Spell out the narrow module-level commands
The agent doesn't see the version catalog and guesses APIs	"Check `libs.versions.toml` before adding a dependency"
It writes a new screen in XML	"New UI is always Compose; do not add new XML layouts"
Hardcoded strings	"Every user-visible string lives in `strings.xml`"
It touches legacy code	"Don't touch `legacy/` — it has its own migration plan"
It breaks module boundaries	"`ui/` never depends on `data/` directly"

Preparing an Android project for the agent

📚 Sources and documentation