gor-dev-plugins

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>

debug

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 attempt

implement

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: "

plan

Create and execute an implementation plan. Two modes: creating a granular plan (tasks of 2-5 minutes each) and step-by-step execution. Use for planning complex tasks or after brainstorm. <example> Context: User wants to plan a feature implementation user: "create a plan for the settings screen" assistant: "Using plan skill in plan mode to create a granular plan for the settings feature." </example> <example> Context: User wants to execute an existing plan user: "execute the plan from .claude/docs/android-dev/plans/2026-03-20-settings.md" assistant: "Using plan skill in execute mode for step-by-step plan execution." </example> <example> Context: User wants to break a complex task into steps user: "break down the DI migration task into steps" assistant: "Using plan skill to decompose the DI migration task into granular tasks." </example>

review

Architectural and code quality review of Android code. Two-pass check: (1) architectural rule compliance — 8 categories, (2) code quality — naming, duplication, error handling, security, performance, maintainability. Use after implementation to verify quality. <example> Context: User created a new feature and wants to check its quality user: "review the authorization feature" assistant: "Using review skill for a two-pass check of the auth feature." </example> <example> Context: User refactored code and wants to verify correctness user: "check the profile refactoring" assistant: "Using review skill to check architecture and code quality of the profile feature." </example> <example> Context: User wants to check code before committing user: "check my code before commit" assistant: "Using review skill for a full check of the modified files." </example>

tdd

Test-Driven Development workflow: RED → GREEN → REFACTOR. Write a failing test first, then write minimal code to pass it, then refactor while keeping tests green. Best for business logic (UseCases, mappers, utils, repositories), not for UI code. This skill should be used when the user says "tdd", "test first", "test driven", "red green refactor", "write tests before code", or when implementing business logic that benefits from test-first approach. <example> Context: User wants to implement a use case with TDD user: "implement the login use case with TDD" assistant: "I'll use the TDD skill — starting with a failing test for the login use case." <commentary> Explicit TDD request for business logic — perfect use case. </commentary> </example> <example> Context: User wants to add a data mapper user: "create the user mapper, let's do it test-first" assistant: "I'll use the TDD workflow — RED phase first with a test for the mapper." <commentary> Test-first request for a mapper — ideal for TDD. </commentary> </ex

test-ui

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>

verify

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. </c

using-superpowers

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

swagger-kotlin-conventions

Rules and conventions for generating Android Kotlin data models, domain models, enums and mappers from Swagger/OpenAPI specifications. Used by the swagger-model-generator agent.

google-dev-docs