developer-workflow

Use this agent when the user asks for architectural review, evaluation of module structure, dependency analysis, API design between modules, or decomposition advice. Also use when a plan or implementation involves architectural decisions that need validation.\n\nExamples:\n\n- user: "Посмотри на структуру модулей в проекте и скажи, правильно ли организованы зависимости"\n assistant: "Запускаю architecture-expert для анализа модульной структуры и направления зависимостей."\n <uses Agent tool to launch architecture-expert>\n\n- user: "Я планирую вынести авторизацию в отдельный модуль. Вот план: ..."\n assistant: "Передаю план в architecture-expert для оценки декомпозиции и boundaries."\n <uses Agent tool to launch architecture-expert>\n\n- user: "Оцени API между domain и data слоями"\n assistant: "Использую architecture-expert для ревью контрактов между слоями."\n <uses Agent tool to launch architecture-expert>\n\n- Context: User has just described an implementation plan involving multiple modules and layers.\n assistant: "План затрагивает архитектурные решения — запускаю architecture-expert для валидации перед реализацией."\n <uses Agent tool to launch architecture-expert>

Use this agent when the task involves Gradle configuration, build system architecture, build performance optimization, multi-module project structure, AGP configuration, KMP source sets, dependency management, custom Gradle tasks/plugins, convention plugins, version catalogs, or any build-related issue in JVM/Kotlin/Android projects.\n\nExamples:\n\n- User: "Сборка стала занимать 5 минут, раньше было 2"\n Assistant: "Запущу build-engineer агента для анализа и оптимизации скорости сборки."\n (Use the Agent tool to launch build-engineer to diagnose build performance regression)\n\n- User: "Нужно добавить новый модуль для feature X"\n Assistant: "Сначала попрошу build-engineer проанализировать текущую модульную структуру и предложить правильное размещение нового модуля."\n (Use the Agent tool to launch build-engineer to review module structure and advise on new module placement)\n\n- User: "Переведи зависимости на version catalog"\n Assistant: "Запущу build-engineer для миграции зависимостей на libs.versions.toml."\n (Use the Agent tool to launch build-engineer to perform the migration)\n\n- User: "Посмотри наши Gradle файлы, что можно улучшить"\n Assistant: "Запущу build-engineer для ревью Gradle конфигурации."\n (Use the Agent tool to launch build-engineer to review all build files)\n\n- User: "Configuration cache ломается при сборке"\n Assistant: "Запущу build-engineer для диагностики проблем с configuration cache."\n (Use the Agent tool to launch build-engineer to fix configuration cache issues)

Use this agent when you need to evaluate plans, features, or technical decisions from a product and business value perspective. This includes requirements analysis, scope management, MVP scoping, acceptance criteria formulation, trade-off analysis, and consistency checks against existing decisions.\n\nExamples:\n\n- User: "Я хочу добавить в приложение систему уведомлений с push, email, SMS и in-app"\n Assistant: "Давай оценю scope этой фичи с продуктовой точки зрения."\n [Uses Agent tool to launch business-analyst to analyze scope, MVP boundaries, and prioritize notification channels]\n\n- User: "Мы решили использовать event sourcing для хранения заказов"\n Assistant: "Перед тем как приступить к реализации, оценю это решение с бизнес-стороны."\n [Uses Agent tool to launch business-analyst to assess impact on time-to-market, maintainability, and consistency with existing architecture decisions]\n\n- User: "Вот список требований к новому модулю оплаты: ..."\n Assistant: "Проанализирую требования на полноту и непротиворечивость."\n [Uses Agent tool to launch business-analyst to review requirements, identify gaps, implicit assumptions, and formulate acceptance criteria]\n\n- User: "Не могу решить — делать свою авторизацию или интегрироваться с Auth0"\n Assistant: "Сравню варианты с продуктовой точки зрения."\n [Uses Agent tool to launch business-analyst for trade-off analysis covering cost, time-to-market, dependencies, and SLA risks]

Use this agent when you need to write Jetpack Compose or Compose Multiplatform UI code — whether from a visual design (Figma mockup, screenshot, wireframe), a feature specification or task description, or a migration brief from the migrate-to-compose skill. This includes screens, composables, previews (@Preview), custom Modifiers, themes (MaterialTheme customizations, color schemes, typography, shape definitions), navigation graphs (NavHost, route definitions, transitions), animations (Animate*, Transition, spring/tween specs), accessibility semantics, loading/skeleton/shimmer UI, and error UI display. This agent produces production-ready composable functions following modern Compose best practices: Modifier.Node API for custom modifiers, Slot API for component design, stateless screen pattern, proper state hoisting, performance-aware recomposition, and full accessibility support. Supports both Android-only (Jetpack Compose) and KMP (Compose Multiplatform) targets. <example> Context: Developer has a Figma mockup for a new screen and wants it implemented in Compose. user: "Here's the Figma mockup for the order details screen. Can you implement it in Compose?" assistant: "I'll launch the compose-developer agent to analyze the design and implement it as a Compose screen." <commentary> The user has a visual design that needs to become Compose code. The agent will decompose the mockup into a component tree, discover project patterns, and produce the implementation. </commentary> </example> <example> Context: Developer has acceptance criteria for a new feature screen. user: "I need a settings screen with these sections: profile info (avatar, name, email), notification toggles (push, email, SMS), and a danger zone with delete account. Here are the acceptance criteria." assistant: "I'll use the compose-developer agent to design and implement this settings screen." <commentary> The user has a feature spec with clear requirements. The agent will parse them into UI states and interactions, design the component tree, and implement. </commentary> </example> <example> Context: The migrate-to-compose skill delegates screen implementation with a detailed brief. user: (internal delegation from migrate-to-compose skill with old implementation files, pattern constraints, and shared components list) assistant: "I'll launch the compose-developer agent with the migration brief to write the Compose implementation." <commentary> The migrate-to-compose skill has already completed discovery, pattern analysis, and gap analysis. The agent receives a structured brief and writes the code following the provided constraints exactly. </commentary> </example> <example> Context: Developer needs a reusable KMP-compatible component for the shared UI module. user: "We need a reusable StarRating composable for our design system. It should work on Android and iOS via Compose Multiplatform." assistant: "I'll use the compose-developer agent to create a KMP-compatible StarRating component following your design system patterns." <commentary> The user needs a shared component — not a screen. The agent will ensure KMP compatibility (no android.*/java.* imports), follow the project's design system conventions, and place it in the correct shared module. </commentary> </example> <example> Context: Developer needs to change the app theme. user: "Add a 'success' color to the theme and update the primary color palette to match our new brand colors." assistant: "I'll use the compose-developer agent to update the MaterialTheme color scheme." <commentary> Theme definitions (MaterialTheme, color tokens, typography, shapes) are Compose UI code and belong to compose-developer, even if they don't contain @Composable functions. </commentary> </example> <example> Context: Developer needs to set up navigation between screens. user: "Set up the navigation graph for the checkout flow: cart → address → payment → confirmation screens." assistant: "I'll use the compose-developer agent to implement the Compose Navigation graph." <commentary> NavHost, route definitions, and navigation transitions are Compose UI infrastructure — compose-developer owns them. </commentary> </example>

Use this agent when the user needs help with CI/CD pipelines, build systems, deployment automation, packaging, release workflows, dependency scanning, environment management, or monitoring/alerting infrastructure. Examples:\n\n- user: "GitHub Actions билд падает на matrix build для iOS"\n assistant: "Запускаю devops-expert агента для диагностики проблемы с CI pipeline."\n <uses Agent tool to launch devops-expert>\n\n- user: "Нужно настроить автоматический релиз с changelog по тегам"\n assistant: "Использую devops-expert для проектирования release automation."\n <uses Agent tool to launch devops-expert>\n\n- user: "Как оптимизировать время сборки в GitLab CI? Сейчас 25 минут"\n assistant: "Передаю задачу devops-expert агенту для анализа и оптимизации pipeline."\n <uses Agent tool to launch devops-expert>\n\n- user: "Нужно собрать Docker образ для нашего сервиса и настроить деплой на staging"\n assistant: "Запускаю devops-expert для настройки контейнеризации и деплоя."\n <uses Agent tool to launch devops-expert>\n\n- user: "Проверь зависимости на уязвимости"\n assistant: "Использую devops-expert агента для dependency scanning."\n <uses Agent tool to launch devops-expert>

Use this agent when you need to write Kotlin code for Android or Kotlin Multiplatform (KMP) client applications — business logic, data layer, domain layer, ViewModels, UseCases, Repositories, data sources, mappers, DI wiring, and unit tests. This agent produces production-ready Kotlin following modern best practices: coroutines and Flow for async work, sealed interfaces for type-safe hierarchies, value classes for domain primitives, Clean Architecture layer separation, and strict visibility discipline. Supports both Android-only and KMP targets. This agent does NOT write Compose UI code — screens, composables, modifiers, previews, @Preview, themes (MaterialTheme, colors, typography), navigation graphs (NavHost, routes), animations, custom Modifiers, accessibility semantics, skeleton/loading UI, or error UI display — all of that belongs to `compose-developer`. <example> Context: Developer needs business logic for a new feature. user: "I need to implement the order history feature — fetching orders from the API, caching them locally, and exposing them to the UI as a paginated list." assistant: "I'll launch the kotlin-engineer agent to implement the data layer, repository, use case, and ViewModel for order history." <commentary> The user needs a full feature stack from API to ViewModel. The agent will discover project patterns, design the architecture, and implement layer by layer. </commentary> </example> <example> Context: Developer needs a ViewModel wired to existing use cases. user: "We already have FetchUserProfileUseCase and UpdateUserProfileUseCase. I need a ProfileViewModel that manages the screen state." assistant: "I'll use the kotlin-engineer agent to create the ProfileViewModel wired to your existing use cases." <commentary> Existing domain layer is in place — the agent reads the use case contracts and builds a ViewModel that exposes state and handles actions. </commentary> </example> <example> Context: Developer needs shared KMP code for multiple platforms. user: "Move our authentication logic to commonMain so iOS can use it too. Right now it's all in the Android module." assistant: "I'll launch the kotlin-engineer agent to extract the auth logic into commonMain with expect/actual for platform-specific parts." <commentary> KMP migration of business logic — the agent identifies platform-specific dependencies, creates expect/actual declarations, and moves shared code to commonMain. </commentary> </example> <example> Context: Developer needs a data source and repository implementation. user: "Add a local cache for the product catalog using our database. The API client already exists." assistant: "I'll use the kotlin-engineer agent to implement the local data source and update the repository to use cache-first strategy." <commentary> Data layer work — the agent reads the existing API client and database setup, implements the local data source, and wires it into the repository with the caching strategy. </commentary> </example>

Use this agent when you need to perform manual-style QA testing of a mobile/web application based on a specification, mockups, or requirements. This agent writes test cases, executes functional and visual checks against a running app (on device/simulator/browser), reports bugs found, and tracks fixes across iterations. <example> Context: Developer has implemented a new onboarding flow and wants it validated against Figma mockups. user: "I've just finished the onboarding screens. Here are the Figma links and the acceptance criteria. Can you QA it?" assistant: "I'll launch the manual-tester agent to review the onboarding flow against your specs." <commentary> The user wants functional and visual validation of a newly implemented feature against a specification source. This is exactly the manual-tester's domain — launch it with the spec and let it produce test cases and a bug report. </commentary> </example> <example> Context: A feature was partially fixed after a previous QA cycle and needs re-verification. user: "The bugs from last sprint are supposedly fixed. Can you recheck them?" assistant: "I'll use the manual-tester agent to re-run the relevant test cases and verify the fixes." <commentary> Re-testing previously reported bugs after a fix iteration is a core QA loop task — use the manual-tester to close the loop. </commentary> </example> <example> Context: There are no existing test cases and the team wants to establish a baseline before shipping. user: "We have no test cases at all. Here's the PRD and the screens. Can you create a test suite?" assistant: "Let me invoke the manual-tester agent to generate a structured test case suite from your PRD." <commentary> Creating test cases from a spec/PRD before any testing begins is part of this agent's responsibilities. </commentary> </example> <example> Context: Developer asks for a quick sanity check with no spec provided. user: "Just go through the checkout flow and tell me if anything is broken." assistant: "I'll launch the manual-tester agent to explore the checkout flow and report any issues." <commentary> No spec is provided — the agent uses the running app itself as the source of truth, performs exploratory testing, and reports defects based on common sense and UX heuristics. </commentary> </example>

Use this agent when reviewing code or architectural plans for performance issues, resource efficiency, and potential bottlenecks. This includes analyzing new code for N+1 queries, memory leaks, threading problems, UI jank, network inefficiency, and battery drain. Also use when the user asks about profiling strategies or performance optimization.\n\nExamples:\n\n- User: "Review this repository implementation for any issues"\n Assistant: "Let me check the code structure first."\n [reads code]\n Assistant: "I see potential performance concerns here. Let me launch the performance-expert agent to do a thorough analysis."\n [uses Agent tool to launch performance-expert]\n\n- User: "I wrote a new screen with a list that loads data from network"\n Assistant: "Here's the implementation."\n [writes code]\n Assistant: "Now let me use the performance-expert agent to check for pagination, recomposition, and network efficiency issues."\n [uses Agent tool to launch performance-expert]\n\n- User: "Can you look at my coroutine usage in this ViewModel?"\n Assistant: "Let me launch the performance-expert agent to analyze threading, dispatcher usage, and potential coroutine leaks."\n [uses Agent tool to launch performance-expert]\n\n- User: "We have a Compose screen that feels sluggish when scrolling"\n Assistant: "Let me use the performance-expert agent to identify recomposition issues and layout performance problems."\n [uses Agent tool to launch performance-expert]

Rules for writing correct, testable, and production-safe coroutine code in Android and KMP projects. Based on official Android best practices and common production pitfalls.

Use this agent when you need to review code, architecture, or plans for security vulnerabilities and compliance with security best practices. This includes OWASP Top 10 analysis, data storage security, network security, authentication flows, CI/CD secrets management, mobile platform security (Android/iOS), web application security, and accessibility-related security concerns.\n\nExamples:\n\n- user: "Вот план архитектуры авторизации через OAuth2 + JWT для мобильного приложения"\n assistant: "Запускаю security-expert агента для оценки auth flow на уязвимости."\n <uses Agent tool to launch security-expert>\n\n- user: "Напиши мне сетевой слой с Ktor Client"\n assistant: "Вот реализация сетевого слоя: ..."\n <code written>\n assistant: "Запускаю security-expert для проверки TLS конфигурации и сетевой безопасности."\n <uses Agent tool to launch security-expert>\n\n- user: "Сделай экран логина с сохранением токена"\n assistant: "Вот реализация: ..."\n <code written>\n assistant: "Запускаю security-expert для проверки безопасности хранения токенов и auth flow."\n <uses Agent tool to launch security-expert>\n\n- user: "Проверь этот код на безопасность"\n assistant: "Запускаю security-expert агента для полного security review."\n <uses Agent tool to launch security-expert>\n\n- user: "Настрой CI/CD пайплайн с секретами для деплоя"\n assistant: "Вот конфигурация: ..."\n assistant: "Запускаю security-expert для проверки управления секретами в CI/CD."\n <uses Agent tool to launch security-expert>

Use this agent when you need to evaluate user experience, UI design decisions, user flows, accessibility, or design consistency in the project. This includes reviewing plans, screens, navigation structure, UI states, and platform convention compliance.\n\nExamples:\n\n- Context: A plan for a new feature has been created with user flows.\n user: "Вот план для фичи настроек профиля, проверь"\n assistant: "Запускаю UX-ревьюера для оценки пользовательских сценариев и полноты плана."\n <uses Agent tool to launch ux-expert>\n\n- Context: New screens or composables have been implemented.\n user: "Я добавил экран онбординга, посмотри с точки зрения UX"\n assistant: "Использую UX-ревьюера для анализа экрана онбординга."\n <uses Agent tool to launch ux-expert>\n\n- Context: After implementing a significant UI feature, proactively check UX quality.\n assistant: "Реализовал экран корзины. Запускаю UX-ревьюера для проверки состояний UI и accessibility."\n <uses Agent tool to launch ux-expert>\n\n- Context: Reviewing a PR or design document that includes navigation changes.\n user: "Проверь навигацию в новом модуле"\n assistant: "Запускаю UX-ревьюера для оценки информационной архитектуры и навигации."\n <uses Agent tool to launch ux-expert>

Invoke whenever a user wants to replace, swap, migrate, modernize, or convert any technology in an existing Android/Kotlin project — even if they're just asking where to start, which approach to take, or whether it's feasible. Trigger when user says: "moving off [library]", "switch to Y", "replace X with Y", "migrate from X to Y", "modernize [component]", "convert to Compose", "upgrade from [old version]", "drop/ditch [library]", "finally leaving [technology]", "thinking about switching", "[library] is ancient/a pain/the worst offender", "heard Y is more idiomatic", "want to modernize it". Covers: async rewrites (RxJava → coroutines, AsyncTask → coroutines/executors, EventBus → StateFlow/SharedFlow), UI rewrites (XML/data binding/view binding → Compose or reverse), library swaps (Glide → Coil, Retrofit → Ktor, any library-for-library replacement), Java-to-Kotlin file conversion, and build tooling upgrades (Groovy DSL → Kotlin DSL, Gradle 6.x → 8.x). Also invoke when user asks which technology to use to modernize existing legacy code (e.g. AsyncTask — coroutines or executors?) — the question is about upgrading existing code, not choosing for a new project. Do NOT invoke for: KMP structural migration (adding commonMain/androidMain source sets, sharing modules with iOS — use kmp-migration instead), debugging broken code with no migration intent, adding new features, general "what's the difference" comparisons for new projects, Kotlin version bumps, or non-Android/Kotlin migrations (Spring Boot etc.).

Use when creating a new pull request (GitHub) or merge request (GitLab) for the current branch. Handles branch push, draft/ready decision, title and description generation, label selection, reviewer suggestions from git history, and PR creation. Invoke whenever the user says "create a PR", "open a PR", "make a PR", "create a draft PR", "submit for review", "push a PR", "open an MR", or any variation — draft or not.

This skill should be used when the user asks to "find bugs", "check if anything is broken", "poke around the app", "explore the app", "do a sanity check", "QA the app", "stress test", "find UX issues", "check for crashes", "do pre-release QA", or "check app quality" — without providing a specification or formal test plan. Also use when the user mentions a running app (emulator, simulator, device, localhost URL, staging URL) and wants undirected quality assessment, when the feature is built but has no spec yet, when checking if a refactor broke anything, when the user reports vague bugs and wants exploration, or for a quick accessibility sweep. Launches the manual-tester agent with device/browser MCP tools for real interaction. Do NOT trigger when: the user provides a spec/mockup/PRD and wants verification against it (use test-feature), the user only wants test cases written without execution (use generate-test-plan), or the user asks about automated unit/integration tests (out of scope).

This skill should be used when the user asks to "create a test plan", "write test cases", "generate QA scenarios", "prepare a testing checklist", "identify what to test", "find edge cases", "plan testing coverage", "document test scenarios", "create a QA handoff document", "what should I test?", "what are the edge cases?", or "how would you test this?". Also use when the user describes requirements or acceptance criteria and asks how to verify them, or wants to plan testing before actually running tests. Produces a structured, prioritized test plan document saved to docs/testplans/ with risk analysis, coverage matrix, automation candidates, and proper TC format. Do NOT trigger when: the user wants to execute tests on a running app (use test-feature or exploratory-test), the user wants automated unit/integration tests written in code (out of scope), or the user wants to run an existing test plan (use test-feature). This skill never launches an app, device, or browser — it only produces a document.

Explicit-only skill — only invoke when the user directly requests it (e.g. "/developer-workflow:implement-task"). Do NOT trigger automatically on implementation requests — the user controls when this workflow runs. Orchestrates the full development cycle: isolated worktree → TDD → implementation → quality loop (simplify + code review) → draft PR → CI/CD monitoring → merge-ready PR.

Use when migrating an Android module or project to Kotlin Multiplatform (KMP) — invoke proactively even when the user is asking where to start, whether it's feasible, or how to share code with iOS. Covers: moving sources to commonMain/androidMain, splitting dependencies between source sets, KMP dependency compatibility audit, Kotlin version check and upgrade to 2.x, module isolation as prerequisite, iOS framework exposure (CocoaPods / XCFramework / SPM), and expect/actual patterns. Trigger on: "move to KMP", "share with iOS", "extract to shared module", "make multiplatform", "migrate :module to KMP", "can we share this with iOS", "move to commonMain", "Kotlin Multiplatform". Do NOT use for: in-project library swaps that don't involve platform sharing (use code-migration instead), general KMP questions without a specific module/codebase to migrate, or iOS-only work.

Use when migrating any Android View-based UI to Jetpack Compose — whether the source is an Activity, a Fragment, or a standalone custom View/ViewGroup. Invoke proactively whenever the user says "migrate to Compose", "convert this screen to Compose", "rewrite in Compose", "move to Compose", "this screen needs Compose", "replace XML layout", "drop this fragment", "convert this Activity", "replace this custom view", "rewrite this ViewGroup", or asks how to approach a View→Compose migration for a specific screen or component. Covers: analyzing the existing View-based implementation regardless of its host (Activity/Fragment/custom View), discovering patterns from screens already written in Compose, identifying shared components that need to be built first, capturing a visual baseline via screenshot, implementing the Compose equivalent, and verifying both visual fidelity and structural consistency. Do NOT use for: migrating entire apps at once (do it screen-by-screen), KMP migrations (use kmp-migration instead), or non-UI code rewrites.

Multi-agent review of an implementation plan using the PoLL (Panel of LLM Evaluators) consensus protocol. The plan can come from any source — Plan Mode output, a file, or conversation context. Use this skill when the user asks to "review the plan", "get feedback on the plan", "check the plan", "validate the approach", "review with different perspectives", "multi-agent review", "план ревью", "проверь план", "оцени план", or after exiting Plan Mode and wanting independent expert evaluation before implementation. Also invoke when the user says "is this plan good?", "what did I miss?", "sanity check this", "review this before I start", "check my approach", or wants multiple viewpoints on an implementation strategy — even if the plan is described inline in the message or referenced as a file. Do NOT invoke for code review (use code-review instead) or PR review.

Use when a PR/MR already exists and needs to be driven to merge — monitors CI/CD, handles multi-round code review, responds to and resolves reviewer comments, and loops until all merge requirements are met.

This skill should be used when the user asks to "prepare for PR", "clean up before review", "quality check the branch", "run the quality loop", "check before PR", "make it PR-ready", or when implementation is complete and the branch needs quality-checking before creating a PR. Runs build, simplify, self-review, and lint/tests in a loop until only minor or no issues remain.

Verify a feature against its specification by running manual QA on a live app. Use this skill whenever the user wants to test, verify, or validate an implemented feature — whether they provide a test plan, a spec (PRD, Figma mockup, acceptance criteria, PR description), or both. Trigger on: "test this feature", "verify against spec", "QA the implementation", "check if it matches the design", "run the test plan", "validate the acceptance criteria", "does it match the mockup", "verify the PR", or any request to compare a running app against a specification source. Also trigger when the user finishes implementing a feature and wants confirmation it works before creating or finalizing a PR.