ripplearc

Stage 3: Coding (Data Layer) - Write RepositoryImpl, DataSources, and DTOs. Data layer implements repository interfaces and handles external data sources (API, DB, cache). ⚠️ INVOCATION: Only use when the ticket touches the data layer (repository implementations, data sources, API/DB access). Trigger: "write data code", "implement data layer", "create datasource" (DataSource interface + related data layer classes)

Stage 3: Coding (Domain Layer) - Write UseCases, Repositories (interfaces), and Services. Domain layer contains pure business logic with no knowledge of UI or data sources. ⚠️ INVOCATION: Only use when the ticket touches the domain layer (business logic, use cases, repository interfaces). Trigger: "write domain layer code", "implement domain layer use cases", "create domain usecase"

Stage 3: Coding (Integration Layer) - GATED - Only for new third-party SDK integrations. Creates wrapper layer so domain never imports SDKs directly. ⚠️ GATED: Only use when ticket explicitly requires adding an external service/SDK that is not previously implemented or integrated in the codebase. Examples: new payment provider, analytics SDK, push notification service. Trigger: "integrate new SDK", "add third party service", "create wrapper"

Stage 3: Coding (Presentation Layer) - Write Pages, BLoCs, and Widgets. Presentation layer handles UI, state coordination, and user interaction with zero business logic. ⚠️ INVOCATION: Only use when the ticket touches the presentation layer (UI, screens, BLoC state management). Trigger: Any of the following phrases exactly as written, without variations: "write UI code", "implement presentation layer", "create page", "create bloc"

Stage 2: Implementation Planning - Decide what to create before writing code. Applies the Digestible PR and Naming & Abstraction rules; checks CoreUI availability. Trigger: "plan implementation" (implementation planning intent), "plan this feature" (ticket-to-file planning intent), "what files do we need for implementation"

Modular PR review for Flutter/Dart changes. Auto-detects which rules apply to each changed file, applies the full rule set in skills/rules/ (referenced by name), and returns a copy-paste-ready markdown PR description + review table. Use when a user asks to review a PR, review a branch, compare branches, or check naming, CoreUI, testing, streams, localization, accessibility, logging, or UI/business separation. Trigger phrases: "review this PR", "review my PR", "review feat/X to main", "check my branch", "code review", "analyze my changes".

Stage 1: Ticket Intake - Understand what to build before coding begins. Identifies architecture layers, anticipates classes, determines test types, flags ambiguities. Trigger: "read ticket CA-123", "analyze ticket", "what does CA-456 require"

Stage 4: Testing - GATED - Run mutation testing for complex business logic. Validates test quality by introducing bugs and checking if tests catch them. ⚠️ GATED: Only for code with at least three conditional branches, complex mathematical calculations, or significant data transformation logic (pagination, filtering, sorting). Trigger: "run mutation tests", "mutation testing", "check mutation score"

Use this skill when reviewing PRs in the ripplearc-flutter-lint repository, or when answering questions about how analyzers work, why analyze() vs analyzeWithResolver() is used, how rules are wired, or how the standalone checker dispatches. Triggers on any PR review for ripplearc-flutter-lint, or questions about analyzer architecture, BaseAnalyzer, BaseLintRule, StandaloneLintChecker, shouldSkipFile, or any custom lint rule internals. Also use when a contributor asks "why does X not produce violations?" or "is this wiring correct?" for any analyzer in this repo.