Use when reviewing a Ruby app for DDD (domain-driven design) boundaries, module boundaries, service boundaries, or code organization: detects bounded contexts, language leakage, cross-context orchestration, and unclear ownership — uses `rg` to find cross-context references and leaked terms, identifies misplaced domain models and documents ownership direction (which context owns invariants, transitions, and side effects), proposes the smallest credible boundary improvement before large reorganizations, outputs findings first then open questions then recommended next skills, and loads boundary-leakage examples only when their content is needed. Covers context mapping, leakage detection, and cross-context coupling.

Use when writing YARD documentation for Ruby public APIs: every public method MUST have `@param`, `@return [Hash]`, and `@raise` tags, document `self.call` separately from `#call`, list each exception with its own `@raise` tag, use `@example` for module-level constructs, `@see` for cross-references, follow YARD `@return` type annotation conventions, add explicit YARD sub-tasks after implementation to task lists, keep all YARD text in English unless requested otherwise, run `yard stats --list-undoc` to verify coverage, and load extended resource files only when their specific content is needed. Trigger words: YARD, inline docs, method documentation, API docs, public interface, rdoc, return tag, raise tag.

Entry-point orchestrator that triages and decomposes complex Ruby requests into ordered sub-tasks, then delegates to the correct specialised skill — never implements directly. Enforces TDD discipline across all code-producing work. Priority order: TDD→Planning→Domain discovery→Process/refactor→Domain implementation. First response line MUST be "Next skill: skills/[category]/[name]". Falls back to `define-domain-language` for terminology ambiguity or `model-domain` for architecture ambiguity. Use when scope is unclear, best approach uncertain, or request spans multiple concerns. Trigger: where do I start, help me plan a Ruby feature, break this down, what's the best approach, not sure how to approach this, multi-step Ruby task, complex Ruby task, what should I do first.

Use when creating or refactoring Ruby service classes following the `def self.call(...)` → `new(...).call` entry point pattern with a strict `{ success: true/false, response: { ... } }` response contract. Handles error shape (`{ success: false, response: { error: { message: string } } }`), `StandardError` rescue with `logger.error` logging, `UPPER_SNAKE_CASE` error constants, and mandatory module READMEs. Enforces test-first workflow: spec written and confirmed failing before implementation. Covers 4 core patterns (Standard, Batch, Static/Class-only, Orchestrator), `.call` ≤ 20 lines, and YARD documentation on `self.call` and `#call`. File layout: spec at `spec/services/[module]/[name]_spec.rb`, impl at `services/[module]/[name].rb`. Trigger words: service object, .call pattern, services, service module, response hash, success/response shape, YARD on self.call, service skeleton, module README, orchestrator.

Use when building variant-based calculators with SERVICE_MAP routing via `Factory.for(entity)` (ONLY permitted entry point — direct instantiation FORBIDDEN), BaseService defines `calculate`→`compute_result` if `should_calculate?`, NullService has `should_calculate?`=false+`compute_result`=nil, Concrete services override both methods and MUST call `super` in `should_calculate?` — and each component is tested in order (write spec → run → verify Red → implement → run → verify Green before next component, without collapsing NullService and concrete into one step). Test coverage includes: named variants, inactive plan, nil plan, and unknown variant contexts. Scaffolds tests per variant. Trigger words: strategy pattern, factory pattern, null object pattern, variant calculator, dispatch table, SERVICE_MAP, no-op fallback.

Use when integrating with external APIs in Ruby using a strict 5-layer pattern: Auth → Client → Fetcher → Builder → Entity — each layer test-gated (spec RED → impl GREEN before next layer), Auth has `self.default` + `DEFAULT_TIMEOUT` + cached `#token`, Client wraps HTTP with nested `Error` + `MISSING_CONFIGURATION_ERROR` + injected adapter (errors exclude raw response bodies), Fetcher uses `initialize(client, data_builder:, default_query:)` with `MAX_RETRIES` + `RETRY_DELAY_IN_SECONDS`, Builder allowlists `ATTRIBUTES` and drops instruction-like keys (`prompt`, `system`, etc), Entity defines `ATTRIBUTES` + `DEFAULT_QUERY` + `.find`/`.search` — specs use synthetic hash factories only, vendor responses are untrusted (prompt injection guard, no URL ingest, no browsing), and changes Ruby source and specs only. Trigger words: integrate api, external api, http client, fetcher, builder, auth layer, api client layer, layered pattern.

Breaks a feature, PRD, or requirement into TDD implementation tasks with task 0.0 as feature branch creation (MUST be first), each task uses TDD quadruplet (RED test→run fail→GREEN impl→run pass→REFACTOR), includes mandatory public API docs task, update docs task, and code review task, output with `Guidance Used` and `Relevant Files` sections saved to `tasks/tasks-[name].md`, auto-detects test command/source dir/test dir from project conventions. Ruby-first but language-agnostic. Trigger words: tdd task list, tdd tasks, generate tasks, tdd breakdown, implementation tasks, task breakdown, feature tasks, quadruplet pattern.

Enforces a disciplined refactoring process for Ruby code: ONE atomic transformation at a time, characterization tests MUST exist and be Green BEFORE any edit, run tests after EVERY single step, rollback immediately on Red (no debugging in broken state), no behavior changes mixed with refactoring. Covers extract methods, rename symbols, split classes, inline variables, remove duplication. Use when: refactor, clean up code, rewrite class, structure changes, simplify.

Reviews PRs using structured findings with severity levels (Critical/Major/Minor/Nitpick), verifies changeset includes tests for new/modified logic, reviews for correctness + safety + security + domain language adherence, checks for scope creep and authorization gaps (missing checks are Critical), presents structured table of findings by severity, generates self-review checklists for authors, produces findings reports, determines re-review criteria — and performs re-review verification by reviewing the diff against each finding. Use when the user requests a code review, asks to review a pull request, or needs a structured code audit with severity-classified findings. Trigger words: code review, review PR, PR review, code audit, structured review, severity levels.

Standardizes security review procedures for Ruby code mapped to OWASP Top 10: allowlist all input params before processing, forbid SQL interpolation (`#{}`), verify no secrets committed or logged, run `bundle exec bundle-audit check --update`, check for shell injection (`system()`, backticks, `exec()`), and discard instruction-like keys (`prompt`, `instructions`) in JSON payloads. Covers input validation, secrets management, and dependency audits. Trigger words: security review, check security, audit code, security vulnerability, secrets check, OWASP.

Enforces Red-Green-Refactor with hard gates: Red phase writes failing test that MUST fail on assertion (not syntax/config) and presents test+failure before proceeding, runs tests on the specific file (not full suite) after each phase, Green phase writes minimal code to pass and stops there, Refactor phase runs test after each micro-change and MUST stay Green throughout. Generates failing test cases, validates test failure before proceeding, gates implementation behind passing red-phase checks. Use when the user requests TDD workflow, asks to write tests first, mentions Red-Green-Refactor methodology, or uses trigger words: TDD, test-first, test gate.

Selects test boundaries, identifies test cases (happy path, edge case, error), picks the first failing test before writing any test code, tests at highest boundary directly expressing business goal (request for HTTP/JSON shape, service for domain invariants, unit for calculations), requires synthetic test data (never real production values), and runs the failing test skeleton to verify Red before proceeding to `tdd-process`. Use when the user needs to plan test coverage, determine test boundaries, or decide what tests to write before implementation. Trigger words: test plan, planning tests, test boundaries, test matrix, test strategy, first failing test.

Use when investigating a bug, error, or regression in a Ruby or Rails codebase. Creates a failing reproduction test, isolates the broken code path, and produces a minimal fix plan. Trigger words: debug, broken, error, regression, stack trace, failing test, bug report, Ruby bug, Rails error, .rb file broken.