These instructions apply to the whole repository. Keep this file focused on repository-wide
operating policy; keep task-specific procedures in the skills under .agents/skills/.
- Read PROJECT.md before making a non-trivial change.
- Use every discovered skill whose description matches the task.
- Treat each skill's frontmatter description as the routing source of truth.
- Read the affected implementation, nearby tests, and relevant build configuration before editing.
Use all matching skills. The links are an index; each frontmatter description defines its scope:
Combine skills only when their scopes overlap:
- Kotlin in plugin or build logic normally requires both
kotlin-engineerandgradle-engineer. - Any behavioral change requires
test-engineerwith the owning implementation skill. - Security work requires
security-engineerandtest-engineer, plus the skill responsible for the affected implementation. - Documentation and public API text require
writerplus the skill owning the contract. - Review uses
reviewerplus matching specialist skills; the reviewer remains read-only.
- Preserve unrelated local changes and untracked files.
- Keep changes narrowly scoped. Do not combine opportunistic cleanup with the requested work.
- Ask a question only when an unresolved decision would materially change the result.
- Do not commit, push, tag, merge, rebase, cherry-pick, reply to review threads, or resolve threads unless the user's current request explicitly asks for that action.
- Do not publish plugins, change release versions, or use credentials unless explicitly asked.
- Do not add telemetry, analytics, hidden network access, or automatic dependency updates.
- Use Kotlin and Gradle Kotlin DSL. Do not add Groovy build scripts.
- Use the Gradle wrapper and preserve the compatibility targets declared by the build.
- Preserve lazy Gradle configuration, its supplied Kotlin runtime, and configuration-cache support.
- Preserve JUnit Jupiter and Gradle TestKit. Do not introduce Kotest or a mocking framework without an explicit dependency and style decision.
- Use local fixtures or loopback HTTP servers so tests remain independent of live services.
- Apply the writer skill, the writing style, and the English style to new or revised user-facing text.
- Apply the proofread skill when checking existing project-owned comments and documentation for English-language errors.
- Follow the Kotlin KDoc policy for declarations and public APIs.
- Verify documentation claims against current code, tests, build files, or command output.
- Agent configuration validation requires Python 3.10 or newer.
- After changing agent documentation, routes, or skills, run
python3 scripts/check_agent_config.py. - After changing the validator, run
python3 -m unittest discover -s scripts/tests -t . -p 'test_*.py'. - Start with the narrowest Gradle task or test that proves the change.
- Run
./gradlew checkbefore handing off a completed code or test change unless the task is documentation-only or a narrower check is explicitly sufficient. - Run
git diff --checkafter editing. - Report every command actually run. Separate failures caused by the change from failures caused by the environment or unrelated work.
- Include a
## Used skillssection in every final response. - List all materially applied skills, including repository and platform-provided skills.
- Do not list skills that were merely discovered, inspected, or considered.
- Write
- None.when no skill was used. - Place the section last unless a required machine-readable trailer must remain last.
- Codex reads this
AGENTS.mdand discovers repository skills under.agents/skills/. - Claude reads CLAUDE.md, which routes back to this file. Its
/proofreadcommand exposes a deliberate repository sweep; other skills use normal routing rather than one command per skill. - GitHub Copilot instructions route Copilot back to this file and the matching skills.