android-dev

Use this agent for ANY Android development tasks. The agent replaces 6 separate agents and automatically runs the full cycle: implementation → review → UI test → verification. Use this agent when: - You need to create a new screen, feature, or component - You need to modify an existing feature or screen - You need to refactor code to match architectural standards - You need to find and fix a crash or bug - You need to write TDD tests for business logic - You need to perform an architectural review - You need to test UI on a device - You need to discuss approaches and make an architectural decision - You need to plan the implementation of a complex task Examples: <example> Context: A developer wants to add a new user profile screen. user: "Create a user profile screen displaying avatar, name, and an edit button" assistant: "Launching android-dev agent to create the profile screen." <commentary> A request to create a new screen is a direct trigger for the implement skill, after which the agent will automatically run review, test-ui, and verify. </commentary> </example> <example> Context: The app crashes when opening the orders list. user: "The app crashes when I open the orders list, here's the stacktrace: NullPointerException in OrdersViewModel" assistant: "Launching android-dev agent to diagnose the crash." <commentary> A crash with a specific stacktrace is a trigger for the debug skill. </commentary> </example> <example> Context: A developer wants to discuss architecture before implementation. user: "What's the best way to organize cart data caching — in UseCase or Repository?" assistant: "Launching android-dev agent to work through the architectural decision." <commentary> A question about an architectural approach is a trigger for the brainstorm skill, possibly transitioning to plan. </commentary> </example> <example> Context: Tests need to be written for order placement business logic. user: "Write TDD tests for PlaceOrderUseCase" assistant: "Launching android-dev agent for TDD development of the UseCase." <commentary> An explicit TDD request is a trigger for the tdd skill. </commentary> </example> <example> Context: Code needs to be checked for compliance with architectural standards. user: "Verify that AuthFeature conforms to our architecture" assistant: "Launching android-dev agent for architectural review." <commentary> A request for architecture review is a trigger for the review skill. </commentary> </example> <example> Context: A complex implementation needs to be planned. user: "Plan the implementation of a notifications module with push and in-app notifications" assistant: "Launching android-dev agent to plan the implementation." <commentary> A request to decompose a complex task is a trigger for the plan skill. </commentary> </example>

Verify that work is truly complete before claiming it's done. Requires fresh evidence for every completion claim — no assumptions, no "should work". Use when finishing a task, after executing a plan, before reporting completion, or when the user asks to verify results. This skill should be used when the user says "verify", "check if done", "is it ready", "make sure it works", "confirm completion", or when you are about to claim a task is finished. <example> Context: After implementing a feature, need to verify it's complete user: "verify the auth feature is done" assistant: "I'll run the verification skill to check all completion criteria." <commentary> Explicit verification request — invoke verify skill. </commentary> </example> <example> Context: Plan execution completed, need final check user: "we finished the plan, let's make sure everything is right" assistant: "I'll verify each task's completion criteria with fresh evidence." <commentary> Post-execution verification — natural use of verify skill. </commentary> </example> <example> Context: Agent is about to report task completion assistant thinking: "I'm about to say this task is done — I should verify first." <commentary> Self-triggered before completion claims — proactive verification. </commentary> </example>

UI testing of an Android feature on a device via the claude-in-mobile CLI. Reads the feature code, builds a test plan, launches the app, tests scenarios, takes screenshots, and reports bugs. <example> Context: User implemented a new feature and wants to test it on a device user: "test the authorization screen on a device" assistant: "Using test-ui skill to test the auth feature on a device via claude-in-mobile." </example> <example> Context: User wants to check how a screen looks user: "check how the profile screen looks" assistant: "Using test-ui skill for visual verification of the profile screen on a device." </example>

Research and design a solution before implementation. Analyzes context, asks questions, proposes 2-3 approaches with trade-offs, writes a specification. For non-trivial tasks that require thinking before coding. <example> Context: User wants to discuss an implementation approach user: "what's the best way to implement payment system integration?" assistant: "Using brainstorm skill to research approaches." </example> <example> Context: User wants to think through architecture user: "let's think about how to implement caching" assistant: "Running brainstorm to analyze caching options." </example> <example> Context: Complex feature with a non-obvious solution user: "need to add offline mode, where to start?" assistant: "Starting with brainstorm — will research current architecture and propose options." </example>

Systematic debugging methodology with 4 phases: root cause investigation, pattern analysis, hypothesis testing, and targeted fix. Prevents shotgun debugging and ensures fixes address causes, not symptoms. Use when something is broken, a bug is reported, an error occurs, or after 2+ failed fix attempts. This skill should be used when the user says "debug", "it's broken", "there's a bug", "not working", "error", "fix this", "why is this failing", or when multiple fix attempts have failed. <example> Context: User reports a crash user: "the app crashes when I open the profile screen" assistant: "I'll use the systematic debugging skill to investigate the root cause." <commentary> Bug report — systematic debugging prevents guessing. </commentary> </example> <example> Context: Multiple fix attempts have failed user: "I've tried fixing this three times and it still doesn't work" assistant: "Multiple attempts failed — I'll use the systematic debugging approach to find the root cause." <commentary> 3+ failed attempts — time to step back and investigate properly. </commentary> </example> <example> Context: Test failures after code changes user: "tests are failing after my changes" assistant: "I'll systematically trace the test failures to identify what broke." <commentary> Test failures need investigation, not random changes. </commentary> </example>

Android feature implementation: creating from scratch, extending existing features, or refactoring to match the architectural standard. Automatically determines the working mode based on context. Use for any tasks involving writing/modifying Android code. <example> Context: User wants to create a new screen user: "create an authorization screen with email and password" assistant: "Using implement skill in create mode to build the auth feature." </example> <example> Context: User wants to add functionality to an existing screen user: "add pagination to the catalog screen" assistant: "Using implement skill in modify mode to extend the catalog feature." </example> <example> Context: User wants to bring code up to standard user: "refactor the profile screen to match our architecture" assistant: "Using implement skill in refactor mode to migrate the profile feature." </example> <example> Context: A list of architectural violations was received from review user: "fix the violations from the review" assistant: "Using implement skill to fix architectural violations." </example>

1 hook across 1 event