# Skill Router

> 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/<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.

- Skill: `igmarin/skill-router` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add igmarin/skill-router`
- Raw SKILL.md: https://api.skillmd.com/api/skills/igmarin/skill-router/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: igmarin (https://skillmd.com/u/igmarin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/igmarin/skill-router

---

# Skill Router

## HARD-GATE

```text
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:

```text
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/test-planning-process → skills/tdd-process → skills/write-yard-docs → PR

**Bug fix:**
skills/triage-bug → **[GATE: reproduction test fails]** → skills/tdd-process → fix → verify passes

**Multi-concern review:**
skills/security-review-process *(if input/secrets touched)* → skills/review-process *(general code review)*

## Extended Resources

- [assets/examples.md](assets/examples.md) — Routing examples.
- [assets/workflows.md](assets/workflows.md) — Extended workflow definitions.
- [assets/skill-map.json](assets/skill-map.json) — Schema of core skill triggers.

## Output Style

1. **Routing statement**: Make the routing statement the first substantive line of every response. For a single skill:

   ```text
   Next skill: skills/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:

   ```text
   Next skill: skills/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.
   ```

2. **Language**: Generated artifacts and output MUST be in English unless explicitly requested otherwise.