# Android Code Review

> Structured Android code review skill with severity-based findings across architecture, correctness, maintainability, performance, and security. Use this for PR reviews and technical debt assessments.

- Skill: `adrigm06/android-code-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add adrigm06/android-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/adrigm06/android-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: adrigm06 (https://skillmd.com/u/adrigm06)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/adrigm06/android-code-review

---


# Purpose

Run disciplined Android code reviews that prioritize issues by incident risk and provide implementation-ready fixes.

## Scope and authority

This skill is synthesis authority across domains.
It consolidates architecture, security, performance, testing, and release concerns into a prioritized outcome.

## When not to use

- when the primary task is deep root-cause investigation (`android-debugging`)
- when the primary goal is new architecture design selection (`android-architecture`)

## When to use

- pull request reviews
- technical debt audits
- release-candidate quality checks

## Decision engine workflow

1. Establish change intent and blast radius.
2. Check non-negotiable constraints first.
3. Evaluate architecture, correctness, maintainability, performance, and security implications.
4. Rank findings by severity and operational impact.
5. Propose fix order and verification strategy.

## Branching decision tree

### Branch A: change risk profile

- `high blast radius` (cross-module, auth, payment, startup, release-critical):
  - perform deep multi-domain review with stricter evidence requirements
- `medium blast radius`:
  - prioritize correctness, maintainability, and boundary consistency
- `low blast radius`:
  - focus on local quality and regression prevention

### Branch B: release proximity

- `near release`:
  - prioritize regressions and production-risk findings first
- `normal window`:
  - include strategic maintainability improvements with staged follow-up

### Branch C: change category

- `security-sensitive`:
  - require stronger evidence and verification for exploitability/reachability concerns
- `performance-sensitive`:
  - require measurement-backed findings for hotspot regressions
- `boundary-sensitive`:
  - prioritize dependency direction and ownership violations

### Branch D: evidence availability

- `full diff/artifacts available`:
  - run normal severity-based review flow
- `partial artifacts only`:
  - scope findings to verified surfaces, mark unknowns explicitly
- `no diff/artifacts provided`:
  - do not approve/reject code quality conclusively
  - return a provisional risk review with required evidence checklist
  - provide a low-risk fallback path (narrow merge scope or hold)

## Quantitative gates

Use measurable evidence gates for high-impact findings:

- evidence sufficiency gate:
  - `pass` when finding has concrete code evidence and reproducible risk path
  - `at-risk` when evidence is partial but plausible
  - `fail` when claim is mostly speculative
- verification readiness gate:
  - `pass` when recommended fix includes clear verification steps
  - `at-risk` when verification is incomplete
  - `fail` when no verification plan exists

## Uncertainty protocol

Always include confidence on non-trivial findings.
For medium/low confidence findings, include the minimum evidence needed to confirm/refute.

Confidence bands:

- `High` (>= 0.80)
- `Medium` (0.60-0.79)
- `Low` (< 0.60)

If confidence is medium/low:

- list assumptions explicitly
- request minimum additional evidence that can re-rank severity
- provide at least one fallback recommendation with lower regression risk
- escalate to specialized skill when domain certainty is insufficient

## Output contract

Follow global order from `../../AGENTS.md`:

1. `Context and constraints`
2. `Decision and rationale`
3. `Alternatives considered`
4. `Tradeoffs`
5. `Risks and mitigations`
6. `Confidence and unknowns`
7. `Cross-skill impacts`
8. `Next implementation steps`

Then include review-specific artifacts:

- `Findings by severity`
- `Evidence`
- `Risk impact`
- `Recommended fix`
- `Follow-up checks`

### No-diff fallback template (required when artifacts are missing)

When PR diff or runtime artifacts are missing, add:

- `Review status`: `Provisional - insufficient evidence`
- `Blocking unknowns`: exact missing artifacts (diff, module list, benchmarks, security config deltas)
- `Provisional findings`: only evidence-backed risks, each marked `confirmed` or `hypothesis`
- `Minimum evidence to finalize`: smallest artifact set needed for final severity ranking
- `Fallback path`: low-risk option (scope split, hold merge, or merge non-runtime subset only)

## Cross-skill handoff payload

Use the standard payload defined in `../../AGENTS.md` (section: Cross-skill handoff contract).
Set `requesting_skill` to `android-code-review`.

## Anti-pattern detection

- hidden coupling or boundary violations
- missing tests on behavior-critical changes
- performance-sensitive changes with no measurements
- security-impacting changes with weak controls

## Related resources

- `references/review-severity-evidence.md`
- `templates/review-report.md`