The Pipelinely Way

I've been working with Claude Code for almost a year.

Like most people, I started in the terminal.

One task. One Claude session. Watch it work.

It didn't stay that way for long.

I discovered git worktrees and realized I didn't need to wait for one task to finish before starting another.

So I started parallelizing.

One worktree became two. Two became four. Soon I had multiple Claude Code sessions working on completely different tasks at the same time.

It was incredibly productive.

It was also exhausting.

I found myself babysitting terminal tabs all day.

Which one is planning? Which one finished? Which one needs me? Did I review that plan? Where was that code review? Which worktree is this? A few times I even typed into the wrong terminal tab entirely.

As a frontend developer, spending my entire day navigating terminal tabs felt wrong.

And by the end of the day, my brain felt like mashed potatoes.

The funny thing was that the agents weren't the problem.

My workflow with them had actually become pretty good.

The problem was that I had become the orchestrator.

---

My workflow had quietly become a pipeline

I wasn't just throwing tasks at Claude and hoping for good code.

Over time, I'd developed a pretty opinionated process for getting from an idea to something I'd actually merge.

Almost every meaningful task started with a plan.

I'd start an Opus 5 agent and ask it to create a tech-design.md.

What actually moved the needle was crafting my own tech-design.md template — shaped by how I used to write tech designs myself, back from the era when I wrote the code by hand. I wrote about that approach here: Tech Design: Get Things Done On Time.

I wanted more than an implementation proposal. I wanted the work broken down into deliverable milestones—small enough to implement and verify independently, with clear boundaries between them.

But I learned that having an agent create a plan and immediately execute its own plan wasn't enough.

So I added another step.

Plan the work. Then challenge the plan.

Once the first plan was ready, I'd start a fresh Opus 5 agent to review it.

That fresh context mattered.

The reviewing agent hadn't spent the previous session convincing itself that its approach was correct. It could challenge assumptions, find holes and look at the problem from another direction.

Then I'd do the final round myself with tools like Plannotator.

I'd question the plan, challenge decisions and make sure I actually understood and agreed with what we were about to build.

Only then would I start development.

It might sound like a lot of planning for an agent that can start coding almost instantly.

That's exactly why I do it.

Writing code became cheap. Going in the wrong direction didn't.

---

Then came orchestration

Once I had a plan I trusted, I'd take each milestone and feed it into an orchestrator skill I'd built.

The goal wasn't simply:

Implement this.

I wanted the agent to approach the milestone the way I would.

What needs to be tested?

Do we need analytics?

What happens when this fails?

What should we log?

What edge cases are we introducing?

What does "done" actually mean?

And then there was context.

I learned that keeping the same Claude session alive forever wasn't necessarily a good thing.

As the conversation grows, so does the baggage.

So I started actively trying to avoid context bloat.

And when a session did get too heavy, I built a handover skill to capture what mattered and let a fresh agent continue the work.

That led to a principle I still use:

Keep the work. Not necessarily the session.

---

Dev should know how you write code

There was another problem I wanted to solve.

Getting Claude to write working code isn't particularly hard anymore.

Getting it to write code the way I would have written it is different.

I spent years at HoneyBook writing code, reviewing PRs and developing opinions about all the tiny decisions that eventually become engineering taste.

Naming.

React architecture.

Duplication.

TypeScript.

Testing.

Analytics.

Error handling.

Responsive behavior.

How components should be structured.

Even how PRs should be broken down.

I didn't want to explain those preferences every time I started a fresh agent.

So I turned them into a skill.

I distilled roughly 600 real PRs I worked on at HoneyBook into concrete engineering rules and patterns.

Some are small:

Don't call something data. Name the thing.

Don't use a magic number. Tell me what the number means.

Don't be cheap with characters. Give things meaningful names.

Others are architectural:

Don't let generic components depend on feature-specific behavior.

Don't put side effects inside useMemo.

Don't use setTimeout when there's a proper event-driven solution.

Don't duplicate logic because the second use case is slightly different.

The skill even captures opinions around how I structure tests, components and PRs.

These aren't rules I invented for Pipelinely.

They're accumulated preferences from years of building and reviewing software.

Some are probably objectively good ideas.

Some are probably just me.

That's the point.

When my Dev stage starts, I don't want a generic coding agent.

I want an agent that understands how I like software to be built.

This gave me another principle:

Fresh context. Persistent standards.

I want a fresh agent when fresh eyes matter.

I don't want that fresh agent to forget everything I've learned over the years.

That's what skills are for.

---

Don't let the implementation review itself

Once development was finished, I still wasn't done.

I'd run T2A Review, a self code-review agent we originally built at HoneyBook, against my changes.

T2A came from trying to capture how our team actually reviewed code—not just generic "find bugs" instructions, but the engineering opinions and patterns we cared about.

We eventually wrote about how we built it in the HoneyBook Engineering article, We Accidentally Built an AI Code Reviewer That Thinks Like Us.

Then came verification.

I'd write E2E tests and run them against my implementation.

I'd do manual QA.

If something failed, I'd fix it and verify it again.

Only after the task survived that process would I merge it.

At some point I looked at everything I was doing and realized:

This isn't a collection of prompts anymore.

It's a pipeline.

Plan → Plan Review → Dev → Code Review → QA → Merge

Different stages need different instructions.

Different stages benefit from different context.

Some can happen automatically.

Some require me.

And I was manually holding the whole thing together through terminal tabs.

---

The agents weren't the problem anymore. I was.

Claude had made me dramatically more capable.

I could have several tasks progressing at once.

Worktrees meant they weren't stepping on each other.

Skills gave me repeatable processes.

Fresh agents gave me independent reviews.

My workflow was working.

But the better it got, the more I had to manage.

All day I was switching terminals.

Checking agents.

Remembering state.

Finding the right worktree.

Looking for something waiting for approval.

Trying to remember whether I'd already reviewed something.

Going back to another terminal.

The agents could parallelize beautifully.

My attention couldn't.

The more parallelism I got from Claude, the more cognitive overhead I created for myself.

That didn't feel right.

So I built myself a dashboard.

---

First came the Command Center

The first version wasn't supposed to become some big product.

I wanted one calm place to see my agents.

What's running?

What's finished?

What's blocked?

What needs me?

Instead of opening terminals to discover their state, I could finally look at the work from above.

That alone made a huge difference.

But once I had the Command Center, something became obvious.

The dashboard knew about my agents.

It didn't know about my workflow.

And the workflow was the interesting part.

I already had planning.

I already had plan review.

I already had an orchestrator for development.

I already had code review.

I already had QA.

I already had rules for context and handovers.

Why was I still responsible for remembering which step came next?

So I put the pipeline into the Command Center.

That's when it started becoming Pipelinely.

---

The workflow became executable

Putting Planning, Dev, CR and QA on a dashboard wasn't enough.

I didn't want Pipelinely to just tell me:

This task is in Code Review.

I wanted it to know how I do Code Review.

So the practices I'd been using manually became skills that Pipelinely triggers as work moves through the pipeline.

Today, Pipelinely encapsulates seven of them:

Planning
/cockpit-plan <slug>
        ↓
Plan Review
/cockpit-plan-review <slug>
        ↓
Development
/cockpit-dev <slug>
        ↓
Code Review
/cockpit-cr <slug>
        ↓
CR Fixes
/cockpit-cr-fixes <slug>
        ↓
QA
/cockpit-qa <slug>
        ↓
QA Fixes
/cockpit-qa-fixes <slug>
        ↓
Merge

They're not seven names for "ask Claude to do something."

Each stage has a different responsibility.

Planning explores the problem and produces the technical design.

Plan Review challenges it with fresh context.

Dev implements the approved milestones using the engineering practices I've accumulated over the years.

CR looks at the implementation with fresh eyes.

CR Fixes takes what the reviewer found and resolves it.

QA verifies the result.

QA Fixes closes whatever gaps QA discovers.

Then the work can move toward merge.

The pipeline defines when work happens.

The skills define how I want it done.

The agents execute it.

Pipelinely holds it together.

My way of working became executable.

That's the part I find most interesting.

I don't want an orchestrator whose only job is to start more Claude Code sessions.

I want the orchestrator to carry the process.

Did we test this?

Did we consider analytics?

Did CR run?

Did we fix what CR found?

Did QA verify the fix?

Is the context getting bloated?

Those things shouldn't live in my head.

They should live in the pipeline.

---

Stop thinking in sessions. Think in tasks.

This became probably the biggest mental shift for me.

A Claude Code session isn't really the thing I care about.

It's an implementation detail.

The task is the thing I care about.

And a task has a lifecycle.

A stage might start a new Claude Code session.

A session might get replaced because its context became bloated.

A milestone might split into several pieces.

Some of those pieces might run in parallel.

I don't want to manage any of that as a collection of terminal tabs.

I want to know:

Where is the task?

Is it moving?

Did the checks pass?

Does it need me?

Everything else is orchestration.

---

Give every task its own space

Parallel agents become much easier when they aren't fighting over the same checkout.

So every task gets its own git worktree.

And every task gets its own persistent tmux session.

That gives the agent an isolated place to work.

But the bigger change for me was psychological:

The session stopped belonging to the tab.

I can close the terminal.

I can go do something else.

I can come back later.

The task is still there.

This sounds like an implementation detail.

For me, it wasn't.

It removed the feeling that I needed to keep every terminal visible just because something might be happening inside it.

---

Let the agents parallelize

Once work is isolated, there's no reason everything needs to happen sequentially.

If a task can be broken into independent milestones, those milestones can run at the same time.

If B depends on A, B waits.

If C and D don't depend on each other, they can run together.

I don't want to manually schedule that either.

I want to describe the dependencies and let the orchestrator figure out the waves.

Agents are incredibly good at making more work happen simultaneously.

We should take advantage of that.

But there was another lesson hiding inside this one.

---

Don't parallelize yourself

This might be the practice I personally use the most.

Once dispatching an agent becomes almost free, every thought becomes dangerously actionable.

I'm working on one task.

I notice something unrelated.

"Oh, Claude could fix that."

Start another agent.

Then I remember another thing.

Start another.

Something else pops into my head.

Start another.

The agents are perfectly happy.

Meanwhile, I've completely destroyed my own focus.

I started thinking about this like meditation.

When you're meditating, the goal isn't to somehow stop thoughts from appearing.

A thought comes.

You notice it.

You don't have to follow it.

You let it go and return to the main thread.

I wanted the same thing while working.

If I'm focused on something and another useful task appears, I don't want to forget it.

But I also don't want to chase it.

I want it to land softly in the backlog.

That's why I built Focus into Pipelinely.

It helps protect the scope of the thing I'm doing now while giving everything else somewhere to go.

The idea survives.

My focus survives too.

Let the agents parallelize. Keep the human focused.

---

Manage attention, not terminals

When one agent is running, checking on it isn't a problem.

When ten agents are running, checking on them becomes a job.

I don't want that job.

So the Command Center isn't really about showing me everything that's happening.

It's about showing me what needs my attention.

An agent is happily implementing something?

Great.

Leave it alone.

A plan needs approval?

That's interesting.

Code Review found something?

I should look.

QA is blocked?

Bring me in.

Everything else can keep moving.

The goal isn't to watch agents work.

The goal is to know when not to watch them.

---

The pipeline should do the remembering

Something unexpected happened once more of my work started flowing through Pipelinely.

It started knowing a lot about my day.

It knows what I started.

What moved through development.

What went through review.

What reached QA.

What finished.

So the next morning, when it's time for daily standup, I don't have to reconstruct yesterday from GitHub, terminal history and my memory.

Pipelinely already saw the work happen.

The history is there.

I hit Copy for standup.

Done.

I didn't build a standup generator.

Standup became a free side effect of having structured work.

I suspect there are going to be many more things like this.

Once the orchestrator understands the lifecycle of the work, a lot of the administrative work surrounding it can simply disappear.

---

Keep the human at the gates that matter

My goal with all of this isn't full autonomy.

And it isn't maximum agent activity.

I want controlled autonomy.

There are moments where Claude doesn't need me.

Let it work.

There are moments where another agent can independently check the result.

Let it check.

And there are moments where judgment matters.

That's where I want to be.

A good agent workflow, for me, isn't one where the human disappears.

It's one where the human stops being interrupted by things that don't require human judgment.

The agents can stay busy.

I don't have to be.

---

So, what is Pipelinely?

Pipelinely didn't start because I wanted to build an AI orchestration platform.

I built it because my own way of working had gradually become a pipeline, and I was tired of being the thing holding that pipeline together.

Today, that pipeline runs Claude Code and helps me ship software.

But Claude Code isn't really the idea.

The pipeline is.

Work has a path.

A pipeline defines that path.

Stages define what needs to happen.

Skills encode how you want it done.

Agents execute the work.

The orchestrator moves it forward.

And the human steps in where judgment actually matters.

For software development, mine currently looks roughly like:

Planning → Dev → CR → QA → Merge

That's where I needed Pipelinely first.

But software isn't the only work that has a process.

That's the part I'm interested in exploring next.

How much of a pipeline can agents take off our plate without putting the cognitive overhead of managing those agents back onto us?

That's what Pipelinely is really about.

---

This isn't a methodology

I haven't figured out the right way to work with coding agents.

I don't think anyone has.

The models are changing.

The tools are changing.

And my own workflow keeps changing with them.

This is simply what works for me today.

Pipelinely is opinionated because it grew out of those opinions.

As I find better ways to plan, build, review, QA, parallelize and work with agents without destroying my own focus, Pipelinely will change too.

And I'll keep this page updated with it.

What works.

What doesn't.

What I've stopped doing.

And what survives as the agents get better.

This is the Pipelinely way.