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
- Identify the critical unknowns (the ones that would change what you build).
- Ask them concisely, grouped, not as a 20-question interrogation.
- If the user's framing seems flawed (wrong problem, contradictory constraints), raise it and propose an alternative before proceeding.
- Write
./design/context.md with answers + explicitly flagged assumptions + risks.
- 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.
1---2name: design-get-context3description: 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.4---56# Design — Get Context78De-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.910## When to use11- Any new design/UI task where the spec isn't already crisp.12- The request is a one-liner ("design a settings page") with implicit, unstated requirements.13- Before `design-research`, `design-audit`, `design-ideate`, or any build skill.1415## When NOT to use16- A solid `./design/context.md` (or equivalent spec) already exists → proceed to the next skill.17- A pure visual-asset task with no UX → that's the Creative Production set.1819## What to interrogate (ask the gaps, don't dump all at once)20- **Goal**: what outcome or behavior change is this UI for? (not "a page" — *why*)21- **User**: who uses it, their context, tech comfort, frequency.22- **Job-to-be-done**: the core task the screen must make effortless.23- **Constraints**: existing stack, design system, brand, platform, deadline.24- **Success criteria**: how we'll know it worked — ideally measurable.25- **Scope**: must-have vs nice-to-have for v1; explicit non-goals.2627Ask 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.2829## Workflow301. Identify the critical unknowns (the ones that would change what you build).312. Ask them concisely, grouped, not as a 20-question interrogation.323. If the user's framing seems flawed (wrong problem, contradictory constraints), **raise it and propose an alternative** before proceeding.334. Write `./design/context.md` with answers + explicitly flagged assumptions + risks.345. Hand off to `design-research`, `design-audit`, or `design-ideate`.3536## Output: ./design/context.md37```38# Context39goal: cut onboarding drop-off (currently 40% abandon at step 2)40user: first-time SaaS trial users, mixed tech comfort, on desktop41JTBD: get to "first value" (a created project) in under 2 minutes42constraints: stack=Next.js + Tailwind DS=internal "Aurora" platform=web deadline=2wk43success: step-2 completion ↑ from 60% → 80%; time-to-first-project < 2min44scope v1: [3-step wizard, skip-able, progress saved]45non-goals: [mobile layout, SSO, team invites]46open assumptions: [users have a use case in mind on arrival]47⚠ risks: [if drop-off is a value problem not a UX problem, redesign won't fix it]48```4950## Quality bar51- Goal, user, and success criteria are all present (or explicitly deferred by the user).52- Success criteria are concrete enough to QA against later (`design-qa` reads these).53- Every guess is labeled an assumption — nothing is silently invented.54- Non-goals are stated so scope can't creep unnoticed.5556## Common pitfalls57- **Starting to design before the brief is clear** — the entire point of this skill is to prevent that.58- **Question-dumping** — 20 questions at once stalls the user. Ask the few that matter.59- **Burying a guess as a fact** — if you assumed it, say "assumption:".60- **Accepting a flawed framing silently** — if the user's asking for the wrong thing, surface it now (cheap) not after building (expensive).6162## Handoff63`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.6465## Tooling66None required — this is a conversation + a written artifact.
dkeken