Part 5 — Pipelines

This part assumes the workspace is already in active use. The earlier walkthroughs gave it single-purpose pieces: the always-on rules (a way to sound, a check before something is sent), the procedures (the work you do twice a week), the focused helpers (the work that needs an actual look). Each piece runs on its own and produces something useful by itself.

Part 5 is for the work that needs more than one piece.

The trunk-and-branches metaphor that carried us this far has done its job. The shape is the same; from here on it is just files on disk and the lines in the Instructions that point at them.

The kind of work where you do one thing, then look at what came back and do another thing with it, then check it against something, then turn the result into a deliverable. End-to-end. Part 5's walkthrough captures that sequence as its own file so the workspace can run it the same way each time, with you in the loop at the boundaries that matter.

When you finish, your folder holds new pipeline files that describe, in your words, the multi-step work this workspace runs end-to-end, sitting alongside what you already built. The Instructions file at the root has new lines appended underneath what was already there. Nothing existing got moved or rewritten.

What that buys you:

• Multi-step work documented as a sequence you run on purpose, not a habit you carry in your head.
• The Instructions file at the root grows by one named line per pipeline, appended underneath what was already there. Existing lines stay exactly as they were.

What a pipeline actually is here

A pipeline in this workspace is a markdown file that describes a sequence: do this, then look at the result, then do that with it, then check it against this, then produce the deliverable. Same shape as everything else in this series — a file you named, sitting alongside the Instructions, that the workspace reads when the work calls for it.

Each step is something the workspace already knows how to do, usually a procedure or a focused helper. The pipeline file is the thing that says which order to run them in and where you want to look before each handoff.

That last bit matters. A pipeline is not "press a button and watch it run." It's "here's the sequence; show me the output of each step before moving to the next." The boundaries are the point.

The reason to write a pipeline down is that the sequence lives in your head, which means the steps that need your eyes on them sometimes get skipped. Once the sequence is in a file, those checkpoints are explicit and the workspace honours them.

The kinds of work that benefit from being captured as a pipeline are the ones where the steps are stable but the input changes every time. The same five moves on a different brief. The same three checks on a different draft. The intake-to-deliverable arc you've already run, just with a new request feeding it. If the steps shift every time the work shows up, that's not a pipeline yet. It's still the work of a focused helper.

How to run it

Open the prompts panel and paste the Part 5 prompt. The model re-reads the Instructions file at the root and the workspace you've grown around it, asks you in one sentence what kind of multi-step work you want this workspace to run end-to-end, and walks you through the rest. You name everything. The model proposes shapes; you decide what each pipeline is called and where it lives.

If the Instructions file isn't at the root, or doesn't show the setup-walkthrough shape, the prompt halts and tells you to run Part 1 first. The intermediate walkthroughs aren't strictly required — this one will work with whatever pieces you've built — but the more pieces are there, the more the pipelines can lean on them instead of restating the steps inline.

What happens when you paste the prompt

Same shape as the earlier walkthroughs, scoped to multi-step work. End to end, with the two boundaries that don't move forward without you:

flowchart TD
    A[Read what is on disk] --> B[Ask: one sentence on the multi-step work]
    B --> C[Multiple-choice questions if the sentence is thin]
    C --> D[Propose a list of pipelines]
    D --> E{You walk the list:<br/>drop, rename, reorder, add}
    E --> F[Fit each pipeline into a slot]
    F --> G[Draft each pipeline file]
    G --> H{You read each draft:<br/>accept, edit, or reshape}
    H --> I[Append approved lines to Instructions]

    classDef step fill:#14b8a6,stroke:#14b8a6,color:#141414
    classDef checkpoint fill:none,stroke:#ca8a04,color:#ca8a04,stroke-width:2px
    class A,B,C,D,F,G,I step
    class E,H checkpoint

The prompt opens by reading what is already on disk: the Instructions, the slots, the procedures and helpers you've added across earlier parts. It confirms what it found with you. Then it asks you, in one sentence, what kind of multi-step work you want this workspace to run end-to-end. Short, plain answers work. If the sentence is thin, the prompt asks a few short multiple-choice questions to thicken it. What triggers a run. Where the work usually ends up. Where you want to put your eyes before moving forward.

From your answer, the prompt proposes a list of pipelines this workspace will want to run. Each one is described as a short sequence in plain language: intake the input, run [the kind of check] on it, produce the [shape of artifact], hand it back. No filenames yet. The procedures and helpers each step uses are referenced by what they do, not by where they live.

You walk through the list with the prompt: drop one, rename one, change the sequence inside one, add what's missing, or say it looks right. The list does not move forward until you say it does.

Then placement. The prompt fits each pipeline into a slot you already named, or asks you about adding a new slot if nothing existing fits. Same as every part before this. The prompt will not propose a new slot unilaterally.

Then it goes one pipeline at a time. For each one, you name the file. The prompt drafts what's inside it: the sequence, the steps, the checkpoints, what the workspace should pause for at each handoff. It uses the procedures and helpers already in place wherever they fit, so the pipeline file does not restate work that's already captured elsewhere. You read, accept, edit, or ask for a different shape. Nothing lands until you say go.

When the files are written, the prompt shows you the exact new lines it wants to append to the Instructions, one per pipeline, in the same ALWAYS read [your-file] for [what-it-runs] shape. You approve. The new lines land underneath what was already there.

When you're done

The workspace runs the pipelines you just named. When you bring it a piece of work that fits one, it follows the sequence in the file, pauses where the file says to pause, and produces the deliverable at the end. The procedures and helpers from earlier parts get used inside the pipelines instead of needing to be invoked one by one.

A practical thing worth knowing. The first few real runs through a pipeline almost always surface a step you wrote loosely. That's normal. Open the file and tighten the step. The next run reads the saved version. Pipelines get sharper through use, same as everything else in this series.

Next: Part 6 — What's Missing extends the same workspace by addressing what's drifted now that you have been using it for a while.