Workflows

A Claude Code skill for building multi-step workflow pipelines from skills — creating missing skills on the fly and wiring everything into an automated chain.

Overview

workflow-chain is a workflow engine skill that turns a sequence of jobs (e.g., “fetch Jira ticket → TDD implementation → send PR to Slack”) into a fully wired skill pipeline. It follows a decentralized chaining model: each skill owns its own routing logic, rather than relying on a centralized orchestrator.

Key Features

• Auto-create missing skills — If a skill in the pipeline doesn’t exist, automatically invokes Skill Creator to build it inline
• Third-party skill wrapping — Handles skills from external skillsets (e.g., superpowers) by creating thin wrapper skills, without modifying the originals
• Decentralized routing — Each skill defines its own → INVOKE: handoff, keeping the chain maintainable and debuggable
• Conditional branching — Supports IF/ELSE → INVOKE: for pipelines with decision points
• Built-in debugging guide — Step-by-step checklist for diagnosing broken chains

Installation

This is a Claude Code skill. Place it in your project’s skill directory:

your-project/
└── skills/
    └── workflow-chain/
        └── SKILL.md

Prerequisites

• Claude Code with skill support
• (Recommended) Skill Creator — for auto-creating missing skills in the pipeline

Usage

Trigger the skill by describing a multi-step workflow:

"I want a workflow that fetches a Jira ticket, does TDD implementation, then sends the PR to Slack."

Or explicitly:

"Run workflow-chain to wire these three skills together."

The 5-Step Process

1. Inventory — List all skills, check which exist, auto-create missing ones
2. Map — Draw the pipeline flow and choose chaining mechanisms
3. Wire — Add → INVOKE: directives to each skill’s SKILL.md
4. Entry Point — Create a trigger skill that kicks off the pipeline
5. Validate — Walk through end-to-end to verify the chain

Example: Jira-to-PR Workflow

[get-jira-ticket] → [tdd-implementation] → [send-slack-pr]

Chaining Protocol

Explicit Handoff (default)

## On Completion
When [done]:
→ INVOKE: skillset:next-skill
Announce: "Using [next-skill] to [purpose]."

Conditional Branch

## Next Step
- **IF** [condition]: → INVOKE: skillset:skill-a
- **IF** [condition]: → INVOKE: skillset:skill-b
- **DEFAULT**: Ask the user.

Third-Party Wrapper

For skills from external skillsets that can’t be modified directly:

---
name: tdd-implementation
description: Wrapper that runs TDD via superpowers and hands off to the next step.
---
## Process
→ INVOKE: superpowers:test-driven-development
## On Completion
→ INVOKE: my-workflow:send-slack-pr

Eval Results

Tested across 2 iterations with 6 eval scenarios using Skill Creator’s eval framework (executor: claude-opus-4-6).

Iteration 1 — Protocol Validation

Iteration 2 — Real-World Scenarios

Key finding: Without the skill, agents default to a centralized orchestrator anti-pattern. With the skill, routing logic is distributed to each skill (decentralized), making chains more maintainable.

Project Structure

workflows/
├── README.md
├── skills/
│   └── workflow-chain/
│       └── SKILL.md              # The skill definition
└── workflow-chain-workspace/
    ├── evals/
    │   └── evals.json            # Test case definitions
    ├── iteration-1/              # First eval iteration
    │   ├── benchmark.json
    │   └── eval-*/               # Per-test results
    └── iteration-2/              # Second eval iteration
        ├── benchmark.json
        └── eval-*/

Design Decisions

Why Decentralized Routing?

A centralized router creates a single point of failure and makes it hard to reuse skills across workflows. By having each skill own its → INVOKE: directive, skills become composable — you can rewire them into different workflows without changing a central config.

Why Wrappers for Third-Party Skills?

External skills (e.g., from superpowers) are maintained by other teams/projects. Modifying them directly would cause merge conflicts or get overwritten on updates. Thin wrappers preserve the original skill while adding the chaining protocol.

Why Auto-Create via Skill Creator?

Asking users to leave the workflow, manually create each missing skill, and come back breaks the flow. Inline creation keeps the entire pipeline buildable in one session — from zero to a fully wired workflow.

License

Private project.