| name | workflow-chain |
| description | Use when the user wants to build a multi-step workflow from skills, or when they describe a job sequence like "first do X, then Y, then Z." This skill creates missing skills on the fly (via Skill Creator) and wires everything into an automated chain. Use it whenever you hear "workflow", "pipeline", "chain these skills", "run these in order", or when the user describes 2+ jobs that should execute in sequence. Also use when debugging why a skill chain isn't firing correctly. |
Workflow Chain
Build a complete workflow pipeline — creating any missing skills along the way and wiring everything together.
When to Use
You want multiple jobs to execute in sequence as a single workflow — like fetching a Jira ticket, running TDD, then sending a Slack notification. Some or all of these job skills may not exist yet. This skill handles both creating and connecting them.
Process
Step 1: Inventory the Skills
List all skills the user wants to chain. For each one, identify:
| Property | What to find |
|---|
| Skill name | The name field in its SKILL.md frontmatter |
| Skill path | Where it lives (e.g., my-skills:get-jira-ticket) |
| Input | What it needs to start (user input, artifact from previous skill, etc.) |
| Output | What it produces (files, data, state changes) |
| Side effects | External actions (API calls, messages sent, files committed) |
| Exists? | Does this skill already have a SKILL.md? |
Read each existing skill's SKILL.md to understand its properties.
Handling Missing Skills
If a skill doesn't exist yet, don't stop — create it. For each missing skill:
- Tell the user: "The skill
[name] doesn't exist yet. I'll create it now using Skill Creator."
- → INVOKE the Skill Creator skill, providing:
- The skill's purpose (what job it performs)
- Its expected input (what the previous skill in the chain passes to it)
- Its expected output (what the next skill in the chain needs from it)
- Any specific tools or APIs it should use (e.g., Jira MCP, Slack MCP,
gh CLI)
- Once Skill Creator finishes, continue the inventory with the newly created skill.
Repeat for every missing skill before moving to Step 2. The goal is that by the end of Step 1, every skill in the pipeline exists and has a SKILL.md.
Why auto-create matters: Asking the user to leave this workflow, manually create each skill, and come back breaks the flow. By invoking Skill Creator inline, the entire pipeline gets built in one session — from zero skills to a fully wired workflow.
Step 2: Map the Pipeline
Draw the flow and choose a chaining mechanism for each edge:
[Skill A] --→ [Skill B] --→ [Skill C] (terminal)
explicit explicit
For each transition, decide:
- Explicit Handoff (
→ INVOKE:) — The default. Use when A always leads to B.
- Conditional Branch (
IF/ELSE → INVOKE:) — Use when the next skill depends on a condition (e.g., tests pass → send PR, tests fail → debug).
- Pass-through data — If Skill B needs output from Skill A, document what artifact or state gets carried forward.
Step 3: Wire Each Skill
For each skill in the pipeline, add chaining directives to its SKILL.md. Modify the existing skill files — don't create separate wrapper skills.
Handling Third-Party Skills
Some skills belong to other skillsets (e.g., superpowers:test-driven-development) and must not be modified — they're maintained externally and your edits would be overwritten or cause conflicts.
For these skills, create a thin wrapper skill that:
- Invokes the third-party skill to do the actual work
- Adds the
→ INVOKE: handoff that the original skill lacks
---
name: tdd-implementation
description: Wrapper that runs TDD implementation via superpowers and
hands off to the next workflow step.
---
# TDD Implementation (Workflow Wrapper)
This is a workflow wrapper around `superpowers:test-driven-development`.
## Process
→ INVOKE: superpowers:test-driven-development
Let the TDD skill run its full process. Do not interfere with its workflow.
## On Completion
When all tests pass and code is committed:
→ INVOKE: my-workflow:send-slack-pr
Announce: "Using send-slack-pr to create the PR and notify the team."
## Integration
**Workflow:** jira-to-pr
**Called by:** my-workflow:get-jira-ticket
**Calls:** my-workflow:send-slack-pr
**Wraps:** superpowers:test-driven-development
**Receives:** Ticket summary, acceptance criteria, branch name
**Produces:** Committed code, passing tests, PR-ready branch
Key rules for wrappers:
- The wrapper's only job is to invoke the third-party skill and then hand off to the next step. It adds no extra logic.
- Use
**Wraps:** in the Integration section to document which external skill it delegates to.
- Name the wrapper after the job it performs (e.g.,
tdd-implementation), not after the skill it wraps.
- If the third-party skill is in a skillset you own, prefer modifying it directly over creating a wrapper.
How to decide: modify vs. wrap?
| Condition | Action |
|---|
| Skill is in the same project/skillset | Modify directly — add ## On Completion |
| Skill is in an external skillset (e.g., superpowers) | Create a wrapper |
| Skill was auto-created by Skill Creator in this workflow | Modify directly |
| Unsure who maintains the skill | Create a wrapper (safer) |
For the first skill through second-to-last skill, add an ## On Completion section:
## On Completion
When [this skill's work] is done:
→ INVOKE: skillset:next-skill-name
Announce: "Using [next-skill] to [purpose]."
For conditional transitions, use:
## Next Step
- **IF** [condition]:
→ INVOKE: skillset:skill-a
- **IF** [other condition]:
→ INVOKE: skillset:skill-b
- **DEFAULT**: Ask the user.
For the last skill, mark it as terminal:
## On Completion
This is the final step. The workflow is complete.
Announce: "Workflow [name] complete. [summary of what was accomplished]."
For every skill, add an ## Integration section for documentation:
## Integration
**Workflow:** workflow-name
**Called by:** skillset:previous-skill (or "entry point")
**Calls:** skillset:next-skill (or "terminal")
**Receives:** [what input/artifact from previous skill]
**Produces:** [what output/artifact for next skill]
Step 4: Create the Workflow Entry Point Skill
Generate a new skill that serves as the trigger for the entire workflow. This skill doesn't do heavy work — it validates preconditions and kicks off the first job skill.
---
name: workflow-name
description: Use when [the trigger condition]. Runs the full
[workflow-name] pipeline: [skill-a] → [skill-b] → [skill-c].
---
# [Workflow Name]
Runs the complete pipeline:
1. **[Skill A]** — [what it does]
2. **[Skill B]** — [what it does]
3. **[Skill C]** — [what it does]
## Preconditions
Before starting, verify:
- [ ] [Required input or context is available]
- [ ] [Required tools/APIs are accessible]
## Start
Gather any required input from the user, then:
→ INVOKE: skillset:first-skill-name
Announce: "Starting [workflow-name]. First step: [first-skill description]."
## Integration
**Skills in this workflow:**
- skillset:skill-a → skillset:skill-b → skillset:skill-c
**Entry trigger:** [what the user says to start this]
Step 5: Validate the Chain
Walk through the pipeline end-to-end:
Example: Jira-to-PR Workflow
A concrete example. The user says: "I want a workflow that fetches a Jira ticket, does TDD implementation, then sends the PR to Slack."
Step 1 — Inventory: Check which skills exist.
| Skill | Exists? | Action |
|---|
get-jira-ticket | No | → INVOKE Skill Creator to create it (uses Jira MCP tools, outputs ticket summary + acceptance criteria) |
tdd-implementation | No (but superpowers:test-driven-development exists) | → Create a wrapper skill that invokes superpowers:test-driven-development and adds chaining |
send-slack-pr | No | → INVOKE Skill Creator to create it (uses gh CLI + Slack MCP, outputs PR link + notification) |
After Skill Creator finishes both missing skills, all three exist. Continue to Step 2.
Step 2 — Map the pipeline:
[get-jira-ticket] → [tdd-implementation] → [send-slack-pr]
Steps 3-5 — Wire, create entry point, validate (same as before).
Entry point skill (jira-to-pr/SKILL.md):
---
name: jira-to-pr
description: Use when the user wants to pick up a Jira ticket and work it
through to PR with Slack notification. Triggered by "run jira-to-pr" or
"pick up [JIRA-123]".
---
# Jira to PR Workflow
1. **get-jira-ticket** — Fetch ticket details and acceptance criteria
2. **tdd-implementation** — Implement with TDD using superpowers
3. **send-slack-pr** — Create PR and notify the team on Slack
## Start
Ask the user for the Jira ticket key, then:
→ INVOKE: my-workflow:get-jira-ticket
Announce: "Starting Jira-to-PR workflow. Fetching ticket details."
Wiring added to get-jira-ticket/SKILL.md:
## On Completion
When ticket details and acceptance criteria are extracted:
→ INVOKE: my-workflow:tdd-implementation
Announce: "Using tdd-implementation to implement the ticket with TDD."
## Integration
**Workflow:** jira-to-pr
**Called by:** my-workflow:jira-to-pr (entry point)
**Calls:** my-workflow:tdd-implementation
**Produces:** Ticket summary, acceptance criteria, branch name
Wrapper skill created: tdd-implementation/SKILL.md (wraps superpowers:test-driven-development):
---
name: tdd-implementation
description: Wrapper that runs TDD implementation via superpowers and
hands off to the next workflow step.
---
# TDD Implementation (Workflow Wrapper)
This is a workflow wrapper around `superpowers:test-driven-development`.
## Process
→ INVOKE: superpowers:test-driven-development
Let the TDD skill run its full process. Do not interfere with its workflow.
## On Completion
When all tests pass and code is committed:
→ INVOKE: my-workflow:send-slack-pr
Announce: "Using send-slack-pr to create the PR and notify the team."
## Integration
**Workflow:** jira-to-pr
**Called by:** my-workflow:get-jira-ticket
**Calls:** my-workflow:send-slack-pr
**Wraps:** superpowers:test-driven-development
**Receives:** Ticket summary, acceptance criteria, branch name
**Produces:** Committed code, passing tests, PR-ready branch
Wiring added to send-slack-pr/SKILL.md:
## On Completion
This is the final step. The workflow is complete.
Announce: "Jira-to-PR workflow complete. PR created and team notified on Slack."
## Integration
**Workflow:** jira-to-pr
**Called by:** my-workflow:tdd-implementation
**Calls:** None (terminal)
**Receives:** PR-ready branch, ticket reference
**Produces:** PR link, Slack notification
Chaining Protocol Reference
Explicit Handoff (strongest)
Always use for unconditional A → B transitions.
## On Completion
When [done]:
→ INVOKE: skillset:next-skill
Announce: "Using [next-skill] to [purpose]."
Conditional Branch
Use when the path depends on state or user choice.
## Next Step
- **IF** [condition]: → INVOKE: skillset:skill-a
- **IF** [condition]: → INVOKE: skillset:skill-b
- **DEFAULT**: [fallback]
Required Sub-Skill (cross-session)
Use when a skill produces an artifact another skill must consume, even across sessions.
**REQUIRED SUB-SKILL:** Use skillset:consuming-skill to process this.
Implicit Trigger (weakest)
Use for cross-cutting concerns only (verification, debugging).
## Implicit Triggers
After this skill, watch for:
- [condition] → a [type] skill should fire
Debugging a Broken Chain
When a workflow doesn't advance to the next skill:
- Check the directive: Is
→ INVOKE: present and spelled correctly?
- Check skill names: Does the name match the
name field in the target skill's frontmatter exactly?
- Check the condition: For conditional branches, is the condition evaluable?
- Check the announcement: If no announcement appears, the handoff isn't firing.
- Check the description: For the entry point skill, does its description match how the user triggers it?
- Trace end-to-end: Walk through each skill in order and verify each
→ INVOKE: points to the right next skill.