Turn a messy transcript, project doc, or pasted chat thread into a structured 5-bullet design brief - with a gap report for what's missing, for design teams and PMs kicking off new work.
design-brief turns whatever a team has scattered around - a call transcript, project doc, pasted freetext, chat thread - into a structured design brief: Problem, Audience, Success metric, Must-haves, Constraints. Its gap report keeps it honest: when the input does not answer the problem or the audience, the skill lists what is missing and stops, rather than writing a plausible paragraph to fill the hole. When a brief already exists and the project pivots, the change folds into the right bullet and the full brief re-emits, so a two-word directive never wipes the rest of the document.
- What it does
- Quick start
- Usage
- Example output
- How it works
- How is this different from just asking the model?
- FAQ
- Related skills
- Who maintains this
- Reads every source in the input - transcripts, docs, freetext, chat history - before asking a question, and never asks for a field already answered.
- Extracts a fixed 5-bullet brief: Problem, Audience, Success metric, Must-haves, Constraints.
- Refuses to build a brief on guesses: if Problem or Audience is absent from every source, it returns a gap report naming what is missing, then stops.
- Marks Success metric, Must-haves, or Constraints
(not stated - ...)when the input does not cover them, instead of guessing. - Ships a bullet with what the input supports when that is short of its count range - two must-haves, one constraint - and marks the shortfall rather than padding it out with an invented one.
- Handles incremental edits ("now it's B2C", "add constraint: iOS only") by folding each change into the bullet it targets and re-emitting the brief, unchanged elsewhere - including a directive that changes two bullets at once.
- Surfaces conflicting sources ("the doc says B2B, the transcript says B2C") instead of silently picking one.
Personal - available in every project:
git clone https://github.com/humbleteam/design-brief ~/.claude/skills/design-briefProject-scoped - checked into one repo:
git clone https://github.com/humbleteam/design-brief .claude/skills/design-briefAny other agent: the skill is plain markdown in the Agent Skills format. Paste SKILL.md into the system prompt of Cursor, Codex, or any LLM agent - no Claude-specific runtime required.
To verify: restart Claude Code and ask it to list its skills. Skills load from ~/.claude/skills/ (personal) and .claude/skills/ (project) - design-brief should appear.
- "Turn this call transcript into a design brief." (transcript pasted or attached) - reads it, extracts every bullet it can source, and gap-reports anything missing.
- "Here's our project doc - what's missing from the brief?" - runs the same extraction and returns the gap report if Problem or Audience is not covered.
- "Update the brief - we're now targeting enterprise buyers, not solo users." - an incremental edit: folds the pivot into Audience, leaves every other bullet untouched, and re-emits the brief.
Example project and notes are invented for illustration.
Input pasted by the user:
Notes from kickoff call, July 8:
- Client is a mid-size trucking dispatch company, 40-80 trucks per client.
- Dispatchers currently juggle 3 different spreadsheets to assign loads -
it's slow and error-prone, they miss delivery windows.
- Want something that cuts load-assignment time in half within the first
month of use.
- Needs to work offline in the truck yard where wifi is spotty.
- Must integrate with their existing ELD (electronic logging device) system.
- No budget yet for a native mobile app - web only for v1.
- Should feel modern - the tool they use now looks like it was built in 2009.
Skill output:
## Design brief - Pathfinder (dispatch scheduling)
- **Problem:** Dispatchers assign loads across 3 disconnected spreadsheets,
which is slow and causes missed delivery windows.
- **Audience:** Freight dispatchers at mid-size trucking companies running
40-80 trucks.
- **Success metric:** Cut load-assignment time in half within the first
month of use.
- **Must-haves:** Works offline in low-connectivity yard environments;
integrates with the client's existing ELD system. (2 of 3-5 - what else is
non-negotiable here?)
- **Constraints:** Web only for v1 - no budget for a native mobile app. (1 of
2-4 - what else is enforceable here?)
_Source - Problem: kickoff call notes, July 8; Audience: kickoff call notes,
July 8; Success metric: kickoff call notes, July 8; Must-haves: kickoff call
notes, July 8; Constraints: kickoff call notes, July 8._
_Dropped as unenforceable - "should feel modern": what would make this
checkable? A product it should look current against, a design system to match,
or a specific visual quality someone other than the author can confirm._
Two must-haves and one constraint is what those notes support, so both bullets
ship short and say so. The counts are a target shape, not a gate: padding
Must-haves up to three means inventing a non-negotiable, and marking a bullet
that carries two real entries (not stated - ...) asks the client for something
they already gave.
The notes named a fourth thing the client wants, and "should feel modern" is not enforceable: two people can disagree about whether it was delivered and neither can point at anything. It gets dropped from the bullet, and it gets named under the brief, because those are separate decisions. Dropping it silently would leave the client with a Constraints bullet marked short and nothing saying their line was read, so the natural thing for them to do is supply it again - and it would be dropped again. The line hands the words back with the one question that can turn them into a constraint.
A follow-up directive changing two bullets at once - the success metric and the constraints:
Update the brief - the success metric is now 30% fewer missed delivery windows
in the first quarter, and add a constraint: WCAG 2.2 AA.
Both targets are clear, so both changes land. Problem, Audience, and Must-haves come back byte-for-byte, and the footer moves only for the two bullets that changed:
## Design brief - Pathfinder (dispatch scheduling)
- **Problem:** Dispatchers assign loads across 3 disconnected spreadsheets,
which is slow and causes missed delivery windows.
- **Audience:** Freight dispatchers at mid-size trucking companies running
40-80 trucks.
- **Success metric:** 30% fewer missed delivery windows in the first quarter.
- **Must-haves:** Works offline in low-connectivity yard environments;
integrates with the client's existing ELD system. (2 of 3-5 - what else is
non-negotiable here?)
- **Constraints:** Web only for v1 - no budget for a native mobile app;
WCAG 2.2 AA.
_Source - Problem: kickoff call notes, July 8; Audience: kickoff call notes,
July 8; Success metric: update; Must-haves: kickoff call notes, July 8;
Constraints: kickoff call notes, July 8 + update._
_Dropped as unenforceable - "should feel modern": what would make this
checkable? A product it should look current against, a design system to match,
or a specific visual quality someone other than the author can confirm._
The new constraint takes that bullet to two, so its shortfall marker clears itself. Must-haves still carries two, so its marker stays until the input answers the question in it. The drop line stays too: the entry is still dropped and still unanswered, and a line that disappears on the next edit would read as the question having been resolved.
Answering it is the one thing that retires it. A later directive saying what "should feel modern" meant - "match the information density of the Stripe dashboard" - is not a new constraint but the reply that line asked for, so it lands in Constraints and the line goes with it. Restated and still not checkable ("it should feel fresh"), it replaces the line rather than adding a second one underneath: one line per dropped entry, not one per attempt at it.
- Read everything before asking anything. Freetext, docs, transcripts, chat history - all read before a field is marked missing.
- Two required bullets, three optional ones. Problem and Audience block the brief if absent; the rest get a
(not stated - ...)marker instead. - The gap report is one compact block, then a full stop. No partial brief gets built on a guess - a missing Problem or Audience triggers one gap-report block, nothing else.
- Audience and constraints need to be specific and checkable. "Users" fails; "freelance expedition guides booking 5-20 trips a year" passes. "Mobile-first, WCAG AA, no native app in v1" survives; "make it modern" gets dropped - and named under the brief, with the question that would turn it into a constraint, so the team can restate it instead of supplying it twice. That line rides every later edit until they answer it, and a checkable answer retires it into the bullet rather than sitting next to the constraint it just produced.
- Every bullet carries a source, named one by one. A footer names which input and section each bullet came from, and it keeps that shape even when a single document answered all five - the grouped form has no slot for a bullet that was never found, and the first edit re-sources one bullet and has to expand it again. A bullet whose origin the input never named - the usual case when a brief is pasted in without a footer and then edited - is marked
carried from the brief as givenrather than pinned on a guessed file name. - The counts are a target, not a gate. 3-5 must-haves and 2-4 constraints describe the brief a full input produces. A bullet with fewer real entries than that ships anyway, marked
(2 of 3-5 - ...), because padding to the floor invents a non-negotiable and(not stated - ...)re-asks for what the input already gave. Above the ceiling nothing is cut: nine stated must-haves all ship, with a question about which are truly non-negotiable. - An incremental edit touches the bullets the directive names, and no others. Each change maps to its own bullet - one is the common case, two is ordinary - everything else stays byte-for-byte, and the full brief is re-emitted, never a reply that reads as if the rest got deleted.
- Conflicting sources get surfaced, not resolved silently. A doc saying B2B against a transcript saying B2C gets named as a conflict, not silently picked.
A bare "write a design brief from this" prompt tends to paraphrase the input into one paragraph and invent a success metric or constraint that sounds reasonable but was never stated. Asking for an update - "now it's B2C" - usually rebuilds the brief from that one sentence, erasing the Problem, Must-haves, and Constraints it never repeated. This skill pins the structure to 5 named bullets, refuses to fabricate the two required ones, and treats an edit as a patch to the bullets the directive names, not a rewrite of the document.
What should a design brief include? 5 bullets: Problem (the pain or business need), Audience (a role, size, and behavior - not just "users"), Success metric (one observable outcome), Must-haves (3-5 non-negotiable features), and Constraints (2-4 enforceable limits like platform, accessibility, or budget).
How do I write a design brief from a meeting transcript? Paste or attach the transcript and ask for a brief. The skill reads it in full, extracts what it can source, and returns a gap report instead of a guess for anything the transcript never covers.
How do I keep a design brief up to date? Give the skill a directive naming what changed ("now it's B2C", "add constraint: iOS only"). It folds the change into the correct bullet, leaves the rest untouched, and re-emits the full brief.
Can I change two things in one update? Yes. "We're B2C now and drop the offline requirement" carries two clear changes, so both land - one in Audience, one in Must-haves - and the other three bullets come back untouched. A clarifying question is for a change whose target bullet is unclear, not for a directive that names two of them.
What if I only have two must-haves?
The brief ships with two. The 3-5 range is the shape a complete input produces, not a quota the bullet has to fill: the bullet comes back as the two real entries plus (2 of 3-5 - what else is non-negotiable here?). Padding it to three would mean inventing a non-negotiable feature, which is the one thing this skill will not do. The same holds the other way: nine stated must-haves all ship, with a question about which of them are truly non-negotiable, rather than a silent cut down to five.
Can Claude write a design brief for me? Yes, from whatever unstructured input you already have - transcripts, docs, chat threads, freetext. It will not invent a problem or audience it cannot source; those two fields trigger a gap report.
What if my brief is missing information?
If Problem or Audience is missing, the skill stops and lists what is needed. If Success metric, Must-haves, or Constraints is missing, the brief still gets built with that bullet marked (not stated - ...).
Part of a 10-skill open-source kit for design teams by Humbleteam.
- design-review - structured UX critique with a 0-4 score, Before/After/Why fixes, and a citation for every claim.
- ascii-wireframes - three distinct layout hypotheses as ASCII wireframes before any hi-fi work.
- html-mockup - census-first HTML mockups that match a reference screenshot: exact palette, item counts, component states.
- extract-design-tokens - pull palette, type, spacing, radii, and shadows from a URL or screenshot into CSS variables and JSON.
- audit-design-tokens - find token drift in a codebase: raw hex values, off-scale spacing, near-duplicate colors.
- design-qa - a pre-ship design QA gate: states, contrast, touch targets, breakpoints, keyboard paths.
- design-handoff - turn a finished mockup into a dev-ready spec: tokens, states, accessibility annotations, open questions.
- accessibility-audit - WCAG 2.2-grounded accessibility review with success-criterion citations and severity levels.
- ux-writing - interface copy that reads human: plain-verb microcopy rules and an AI-tell strip pass.
Humbleteam is a digital product design and AI-engineering studio: founded in 2017, working from Prague and Dubai, with 80+ digital awards to the name, including 14 Awwwards wins, a Webby, and a Red Dot. We design digital products for startups and enterprises in fintech, healthtech, sports, and AI, and we build AI infrastructure for design teams - agents, workflows, and skills like this one.
This skill is distilled from the internal playbooks we run on client work: the same checklists behind the case studies at humbleteam.com/work, for clients like Tinder and Acronis.
- The full 10-skill kit: Related skills above, or all repos at github.com/humbleteam
- What we do with AI for design teams: humbleteam.com/ai
- Design and AI writing: humbleteam.com/blog
- LinkedIn: linkedin.com/company/humbleteam
- Talk to us: hi@humbleteam.com
Issues and PRs welcome.
MIT - see LICENSE.