How do I install the Working With Design skill?

Run npx skillmds@latest add dragoon0x/working-with-design in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Working With Design safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Working With Design?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Working With Design free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Working With Design?

dragoon0x (@dragoon0x) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Working With Design by dragoon0x — Agent Skill

Name: Working With Design
Author: dragoon0x

Working With Design

Partner with design to create better products, not just prettier ones. Covers when to involve design, how to give useful feedback, and respecting the design process. Use when PM-design handoffs feel clunky, design feedback conversations are unproductive, or design is brought in too late.

dragoon0x 36600fc 2.6 KB Updated Sep 17, 2026

File contents

Working with Design

Partner with designers to solve the right problems, not just make things look good.

How to use

/working-with-design Apply design collaboration constraints to this conversation.
/working-with-design <situation> Navigate a specific PM-design challenge.

Constraints

Involvement Timing

MUST involve design at the problem definition stage, not after requirements are locked
Designers SHOULD be in user research conversations alongside PM
MUST give design time to explore before converging on a solution
NEVER hand design a finished spec and ask them to "make it pretty"
SHOULD involve design in prioritization discussions — they often see user impact PM misses

Problem Framing

MUST share the user problem, constraints, and success metrics with design — not a wireframe
SHOULD provide design with user research, data, and competitive context
MUST articulate what success looks like so design can evaluate their own work
NEVER give design a solution to execute. Give them a problem to solve.

Feedback

MUST give feedback on design decisions in terms of user goals and business outcomes
SHOULD say "I'm worried users won't find this because..." not "make the button bigger"
MUST separate personal taste from product judgment. "I don't like blue" is not useful feedback.
NEVER critique design in front of stakeholders without discussing 1:1 first
SHOULD trust design expertise on visual and interaction decisions

Process Respect

MUST respect that good design takes iteration — the first version is not the final one
SHOULD agree on review cadence: when will design share work and when will PM give feedback
MUST protect design time from "quick favors" that fragment their focus
NEVER go around design to make UI decisions directly with engineering

Anti-Patterns

The Wireframe PM: designing the solution yourself and handing it to design for execution
Late Involvement: bringing design in after the PRD is approved and scope is fixed
Pixel Feedback: commenting on visual details instead of whether the design solves the problem
Design by Committee: running every design decision through 8 stakeholders
Ignoring Design Debt: never investing in design consistency, polish, or system improvements

---name: working-with-designdescription: Partner with design to create better products, not just prettier ones. Covers when to involve design, how to give useful feedback, and respecting the design process. Use when PM-design handoffs feel clunky, design feedback conversations are unproductive, or design is brought in too late.---# Working with DesignPartner with designers to solve the right problems, not just make things look good.## How to use- `/working-with-design` Apply design collaboration constraints to this conversation.- `/working-with-design <situation>` Navigate a specific PM-design challenge.## Constraints### Involvement Timing- MUST involve design at the problem definition stage, not after requirements are locked- Designers SHOULD be in user research conversations alongside PM- MUST give design time to explore before converging on a solution- NEVER hand design a finished spec and ask them to "make it pretty"- SHOULD involve design in prioritization discussions — they often see user impact PM misses### Problem Framing- MUST share the user problem, constraints, and success metrics with design — not a wireframe- SHOULD provide design with user research, data, and competitive context- MUST articulate what success looks like so design can evaluate their own work- NEVER give design a solution to execute. Give them a problem to solve.### Feedback- MUST give feedback on design decisions in terms of user goals and business outcomes- SHOULD say "I'm worried users won't find this because..." not "make the button bigger"- MUST separate personal taste from product judgment. "I don't like blue" is not useful feedback.- NEVER critique design in front of stakeholders without discussing 1:1 first- SHOULD trust design expertise on visual and interaction decisions### Process Respect- MUST respect that good design takes iteration — the first version is not the final one- SHOULD agree on review cadence: when will design share work and when will PM give feedback- MUST protect design time from "quick favors" that fragment their focus- NEVER go around design to make UI decisions directly with engineering### Anti-Patterns- The Wireframe PM: designing the solution yourself and handing it to design for execution- Late Involvement: bringing design in after the PRD is approved and scope is fixed- Pixel Feedback: commenting on visual details instead of whether the design solves the problem- Design by Committee: running every design decision through 8 stakeholders- Ignoring Design Debt: never investing in design consistency, polish, or system improvements

Frequently asked questions