Building the delivery pipeline my own team runs on

Every partner engagement started the same way. A pile of client material in whatever shape the partner had it: a PRD, call notes, a spec, sometimes a Figma file. Turning that into structured requirements, then a PRD, then a roadmap, then tickets a team could pick up on Monday took thirty to sixty minutes of focused work per engagement, every time, and it landed on whichever PM had the context. Two PMs carry eight to ten active projects each.

That intake cost is not a one-off. It repeats on every new engagement and on every scope change to an existing one, and it always lands on the same two people.

Four chained skills, each usable alone.

• Requirements Analyzer. Client material in, structured requirements out, MoSCoW prioritised, with gaps explicitly flagged as critical or non-critical rather than silently filled in.
• PRD Generator. Requirements to a full PRD, every component classified as reusable from the internal library or custom build, with a complexity rating on each custom item.
• Roadmap and Timeline Generator. PRD to a partner-facing tracker, milestones grouped by workflow rather than by component, statuses defaulting conservatively.
• Linear Roadmap Sync. Tracker to Linear milestones and issues, deduplicating by name so a re-run after an edit creates only what is new.

All four are public, at github.com/Mihirmodi27/product-management-skills.

Two stages, not one. The model produces a structured spec. A deterministic script renders the output. Generation is where a language model is useful and rendering is where it is a liability, because a model asked to produce a formatted document produces a slightly different one every time. Splitting them meant the output is identical across runs and the model only has to be right about content.

Gaps stay visible. The analyzer flags what the source material does not say instead of inventing a plausible answer. On one engagement it surfaced fourteen gaps, six of which blocked scoping decisions. Those six were the most valuable output of the run. An analyzer that smoothed them over would have produced a cleaner document and a worse project.

Cancelled work stays in the record. Cancelled deliverables get created in Linear in a cancelled state rather than skipped. Skipping makes a cleaner board and destroys the paper trail of what was scoped out and why. Partners ask that question three months later, every time.

Approval gates where the blast radius is largest. The two stages that commit to something, the one producing a plan and the one writing to Linear, stop for explicit human confirmation. The pipeline could run end to end without them. It does not, deliberately.

The reasoning: a wrong document is a wrong document, and someone reads it and fixes it. A wrong ticket in Linear is a week of a developer’s time, because someone picks it up and builds it.

Gates go where the cost of being wrong is highest, not where the automation is weakest.

That is a different placement rule than most people use, and it is the one I would argue for.

The sync passed testing and then quietly did the wrong thing on a live project.

Passing status names directly to the Linear write call caused silent misrouting. “Cancelled” with the UK spelling landed in Backlog. “Canceled” with the US spelling resolved to Duplicate. Both share an underlying state type with the one I actually wanted, so the API accepted the write, returned success, and put the work somewhere I did not intend.

Nothing errored. The only reason I caught it was verifying the board afterwards against the plan.

The fix: resolve workflow state IDs explicitly before any write, never pass a name, and treat state lookup as a mandatory stage rather than an optimisation. I added a rule for when two states share a type, which is to stop and ask rather than guess, and added write verification so the pipeline checks what it created instead of trusting the response.

An agent that fails loudly is a bug. An agent that succeeds into the wrong state is an incident, because nobody goes looking.

That lesson generalises well past this bug. Every write path in the pipeline verifies now, and it is the rule I carry into any agent product.

Live-tested end to end on a real project: six milestones and twenty-five issues created in a single run, verified against the plan.

Producing the document set for an engagement went from thirty to sixty minutes down to about five. The skills are installed globally rather than kept on my machine, so the whole product team runs them: both PMs, across sixteen to twenty active projects between them.

The adoption matters more than the minutes.

A tool one person builds and one person uses is a personal shortcut. A tool the other PM picked up and runs on their own projects is a change to how the team works, and it means the intake step no longer depends on who happens to have the context.

There is no measure of whether the output is any good.

I know the pipeline works because I read what comes out. That is a judgment call by the person who built it, made on every run, and it does not scale past me. What it needs is a drift score: a measure of how much of the source material actually made it into the generated PRD or timeline, and what got dropped on the way through. Right now a document that quietly omits a third of a client’s requirements looks exactly like one that captured everything. Both are well formatted. Only one is correct.

That is the real gap. Speed I can demonstrate. Fidelity I currently cannot, and fidelity is the thing that matters when a partner builds off the document.

The second limitation is a constraint rather than a mistake, but it shapes the same output. Timeline estimation runs on the structure of the work rather than on evidence, because the actual development lifecycle data sits behind partner NDAs. Estimates built from what similar projects really took would be materially better than estimates built from decomposition alone. I do not have a way around that, and it is worth saying plainly rather than implying the timelines are more grounded than they are.