Claude Skills by makifbaysal

Procedure for an analiz (analysis) task when you hold the analyst role. Use when a task with task_type analiz is assigned to you and add_task_document is in your tool list.

Use when you add or change any HTTP endpoint's request or response shape (Go or Java) — implement the task's contract exactly, evolve additively, keep the OpenAPI document in sync, and detect breaking changes before hand-off

Use when a backend or worker service needs a cloud deploy - container-first GitHub Actions deploys to Google Cloud Run (WIF) or AWS ECS/App Runner (OIDC), with migrate-before-deploy and a health-check gate

Use when adding or changing a Go HTTP endpoint — Fiber v2 or v3 (detect which), thin handlers, central error mapping, boundary validation; the same rules apply to net/http, chi, echo or gin

Use when adding a use case, port, repository or adapter in a Go service — where each piece goes, how errors and transactions cross layers, and how to check the import direction

Use when modelling a rich domain in Java - SOLID principles, encapsulated entities that enforce their own invariants, and value objects over primitives

Use when a Java service reads or writes the database - JPA/Hibernate and Panache/Spring Data mapping, transaction boundaries, pagination and avoiding N+1 and entity-over-the-wire leaks

Use when writing tests for Java (Quarkus or Spring) code - JUnit Jupiter structure, Mockito for collaborators, test slices, Testcontainers, and framework-native integration tests, test-first

Use when starting a backend task that could be built in either language - decide Go vs Java (Quarkus/Spring) from the task's shape and the repository's existing stack

Use when writing Go tests that need test doubles or cover multiple cases - detect the repo's mocking approach (Mockery v3, gomock, hand-written testify mocks, fakes), table-driven cases, testify suites when the repo uses them, and real-Postgres tests for repository adapters

Use when changing the database schema - detect the repo's migration tool, ship a new migration in its layout, never edit an applied one, and avoid lock-unsafe DDL on a live table

Use when building or extending a Java service with Quarkus - layered architecture, JAX-RS resources, CDI beans, Panache persistence, and native-friendly patterns

Use when Java is chosen but Quarkus does not fit - build the service with Spring Boot using the same clean layering, only when a required library lacks a Quarkus extension or the repo already standardizes on Spring

Use when adding logging to Go code - the repository's logger with structured fields, request-scoped correlation, correct levels, no secrets or double-logging

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

Use when a component talks to the backend - go through the typed api client, type every response, and handle loading, success, and error states explicitly

Use when a web/frontend app needs a cloud deploy - GitHub Actions to Cloud Run/ECS for SSR or GCS+CDN/Firebase and S3+CloudFront for static, with build-time env and cache invalidation

Use on every UI change - Atomic Design levels, reuse-before-build, correct placement, and import direction through the shared component library.

Use when writing or changing any React component - React Testing Library tests are behavior-focused (byRole first), use user-event, assert on accessible output, one behavior per test, and run in npm test

Use when writing React + TypeScript components - functional components, explicit typed props, derived state over effects, and no any/unsafe casts

Use when adding routes or deciding where state lives - carry resource ids and navigation-surviving state in the URL, keep route components thin, and lift shared state to a hook not a global store

Use when styling any web UI - style with Tailwind utility classes and design tokens, avoid custom CSS, and build on the existing Radix/shadcn primitives instead of hand-rolling

Use when building native Android with Jetpack Compose - stateless composables, state hoisting, ViewModel-owned state, edge-to-edge, predictive back, adaptive layout, atomic components, and Material theming over hardcoded values

Use when a mobile app needs a release pipeline - fastlane GitHub Actions to TestFlight (iOS) and Play internal track (Android), with code signing and the release naming that maps to TaskTrooper's prod deploy

Use when adding or reusing Flutter UI - organize widgets as atoms, molecules, and organisms in a shared library and never hand-roll a component that already exists

Use when a Flutter screen needs app state or data - separate presentation from state, keep business logic out of widgets, and follow the app's existing state solution (Riverpod 3 Notifier/AsyncNotifier, or the official ChangeNotifier+ListenableBuilder MVVM pattern)

Use when testing Flutter code - unit tests for logic, widget tests for UI behavior, golden tests for appearance, the multi-size/text-scale/dark matrix, accessibility guidelines, test-first

Use when building Flutter screens - compose small stateless widgets, keep layout declarative, decide layout by available width not device/orientation, separate presentation from business logic, and use the theme not hardcoded styles

Use when adding a screen, a tab, a deep link, or back-navigation handling - the per-stack navigation APIs, state preservation, auth-boundary resets, and how to verify a deep link actually opens the right screen.

Use when designing or building any mobile screen or component a user sees (Flutter, SwiftUI or Compose) - platform conventions, hierarchy, type that scales, colour roles and dark mode, safe areas and insets, forms and keyboard, states, feedback, and the generic-mobile anti-patterns.

Use when starting a mobile task that could be Flutter or native - decide from the existing app, platform-specific needs, and the analiz task

Use when a screen must work without network or a mutation must survive a lost connection - local storage choice, the outbox pattern with idempotency keys, background replay, and how to test it with a fake clock and fake network.

Use when a feature needs camera, location, photos, notifications, contacts, microphone, Bluetooth, or local network - the per-platform request flow, every denial state, and how to actually test the denied path when the shared test device auto-grants permissions.

Use when building native iOS with SwiftUI - small composable views, observable state models, atomic components, Swift 6.2+ concurrency, and system styling over hardcoded values

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation

Use when opening an analiz task for the system-architect - the required fields, what the criteria may say, and what the description must hand over

Use when the stakeholder asks a factual or status question about the workspace - call the matching read tool and answer conversationally, without creating tasks or asking for approval

Use when ordering board tasks - set priority/blocked_by/deploy_depends_on by severity and dependency, split MoSCoW within a feature, and use RICE/ICE only for a genuine "what next" call across several features

Use when moving tasks or reporting status - the kanban column semantics, which columns are human/architect/QA gates, and where the PM actually acts

Use when you create an implementation board task directly - the required fields, one-role-one-deliverable rule, and dependency ordering

Use when planning a delivery request as the only orchestration agent - one board-writing subtask, backlog first, one approval question, then move approved tasks to todo

Use when a task is in pm_uat - verify every acceptance criterion and the human's comments yourself in the browser, on a device, or over a loopback HTTP request, record a verdict per criterion, then move to human_uat or need_revision

Use when the stakeholder asks about an analysis outcome or its implementation tasks - understand the human approval gate and review the tasks the architect created once the human approved

Use when organizing the workspace - create/rename initiative projects and link repositories to them directly, since these are factual actions needing no analiz or approval

Use when the stakeholder asks for release notes or a changelog - group done/released work into Added, Changed, Deprecated, Removed, Fixed and Security, in outcome language, with task references

Use when a product decision or feature needs a written record - what to capture in a task document (PRD, decision record) and where to attach it, since TaskTrooper has no epic

Use when capturing what a feature must do - write testable user-story requirements that state WHAT and WHY, never HOW, with assumptions made explicit

Use when defining a feature - name what is in scope, out of scope, and assumed, and handle mid-flight expansion without corrupting in-progress tasks

Use when updating the stakeholder - report in outcome language (what changed for users, what's next, what decision is needed), translate technical detail, and surface risks early