CtrlK
BlogDocsLog inGet started
Tessl Logo

igmarin/ruby-core-skills

Curated library of 16 public Ruby AI agent skills covering TDD, refactoring, code review, security review, DDD, YARD documentation, and common design patterns.

94

1.13x
Quality

96%

Does it follow best practices?

Impact

94%

1.13x

Average score across 16 eval scenarios

SecuritybySnyk

Advisory

Suggest reviewing before use

Overview
Quality
Evals
Security
Files

SKILL.mdskills/orchestration/skill-router/

name:
skill-router
type:
atomic
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

SkillUse when...Notes
define-domain-languageExtracting ubiquitous language or glossary definitionsDefault fallback for ambiguous requirements or terminology confusion
review-domain-boundariesAuditing context boundaries and language leakageUse when auditing boundaries between subsystems, not for standard code review
model-domainTactical DDD design (aggregates, entities, value objects, domain services)Fallback when architecture is the source of ambiguity
write-yard-docsWriting or reviewing inline YARD documentation for public Ruby APIs
create-service-objectCreating a service object (PORO .call pattern)
implement-calculator-patternImplementing polymorphic variant-based calculators (Strategy + Factory)
integrate-api-clientDesigning HTTP integrations (layered client/fetcher/builder pattern)
triage-bugInvestigating a bug, reproducing via failing test, and creating a repair planPrimary entry point for bug fixes
respond-to-reviewReceiving code review feedback and addressing comments
tdd-processGeneral engineering loop: Red-Green-Refactor process gates and checkpointsUse to execute the loop; see test-planning-process to map what to test
refactor-processSafely refactoring code while preserving behavior under characterization tests
review-processReviewing changesets (severity taxonomies, structured findings, re-review)Use for standard code review of a specific changeset
security-review-processReviewing code for general Ruby security flaws (secrets, injections)
test-planning-processChoosing test boundaries (unit vs integration) and test scenariosUse 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

  • assets/examples.md — Routing examples.
  • assets/workflows.md — Extended workflow definitions.
  • 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:

    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.

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

skills

orchestration

skill-router

SKILL.md

README.md

tile.json