home / skills / athola / claude-night-market / service-registry

service-registry skill

/plugins/leyline/skills/service-registry

This skill helps you manage multiple external services with a unified registry, including health checks, configuration, and failover.

npx playbooks add skill athola/claude-night-market --skill service-registry

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
4.9 KB
---
name: service-registry
description: Consult this skill when implementing service registry patterns. Use when
  managing multiple external services, implementing health checks, centralizing service
  configuration, unified service execution. Do not use when single service integration
  without registry needs.
category: infrastructure
tags:
- services
- registry
- execution
- health-checks
- integration
dependencies:
- quota-management
- usage-logging
tools:
- service-executor
provides:
  infrastructure:
  - service-registry
  - health-monitoring
  - execution-engine
  patterns:
  - service-discovery
  - unified-execution
  - configuration-management
usage_patterns:
- multi-service-integration
- service-health-checks
- unified-execution
- configuration-management
complexity: intermediate
estimated_tokens: 550
progressive_loading: true
modules:
- modules/service-config.md
- modules/execution-patterns.md
---
## Table of Contents

- [Overview](#overview)
- [When to Use](#when-to-use)
- [Core Concepts](#core-concepts)
- [Service Configuration](#service-configuration)
- [Execution Result](#execution-result)
- [Quick Start](#quick-start)
- [Register Services](#register-services)
- [Execute via Service](#execute-via-service)
- [Health Checks](#health-checks)
- [Service Selection](#service-selection)
- [Auto-Selection](#auto-selection)
- [Failover Pattern](#failover-pattern)
- [Integration Pattern](#integration-pattern)
- [Detailed Resources](#detailed-resources)
- [Exit Criteria](#exit-criteria)


# Service Registry

## Overview

A registry pattern for managing connections to external services. Handles configuration, health checking, and execution across multiple service integrations.

## When To Use

- Managing multiple external services.
- Need consistent execution interface.
- Want health monitoring across services.
- Building service failover logic.

## When NOT To Use

- Single service integration without registry needs

## Core Concepts

### Service Configuration

```python
@dataclass
class ServiceConfig:
    name: str
    command: str
    auth_method: str  # "api_key", "oauth", "token"
    auth_env_var: str
    quota_limits: dict
    models: list[str] = field(default_factory=list)
```
**Verification:** Run the command with `--help` flag to verify availability.

### Execution Result

```python
@dataclass
class ExecutionResult:
    success: bool
    stdout: str
    stderr: str
    exit_code: int
    duration: float
    tokens_used: int
```
**Verification:** Run the command with `--help` flag to verify availability.

## Quick Start

### Register Services
```python
from leyline.service_registry import ServiceRegistry

registry = ServiceRegistry()

registry.register("gemini", ServiceConfig(
    name="gemini",
    command="gemini",
    auth_method="api_key",
    auth_env_var="GEMINI_API_KEY",
    quota_limits={"rpm": 60, "daily": 1000}
))
```
**Verification:** Run the command with `--help` flag to verify availability.

### Execute via Service
```python
result = registry.execute(
    service="gemini",
    prompt="Analyze this code",
    files=["src/main.py"],
    model="gemini-2.5-pro"
)

if result.success:
    print(result.stdout)
```
**Verification:** Run the command with `--help` flag to verify availability.

### Health Checks
```python
# Check single service
status = registry.health_check("gemini")

# Check all services
all_status = registry.health_check_all()
for service, healthy in all_status.items():
    print(f"{service}: {'OK' if healthy else 'FAILED'}")
```
**Verification:** Run the command with `--help` flag to verify availability.

## Service Selection

### Auto-Selection
```python
# Select best service for task
service = registry.select_service(
    requirements={
        "large_context": True,
        "fast_response": False
    }
)
```
**Verification:** Run the command with `--help` flag to verify availability.

### Failover Pattern
```python
def execute_with_failover(prompt: str, files: list) -> ExecutionResult:
    for service in registry.get_healthy_services():
        result = registry.execute(service, prompt, files)
        if result.success:
            return result
    raise AllServicesFailedError()
```
**Verification:** Run the command with `--help` flag to verify availability.

## Integration Pattern

```yaml
# In your skill's frontmatter
dependencies: [leyline:service-registry]
```
**Verification:** Run the command with `--help` flag to verify availability.

## Detailed Resources

- **Service Config**: See `modules/service-config.md` for configuration options.
- **Execution Patterns**: See `modules/execution-patterns.md` for advanced usage.

## Exit Criteria

- Services registered with configuration.
- Health checks passing.
- Execution results properly handled.
## Troubleshooting

### Common Issues

**Command not found**
Ensure all dependencies are installed and in PATH

**Permission errors**
Check file permissions and run with appropriate privileges

**Unexpected behavior**
Enable verbose logging with `--verbose` flag

Overview

This skill implements a service registry pattern to centralize configuration, health checks, and execution across multiple external services. It provides a uniform interface to register services, run commands or API calls, and collect structured execution results. Use it to simplify failover, auto-selection, and monitoring when working with many integrations.

How this skill works

You register each service with a ServiceConfig that includes command, auth method, environment variables, quotas, and supported models. The registry exposes operations to execute tasks against a named service, run health checks for one or all services, auto-select the best service based on capability requirements, and perform failover across healthy services. Execution results are returned as structured objects with success, stdout/stderr, exit code, duration, and token usage for easy handling.

When to use it

  • Managing multiple external services with differing interfaces
  • Needing a consistent execution and result format across integrations
  • Implementing health monitoring and automated failover
  • Centralizing service configuration, auth, and quota tracking
  • Selecting services automatically based on task requirements

Best practices

  • Register every external tool with a complete ServiceConfig: name, command, auth method and env var, quotas, and supported models
  • Verify service availability by running the configured command with --help during registration or CI checks
  • Prefer health_check_all in periodic jobs and use health status to drive load and failover decisions
  • Limit credentials exposure: store keys in environment variables and avoid checking them into source control
  • Log execution results and durations for observability and quota enforcement

Example use cases

  • A multi-model inference platform that routes prompts to the best model provider and falls back on failure
  • A CI step that runs code analysis tools installed as separate commands and reports unified results
  • A service aggregator that enforces per-provider rate limits and switches providers when quotas are reached
  • An operations dashboard that polls health_check_all to display live service status and alert on failures

FAQ

How do I verify a service is available after registering it?

Run the service command with the --help flag or call the built-in health_check for that service; include a CI step to perform this verification automatically.

What happens if all services fail during execution?

Use the failover pattern to try healthy services in order; if none succeed, raise a clear AllServicesFailedError and surface diagnostics (stderr, exit codes, durations).