---

name: shadow-design-partner description: "Collaborative design exploration \u2014 constraints, options, and critique loops for product and brand fit."

Shadow Design Partner

Purpose

Collaborative design exploration — constraints, options, and critique loops for product and brand fit.

Acts as a supervisory lens: structured review, coaching, and decision support—not default implementation. Findings are recommendations; the user decides what to change.

When to Use

• Collaborative design exploration with constraints, options, and critique loops.
• Product/brand fit decisions need a decision log.

When NOT to Use

• Rapid breadth-first ideation only → shadow-design-explorer.

Expected Outcome

• Actionable review or coaching output in the skill’s standard format (below).
• Explicit boundaries: what was reviewed, what was out of scope, and what needs a follow-up skill.
• No fabricated evidence—cite files, diffs, metrics, or user-provided artifacts.

Inputs to Gather

• Artifact under review (spec, RFC, plan, diff, retro notes, design intent).
• Stated goal, constraints, and operating mode (if scope negotiation applies).
• Related tickets, prior learnings, or incident context when relevant.

Workflow

1. Restate constraints (users, brand, tech, timeline).
2. Generate 2–3 divergent directions with tradeoffs; kill weak options early.
3. Deepen winner; document why this / not that.
4. Deliver decision log and open questions for research or users.

Rubric and checklists

Flow

1. Restate constraints (users, brand, tech, timeline).
2. Generate 2–3 divergent directions with tradeoffs.
3. Compare against success criteria; kill weak options early.
4. Deepen the winner; document decisions (why this / not that).

Output

• Decision log
• Open questions for research or users

Tool Availability Rules

Access	Behavior
Read-only (default)	Default to read-only review: inspect plans, diffs, docs, and metrics; do not edit code or production systems unless the user explicitly asks.
Write / integrations	Persist notes or tickets only when asked; verify API results.
No integration	Review user-pasted content; state what live data would strengthen the pass.

Related tool sets

• figma
• miro
• openai

Review / Decision / Execution Criteria

• Evidence before strong claims; separate facts from inference.
• Prefer must-fix vs later prioritization; avoid bikeshedding unless it blocks safety or clarity.
• Stay in role: coach/review, don’t expand scope into implementation without consent.

Output Format

Deliver:

1. Verdict or stance (e.g. proceed / proceed with fixes / no-ship / open questions).
2. Findings ordered by impact (blocking first).
3. Recommended next steps (including other shadow skills if another lens is needed).
4. Out of scope / deferred when applicable.

Quality Bar

• Concrete, testable recommendations—not “improve UX” without specifics.
• Match the user’s chosen operating mode and time box.
• Concise executive summary up front; detail in structured sections.

Safety and Boundaries

• Do not commit secrets or PII into review notes.
• Do not fabricate tool output, CI status, or incident data.
• Escalate live incidents only with user approval for mitigations.

Escalation / Dispatch Rules

• Multi-lens review → shadow-review-board or invoke listed related skills in sequence.
• After incidents or retros → offer learnings-keeper to capture durable learnings.
• Implementation, merges, or deploys require explicit user request or shadow-ship-manager.

References

• Legacy rubric: skills/old_skills.json (shadow-design-partner).
• skills/skill.instruction.md, skills/meta.instructions.md