design-review
Workflow recipe — review a design end-to-end, ending in measured numbers rather than adjectives, by chaining 4 skills.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/mohitagw15856/pm-claude-skills/HEAD/commands/design-review.md -o ~/.claude/commands/design-review.mddesign-review.md
Run the **Design Review** workflow recipe for: $ARGUMENTS This is a *chain* of skills. Run each stage in order and **carry every stage's output forward as context** for the next. Open with a one-line plan of the 4 stages, then ask once for essential missing inputs (the actual hex values or a URL, the target WCAG level, whether it will ever be printed, who signs off). Don't re-ask between stages. **Before stage 2, measure.** A design review that assesses contrast by eye is an opinion with a standards reference attached. If you have a URL or hex values, run these first and carry the numbers through every stage: ```bash npx --yes notugly spec <url> # palette, type scale, radii — what it is made of npx --yes notugly onepager <url> --out review.html # every pairing, with the nearest passing colour npx --yes notugly vision <url> # colours that merge for colour-blind viewers ``` Deterministic, zero dependencies, **no model call**. If you only have a screenshot, say so explicitly in the output — an inferred ratio is not a finding. Run each stage under a clear `## Stage N — <name>` heading: 1. **React honestly** — apply the `design-critique` skill: what the design is trying to do, where it succeeds, and where intent and execution diverge. Do this *before* the measurements so the critique is about the design rather than about its contrast ratios. 2. **Measure what can be measured** — apply the `accessibility-audit` skill, filling every contrast row from the `notugly` output above rather than assessing it. Flag explicitly which findings are computed and which are judgement. 3. **Check the system behind it** — apply the `design-system-audit` skill: is this a one-off, or does it reveal a token problem? Run `npx notugly tokens <file>` if a token file exists; it names failing pairs semantically (`color.text.danger on surface.default is 2.99:1`), which turns a vague note into a bug with an owner. 4. **Hand it over** — apply the `design-handoff-brief` skill: the decisions, the measured values, and the open questions, in the form an engineer can build from. Close with a **one-page verdict**: the three things to fix before ship, the measured evidence for each, and the split between *find-and-replace* fixes and fixes that need a design decision. That split is the whole reason this recipe exists — "twelve accessibility issues" gets deferred; "nine are a find-and-replace and three need Priya to pick a colour" gets scheduled.
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.