bandersnatch0x/design-playbook
Evidence-backed UI delivery for coding agents working on existing Web products: declared criteria, criterion-bound artifacts, findings linked to declarations, and repair guidance. Evaluator review does not replace human semantic approval.
Cross-run component backflow. Derive the reusable components that have recurred across iterated pages and render a propose-only promotion proposal for user adjudication. Use when iterated pages may have produced components worth promoting into DESIGN.md or the same component recurs across runs and scenes. Also use when the user asks what the pages have taught the design system. Report-only, never writes DESIGN.md or any authority.
UI craft and feedback quality. Use when polishing product UI (motion, loading and error feedback) or when a page reads as AI slop.
Discover, validate, or draft a project-owned DESIGN.md before adding or revising UI in an existing frontend. Use during design-playbook initialization when a repository already has pages, components, themes, tokens, or styles. When new UI looks inconsistent with existing surfaces. When DESIGN.md may be missing, incomplete, conflicting, or stale. Or when the user asks to generate a design system from existing frontend source. Produces a provenance-backed draft and requires confirmation before creating or replacing the durable baseline.
Route and orchestrate outcome-first product UI work. Use for answer, review, diagnosis, plan, prototype, build, or fix requests about pages, dashboards, lists, or settings. Also use to recirculate failed design review through declarations and evidence.
Native-feel declaration for desktop apps. Use when a cross-platform desktop app (macOS+Windows) must feel indistinguishable from native. Invoked before ui-picker for native-desktop targets, not web pages.
Reference intake contract from screenshot, URL, design file, or product analogy. Use when the user supplies a visual or product reference before build. Also use when Keep, Change, and Do not copy boundaries are missing.
Run evidence-backed UI acceptance. Use after generating a page, or when the user wants a design review or recirculatable critique against declared goals and success criteria.
UI shell and component semantics. Use when building a product page (list, dashboard, settings, detail, agent-admin), or when the wrong template and Badge-Tag pairing is about to be coded.
Declaration-first UI spec (six-layer spec.md) shaped through an S0-S6 interactive session. Use when turning a short product and UI ask into six-layer spec.md, or when goal, edge-state, acceptance, or evidence requirements are missing before build.