pb

Plugin pb from marketplace product-builder in danhnbui/prototype-builder. Commands read from the repo's manifest — 5 days ago.

Skills (18)

• agent-dispatch

  Route Product Builder tasks to the right pb-* agent and run them in dependency waves — map each task's skill/slice to one of the 8 routable agents (the 9th, pb-explorer, is /pb:explore's alone), dispatch a wave concurrently, apply returned patches serially, render once per wave, then gate on pb-test

• agent-orchestrate-tasks

  Decompose a multi-step Product Builder request into an ordered, trackable task plan — clarify intent, break it into subtasks, sequence them, and define each task's acceptance + which skill it invokes. Use when planning a build — loaded by /pb:plan — so a feature becomes a per-tab task breakdown rath

• craft-connect-flow

  Connect multiple Product Builder screens into a working journey — navigation, shared state, entry/exit points, and transitions — using the shell's declarative data-* runtime. Use when building a multi-screen prototype or mapping its flow — loaded by /pb:build and /pb:plan --flow. Not for single-scre

• design-component-build

  Build a new local component for Product Builder — its render body file, anatomy/spec, state variants, and token-only styling at the right atomic level. Use when /pb:build decides "build local" (nothing existing fits). Produces the registry entry + the render/components/<id>.js body. Not for deciding

• figma-use

  Authoring rules for the DS Bridge code→Figma bridge — how to emit / edit valid declarative node JSON that the plugin rebuilds as real, linked component instances. Loaded by /pb:handoff Step 6 (and the pb-design-system agent) — an internal contract, not a command. The transformer (registry_to_figma.p

• ref-blueprint

  Screen-level design thinking for Product Builder. Use BEFORE building or restructuring a screen — carried by the pb-builder agent on /pb:build and cited from think-layout §1 and think-direction §2 — to define the screen's Job To Be Done (JTBD) from the ia.jobs[] that /pb:clarify approved, justify ev

• ref-design-compare

  The contract for generating genuinely different design alternatives and scoring them against a rubric instead of asking "which do you like?". Use whenever N alternatives are produced for a human to choose between — loaded by /pb:explore Mode A (A1/A2/A4) and Mode B (B4), after think-direction suppli

• ref-design-system

  Normalize any design-system source — a dedicated DS MCP, a Figma design-system link, a code library, or a common DS — into Product Builder's DS-export shape (tokens + component metadata + provenance). Use when cloning or re-cloning a DS — loaded by /pb:pull-ds and /pb:test --drift (init reaches it t

• ref-figma-frame

  Read a Figma frame via the Figma MCP and normalize it to Product Builder's frame-export shape (layers → DS-component ids), so /pb:init --figma can resolve it into a screen. Use when entering from a Figma frame — loaded by /pb:init --figma. Maps each layer to a design system component that ALREADY EX

• ref-ia

  The vocabulary and the contract for information architecture in Product Builder — organization scheme, labeling, navigation systems, depth vs breadth, hub load, findability — and for turning one approved ia.jobs[] list into N genuinely different groupings that the user scores instead of likes. Use o

• ref-prd

  Parse a product requirements doc (a file the user points at, or a short Q&A) into structured project context for Product Builder. Use at the start of a prototype — loaded by /pb:init and /pb:plan — to turn a PRD or feature brief into a clean objective, personas, key screens, and success criteria the

• ref-research

  The method for validating what a project is unsure about with real people in Product Builder — defining the question and the decision a study informs, choosing among survey, interview, usability test, tree test, card sort and first-click, writing the research plan (recruiting, screeners, sample size

• sandbox-test

  Drive the Product Builder Prototype sandbox to verify authored scenario tests — encode the test{} step/expect vocabulary, resolve targets against the live #proto-frame, run per-role and security passes, and write each scenario's lastResult. Use when running /pb:test so a scenario becomes a real, obs

• think-clarify

  Decide what genuinely needs a human answer vs what can proceed on a sensible default. Use when a PRD, brief, or task is ambiguous in Product Builder — loaded by /pb:init and /pb:specify — to ask the few high-leverage questions and assume the rest, so building isn't blocked by over-asking or derailed

• think-critique-prd

  Push back on a PRD or feature brief before building — surface unclear goals, missing personas, assumption gaps, unrealistic scope, and missing edge cases. Use when reviewing requirements in Product Builder — loaded by /pb:init and /pb:specify — so the prototype is built on solid intent, not silent a

• think-direction

  Fix the shared ground before N design alternatives are generated, in two outputs — a one-screen direction the user approves at G-DIRECTION (the job, the taste position, the hard constraints, the real content, which of the seven divergence axes are locked, and N one-line bets), then, only after appro

• think-layout

  Decide how a Product Builder screen or component is built and arranged — the job it serves, which design-system component fills each region, how much text it may carry, then flex vs grid, spacing rhythm, responsive behavior and layering — and look at the rendered result before hand-back. Use when st

• think-logic

  Define the behavior of a Product Builder screen or component — states, transitions, validation rules, and conditional rendering. Use when adding interactivity or logic — loaded by /pb:build when logic changes. Maps intent onto the shell's declarative data-* runtime (data-required, data-validate, dat

Slash commands (15)

• /pb:build

  The cheap build loop. Apply a targeted patch to the touched registry.json slice, trio-gated (drift/Stack/DS gate only when a screen/component/logic changes), and NEVER re-render prototype.html per tweak. Use --render to regenerate the HTML.

• /pb:clarify

  Capture User Insights into the Project Summary tab; the jobs each role needs done and the glossary of the words they use (content.terms[]), approved together at the G-JTBD gate; the information architecture — N genuinely different groupings of those jobs, authored by the coordinator, scored on the /

• /pb:clean

  Show what this project has piled up — closed explore rounds, backups, orchestrate patches, the decisions log, the preview server's log, screenshots, scratch candidate folders, worktrees — and prune it on request. A dry run by default; nothing is deleted without --apply, and a backup, a closed round

• /pb:explore

  Explore alternatives. With a component/screen id, write a one-screen direction (job, constraints, locked/free axes, N one-line bets) and get it approved at G-DIRECTION, then write one execution plan per bet and dispatch N pb-explorer agents in parallel; show the results side by side on one compare p

• /pb:handoff

  The one hand-off command. Asks who is receiving the work, then delivers it — (1) everything including a vendored Product Builder, so they keep building; (3) Figma, lowered deterministically from the registry and written through the Figma MCP, with the DS Bridge plugin as the fallback; (4) tickets fo

• /pb:init

  Scaffold a new Product Builder prototype — PRD intake (Q&A or file, never blank), set Stack + DS locks, seed registry.json + memory/. Optional --import <bundle> to ingest a context hand-off.

• /pb:orchestrate

  Execute a whole memory/tasks.md plan by dispatching each task to its fitting pb-* agent in dependency waves — agents return slice patches, the coordinator applies them serially, renders once per wave, and gates each wave on pb-tester + pb-reviewer. Fail-closed on a final strict contract check.

• /pb:plan

  Design the structure — the implementation plan and the per-tab task breakdown, consuming the information architecture /pb:clarify chose at its G-IA gate (one task per planned screen and for the hub; --ia places one late job), and the first authoring of the flow, erd and content slices (wireflow + fi

• /pb:preview

  Live preview dev server. Watches registry.json (+ the shell templates + runtime + render.py), re-renders through the same generator render.py uses, and live-reloads the browser on every change. One server, two routes from the one registry — the prototype at / and the design system at /design-system

• /pb:pull-ds

  Clone a design system into this project — resolve the DS via the fallback ladder (dedicated DS MCP → Figma design-system link → current code library → a common DS), normalize it to a DS-export, then materialize tokens + a scannable reference + a drift snapshot. Records meta.dsSource + meta.platform.

• /pb:report

  Scan this project's memory, decisions log and context, and write one retrospective report of what its history says Product Builder should change in the next release. Read-only on the project; the report is the only file written.

• /pb:research

  Validate what the project is unsure about with real people — frame a falsifiable question, choose among survey, interview, usability test, tree test, card sort and first-click test, write the plan and the instrument from the jobs, flows and rules, approve it at G-STUDY, run sessions on this machine

• /pb:specify

  Produce the spec / PRD for the prototype, native (no SpecKit). Prototype-shaped user stories with JTBD, tabs affected, and custom organisms.

• /pb:test

  Check everything. By default runs the whole battery — authored scenarios, role gating, server health, the security scan, the constitution drift audit, the ranked health report, shell coherence and DS drift — and reports one verdict. Any mode flag narrows it to that one check. Read-only on the design

• /pb:update-version

  Run versioned schema updates on a Product Builder registry.json. Default is dry-run (prints the plan, writes nothing). Use --apply to execute, --rollback to restore the latest backup, --to <N> to target a specific schema version.

Subagents (9)

• pb-builder

  Use to build or change a screen, a component, or its logic — patching one registry slice plus its render body file, trio-gated and without per-tweak render. Wraps /pb:build. Not for /pb:explore options — those are pb-explorer's.

• pb-clarifier

  Use to turn a PRD or feature brief into a structured spec, the Project Summary tab, the jobs each role needs done, the information architecture that places them and the rules behind its contested UI decisions — objective, prototype-shaped user stories, user insights, ia.jobs[] (gated at G-JTBD), N s

• pb-data

  Use to generate or update the Data tab — a field / type / example table per entity plus a Mermaid ERD for the prototype's eventual data model. Wraps /pb:plan --data; authors the erd slice. /pb:build reconciles it on trio writes.

• pb-design-system

  Use when a component is added or changed to decide reuse vs extend-with-a-variant vs build-local, and to manage design tokens under the naming contract. Wraps /pb:build as the DS-first gate for pb-builder.

• pb-explorer

  Use to execute ONE exploration plan written by the /pb:explore coordinator — it edits only its slot's candidate files, keeps the same renderFn and props, styles token-only, lints, and hands back. Dispatched by /pb:explore A1d / B4d on sonnet at xhigh effort, one per plan, with no design context beyo

• pb-flow

  Use to generate or update the UX Design / Flow tab — a Mermaid wireflow plus a numbered user-story test checklist with categorized scenarios. Wraps /pb:plan --flow; authors the flow slice. /pb:build reconciles it on trio writes.

• pb-planner

  Use to break an approved spec, and the information architecture /pb:clarify chose, into an implementation plan and a per-tab task graph, where each task carries acceptance, the skill it invokes, its owning agent, its dependencies, and the registry slice it touches. Wraps /pb:plan.

• pb-reviewer

  Use as the acceptance/critic gate — a read-only drift audit of the trio against the constitution plus contract and secrets/PII scans. Wraps /pb:test --drift, lint_registry.py, and security_scan.py; never writes to the registry or prototype.html.

• pb-tester

  Use to run the prototype's functional, server, and role/auth-enforcement tests against the rendered sandbox and record per-scenario results, or to answer a slice of a /pb:test plan as yes/no/blocked rows with evidence. Wraps /pb:test via test_run.py; read-only on the registry except for writing test

Hooks (15)

• SessionStart

  python3

• SessionStart

  python3

• PreToolUse

  python3

• PreToolUse

  python3

• PreToolUse

  python3

• PreToolUse

  python3

• UserPromptSubmit

  python3

• PostToolUse

  python3

• PostToolUse

  python3

• PostToolUse

  python3

• PostToolUseFailure

  python3

• PostToolUseFailure

  python3

• SubagentStart

  python3

• SubagentStop

  python3

• Stop

  python3