home / skills / lukeslp / dreamer-skills / sm-orchestrate

sm-orchestrate skill

/skills/sm-orchestrate

This skill orchestrates multiple dr.eamer.dev services, managing groups, dependencies, and parallel checks to ensure reliable, scalable workflows.

npx playbooks add skill lukeslp/dreamer-skills --skill sm-orchestrate

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

Files (1)
SKILL.md
4.5 KB
---
name: sm-orchestrate
description: Orchestrate multiple dr.eamer.dev services - manage service groups, dependencies, and parallel health checks.
version: 1.0.0
---

# Service Manager Orchestration

You are orchestrating multiple services using the dr.eamer.dev service manager (`sm`). This skill helps manage service groups, dependencies, and parallel operations.

## Service Manager Basics

```bash
sm status              # View all services
sm start <service>     # Start single service
sm stop <service>      # Stop single service
sm restart <service>   # Restart single service
sm logs <service>      # View logs
sm health <service>    # Check health endpoint
```

## Service Groups

### AI Stack
Services for AI/LLM functionality:
- `swarm` (5001) - Multi-agent orchestration
- `studio` (5413) - AI interface provider
- `storyblocks` (8000) - Story generation

### Content Services
Content generation and management:
- `lessonplanner` (4108) - EFL lesson generator
- `clinical` (5015) - Clinical documentation
- `insults` / `jokes` - Entertainment APIs

### Core Infrastructure
Essential services:
- `coca` (3034) - Corpus linguistics API
- `wordblocks` (8847) - AAC communication
- `luke` (5211) - Portfolio/showcase

### Development
Development tools:
- `firehose` (5056) - Bluesky dashboard
- `skymarshal` (5050) - Bluesky CLI web

## Orchestration Patterns

### Start Service Group
```bash
# Start AI stack in dependency order
sm start swarm && sm start studio && sm start storyblocks

# Or parallel (if no dependencies)
sm start swarm & sm start studio & sm start storyblocks & wait
```

### Health Check All
```bash
for service in swarm studio lessonplanner coca; do
    sm health $service
done
```

### Restart with Verification
```bash
sm stop <service>
sleep 2
sm start <service>
sm health <service>
```

## Output Format

```
šŸ”§ SERVICE ORCHESTRATION

Operation: {start/stop/restart/health}
Target: {service_group or specific services}
Date: {timestamp}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
           SERVICE STATUS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| Service | Port | Status | Health |
|---------|------|--------|--------|
| swarm | 5001 | āœ… Running | āœ… Healthy |
| studio | 5413 | āœ… Running | āœ… Healthy |
| coca | 3034 | āš ļø Stopped | āŒ N/A |

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
           OPERATIONS LOG
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[12:00:01] Starting swarm...
[12:00:03] swarm started on port 5001
[12:00:03] Starting studio...
[12:00:05] studio started on port 5413
[12:00:05] Health check: swarm āœ…
[12:00:06] Health check: studio āœ…

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
              SUMMARY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Services Started: 2/2
Services Healthy: 2/2
Total Time: 5.2s
```

## Port Reference

| Port Range | Purpose |
|------------|---------|
| 3034 | COCA API |
| 4108 | Lesson Planner |
| 5001 | Swarm |
| 5010-5019 | Test/generator APIs |
| 5050-5059 | Dev tools (firehose, skymarshal) |
| 5211 | Portfolio |
| 5413 | Studio |
| 8000 | Storyblocks |
| 8847 | Wordblocks |

## Dependency Ordering

Some services depend on others:

```
studio → depends on → swarm (for orchestration)
lessonplanner → depends on → swarm (for generation)
```

Start dependencies first:
```
1. swarm (core AI)
2. studio, lessonplanner (consumers)
```

## Integration with Deployment

For Caddy routing changes, use `@geepers_caddy` agent.
For full deployment orchestration, use `@geepers_orchestrator_deploy`.

## Common Workflows

```
# Morning startup
/sm-orchestrate start ai-stack

# Pre-deployment check
/sm-orchestrate health all

# Restart after code changes
/sm-orchestrate restart lessonplanner

# Full system status
/sm-orchestrate status
```

## Key Principles

1. **Dependency ordering** - Start dependencies first
2. **Health verification** - Always check health after start
3. **Parallel when safe** - Independent services can start together
4. **Graceful stops** - Stop dependents before dependencies
5. **Log monitoring** - Check logs if health fails

## Related Skills

- `/session-start` - May trigger service checks
- `/quality-audit` - Includes service health in assessment

Overview

This skill orchestrates multiple dr.eamer.dev services using the dr.eamer.dev service manager (sm). It manages service groups, dependency ordering, parallel starts, and aggregated health checks. The skill outputs clear operation summaries and logs to help verify actions and diagnose failures.

How this skill works

The skill issues sm commands to start, stop, restart, inspect logs, and run health endpoints across named service groups or individual services. It understands service groups (AI Stack, Content Services, Core Infrastructure, Development), dependency relationships (for example, studio and lessonplanner depend on swarm), and can perform parallel operations when safe. After operations it runs health checks and compiles a human-friendly status report with timestamps, service ports, and health results.

When to use it

  • Boot the full AI stack in correct dependency order before running workflows
  • Run parallel starts for independent services to reduce startup time
  • Verify system health before deployment or after configuration changes
  • Restart a service and confirm it returned to healthy state
  • Collect status and logs for troubleshooting or audits

Best practices

  • Start dependency services first (e.g., swarm before studio and lessonplanner)
  • Always run health checks after start or restart to verify readiness
  • Use parallel start only for services without dependencies to avoid race conditions
  • Stop dependents before stopping core services for graceful shutdowns
  • Monitor logs immediately if a health check fails to capture error context

Example use cases

  • Morning startup: start the AI stack (swarm → studio → storyblocks) and confirm health
  • Pre-deployment validation: run sm health across all services and fail fast on unhealthy endpoints
  • Quick restart workflow: stop a single service, wait, start it, then run sm health to verify
  • Parallel dev boot: start independent dev tools (firehose, skymarshal) concurrently to save time
  • Operational report: produce a summarized status output with ports, statuses, and operation logs

FAQ

How do I handle services with dependencies?

Start dependency services first (for example start swarm, then start studio and lessonplanner). For stops, reverse the order: stop dependents before core services.

When is it safe to start services in parallel?

Start services in parallel only if they have no dependency relationship. Use parallel starts to speed up independent parts like development tools.

What should I do if a health check fails after start?

Inspect the service logs with sm logs <service>, check recent operation timestamps, then try a graceful restart and re-run sm health.