Decide First, Then Code — How the product-pipeline Skill Forces You to Spec Up Front

Even solo developers can avoid the “I have to rip this out” moment

There’s one mistake solo developers make more than any other. The moment an idea hits, they start coding. It goes well at first — the screen comes up, data flows in. Then at some point it grinds to a halt. “Wait, how am I going to handle this DB?” “If I isolate spaces this way, search won’t work later.” You stop, make a decision, get back to coding — then hit another wall a bit later. The coding flow and the design flow keep colliding.

Everyone knows you’re supposed to write the spec first. The problem is that when you’re working alone, there’s nothing to enforce it. Nobody on Slack is going to ask the right question. Nobody’s reviewing your design doc. So you end up starting with code again anyway.

Pulling All the Decisions to the Front

What the product-pipeline skill does is simple. It pulls every decision that would otherwise interrupt your coding — and moves it all to the front.

When you run the skill, a decision catalog (AD-1 through AD-13) comes out in order. It asks multiple-choice questions about the core architectural decisions for your app — storage location (AD-1), authentication method (AD-4), payments (AD-5), and so on. Each item already has a recommended default, so you either agree and move on, or pick something else and log your reasoning. Once you’re done answering, seven design documents (functional spec, architecture decision records, system diagram, domain model, API contract, app architecture, coding conventions) plus a build plan are generated automatically.

The only place a human has to show up is the decision round. Generation is handled by the AI.

AD-6: When Direction Shifts Mid-Design

The most dramatic moment during the myWiki design process was AD-6.

The original design was a “space isolation” approach — completely separating context per space. But partway through the decision round, a problem became visible. “Contamination” wasn’t happening because content crossed spaces; it was happening because unrelated content was slipping in. That means the right approach isn’t walls between spaces — it’s filtering by relevance.

So AD-6 became a pivot: “space isolation → relevance-based context.”

What matters here is that this pivot happened before any code was written. If I had started coding without a spec, the space isolation assumption would have gotten baked into multiple places — the service layer, query logic, API design, all of it. Because the decision was recorded in the ADR, the direction change was reflected in one place and handled cleanly.

AD-12: A Breaking Change Discovered During Implementation

The second case came up during the implementation phase.

When B2 (persistence base) work started, the installed version of MikroORM was v7. But v7 had completely removed the old decorator API (@Entity, @PrimaryKey, @Property) and unified everything under the defineEntity builder pattern. AD-10 (persistence decisions) had assumed decorator-based Data Mapper — so there was a conflict.

Having the ADR made a real difference here. I added AD-12 and recorded: “All subsequent entity slices will follow the defineEntity pattern.” One line of decision became the standard for all future work.

Without the ADR, each slice — B3, B6, and so on — would have discovered the issue one by one. Every time it showed up, I’d spend time starting from scratch figuring out “wait, why did this end up like this?”

Why “Decisions Up Front Means Straight-Line Generation”

빌드플랜 @docs/guide/build-plan.md B2 진행하자 — that’s the pattern I actually use. When decisions are in the documents, a single line is enough to hand off the full context. The AI agent already knows the design intent, so it generates consistently without making its own judgment calls.

Without decisions, the agent fills in gaps with its own judgment in the moment. Different calls get made across different slices, consistency breaks down, and eventually you’re ripping things out piece by piece.

The Skill Itself Went Through a Spec → Validate → Improve Cycle

The product-pipeline skill wasn’t finished from day one. Six patches came out of actually using it during the myWiki design process. Things like “this decision item is necessary,” “there’s no way to handle provisional decisions,” and “open items need their own separate section” — these surfaced through real friction.

The point is that the skill itself went through a spec → validate → improve cycle. As the decision catalog accumulates across projects, the next project can move through mostly on “accept.” The cost of discovering things from scratch keeps going down.

Next time you start a new app, ask AD-1 before you open a code file. “Where is this app going to store its data?” Ten minutes and you have a design direction. Those ten minutes are what prevent “I have to rip all of this out” later.

← Prev: Cutting Dev Time with the Build Plan Skill · Next →: The Secret of Skills: When Natural Language Becomes Logic Background: myWiki Origin Story · See also: Claude Code 4-Lever Method