| name | skill-router |
| license | MIT |
| description | 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.
|
| metadata | {"user-invocable":"true","version":"1.0.0","keywords":"ruby, tdd, testing, code-review, ddd, orchestration, entry-point","origin":"Extracted from igmarin/rails-agent-skills v5.1.17"} |
Skill Router
HARD-GATE
Non-negotiable: no implementation code until a test exists, runs, and fails for the right reason (feature missing, not config/syntax).
ALWAYS identify the matching skill and name it explicitly as the next skill to use before responding further (see Output Style for the required format).
Core Process
Triages and decomposes any Ruby request into ordered sub-tasks, then delegates to the correct specialized skill.
When a task arrives, identify the matching skill from the table below and route to it using the format defined in Output Style before responding further.
Core Skills Catalog
| Skill | Use when... | Notes |
|---|
| define-domain-language | Extracting ubiquitous language or glossary definitions | Default fallback for ambiguous requirements or terminology confusion |
| review-domain-boundaries | Auditing context boundaries and language leakage | Use when auditing boundaries between subsystems, not for standard code review |
| model-domain | Tactical DDD design (aggregates, entities, value objects, domain services) | Fallback when architecture is the source of ambiguity |
| write-yard-docs | Writing or reviewing inline YARD documentation for public Ruby APIs | |
| create-service-object | Creating a service object (PORO .call pattern) | |
| implement-calculator-pattern | Implementing polymorphic variant-based calculators (Strategy + Factory) | |
| integrate-api-client | Designing HTTP integrations (layered client/fetcher/builder pattern) | |
| triage-bug | Investigating a bug, reproducing via failing test, and creating a repair plan | Primary entry point for bug fixes |
| respond-to-review | Receiving code review feedback and addressing comments | |
| tdd-process | General engineering loop: Red-Green-Refactor process gates and checkpoints | Use to execute the loop; see test-planning-process to map what to test |
| refactor-process | Safely refactoring code while preserving behavior under characterization tests | |
| review-process | Reviewing changesets (severity taxonomies, structured findings, re-review) | Use for standard code review of a specific changeset |
| security-review-process | Reviewing code for general Ruby security flaws (secrets, injections) | |
| test-planning-process | Choosing test boundaries (unit vs integration) and test scenarios | Use when the first failing test is not obvious; maps what to test |
Skill Priority
When multiple skills could apply, state this priority rule immediately after the routing statement:
Priority: TDD → Planning → Domain discovery → Process/refactor → Domain implementation.
Fallback for ambiguous requests: If no clear skill match, label this explicitly as Fallback: define-domain-language or Fallback: model-domain depending on whether terminology or architecture is the source of ambiguity.
Typical Workflows
Sub-skills are invoked by stating their name as the next skill to apply (see Output Style) before proceeding with that skill's instructions.
TDD Feature Loop (primary daily workflow):
skills/process/test-planning-process → skills/process/tdd-process → skills/docs/write-yard-docs → PR
Bug fix:
skills/testing/triage-bug → [GATE: reproduction test fails] → skills/process/tdd-process → fix → verify passes
Multi-concern review:
skills/process/security-review-process (if input/secrets touched) → skills/process/review-process (general code review)
Extended Resources
Output Style
-
Routing statement: Make the routing statement the first substantive line of every response. For a single skill:
Next skill: skills/process/tdd-process
This is a feature request. I will start by writing a failing test scenario.
When multiple skills apply, immediately follow the routing line with one concise priority/chain statement before any analysis or implementation:
Next skill: skills/process/security-review-process
Priority: security-review-process > review-process; Chain: security-review-process then review-process.
This pull request contains custom parser rules and input validation, so we will perform a security review first followed by general code review.
-
Language: Generated artifacts and output MUST be in English unless explicitly requested otherwise.
