mohitagw15856
f3b9d008fe
New skills added: - teaching-lesson-plan: structured lesson plans for any subject/audience/setting - seo-content-brief: complete SEO briefs with intent, competitor gaps, and outline - media-pitch: story-first journalist pitches with angle development framework - change-management-plan: stakeholder analysis, comms strategy, adoption metrics - workshop-facilitation-guide: activity instructions, decision protocols, facilitator moves - sales-forecasting-model: pipeline model, scenario analysis, assumption log - tax-planning-checklist: year-end tax planning across income, pension, CGT, reliefs Quality improvements across all 93 existing skills: - Standardised description format: "Verb the thing. Use when X. Produces Y." - Added Required Inputs section to all skills missing it (prompts for missing info) - Added Quality Checks section to all skills missing it (specific, not generic) - Fixed broken multiline YAML descriptions - Removed non-standard frontmatter keys (tool_integration, metadata blocks) README updated to v6.0.0 with 100-skill count, new skill tables, and article series Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.1 KiB
3.1 KiB
name, description
| name | description |
|---|---|
| design-handoff-brief | Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries. |
Design Handoff Brief Skill
Produce a design brief that sets designers up for success — grounding them in user context and constraints before they open Figma, not after they've gone in the wrong direction.
Required Inputs
Ask the user for these if not provided:
- Feature brief or PRD (even rough notes work)
- Designer's name or team (for personalisation)
- Technical constraints (any engineering limitations already known)
- Timeline (when does design need to be done?)
What Designers Actually Need (and PMs Often Skip)
- The user's goal, not the feature name
- The emotional state of the user at this moment in the journey
- What success looks like — how will we know the design worked?
- Constraints: technical, legal, brand, accessibility
- Edge cases that must be handled
- What we're explicitly NOT solving for
Process
- Read the feature brief or PRD provided
- Extract user goal (reframe from feature language to user outcome language)
- Identify constraints — technical limitations, brand guidelines, accessibility requirements
- List edge cases the design must handle
- Define success criteria the design should be evaluated against
- Write a "not in scope" section to prevent scope creep in design
- Validate — Confirm every edge case listed is specific enough to design for, and every out-of-scope item is concrete enough to say "no" to
Output Structure
Design Brief: [Feature Name]
User Goal: (in the user's words, not ours) "When I [situation], I want to [motivation] so that I can [outcome]."
Context & Emotional State: [Where is the user in their journey? What are they feeling? What just happened?]
Design Success Criteria:
- [Criterion 1 — measurable where possible]
- [Criterion 2]
- [Criterion 3]
Constraints:
- Technical: [limitations engineering has flagged]
- Brand: [relevant brand guidelines]
- Accessibility: [WCAG level required, any specific requirements]
- Legal/Compliance: [if applicable]
Edge Cases to Design For:
- [Edge case 1]
- [Edge case 2]
- [Edge case 3]
Explicitly Out of Scope:
- [What we are NOT solving in this design iteration]
Reference Material:
- User research: [link]
- Existing patterns: [Figma component library link]
- Competitor examples: [links if relevant]
Quality Checks
- User goal is written in user language (not feature/product language)
- At least one edge case covers an error or failure state
- Success criteria are measurable or observable (not "looks good")
- Out-of-scope section names at least one thing that might seem in scope but isn't
- Technical constraints are specific enough for an engineer to confirm