git:20260911.7597661 to git:20260911.ccf9aed

---

name: monozukuri-blueprint

description: "Author a greenfield build blueprint in four gated stages — business logic, tech stack, logic-to-stack mapping, and a phase plan — each requiring explicit user approval before the next. Use when building a new project or a substantial new subsystem from scratch."

---

# Monozukuri blueprint

This skill turns a framed idea into four approved artifacts and an ordered

phase plan. It does no implementation — it sets direction and order so each

phase can then be built under its own playbook.

## Use this skill when

- building a new project from scratch;

- adding a substantial standalone subsystem;

- the router selected the `greenfield` playbook; or

- the user asks for a build plan or blueprint.

## Do not use when

- the work changes an existing flow — that is `feature`;

- the work is a one-off script; or

- the request is a pure question.

## Prerequisite

`nemawashi` has run, or its output already exists. Blueprint consumes the

framed intent, users, and constraints; it does not re-ask them.

## The gate

After producing each stage's artifact, stop. Present it, say what the next

stage will do, and wait for explicit approval. A later stage may send you

back to revise an earlier artifact; re-approve the changed artifact before

resuming. Never begin a stage while the previous one is unapproved.

See `monozukuri-core/references/blueprint.md` for the full gate protocol and

for what a strong artifact at each stage looks like.

## Stages

### Stage 1 — business logic

- produces: `.monozukuri/blueprint/01-business-logic.md`

- contains: domains, actors and roles, entities and their relationships,

business rules, primary flows, state transitions, invariants, and notable

edge cases — in plain language.

- refuses: any technology, framework, or datastore choice; naming a library.

- template: `monozukuri-core/references/templates/blueprint/business-logic.md`

### Stage 2 — tech stack

- produces: `.monozukuri/blueprint/02-tech-stack.md`

- contains: language and runtime, framework(s), datastore(s), infra and

deploy target, and key libraries — each with a one-line "why this — over

what", derived from a stage-1 need, `kanso` applied.

- refuses: a choice stage 1 does not justify; components added "for later".

- template: `monozukuri-core/references/templates/blueprint/tech-stack.md`

Significant choices — those whose later reversal would touch many modules or

the data model — also become ADRs under `.monozukuri/decisions/`.

### Stage 3 — logic to stack map

- produces: `.monozukuri/blueprint/03-logic-to-stack-map.md`

- contains: one row per stage-1 element (actor, domain, entity, rule, flow,

state) mapped to exactly one home in the stack; orphans and unused

components listed explicitly.

- refuses: leaving any stage-1 element unmapped.

- template: `monozukuri-core/references/templates/blueprint/logic-to-stack-map.md`

### Stage 4 — phase plan

- produces: `.monozukuri/blueprint/04-phase-plan.md`

- contains: ordered phases, each with `intent` (one line), `affected`

(areas or files), `prereqs` (earlier phase ids and named external

dependencies, or "none"), `playbook`, and `risk`. Phase 1 is a vertical

slice through real boundaries.

- refuses: step-by-step task lists; a phase whose prereqs are not satisfiable

by earlier phases.

- template: `monozukuri-core/references/templates/blueprint/phase-plan.md`

## Outcome

Four approved artifacts in `.monozukuri/blueprint/`, and a phase plan whose

phases each name a `playbook` (`feature | refactor | migration | release`)

and a `risk` tier (`low | medium | high | critical`).

After stage 4 approval, start phase 1. Its `playbook` and `risk` are already

set, so the router's classify step is already answered: go straight to that

playbook, render its Definition of Done from `definition-of-done.md` for the

stated risk tier, and execute. The detailed task list for the phase comes

from `spec-driven-implementation` / `writing-plans` at that point, not from

blueprint. Re-run `monozukuri-router` only if a phase proves misclassified.

If a referenced skill is not installed, apply its named lens inline instead

of trying to invoke it.