/red-line-digital
Interactive field guide

The /module-build pipeline

Before a single page gets built, a module needs a plan: what it's for, what it touches, and which pages come first. This pipeline drafts that plan, concept, then architecture, then phases, and freezes it as a spec the rest of the build reads from.

The concept stage runs with no critic on purpose. If that feels like too little rigor up front, or the right amount, tell us. Reply on LinkedIn.

How to read this map

Each card is a stage of the pipeline, in order. Two of them stop and wait for your approval.
The colour on each card's edge tells you what kind of work it is: a gate, drafting, sketching, or the lock.
Open any card for the full, plain-language walkthrough at that stage.

Pick a stage to walk, or start at the top

Get this command /plugin marketplace add fire-farmer/red-line-toolkit view source →

The walkthrough, as text

Every stage of the interactive walkthrough above, as plain readable text. Each stage has its own link.

Stage 0Is this really a new module?A module, not a sub-feature

Pre-flight

Before anything, the pipeline checks that what you're building is genuinely a new module and not just another page inside one that already exists. Whole modules earn the full planning ceremony; a single page does not.

Confirm this is a new module, not a sub-feature. If it's a sub-feature, it goes straight to /page-design instead.

What happens

The pipeline reads the project's vision and current state to see the shape of what's already built, then checks your request against it. A new module gets the full concept-to-spec treatment.

If the request is really a sub-feature of an existing module, the pipeline redirects you to /page-design and stops. The heavy planning only pays off for genuine module-sized work.

Who acts

  • Read, tool: Reads the project vision and live state to place the request.

The rules

  • Modules only. A single page or small feature does not earn this pipeline; it goes to /page-design.

In: A module name and a brief of what it's for. Out: A confirmed new-module intent, cleared to plan.

Stage 1Draft the conceptGoal, scope, success, value

Concept

First the pipeline writes down what the module is actually for: the goal, what's in and what's deliberately left out, how you'll know it worked, and the specific problem it solves for the person using it. Then it stops and waits for your sign-off.

A plain-language concept: the goal, the in-and-out scope, the success criteria, and the user value. Approved before anything else.

What happens

The concept is drafted with the brainstorming skill and covers four things: the goal, the scope in and out, how success is measured, and the concrete value to the user. It is deliberately high-level, no page design yet.

This is the first hard pause. You approve the concept, send it back for a revision, or defer the whole module. Nothing proceeds until the concept is right, because everything downstream is shaped by it.

Who acts

  • brainstorming, skill: Drives the concept draft: goal, scope, success, value.
  • AskUserQuestion, command: The approval gate after the concept is drafted.

The rules

  • No critique at concept. Concept-stage critique is noise; the pipeline trusts /page-design and /page-code downstream to catch plan errors.
  • Approve before architecture. The concept must be signed off before the pipeline sketches how it's built.

In: The confirmed module intent. Out: An approved concept: goal, scope, success, value.

Stage 2Sketch the architectureData, pages, integrations, tiers

Architecture

With the concept approved, the pipeline sketches how the module fits together: what data it adds to the app's shared core, the full list of pages it needs, what it connects to, and which capabilities sit behind which tier. This part runs on its own, no pause.

A structural sketch: the data the module adds, its full page list, its integration points, and how capability is gated by tier.

What happens

The sketch names the data the module extends onto the app's shared core, lists every page with a one-line purpose, marks the integration points to other modules or services, and notes which tier unlocks which capability.

This stage auto-continues from the approved concept with no checkpoint of its own; it flows straight into breaking the pages into phases.

Who acts

  • the orchestrator, agent: Drafts the architecture sketch directly, no subagent.

The rules

  • Stay generic at apex. The sketch names pages and shapes, not per-page design; that is /page-design's job.
  • Extend the shared core. New data hangs off the app's central hub rather than standing alone.

In: The approved concept. Out: A sketch: data deltas, page list, integrations, tier gating.

Stage 3Break it into phasesMVP first, then the rest

Phases

The pipeline groups the pages into phases: the smallest set that delivers the real value first, then the follow-up phases with their dependencies mapped. Then it stops and asks whether to lock the whole thing as a spec.

Group the pages into an MVP phase and follow-ups, each with dependencies and acceptance criteria. The last pause before the spec is frozen.

What happens

Phase A is the minimum viable cut: the pages needed to deliver the core value and nothing more. Later phases carry the rest, with their dependencies on other modules or phases made explicit.

This is the second hard pause. You lock the spec, revise the phase boundaries, or keep the draft in the conversation only. Locking is what makes the plan real.

Who acts

  • AskUserQuestion, command: The lock-or-revise gate before the spec is written.

The rules

  • MVP is the smallest real cut. Phase A is only the pages that deliver the core value; everything else waits for a later phase.
  • Dependencies are mapped, not assumed. Each phase names what it depends on, so the build order is never a guess.

In: The architecture sketch. Out: A phased page plan, ready to lock.

Stage 4Lock the specFreeze it to disk

Lock

On your go, the pipeline writes the whole plan to a spec file on disk, marked locked, with its phases listed in the frontmatter. From here on, that file is the source of truth every later step reads from.

Write the Module Spec to disk with a locked marker. This file is what /module-sprint and the per-page pipelines build against.

What happens

The spec is written to docs/plans/<date>-module-<slug>-spec.md with frontmatter carrying status: locked, the date, the module name, and the phase list.

The lock is the contract. The /module-sprint runner and the per-page pipelines all read this one file; nothing downstream rewrites it silently.

Who acts

  • Write, tool: Writes the locked Module Spec to disk.

The rules

  • Locked means canonical. The frontmatter status: locked tells every downstream pipeline this spec is the source of truth.
  • One spec per module. The whole plan lives in one file, so the sprint and the page pipelines never disagree about scope.

In: The approved phased plan. Out: A locked Module Spec file on disk.

Stage ✓A plan before a single pageReady for the sprint

Spec locked

What you end with is a frozen plan: what the module is, how it's built, and the order to build it in. The next step is to hand it to the sprint, which walks each page from design to shipped.

A locked spec is the hand-off point: /module-sprint reads it and builds the pages one at a time.

What happens

The pipeline did no page design and wrote no code. It produced one thing: a spec solid enough that the rest of the build never has to guess what the module is or what comes first.

From here, /module-sprint takes the spec and walks each page through design, code, and build. That runner has its own field guide.

The rules

  • Plan, then build. Nothing gets built until the spec is locked; the spec is what the sprint reads first.

In: An approved, phased plan. Out: A locked spec, ready for /module-sprint.