I built skills one at a time, as I needed them. One for when blogging felt stuck. One for when building apps got frustrating. One for when tasks stopped moving. Each solved a different problem and I never referenced one while building another. I wasn’t thinking about app skills while designing blog skills.
But at some point I was refining each of them and suddenly saw it. For the backend, I was locking in design decisions with docs-spec and splitting execution with plan. For the frontend, take requirements, generate multiple mockups, pick one, expand it, then move to feature development. For the blog, seed to outline to draft to publish. For tasks, todo to breakdown to triage to execution. Different names, different domains — laid side by side, the shape was identical.
Three pipelines, three separate reasons
The motivations were completely unrelated.
The blog pipeline came from ideas evaporating mid-thought. blog-mine digs through chat history and wiki for material, blog-brief locks in direction with human sign-off, blog-draft writes the post, blog-publish ships it.
The app pipeline came from handing too much to an agent at once and watching context collapse halfway through. Covered that in earlier posts — briefly: app-req pulls requirements, docs-spec locks design decisions, plan chunks it into session-sized pieces, /goal runs it unattended.
The task pipeline came from Todoist filling up and never moving. triage categorizes, plan-todo groups into plans, dispatch and /goal handle the actual execution.
Evaporating ideas. Context collapse. Tasks that never move. What do any of these have to do with each other.
Laid out side by side, they were all the same
Only when I put them in a table did it become visible.
| Pipeline | Input / Material | Specify | Pre-work | Agent execution | Where humans stop |
|---|---|---|---|---|---|
| Blog | blog-mine / seed | blog-brief | raw link · outline | blog-draft / publish | brief approval, draft review |
| App | app-req | discuss · docs-spec | plan | /goal | design decisions, gate items |
| Task | Todoist input | triage | plan-todo | dispatch · /goal | confirm classification |
Same columns, different words. First you figure out what to do (input/material). Then you break it down until an agent can actually execute it. Then you set up everything it needs right before handoff. Then you hand it off. And woven through the middle, one or two places where a human has to stop and check. Blog: human approves brief before draft can happen. App: agent stops at design decisions and gate items. Tasks: human confirms the classification looks right.
Doesn’t matter if the domain is blogging, apps, or tasks. The shape doesn’t change. Human sets everything up at the front. Agent executes at the back. A few gates in the middle.
Why they all ended up the same
At first it seemed like coincidence. Looking back, it couldn’t have been anything else.
Agents need context to move. What to build, what the constraints are, what depends on what — without that, they just produce something plausible. Throw just a topic at blog-draft and it writes general observations. Throw just a goal at /goal and the direction starts drifting halfway through. So the front end always ends up with requirements and breakdown. Skipping the spec means reworking it later. Catch it at the front.
Which means the preparation phase is unavoidable for humans. Delegating work to an agent means getting it into a state where it can be delegated. That getting-it-ready part is human work, and it takes the same shape every time. Big picture: plan and prepare everything, then hand execution to an agent. Whatever the domain, this skeleton doesn’t move.
Gates are the same logic. I always want to push through to the end unattended, but if the front-end decision is off by even a fraction and it propagates automatically, everything downstream inherits that error. The cost of debugging beats the savings from automation. So important, hard-to-reverse decisions get a human stop. Blog brief approval or app design gate — the location is different, the role is identical.
Where you draw the line is everything
Now I think I understand why this shape exists.
Put an agent in a spot that belongs to a human and the product breaks. Direction-free material input produces generic output. Goal-without-spec means the direction drifts mid-run. Agents are only smart inside the context humans put in front of them.
The reverse is just as true. Put a human in a spot that belongs to an agent and productivity drops. If a human is writing drafts directly or executing plan items one by one, what’s the automation for.
So there’s a front and a back. Front is human territory. Back is agent territory. Draw that line wrong in either direction and something breaks. I’ve drawn it a little differently for each pipeline, but the common thread was one thing: humans decide, agents execute. That order can’t be reversed.