servierhub/product-design

Process pending browser annotations left on a running Product Design prototype or app, in any supported framework (Vite, Next.js, Nuxt, Astro, or another framework annotation was ported to via product-design:annotate-inject). Use when the user says they left/added annotations, marked up a region, drew a box, or asks to check/apply feedback from the annotate tool on a project that is currently running locally. Also check proactively, unprompted, whenever returning to a project with the annotation overlay and a running dev server, before other work on it.

Install and verify browser annotation in an existing/user-provided boilerplate (Next.js, Nuxt, Astro, Vite, or port) after the user explicitly requests it or confirms the proposed non-trivial codebase change. Bundled Product Design templates already include annotation. The agent starts/reuses the dev server, verifies toggle + POST + inbox write, keeps it running, and returns the URL; never delegate startup commands to the user.

Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings inline from that evidence. Use Figma only when the user explicitly asks for a board. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.

Blocking Product Design handoff gate after product-design:image-to-code, product-design:url-to-code, or Goose Apps rendering. Requires an openable source visual and browser-captured rendered implementation at a comparable state; write passed/blocked evidence before handoff. Broad UX critique belongs to product-design:audit.

Product Design brief gate. After product-design:index, load before product-design:ideate, product-design:image-to-code, redesign, Product Design + Goose Apps, or product UI build work; require a clear design target and intended user outcome, play back the brief, then hand off to the named focused workflow before any rendering tool.

For each of three multi-step variants, define the journey, generate one full-size image per traversed screen, then create one separate board page arranging those files. Single-screen work generates three directions for the same screen.

Build a selected visual target into a reviewable frontend after product-design:get-context. Trigger for screenshot/mock/Figma/ImageGen-to-code, including Servier/DIFA/DNA screens in an existing boilerplate. Default design-validation builds to mock data only (no new DB/auth/services/actions). Bundled templates include annotation by default; for an existing user project, offer annotation support and obtain confirmation before changing it. Start the app yourself, verify the review URL, then run product-design:design-qa. Never ask the user to launch the server manually.

Primary Product Design router. Load this exact skill first whenever the user explicitly names Product Design or the product-design plugin, including requests that also name Goose Apps. Also route design exploration, UX research/audit, visual-source cloning, prototype QA, and sharing here; ordinary UI implementation stays outside unless Product Design is explicit.

Optional: track a Product Design project's phase (product-design:get-context, visual sourcing, build, product-design:design-qa, product-design:share) or annotation rounds as Beads (bd) issues, so status is queryable via bd ready/bd show instead of only living in conversation history. Triggers on two kinds of request: (1) explicit — the user names Beads, bd, issue tracking, or asks to track/plan progress; (2) vocabulary-based — the user talks in epic, gate, user story, success/acceptance criteria, task breakdown, ready/blocked, or backlog terms about a Product Design project. Never a gate — Product Design workflows run the same with or without this.

Run fast, source-grounded UX research on the highest-signal problems users are experiencing with a user-specified digital product. Use when the user asks to research user pain, UX friction, onboarding issues, docs/help problems, developer experience friction, support pain, product workflow issues, or current user complaints for a named product.

Focused Product Design deployment handoff. Use only after a runnable prototype exists and the user requests sharing; require a chosen available hosting target and return a verified working URL. Goose Apps creation alone is not deployment.

Clone a live URL as a runnable frontend-only local app.

Load or manage optional Product Design context stored locally for Goose. Use only when the user asks to set up, save, recall, inspect, or update durable product/design references or preferences; ordinary Product Design workflows do not require persisted context.