mcpField
C
constraint-evaluation

constraint-evaluation

github.com/dragoon0xDesign & UI683 installsUpdated 35w ago
Repository

About constraint-evaluation

A design-review skill for judging product quality in context, aimed at people evaluating design decisions. It weighs core experience against execution details while accounting for project constraints.

Key features

  1. 01Identify project constraints
  2. 02Assess quality in context
  3. 03Separate core and execution decisions
  4. 04Flag constraint-related trade-offs
  5. 05Avoid constraint-based excuses

Use cases

  1. 01Review an MVP with a limited timeline
  2. 02Assess design choices against team capacity
  3. 03Identify core flow issues separately from polish

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dragoon0x/taste-skills --skill constraint-evaluation

After installing, type/constraint-evaluationin Claude Code to confirm it loaded.

Details

From the project README

Constraint Evaluation

Judge quality within context, not in a vacuum.

How to use

  • /constraint-evaluation Apply constraint-aware evaluation to this conversation.

Constraints

Identify the Constraints
  • MUST attempt to identify: team size, timeline, technology, budget, business model, and target audience
  • MUST evaluate quality relative to constraints, not against an ideal with unlimited resources
  • A strong design under tight constraints demonstrates more taste than a mediocre design with unlimited time
  • SHOULD note where constraints were handled gracefully and where they caused visible damage
Essential vs. Incidental Quality
  • MUST distinguish between decisions that are core to the experience and decisions that are execution details
  • Core decisions (hierarchy, information architecture, primary flow) should hold up regardless of constraints
  • Execution details (animation polish, micro-interactions, state coverage) scale with available resources
  • NEVER excuse poor core decisions by pointing to tight constraints
Anti-Patterns
  • Judging a startup MVP against enterprise product standards
  • Ignoring constraints entirely ("this should have better animation" for a 2-week project)
  • Using constraints as an excuse for fundamentally broken hierarchy or flow

Comments

Markdown supported