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>

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.