Skip to content
Design
Command

/mock

Produce a cheap mock from the design plan and gate on user sign-off before committing to the full build. Dispatches the design-build-agent (via prototype skill) to render a viewable mock, then the design-review-agent for a cross-pillar validation on the rendered pixels. Use

BOOST
From plugin
design-for-ai
3134 skills2 agents4 commands
Install
$ npx -y skills add ryanthedev/design-for-ai --agent claude-code

How it fires

How this command gets triggered: by you, by Claude, or both.

  • Fires itselfClaude auto-loads it when your prompt matches the work.
  • You can call itInvoke it directly when you want it.
  • Slash command/mock

Context preview

What this command does when you run it.

Produce a cheap mock from the design plan and gate on user sign-off before committing to the full build. Dispatches the design-build-agent (via prototype skill) to render a viewable mock, then the design-review-agent for a cross-pillar validation on the rendered pixels. Use

Command definition

mock.md
description: "Produce a cheap mock from the design plan and gate on user sign-off before committing to the full build. Dispatches the design-build-agent (via prototype skill) to render a viewable mock, then the design-review-agent for a cross-pillar validation on the rendered pixels. Use after plan, before build, to prove the design direction on real pixels cheaply."
argument-hint: "[plan path]"

Command: mock

The cheap go/no-go checkpoint. `mock` renders a throwaway-fidelity prototype from the plan's direction, runs a cheap cross-pillar validation on the rendered pixels, presents the screenshot and findings, then **gates on your sign-off** — prove the direction before paying for the full phased `build`.

This command obeys the shared contract in `docs/workflow-conventions.md` (the lifecycle, the DESIGN.md/JOURNEY.md gates, the design done-when vocabulary) and cites it rather than restating it. It **dispatches** the two agents — it never inlines the design or the review work.

**Mock → Validate → Present → Sign-off gate → Chain or loop.**

---

Read the Input First

`$ARGUMENTS` is the **plan path** (e.g. `.design-foundations/plans/2026-06-20-acme.md`).

  • **Path to an existing plan:** `Read` it. You need its Context (for your own framing), the design direction, and the page(s) to mock.
  • **No path given:** `ls .design-foundations/plans/*.md` and ask "Which plan should I mock?"
  • **Path does not exist:** say so and ask for the right path.

Then scan the design state — this sets the mock fidelity:

ls DESIGN.md JOURNEY.md 2>/dev/null

| Artifacts present | Mock fidelity | Flag to surface | |---|---|---| | DESIGN.md locked (token block present + user-confirmed) | **Styled** — full tokens applied | — | | DESIGN.md absent or not locked | **Wireframe** — greyscale defaults | "Design isn't locked yet — this is a wireframe checkpoint. The core `design` mode establishes tokens." (workflow-conventions.md §2) | | JOURNEY.md present | Mock the page(s) from its page specs | — | | JOURNEY.md absent | Scaffold generic page structure | "No JOURNEY.md page specs — mocking generic structure." |

`mock` is a **checkpoint, not the build.** Keep it cheap: mock the one or two highest-signal pages from the plan, not every surface.

---

Step 1 — Dispatch the build-agent to produce the mock (via `prototype`)

Dispatch `design-build-agent` in **minimal-gate** mode (cheap — no discovery pass) to render the mock. The agent routes the mock through the **`prototype`** skill (its Render evidence path) — that is how `mock` consumes the prototype skill without inlining it.

Agent tool:
- subagent_type: "design-build-agent"
- description: "MOCK — render checkpoint prototype"
- prompt: |
    Produce a throwaway-fidelity mock for a design checkpoint. This uses
    minimal gate policy — skip discovery, produce directly. Render the
    mock via the `prototype` skill; do not hand-roll HTML.

    ## Goal
    Render a viewable [styled | wireframe] mock of [the page(s) named below]
    so the user can judge the design direction on real pixels before the
    full build. This is a CHEAP checkpoint, not a finished artifact —
    fidelity is throwaway.

    ## Plan
    Plan file: [plan path]
    Mock these page(s): [name the 1-2 highest-signal pages from the plan]
    Fidelity: [styled if DESIGN.md locked, else wireframe — from the table above]

    ## Done-When Items (DW-IDs)
    - [ ] DW-MOCK.1: a self-contained .html mock renders for each named page.
    - [ ] DW-MOCK.2: when DESIGN.md is locked, its tokens are applied (styled);
          when absent, wireframe greyscale defaults are used and flagged.
    If any item cannot be met, return UPDATE_PLAN.

    ## Inputs
    - Plan file: [plan path]
    - DESIGN.md / JOURNEY.md at the project root if present (the prototype
      skill reads them; wireframe mode when DESIGN.md is absent).

    ## Output
    Return the .html path(s), the screenshot path (or the "browser MCP down —
    open the .html" note), and which fidelity you used.

Capture from the agent's report: the `.html` path(s), the screenshot path (or the graceful no-screenshot note), and the fidelity used. If the agent returns BLOCKED or UPDATE_PLAN, surface it to the user and stop — do not proceed to review on a missing mock.

---

Step 2 — Dispatch the review-agent for cheap cross-pillar validation

Dispatch ONE `design-review-agent` for a cheap validation on the rendered pixels.

**Debiasing rule (do not violate).** The reviewer gets **requirements + the rendered artifact ONLY** — NO plan Context, NO "this is our direction," NO account of how the mock was made. Conclusion framing collapses defect detection (the agent enforces this too, but the dispatch must not break it).

Agent tool:
- subagent_type: "design-review-agent"
- description: "MOCK validation — cross-pillar critique on pixels"
- prompt: |
    Independently critique the rendered design surface below against the
    requirements below. You did not produce it and have no information about
    how or why it was made. Do NOT assume it is good or finished. Re-derive
    every finding from the rendered artifact + the requirements alone.

    ## Requirements to verify (Done-When items)
    - DW-MOCK.1: the mock renders a viewable surface for the named page(s).
    - DW-MOCK.2: text/interactive contrast and applied tokens hold on the
      rendered pixels (styled), or wireframe structure is sound (wireframe).

    ## The rendered artifact
    - Screenshot: [screenshot path from Step 1, or "none — browser MCP down"]
    - .html: [.html path(s) from Step 1]
    - DESIGN.md / JOURNEY.md at the project root if present.

    ## Dual-blind review — run BOTH assessments
    Assessment A: your cross-pillar critique. Assessment B: the
    deterministic detector — run `node scripts/detect.mjs [.html path(s)
    from Step 1]` FIRST, redirected to a file you do not read until
    Assessment A's findings are frozen (your protocol's isolati
Read more
Ships withdesign-for-ai

Claude builds interfaces that look like Claude built them. Cyan-on-dark hero sections. Cards in a grid, all the same size. Glassmorphism on everything. Bounce easing. Inter at 16px. You've seen it. You've shipped it. Your users noticed.

Get the whole plugin

Other commands on design-for-ai.

build
Command

build

Execute an approved design plan through gated phases (BUILD → REVIEW → commit) with subagent dispatch. Produces JOURNEY.md,…