openai/get-context
Mandatory design-brief gate for clarifying the product and outcome. Use before ideation, image-to-code builds, redesigns, or product UI work to clarify missing product information and play back the brief before proceeding.
npx skills add https://github.com/openai/role-specific-plugins --skill get-context
Run this skill at the start of Product Design requests that ask to design, build, prototype, clone, redesign, extend, or generate product UI directions.
Use question mode to clarify the following:
Do not re-ask answered questions. When both are clear, play back the brief and defaults in one pithy note, name the next workflow, and continue in the same turn. Playback is not a request for approval. The user can course-correct style, scope, or interactivity at any point.
Hard boundary: do not implement UI, scaffold a prototype, start a server, or create files while the design target or intended user outcome is still missing.
Before starting, load $user-context and run its preflight script when local shell access is available.
Use saved product URLs, Figma files, screenshots, reference images, codebase paths, Storybook, tokens, design systems, brand assets, component refs, browser preferences, and share targets as grounding material when relevant.
Do not inspect every saved reference. Inspect only what the current task needs.
$ideate, $url-to-code, or $image-to-code, play back the minimum brief and any defaults in one pithy user-visible note.This kind of build usually takes about 10-15 minutes, and ambitious ones can take longer. Good moment to grab coffee or tend to something else; I’ll keep moving and bring the prototype back when it is ready.
Do not send this note for tiny static changes, quick audits, simple research, setup-only, or share-only requests.
Done means the design target and intended user outcome are clear, defaults have been played back, and any already-determined next skill has been read.
Take openai/get-context from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.