Produces production-ready Astro/React components in a venture's own repo from the harness inputs (nav-spec, design system, UX brief). Runs a simple loop — assemble prompt from specs and existing component source → generate component → build (npm/pnpm/yarn auto-detected from lockfile) → validate.py → land. Components drop into src/components/..., pages stay hand-wired. Invoke when the Captain asks to design, generate, revise, or build product UI for any venture.
Invocation: As your first action, call
crane_skill_invoked(skill_name: "product-design"). Non-blocking — if the call fails, log and continue.
You produce Astro/React components in a venture's own repo. You consume the harness inputs (nav-spec + DESIGN.md + UX brief + existing component source) and emit components that satisfy them — validated by the venture's build command and validate.py, reviewed by the Captain.
Package manager detection. At build-check time, detect the venture's package manager by lockfile, in this order: pnpm-lock.yaml → pnpm build, yarn.lock → yarn build, package-lock.json (or absent) → npm run build. Preview commands follow the same mapping (npm run dev etc.). Don't hardcode.
You are not a design tool. External design tools are LLM wrappers built for customers without our harness. We have nav-spec v3.1 with citation-anchored disqualifiers, a 26-rule structural validator, a four-agent design-brief methodology, and Claude Code writing production code daily. This skill treats screen realization as a first-class capability of that stack.
Components, not pages. You write component files (e.g., src/components/portal/QuoteDetail.astro). Pages stay hand-wired with their data fetching — they import your components and pass data. This keeps auth/data layers out of scope and makes components render from props alone.
For greenfield ventures with no pages yet, you may also produce a page wiring example. In mature ventures (the common case), stick to components.
/product-design [--surface <name>] [--set <surface-set>] [--revise <path>]
--surface <name> — generate a single surface (e.g., portal-quotes-detail). Surface names must match the classification in the venture's NAVIGATION.md.--set <surface-set> — generate a batch (e.g., portal generates every client-portal surface declared in NAVIGATION.md §1 task model).--revise <path> — revise an existing component file with a new request. Reads the existing file, treats it as prior context, generates a new version.Before any generation:
crane_ventures. If no match: stop, tell the user the skill must be invoked from a venture console repo..design/NAVIGATION.md from the venture repo. Check spec-version frontmatter. If absent or < 3: stop, suggest /nav-spec first..design/<target>-ux-brief.md where the surface class matches. Skim the brief; if the requested surface isn't named in the brief's scope section, refuse with: Brief at .design/<target>-ux-brief.md does not cover <surface>. Run /ux-brief to extend it, or pick a covered surface. This is the negative-case behavior — it's the point..design/DESIGN.md if present, or extract the @theme block from src/styles/global.css (Tailwind v4). If neither exists: stop, suggest running the design-brief or synthesizing DESIGN.md first.adapters/astro-component.mdadapters/nextjs-page.md (Phase 2; not in v1)If any pre-flight fails, stop before calling the generation workflow. Do not invent context.
| User intent | Workflow |
|---|---|
| "Design/build one surface" | workflows/generate-single-surface.md |
| "Design/build the whole client portal (or any set)" | workflows/generate-surface-set.md |
| "Revise this component" | workflows/generate-single-surface.md with --revise — same flow, prior file loaded as context |
Five steps. Every generation follows this shape. Do not add steps without Captain approval.
surface=, archetype=, viewport=, task=, pattern=), adapter template, **raw source of every file under the venture's src/components/****. No registry. No AST. Let Claude read the component source directly.~/.agents/skills/nav-spec/validate.py --file <html> --surface <tag> --archetype <tag> --viewport <tag> --task <tag> --pattern <tag> --spec <path-to-NAVIGATION.md>. If structural violations: append to prompt, regenerate. Max one retry. If no preview route exists for this surface yet, skip — validator runs after the Captain promotes./design-preview/<surface>), and anything you iterated on. Done.Iteration budget: 2 total (initial + 1 retry). If the retry fails build or validator, stop. Do not polish on iteration 3. Surface the diagnostic (which check failed, why) and ask the Captain how to proceed.
No vision-critique loop in v1. The Captain is the visual critic at gate 0. Chrome MCP screenshots, vision critique, reuse-check scripts — all deferred to Phase 2, added only if gate 0 surfaces quality problems the simple loop missed.
Each generated component must be previewable at /design-preview/<surface> in the venture's dev server. See references/preview-route-pattern.md for the exact convention. Preview routes live in src/pages/design-preview/ and are gated to import.meta.env.DEV, so they never serve in production. Fixture data co-located: <surface>.fixture.json.
If a preview route for the requested surface doesn't exist yet, the skill creates it alongside the component. ~15 lines per preview route.
/nav-spec v3)src/pages/ other than the preview routes (pages are hand-wired; you produce components)package.json~/.agents/skills/nav-spec/validate.py — structural validator~/.agents/skills/nav-spec/references/injection-snippet-template.md — nav-contract block templatedesign-brief — PRD → design charter (upstream)nav-spec — IA + patterns + chrome authority (sibling; structural authority)ux-brief — three-reviewer surface-level UX brief (upstream)--set generate serially; whole batch must fit within one Claude Code session (Max plan billing).