From Idea to Build Plan — How I Automated 8 App Design Documents with AI
Revealing the product-pipeline workflow validated through myWiki’s design process
On the day I started designing myWiki, I spent the entire day wrestling with AI. Where to put the repository, how to pass LLM context, how to implement space isolation — I was discovering each decision item from scratch. When I looked back at the end of the session, I had made one full loop from “requirements → 4 design docs → stack decisions (AD-1~11) → coding rules → automation scenarios,” but it had taken way too long.
That’s when I realized: the reason it was slow was because I was discovering the decision items on the fly, one by one.
Problem Definition: Why Design Takes So Long
When you’re designing an app, AI helps, but the flow usually goes like this. You ask “what DB should I use?” and it lists options. You pick one, and the next question comes up. Most of the time gets spent discovering what needs to be decided. Even if you build the same type of app twice, you end up redoing all the same decisions from scratch.
The idea behind this pipeline is simple. If I embed today’s discovered decision items plus their recommended defaults into a skill, the next app becomes “accept the recommendation + tweak only what’s unique to this app.” The cost of discovering decisions drops to zero.
The Approach: The product-pipeline Skill
You lay the document skeleton with [[docs-init-스킬-문서-골격-최소화|/docs-init]], then fill in the content with /product-pipeline. These are two separate layers.
- docs-init: any project — lay the document skeleton (index/todo/log + type folders)
- product-pipeline: product apps only — fill in the design document content
The pipeline takes two inputs: a requirements document + a prototype (or idea notes if there’s no prototype). The output is 8 documents:
- Feature spec
- Architecture decisions (ADR)
- System diagram
- Domain model
- API contract
- App architecture
- CLAUDE.md coding rules
- Build plan (trunk → branches → integration → verification)
Each Stage: How It Works
Stages 0–2: Preparing Inputs
First, lay the skeleton with docs-init and import the requirements document. If there’s a prototype, include it too. Entity drafts are automatically extracted from the requirements, and screen structure from the prototype.
Stages 3–6: Decision Rounds
This is the key section where humans get involved. The agent presents each decision item as a multiple-choice with a recommended pre-fill, and most of them get passed through as “accept.” The decision catalog (AD-1~11) is a set of standard decision items created during the myWiki design process.
There was an impressive moment during myWiki’s actual design — the AD-6 decision round. It started with “space isolation” — the idea of completely separating context per space. But while the AI was helping with the design, it suggested a better direction: “What if we scope context based on relevance rather than space? Bring it in if it’s relevant, even across spaces; don’t bring it in if it’s not relevant, even within the same space.” I changed direction right there. It was the moment the AI came up with a better idea than me mid-design.
Like this, decision rounds aren’t just about making choices — they’re the phase where you’re actually building the design together with AI.
Heavy steps (spec extraction, entity/endpoint design) are handled in parallel via workflow fan-out.
Stages 7–9: Output Review + Build Plan
Once decisions are done, 8 design documents are generated. The build plan breaks the work down into “independently executable units per session” right up to the point of implementation. After that, coding proceeds one plan item at a time, one session at a time.
Why It Works
The core is the decision catalog. AD-1~11 covers the recurring decisions in web app design: storage approach, LLM separation, context scoping, ORM, auth, payments, and more. The recommended defaults are built in around the Slowloop default stack (self-hosted · Next.js · Postgres+pgvector).
Next time you build an app, you don’t need to rediscover these decisions from scratch. Just accept the recommendations or swap out only what’s unique to your app. This is a battle-tested catalog — refined through 6 patches on product-pipeline and 3 patches on docs-init during myWiki’s real design process.
Every decision is recorded as an ADR. I learned firsthand that “if you don’t write it down, it evaporates” going through context compaction. The next step and the next app both start on top of these decisions.
How to Apply It in Practice
Next time you build an app and your requirements are ready, work through the decision rounds from AD-1 one by one. Most will fly by as “accept recommendation.” It’s much faster than starting to code without design documents — because the cost of restructuring mid-code is far higher.
In 빌드플랜-스킬로-개발시간-단축, you can see how I connected the build plan — the output of this pipeline — to actual development.
Background: Why myWiki was built · Second brain design decisions Deep dive: Build plan skill in practice · product-pipeline skill in depth See also: Claude Code 4-lever method