mohitagw15856
036511ab3e
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
79 lines
3.4 KiB
Markdown
79 lines
3.4 KiB
Markdown
# 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
|
|
1. Read the feature brief or PRD provided
|
|
2. Extract user goal (reframe from feature language to user outcome language)
|
|
3. Identify constraints — technical limitations, brand guidelines, accessibility requirements
|
|
4. List edge cases the design must handle
|
|
5. Define success criteria the design should be evaluated against
|
|
6. Write a "not in scope" section to prevent scope creep in design
|
|
7. **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
|
|
|
|
## Anti-Patterns
|
|
|
|
- [ ] Do not write the user goal in feature language ("design the checkout flow") — it must be written from the user's perspective with a motivation and outcome
|
|
- [ ] Do not skip the "Explicitly Out of Scope" section — without it, designers will inadvertently solve problems not intended for this iteration
|
|
- [ ] Do not list edge cases that are so generic they apply to any feature (e.g. "handle errors") — each edge case must be specific to this feature's failure modes
|
|
- [ ] Do not hand off the brief without confirming engineering constraints are accurate — a constraint that is wrong is worse than no constraint
|
|
- [ ] Do not omit the emotional context of the user — designs without emotional grounding produce technically correct but experientially flat results
|