Claude Skill

monozukuri-blueprint

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.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download kuya-egg-Monozukuri-monozukuri-blueprint-fe2f1d7.zip · 2 KB

kuya-egg/monozukuri 11 1 forks MIT Updated 3d ago

Part of kuya-egg/monozukuri — 13 skills

Install

skills CLI npx skills add https://github.com/kuya-egg/Monozukuri/tree/main/monozukuri-blueprint

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install kuya-egg-monozukuri@llmmart

Git git clone https://github.com/kuya-egg/Monozukuri.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole kuya-egg/monozukuri collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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; later phases run smallest first within prereq order (monozukuri-core/references/checkpoints.md).
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

Handoff

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.

Files (monozukuri)

agents

openai.yaml 388 B

interface:
  display_name: "Monozukuri Blueprint — Greenfield Gates"
  short_description: "Four approval-gated stages before building from scratch"
  brand_color: "#1F2937"
  default_prompt: "Use $monozukuri-blueprint to take this greenfield idea through business logic, tech stack, logic-to-stack map, and phase plan, gated on my approval."

policy:
  allow_implicit_invocation: false

SKILL.md 4.3 KB

---
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; run by monozukuri-core for greenfield tasks."
user-invocable: false
---

# 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; later phases run smallest first within
  prereq order (`monozukuri-core/references/checkpoints.md`).
- 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`).

## Handoff

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.