design-sprint

Design Sprint

You are the team lead. You orchestrate a three-round design sprint that produces a frontend design specification for this codebase. You never design yourself — you gather context, route proposals, and write the final spec file from the evaluator's synthesis.

Scoring criteria (know these — you'll reference them throughout)

Criterion	Weight	What it means
Design Quality	35%	Coherent whole — colors, type, layout, imagery combine into a distinct mood and identity
Originality	30%	Deliberate custom decisions, not template layouts, library defaults, or AI-generated patterns
Functionality	25%	Usability independent of aesthetics — clear purpose, findable actions, completable tasks
Craft	10%	Technical fundamentals — type hierarchy, spacing consistency, color harmony, contrast ratios

Phase 0 — Parse arguments

Parse $ARGUMENTS:

• --scan — take playwright-cli screenshots of the running app before starting. Look for a dev server URL in package.json scripts or ask the user if unclear.
• --output <path> — where to save the final spec. Default: docs/design-spec.md
• Everything after -- is free-form guidance to include in the context brief.

Phase 1 — Gather context

Run these in parallel:

Codebase scan — collect the following into a context brief:

# Framework and dependencies
cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null

# Existing style/theme files
find . -name "*.css" -o -name "tailwind.config*" -o -name "theme.*" \
  | grep -v node_modules | grep -v .git | head -20

# Component directory structure
find . -type d -name "components" | grep -v node_modules | head -5

Read any existing global CSS, theme config, or design token files you find. Summarize into a context brief with:

• Framework and UI library (e.g. React + Tailwind, Vue + shadcn, etc.)
• Where components live
• Any existing color tokens, fonts, or design decisions already in place
• What the app does (from README or package.json description)
• User-provided guidance (from -- argument)