| name | ssmdorch |
| description | Orchestrate multi-stage pipelines for ssmd workflows. Pre-defined pipelines chain skills and agents in sequence — deploy, feature, hotfix, and dq-investigate. Use when user says "ssmdorch", "orchestrate", "pipeline", or named pipelines like "ssmdorch deploy", "ssmdorch feature", "ssmdorch hotfix", "ssmdorch dq". |
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
- Explicit name match: if the user says a pipeline name (e.g., "ssmdorch deploy"), use that pipeline directly.
- Keyword match: scan the user's request for trigger keywords from the table above. Select the pipeline with the strongest keyword overlap.
- 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:
- Announce: print
Stage {N}/{total}: {stage name} — {purpose}
- 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.
- Capture output: store the stage result for use as
{previous} in the next stage
- 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:
- Stage summary table:
| Stage | Name | Status | Key Output |
|---|
| 1 | ... | pass/fail | one-line summary |
- Summary paragraph: what was accomplished end-to-end
- 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 |