ssmdorch

What this skill does

# ssmdorch

Orchestrate pre-defined pipelines that chain existing skills and agents into sequential workflows.

## Pipelines

| Pipeline | Trigger Keywords | Stages |
|----------|-----------------|--------|
| `deploy` | deploy, ship, release, push, tag | defensive-coding, QA, ecc-verification, docs, ssmd-deploy, health, DQ, verification |
| `dq-investigate` | dq, data quality, freshness, missing, reconciliation | systematic-debugging, dq-checks, dq-run, health-metrics, docs, verification, report |
| `feature` | feature, add, build, implement, new | brainstorming, writing-plans, waldstorm, defensive-coding, TDD, ecc-verification, docs, code-review, simplify, verification |
| `hotfix` | fix, hotfix, bug, patch, broken, urgent | defensive-coding, TDD, docs, ssmd-deploy, health, verification |

## Instructions

### Step 1: Identify Pipeline

1. **Explicit name match**: if the user says a pipeline name (e.g., "ssmdorch deploy"), use that pipeline directly.
2. **Keyword match**: scan the user's request for trigger keywords from the table above. Select the pipeline with the strongest keyword overlap.
3. **Ambiguous**: if multiple pipelines match or none match clearly, present the pipeline table and ask the user to choose.

### Step 2: Load Pipeline Definition

Read the pipeline definition file from `pipelines/{name}.md` relative to this skill's directory.

Each pipeline file defines an ordered list of stages. Each stage specifies:
- **type**: `skill` (invoke via Skill tool), `agent` (invoke via Agent tool), `subagent-dev` (invoke `superpowers:subagent-driven-development`), or `report` (synthesize and present)
- **ref**: the skill name or agent subagent_type to invoke
- **purpose**: what this stage accomplishes in the pipeline
- **context template**: prompt text using `{task}` (original user request) and `{previous}` (output from the prior stage) placeholders

### Integrated Plugin Skills

Pipelines chain skills from three plugin ecosystems:

| Plugin | Skills Used | Purpose |
|--------|------------|---------|
| **superpowers** | `brainstorming`, `writing-plans`, `executing-plans`, `subagent-driven-development`, `test-driven-development`, `requesting-code-review`, `verification-before-completion`, `systematic-debugging` | Core workflow: design → plan → execute → verify |
| **everything-claude-code** | `verification-loop`, `code-review` | Quality gates: multi-phase verification, structured code review |
| **dlaw** | `defensive-coding`, `simplify`, `ssmd-deploy`, `ssmd-health-run`, `ssmd-dq-run`, `ssmd-dq-checks`, `ssmd-health-metrics`, `waldstorm` | Domain skills: coding standards, deployment, health, DQ |

### Step 3: Execute Stages Sequentially

**Execution model:** All implementation work uses `superpowers:subagent-driven-development` — fresh subagent per task with two-stage review (spec compliance, then code quality). This applies to any stage that writes or modifies code.

For each stage in the pipeline:

1. **Announce**: print `Stage {N}/{total}: {stage name} — {purpose}`
2. **Execute**:
   - If type is `skill`: invoke using the Skill tool with the ref name, passing the rendered context template as args
   - If type is `agent`: invoke using the Agent tool with `mode: "dontAsk"`, the ref as subagent_type, and the rendered context template as the prompt
   - If type is `subagent-dev`: invoke `superpowers:subagent-driven-development` — dispatch a fresh implementer subagent for the task, then spec reviewer, then code quality reviewer. Do not proceed to the next stage until all reviews pass.
3. **Capture output**: store the stage result for use as `{previous}` in the next stage
4. **Stop on failure**: if a stage fails or returns an error, halt the pipeline and report which stage failed and why

### Subagent-Driven Development

Pipelines that include implementation work (feature, hotfix) use subagent-driven development:

- **Fresh subagent per task**: no context pollution between stages
- **Two-stage review**: spec compliance first (did we build what was requested?), then code quality (is it well-built?)
- **Autonomous**: stages flow without user gates, but reviews must pass before proceeding
- **Stop on failure**: if tests fail or reviews reject, pipeline halts

Referenced skill: `superpowers:subagent-driven-development`

### Step 4: Report

After all stages complete (or on failure), produce:

1. **Stage summary table**:

| Stage | Name | Status | Key Output |
|-------|------|--------|------------|
| 1 | ... | pass/fail | one-line summary |

2. **Summary paragraph**: what was accomplished end-to-end
3. **Action items**: any remaining manual steps or follow-ups

## Model Routing

When dispatching agents in pipeline stages, use ECC's `agentic-engineering` model routing pattern:

| Stage Type | Model | Rationale |
|------------|-------|-----------|
| brainstorming, writing-plans | opus | Architecture decisions need deep reasoning |
| defensive-coding, documentation | sonnet | Focused analysis, well-scoped |
| subagent-dev (implementation) | sonnet | Good balance for code generation |
| ecc-verification, code-review | sonnet | Structured checklist evaluation |
| health-check, dq-run | haiku | Mechanical operations, fast feedback |
| verification-before-completion | opus | High-stakes final gate |

Pass the `model` parameter when using the Agent tool for agent-type stages.

## Matching Rules

| Keyword | Pipeline |
|---------|----------|
| deploy, ship, release, push, tag | `deploy` |
| dq, data quality, freshness, missing, reconciliation | `dq-investigate` |
| feature, add, build, implement, new | `feature` |
| fix, hotfix, bug, patch, broken, urgent | `hotfix` |