How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

domain-driven-design - Skill

Name: domain-driven-design
Author: davila7

Imported from davila7/claude-code-templates (cli-tool/components/skills/development/domain-driven-design/SKILL.md). Install upstream with npx skills add davila7/claude-code-templates --skill domain-driven-design. Copyright stays with the author.

Domain-Driven Design

Use this skill when

You need to model a complex business domain with explicit boundaries.
You want to decide whether full DDD is worth the added complexity.
You need to connect strategic design decisions to implementation patterns.
You are planning CQRS, event sourcing, sagas, or projections from domain needs.

Do not use this skill when

The problem is simple CRUD with low business complexity.
You only need localized bug fixes.
There is no access to domain knowledge and no proxy product expert.

Instructions

Run a viability check before committing to full DDD.
Produce strategic artifacts first: subdomains, bounded contexts, language glossary.
Route to specialized skills based on current task.
Define success criteria and evidence for each stage.

Viability check

Use full DDD only when at least two of these are true:

Business rules are complex or fast-changing.
Multiple teams are causing model collisions.
Integration contracts are unstable.
Auditability and explicit invariants are critical.

Routing map

Strategic model and boundaries: @ddd-strategic-design
Cross-context integrations and translation: @ddd-context-mapping
Tactical code modeling: @ddd-tactical-patterns
Read/write separation: @cqrs-implementation
Event history as source of truth: @event-sourcing-architect and @event-store-design
Long-running workflows: @saga-orchestration
Read models: @projection-patterns
Decision log: @architecture-decision-records

If templates are needed, open references/ddd-deliverables.md.

Output requirements

Always return:

Scope and assumptions
Current stage (strategic, tactical, or evented)
Explicit artifacts produced
Open risks and next step recommendation

Examples

Use @domain-driven-design to assess if this billing platform should adopt full DDD.
Then route to the right next skill and list artifacts we must produce this week.

Limitations

This skill does not replace direct workshops with domain experts.
It does not provide framework-specific code generation.
It should not be used as a justification to over-engineer simple systems.

Install domain-driven-design and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "davila7-claude-code-templates-domain-driven-design", "kind": "skill", "name": "domain-driven-design", "description": "Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns.", "publisher": "davila7", "version": "1.0.0", "capabilities": { "domains": [ "general" ], "tags": [ "skill-md", "ddd", "domain", "bounded-context", "architecture", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Plan and route Domain-Driven Design work from strategic modeling to tactical implementation and evented architecture patterns." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/davila7/claude-code-templates", "path": "cli-tool/components/skills/development/domain-driven-design/SKILL.md", "ref": "HEAD", "url": "https://github.com/davila7/claude-code-templates/blob/HEAD/cli-tool/components/skills/development/domain-driven-design/SKILL.md", "key": "davila7/claude-code-templates/cli-tool/components/skills/development/domain-driven-design/SKILL.md" } }, "instructions": "# Domain-Driven Design\n\n## Use this skill when\n\n- You need to model a complex business domain with explicit boundaries.\n- You want to decide whether full DDD is worth the added complexity.\n- You need to connect strategic design decisions to implementation patterns.\n- You are planning CQRS, event sourcing, sagas, or projections from domain needs.\n\n## Do not use this skill when\n\n- The problem is simple CRUD with low business complexity.\n- You only need localized bug fixes.\n- There is no access to domain knowledge and no proxy product expert.\n\n## Instructions\n\n1. Run a viability check before comm", "cost": { "context_tokens": 552 } }

domain-driven-design

About

Domain-Driven Design

Use this skill when

Do not use this skill when

Instructions

Viability check

Routing map

Output requirements

Examples

Limitations

Install domain-driven-design and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews