From Idea to Working Code: The 4 Beginner Workflows

When you start working with AI coding tools, one thing becomes clear very fast: if you just throw a raw idea at your AI assistant and say "build it," you get a mess. The model guesses, you correct, it guesses again, and somewhere along the way the original idea gets lost. Sound familiar?

This is the blog post for you. In this post, I'll walk you through the four beginner workflows I use to take a feature idea all the way to working code, one clear step at a time. Each one is a slash command, each one produces a file, and each one hands that file to the next. By the end you'll know exactly what each command does, when to run it, and why the chain works.

link to the workflow ready to use: https://github.com/tomeraitz/dotclaude-templates/blob/main/docs/beginners-workflows.md

Let's dive in.

Why a chain instead of one big command?

Great question! When I was building Vibki, I tested a lot of ways to get from "I have an idea" to "it's running." The thing that kept biting me was context. If you ask one giant command to figure out what to build, how to build it, who does what, and then actually build it, all in one go, the AI has to juggle everything at once. Quality drops.

So instead, we break the journey into four steps. Each step answers exactly one question:

📄Text
Copy
1
2
/create-prd  ──▶  /create-design  ──▶  /create-plan  ──▶  /run-plan
  (what & why)      (the how)          (who does what)      (build it)

Here's the high-level flow of the whole chain:

Notice the dotted line: /run-plan reads both the plan and the design. We'll get to why in a moment. Now let's go through each command one at a time.

1. /create-prd: Idea - Product Requirements

The first command takes your raw idea (pasted text, or a file like a PDF or doc) and turns it into a PRD (Product Requirements Document). The most important thing to understand here: the PRD is about the what and the why, never the technical how.

Why do we start with product and not code? Because if you skip straight to "how," you build the wrong thing beautifully. First we get crystal clear on the problem, the users, and the goals.

• Input: pasted text, or a path to a .pdf / .md / .txt / .docx.
• What it does: it ingests your idea, asks you a few product clarifying questions (one at a time, no overwhelming wall of questions), then writes the PRD.
• Output: a self-contained .html PRD (default .notes/prd/-prd.html) you can read in under 2 minutes: problem, target users, goals, user stories, requirements, and open questions.

2. /create-design: PRD - Technical Design

Now that we know what we're building, it's time for the how. The second command takes the PRD and produces a short, solution-focused design document.

• Input: the PRD .html from /create-prd (or any doc describing the feature).
• What it does: it first asks what kind of design this is (frontend, backend, system, or custom), proposes up to 5 focused sections, and strongly recommends a UML diagram.
• Output: a self-contained .html design (default .notes/design/-design.html) with an animated UML diagram (inline SVG + CSS) that explains the solution visually.

Why the diagram? Because a picture of how the pieces talk to each other is worth a hundred lines of prose, for you and for the AI that reads this design later.

3. /create-plan: Design - Implementation Plan

We know the what and the how. Now, who does what, in what order? The third command turns the design into a concrete, execution-ready plan broken into phases.

Here's the key idea: each phase holds a handful of discrete tasks, and each phase is sized so that a single subagent can execute it. That sizing matters a lot, and it's exactly why the next command can run cleanly.

• Input: the design .html from /create-design (or any doc describing the solution).
• What it does: it drafts a first-pass phase/task breakdown, then reviews it with you to adjust granularity, ordering, and dependencies.
• Output: a self-contained .html plan (default .notes/plan/-plan.html) where each phase is a self-contained unit: Goal · Tasks · Touches · Depends on · Done when.

4. /run-plan: Plan + Design - Working Code

This is where we get to do the fun stuff: actually build it. The last command takes the implementation plan and the design, then executes the plan one phase at a time using subagents.

• Input: the plan .html from /create-plan and the design .html from /create-design.
• What it does: for each phase, it builds a focused execution prompt (baking in the design guidelines), runs a subagent for that phase, and waits for it to finish before starting the next.
• Output: the implemented feature, built phase by phase in order, plus a per-phase summary of what changed.

Remember that dotted line from the very first diagram? This is why. The plan tells the subagent what to build, but the design tells it how it should look and behave. Feeding in both keeps every phase honest to the original solution.

The one rule that ties it all together

There's one habit I really want you to take away from this post:

Why? Each command does a lot of work and fills the context window with details from the previous step. If you run the next command in the same chat, it has to compete for context with everything that came before, and quality drops. But here's the beautiful part: because every command writes its output to a file and the next command reads that file, you lose nothing by starting fresh.

So the rhythm is:

1. Run /create-prd → note the saved PRD path → new session.
2. Run /create-design (point it at the PRD) → note the design path → new session.
3. Run /create-plan (point it at the design) → note the plan path → new session.
4. Run /run-plan (point it at the plan + design).

Each command prints where it saved its file when it finishes, so just pass that path to the next one:

📄Text
Copy
1
2
3
4
/create-prd          # paste your idea, or give a file path when asked
/create-design  .notes/prd/my-feature-prd.html
/create-plan    .notes/design/my-feature-design.html
/run-plan       .notes/plan/my-feature-plan.html  .notes/design/my-feature-design.html

Conclusion

That's the whole chain: /create-prd → /create-design → /create-plan → /run-plan. Four small, focused steps that each answer one question (what & why, the how, who does what, and finally build it) with a file handed cleanly from one to the next. The magic isn't in any single command; it's in keeping each step simple and giving it a clean context to work in.

Try it on a small feature first, get a feel for the rhythm, and you'll wonder how you ever vibe-coded without it. Next time, we'll dig deeper into one of these steps and look at how to customize the commands for your own project. See you then!