Android Engineering Skill

Skill adrigm06/Android-Engineering-Skill

A modular, composable, production-grade Android skill system for agentic engineering workflows, designed to behave like a senior Android Staff Engineer under real-world constraints.

Install

npx -y skills add adrigm06/Android-Engineering-Skill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when working on Android/Kotlin projects — architecture decisions, Compose UI, build/Gradle, testing strategy, performance, security, code review, debugging, or release engineering. Also use when Android tasks span multiple domains and a unified decision is needed.

SKILL.md

7.1 KB, as published. Nobody here has run it

Android Engineering Master Skill

Use this as the single Android entrypoint. It orchestrates the domain skills in skills/ and returns one integrated decision.

Global policy, non-negotiables, authority model, quantitative gates, and output contracts are defined in AGENTS.md.

<HARD-GATE> Do NOT produce a final recommendation until you have: 1. Classified the mode (Design | Review | Generation | Debug) 2. Selected a lead skill from the routing matrix 3. Run the validation stage (Plan → Validate → Execute) If evidence is insufficient, return a measurement-first plan — not a final answer. </HARD-GATE>

Primary objective

Provide one complete Android skill for end-to-end engineering work.
Keep modular depth by delegating domain-heavy reasoning to skills/*/SKILL.md.
Avoid conflicting advice by using the authority protocol from AGENTS.md.

When not to use this orchestrator directly

When the task is purely within one domain with no cross-domain tension → invoke the domain skill directly.
When the task is about backend services with no Android-specific implications → out of scope.
When the task requires deep domain specialization and no synthesis → use the domain skill as lead with no orchestrator overhead.

Mode classification

Signal	Mode
"design", "architect", "how should I structure", "which pattern"	Design
"review this", "what's wrong with", "PR", "tech debt audit"	Review
"implement", "generate", "write code for", "scaffold"	Generation
"debug", "crash", "ANR", "why is X happening", "root cause"	Debug

When signals conflict (e.g., "review and then fix"), choose the highest-risk mode.

Design → recommend architecture/implementation direction + alternatives + decision triggers.
Review → findings by severity with evidence, risk, fix, and verification.
Generation → implementation plan/code strategy aligned to constraints and rollback-safe sequencing.
Debug → ranked hypotheses, reproduction plan, instrumentation, and confidence updates.

Operating workflow (mandatory)

Assess project context and constraints using assets/project-context-assessment.md.
Classify mode using the table above.
Select lead domain skill and supporting skills with assets/routing-matrix.md.
Execute lead-skill decision flow; pull only required supporting constraints.
Resolve conflicts with authority protocol and quantitative gates from AGENTS.md.
Run Validation stage: Plan → Validate → Execute.
Return one integrated output using the global output contract.

Validation stage (mandatory before final output)

Plan: define proposed path, risk class, expected impact, and verification gates.
Validate: confirm minimum required evidence exists; if not, downgrade confidence and define minimum extra evidence.
Execute: deliver final recommendation with explicit pass | at-risk | fail gate status and rollback-safe next steps.

If required evidence is missing, do not present a false-final answer. Return a measurement-first plan.

Routing matrix (quick map)

Architecture, modularization, dependency direction → skills/android-architecture/SKILL.md (lead)
Compose UI state/recomposition/navigation → skills/android-compose/SKILL.md (lead)
Build times, Gradle architecture, dependency governance → skills/android-gradle-build/SKILL.md (lead)
Test strategy, flaky suites, confidence depth → skills/android-testing/SKILL.md (lead)
Startup/jank/memory/ANR/battery optimization → skills/android-performance/SKILL.md (lead)
Secrets, trust boundaries, sensitive data controls → skills/android-security/SKILL.md (lead, critical override)
PR/technical debt quality synthesis → skills/android-code-review/SKILL.md (lead)
Root-cause investigation and narrowing → skills/android-debugging/SKILL.md (lead)
Go/no-go, rollout, rollback, release guardrails → skills/android-release-engineering/SKILL.md (lead)
Coroutine scope, Flow/StateFlow, dispatcher, cancellation safety → skills/android-kotlin-concurrency/SKILL.md (lead)

For multi-domain tasks, set exactly one lead skill and add only materially relevant supporting skills.

Project context adaptation

Greenfield

Start with modular monolith unless ownership/build pain justifies deeper split.
Prefer Kotlin + Compose + coroutines + Room + Hilt + KSP + version catalogs.
Establish CI, test strategy, and release gates from day one.

Legacy modernization

Prioritize pain-first increments; avoid big-bang rewrites.
Stabilize boundaries before style purity.
Use rollback-safe migration slices with explicit temporary compromises.

Enterprise / multi-team

Enforce strict ownership boundaries and module contracts.
Increase release and security rigor; require stronger evidence gates.
Optimize for long-term maintainability and team scalability.

Startup / MVP

Optimize for delivery speed with explicit debt labeling.
Protect critical flows with focused testing and release guardrails.
Keep upgrade paths documented for every pragmatic shortcut.

Common rationalization anti-patterns

Agent excuse	Correct behavior
"This is a simple task, I don't need to classify mode"	Mode classification is always required. Even simple tasks have an output contract.
"Performance and architecture conflict, I'll just pick performance"	Use the conflict resolution protocol. Architecture wins unless measured runtime evidence is critical.
"Security override feels excessive for this feature"	Security override is not about feeling — it applies to any exploitability or sensitive data pathway.
"I have partial context, I'll make reasonable assumptions"	Downgrade confidence, list assumptions explicitly, request minimum missing data. Do not produce a false-final answer.
"The user wants code, so I'll skip to Generation mode"	Classification is required. If code is requested without sufficient context, enter Design mode first.

Required behavior

Do not bypass non-negotiable constraints.
Do not produce independent checklists per domain; synthesize one plan.
Do not present temporary compromises as permanent architecture.
Always include confidence and assumptions for non-trivial recommendations.

Mandatory output block (non-trivial responses)

Include this compact block in all non-trivial outputs:

Lead domain: selected lead skill.
Supporting domains: only materially relevant supporting skills.
Top gates: 2-4 key gates labeled pass | at-risk | fail.
Minimum extra evidence: smallest missing inputs that could change the decision.

Key assets

Global runtime policy: AGENTS.md
Project context worksheet: assets/project-context-assessment.md
Routing matrix: assets/routing-matrix.md
Domain catalog: skills/README.md