agentsclimarketplace
Sign in

Working with design

Skill Dragoon0x/product-skills/skills/collaboration/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.From its SKILL.md

Install
npx -y skills add Dragoon0x/product-skills --skill working-with-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.6 KB, 462 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,750. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.