design-get-context

---
name: design-get-context
description: Clarify the brief BEFORE any design work to avoid building the wrong thing. Interrogates goal, user, constraints, success criteria, and scope, then writes a short context doc the other design skills consume. Use when the user says "let's design X", "build a UI for Y", "get context", "clarify the brief", or kicks off any product-design task without a clear spec. First stage of the Product Design set — highest leverage for reducing rework.
---

# Design — Get Context

De-risk the whole design effort by nailing the brief first. The cheapest fix is the question you ask before building. This skill produces `./design/context.md` — the single source of truth every other design skill reads. Skipping it is the #1 cause of "that's not what I meant" rework.

## When to use
- Any new design/UI task where the spec isn't already crisp.
- The request is a one-liner ("design a settings page") with implicit, unstated requirements.
- Before `design-research`, `design-audit`, `design-ideate`, or any build skill.

## When NOT to use
- A solid `./design/context.md` (or equivalent spec) already exists → proceed to the next skill.
- A pure visual-asset task with no UX → that's the Creative Production set.

## What to interrogate (ask the gaps, don't dump all at once)
- **Goal**: what outcome or behavior change is this UI for? (not "a page" — *why*)
- **User**: who uses it, their context, tech comfort, frequency.
- **Job-to-be-done**: the core task the screen must make effortless.
- **Constraints**: existing stack, design system, brand, platform, deadline.
- **Success criteria**: how we'll know it worked — ideally measurable.
- **Scope**: must-have vs nice-to-have for v1; explicit non-goals.

Ask only the questions whose answers would *change the design*. If something's already given, don't re-ask. If the user can't answer "success criteria", propose 2-3 candidates and let them pick.

## Workflow
1. Identify the critical unknowns (the ones that would change what you build).
2. Ask them concisely, grouped, not as a 20-question interrogation.
3. If the user's framing seems flawed (wrong problem, contradictory constraints), **raise it and propose an alternative** before proceeding.
4. Write `./design/context.md` with answers + explicitly flagged assumptions + risks.
5. Hand off to `design-research`, `design-audit`, or `design-ideate`.

## Output: ./design/context.md
```
# Context
goal: cut onboarding drop-off (currently 40% abandon at step 2)
user: first-time SaaS trial users, mixed tech comfort, on desktop
JTBD: get to "first value" (a created project) in under 2 minutes
constraints: stack=Next.js + Tailwind  DS=internal "Aurora"  platform=web  deadline=2wk
success: step-2 completion ↑ from 60% → 80%; time-to-first-project < 2min
scope v1: [3-step wizard, skip-able, progress saved]
non-goals: [mobile layout, SSO, team invites]
open assumptions: [users have a use case in mind on arrival]
⚠ risks: [if drop-off is a value problem not a UX problem, redesign won't fix it]
```

## Quality bar
- Goal, user, and success criteria are all present (or explicitly deferred by the user).
- Success criteria are concrete enough to QA against later (`design-qa` reads these).
- Every guess is labeled an assumption — nothing is silently invented.
- Non-goals are stated so scope can't creep unnoticed.

## Common pitfalls
- **Starting to design before the brief is clear** — the entire point of this skill is to prevent that.
- **Question-dumping** — 20 questions at once stalls the user. Ask the few that matter.
- **Burying a guess as a fact** — if you assumed it, say "assumption:".
- **Accepting a flawed framing silently** — if the user's asking for the wrong thing, surface it now (cheap) not after building (expensive).

## Handoff
`context.md` → `design-research` (gather outside signal), `design-audit` (if improving existing UI), or `design-ideate` (go straight to directions). Every downstream skill reads this file.

## Tooling
None required — this is a conversation + a written artifact.