Part 5 of 7

Part 5 — The Pipeline: Wiring It Together

ai claude cowork pipeline integration skills agents cowork-skills cowork-agents

Created: April 17, 2026 | Modified: April 21, 2026

Cowork Features

Used: Skills, Agents, Rules, CLAUDE.md, Memory

Your workspace has staff. In Part 3 and Part 4 you built the first two Skills and the first two Agents your role's pipeline plan called for. Each is competent in isolation. None is talking to the others.

Part 5 fixes that. You stop running each tool in its own conversation and start running them as a workflow where the output of one becomes the input of the next. The sequence — which stages in which order, who owns each artifact, where the gates sit — is not invented here; it is declared in the pipeline section of your CLAUDE.md. Part 5 explains the concept; CLAUDE.md supplies the specifics for your role.

Jumping in from mid-series? See Part 3's Quick Start for the starter config. This part assumes you have a Cowork project with CLAUDE.md, rules in .claude/rules/, and the anchor Skills and Agents from Parts 3-4 already saved in their folders.

What a Pipeline Is

A team does this with people. One person drafts, another reviews, a third plans, a fourth produces. Each handoff has a defined input, a defined output, and a quality check between. A pipeline replaces those handoffs with the Skills and Agents from Parts 3-4 — each stage passes its work to the next, and you stay in the loop at every checkpoint.

The stages are role-specific. Three examples, same shape:

A content role's pipeline runs Brief → Voice Check → Campaign Plan → Asset Production → Distribution → Measurement.
A sales role's pipeline runs Inbound Capture → Discovery → Proposal → Procurement Review → Close → Post-Close Feedback.
A support role's pipeline runs Triage → Investigation → Response Drafting → QA Review → Send.

What stages your role has is documented in CLAUDE.md. What each stage owns, what artifact it emits, and what gate sits at its boundary are documented there too. Part 5 does not invent a pipeline; it wires the one CLAUDE.md already describes.

A closer look — Pipelines (community term)

Pipelines is a community term, not an official Cowork feature shipped under that name.

What file. No dedicated file or folder — the chain is built from Skills, Agents, and Scheduled Tasks.
When written. Never written as a Pipelines artifact — the underlying pieces each write to their own files.
What format. Convention only — the pattern lives in how you sequence the Skills and Agents you already built.
How to inspect. Read the Skill and Agent files in the chain, and the Scheduled Task that triggers it.
How to undo. Edit the underlying Skills, Agents, or Scheduled Tasks — there is nothing Pipelines-specific to undo.

There is no Pipelines tab in the sidebar and no dedicated Pipelines section in the product. The closest official feature is scheduled tasks in Claude Cowork, covered in Part 7 — Scaling. Scheduled Tasks automate when a pipeline runs, and the pipeline itself remains the pattern.

Gotcha. A scheduled run is only as good as the pieces underneath it. If your Skill is shaky or your Agent brief is loose, putting it on a timer does not improve it — it makes it wrong on a schedule instead of once.

Here is the generic flow — CLAUDE.md fills in the stage names:

INPUT (topic, lead, ticket, incident — whatever your role consumes)
  |
  v
[Stage 1 owner]  -- Skill or Agent: produces the first structured artifact
  |
  v
[Stage 2 owner]  -- audits or gates the artifact against standing rules
  |
  v
[Stage 3 owner]  -- turns the audited artifact into a plan or decision
  |
  v
[Stage 4 owner]  -- produces the delivered work the plan called for
  |
  v
OUTPUT (assets, proposal, response, remediation — whatever your role ships)

Each arrow is a handoff CLAUDE.md names, each stage has a documented artifact path, and each boundary is a checkpoint where you approve or send the work back. You are not building anything new at this step — you are wiring what exists into a single connected workflow with defined inputs, gates, and predictable output every run.

Gotcha — no built-in hand-off between stages

There is no built-in way for one stage to pass working context to the next. The conversation itself is the shared memory. The moment you leave the conversation, that shared memory is gone. If you run Stage 1 in one chat and try to run Stage 2 in a separate chat the next day, the second chat will not see the Stage 1 output unless you paste it in, or unless the relevant facts made it into Memory. For a pipeline you run often, keep it inside one long-running conversation, or save the in-between outputs to files the next stage reads explicitly.

Wire It Together

Run the full pipeline in a single Cowork session — one conversation, every stage CLAUDE.md documents, one input carried all the way through. The shape below is generic; substitute your own stage names and artifacts from the pipeline section of CLAUDE.md.

Stage 1: Produce the First Artifact

Open your Cowork project and start a new conversation. Invoke the Skill or Agent CLAUDE.md names as the Stage 1 owner, and hand it the input your role consumes — a topic, a lead record, a ticket, an incident. The Stage 1 owner emits the first structured artifact: a brief, a qualified lead record, a triage summary, whichever CLAUDE.md documents.

Read it. Does it capture the actual goal? Are the facts right? Is the classification (audience, segment, severity) aligned with what you know about the input? If the Stage 1 artifact is off, correct it now. A bad first artifact produces a bad second, a bad second produces a bad third, and every error compounds downstream. It is cheaper to fix at Stage 1 than to rework the output of Stage 4.

Stage 2: Run the Gate

Take the Stage 1 output and run it through the Stage 2 owner CLAUDE.md names — the Skill or Agent whose job is to audit, score, or qualify the Stage 1 artifact before it advances.

Run the [Stage 2 Skill or Agent] on the artifact above.
Apply the rubric declared in .claude/rules/<relevant-rule>.md.

Stage 2 is where the rubric lives. A voice-check stage reads a voice rule file and flags drift; a qualification stage reads an ICP declaration and scores a lead; a QA-review stage reads a response-quality rule and grades a draft. Some flags are valid catches. Others are false positives. Accept or reject each, and produce the audited artifact that Stage 3 will consume.

Stage 3: Build the Plan or Decision

Feed the audited artifact to the Stage 3 owner. This is usually the stage where judgment enters — the stage that produces a plan, a proposal, a remediation sequence, whatever your role's "decide what we are going to do" step looks like.

Run the [Stage 3 Agent] on the audited artifact above.
Respect the constraints declared in CLAUDE.md and the relevant rule files.

Check the output against reality. Does the plan fit your capacity? Do the named resources — channels, segments, teams, tools — actually exist in your workspace? Adjust before moving on. Stage 3 outputs are the most expensive to produce and the most expensive to rework later; the gate before Stage 4 is the one to take seriously.

Stage 4: Produce the Delivered Work

Hand the approved plan to the Stage 4 owner. This is the stage that produces the actual thing that ships — the assets, the proposal document, the customer-facing response, the remediation commits.

Run the [Stage 4 Agent] on the plan above. Produce each deliverable the
plan names, applying the voice, structure, and format rules declared in
.claude/rules/.

Every deliverable should trace back to a specific line in the Stage 3 plan, inherit voice and structure from the standing rules, and carry whatever cross-reference CLAUDE.md requires. Review each, approve or revise, and the pipeline has produced its run of output.

Later stages

Some roles stop at four stages. Some document more — a Distribution stage, a Procurement Review stage, a Post-Close Feedback stage, a Measurement stage. The pattern does not change as you add stages: each one names an owner, documents an artifact, and sits behind a gate. CLAUDE.md is the source of truth for your pipeline shape and what each stage produces; Part 6 picks up the Measurement stage specifically.

Troubleshooting and Guardrails

The Stage 2 gate flags too much. Your rule file is too strict. Open the rule the gate reads (.claude/rules/<name>.md) and loosen — if every adjective is banned, allow role-specific ones; if every sentence must be under 15 words, raise the limit. The gate enforces whatever you wrote.

Stage 3 produces generic plans. Segments vague, recommendations bland, next steps interchangeable. The agent pulls from CLAUDE.md, and CLAUDE.md does not have enough specifics. Add your actual product, real customer pain points, real operational constraints with concrete details.

Stage 4 loses voice or structure. One deliverable sounds right, another sounds like a template. Strengthen the relevant rule file with format-specific guidance — "In this format, write this way. In that format, write that way."

Stage 1 is fine but Stage 3 contradicts it. Add explicit constraints when you hand work to the Stage 3 owner. A CLAUDE.md-declared constraint ("this is a retention motion, not an acquisition motion" or "this is enterprise, not SMB") should carry through every stage; if it is not, the Stage 3 prompt needs to restate it.

When to stop and fix. Not every problem needs to cascade through the full pipeline:

After Stage 1: If the first artifact targets the wrong audience or misses the goal, stop. Do not gate an artifact pointed in the wrong direction.
After Stage 2: If the gate finds more than three critical issues, the artifact needs a rewrite, not a patch.
After Stage 3: If the plan references resources or segments that do not match reality, the plan is theoretical. Fix it before producing deliverables.
After Stage 4: If the deliverables do not match the plan, tighten the Stage 4 owner's definition, not the individual pieces.

Extending: Adding a Skill to the Pipeline

Once the core pipeline runs clean, extensions arrive. A last-mile format you need but no current stage produces. A specialized output your role delivers once a quarter. A new rule file one stage should consult.

The mechanics are Part 3 mechanics — you already know how to build a Skill. The pipeline question is where the Skill slots in. Three placements cover most cases:

Between two existing stages. The new Skill consumes the prior stage's artifact and emits a transformed artifact the next stage reads. Insert it into the pipeline section of CLAUDE.md and rebuild the conversation flow.
In parallel with an existing stage. The new Skill runs against the same input as an existing stage and produces a complementary artifact — a second rubric on the same draft, a second classification on the same record.
As a post-processor on a stage output. The new Skill runs only after Stage N succeeds and produces a derived output the next stage would not otherwise produce — a format-specific variant, a summary, a translation.

Keep specs in a separate rule file

When the Skill depends on specs that drift (platform character limits, vendor SLAs, regulatory cadences), put them in a rule file rather than the Skill prompt. The Skill reads the rule file on every run, so you update one file instead of editing the Skill. This is the same rule-file discipline from Part 2 applied inside the pipeline.

The easy path: /skill-creator. Cowork's built-in Skill-building Skill is the canonical route. Open a new conversation, type /skill-creator, and describe the stage the new Skill sits in, what it consumes, and what it emits. The Skill file lands in .claude/skills/; update the pipeline section of CLAUDE.md so the next run of the pipeline invokes it at the right point.

Extending: Adding an Agent to the Pipeline

Skills handle one-step transformations. When the new stage needs judgment across multiple sub-steps — select among options, sequence work, decide what to include and what to drop — the primitive is an Agent, not a Skill, and Part 4's mechanics apply.

Three recurring patterns for Agent-shaped stages:

A scheduling or orchestration stage. Takes the prior stage's deliverables and decides when, in what order, and through which channels they reach the next destination. The sales pipeline's procurement-review stage, the content pipeline's distribution stage, the support pipeline's escalation-routing stage all fit this shape.
A gating stage with discretion. A rubric alone is not enough; the stage needs to decide whether an edge case clears or escalates. A human-in-the-loop approval checkpoint sits on top, but the Agent does the structured read that feeds the decision.
A measurement or feedback stage. Reads closed work, clusters drivers, writes structured records into Memory the next pipeline run will read. This is the stage Part 6 builds out specifically.

The placement logic is the same as for Skills — name the stage in the pipeline section of CLAUDE.md, document its owner, document its artifact, and insert it at the right boundary.

The Agents section of CLAUDE.md names the Cowork agent type (e.g., cagents:content-marketing-manager, cagents:business-development-manager) each archetype maps to. The pipeline stage cites the archetype by name; the agent type is an implementation detail. If you change the underlying agent type later, update the Agents section of CLAUDE.md and the pipeline keeps working.

When to Promote a Pipeline to a Scheduled Task

Once the manual pipeline feels boring — same inputs, same review points, same outputs — that is the signal to let Cowork run it on a cadence. Scheduled Tasks fire the whole sequence on a schedule you define, using the same CLAUDE.md, Rules, Skills, and Agents you built here. Part 7 — Scaling covers the automation step in detail.

The hire framing still applies. Right now your workspace does drop-in meetings: you start a conversation, walk through the stages, review each handoff. Scheduling promotes those drop-ins to standing meetings on the role's calendar. But you only put a standing meeting on someone's calendar once the one-off version has proven it works. A flaky pipeline on a cadence just produces flaky output on a cadence.

Off-Ramp 2 — What You Have Built

What you have built: A complete role-scoped pipeline — from raw input to delivered output — with a rubric gate between stages, human approval at every boundary, and a saved file at each stage so the next run can read the last one. This system works as-is and will produce results today.

What is ahead: Parts 6-7 add measurement so the pipeline self-improves, then automation so it runs on a schedule. Worth doing when you are ready — but what you have now is already working for you.

With the pipeline, you hand in the input and walk through the stages. Each stage has defined inputs, defined outputs, and a quality gate before the next one starts. Your fifth run goes through the same pipeline as your first. You can stop here; the combination of a role-scoped Project, standing rules, named Skills, and sequenced Agents is already a serious operation.

What Just Changed

No new file for the pipeline itself — it is conversation flow plus the pipeline section of CLAUDE.md, not a /pipelines/ folder. Future turns chain the anchor tools from Parts 3-4 through prompts you now know how to write.

Any extension Skills and Agents you added for your role land in their familiar folders — .claude/skills/<name>/SKILL.md, .claude/agents/<name>.md, plus any new rule files under .claude/rules/. Your .claude/ folder now carries everything the pipeline needs, callable from the same conversation. The setup's final pipeline step writes .claude/memory/pipeline-first-run.md so Part 6's measurement framework reads real Memory entries, not theoretical ones.

What Is Next

Running on a cadence feels productive. A full calendar of stages looks like progress. But the numbers that say the pipeline worked — whatever your role's equivalents are — are the only ones that matter, and right now you are not tracking them in any structured way. You are guessing.

In Part 6 — Measurement, you build a metrics framework. Your workspace helps you define what "working" means for your role, pick the KPIs that indicate real progress, and set up a review cadence so you catch what is underperforming before you have wasted a quarter on it. The pipeline tells you what to ship and when. The measurement framework tells you whether it mattered.

Part 5 of 7