---
name: dkeken/design-share
source: https://app.decimal.ai/s/dkeken-design-share@1/SKILL.md
source_sha256: d569bb73686c
---

# Design — Share

Get the prototype in front of reviewers with a working link + clear run notes. Final handoff stage. The goal is that someone who wasn't involved can open it, know what to look at, and leave useful feedback — without you in the room.

## When to use
- A QA'd prototype is ready to circulate for feedback.
- "Share it", "give me a link", "publish", "let the team see it".
- Handing off to stakeholders for review/sign-off.

## When NOT to use
- The prototype hasn't passed `design-qa` (especially HIGH items) — fix or explicitly flag first.
- It's not runnable yet → `design-prototype`.

## Inputs
- The **QA'd prototype** (path).
- **Share method**: local serve, tunnel, or deploy to a host.
- **Host/account constraints** — ask before deploying anywhere external.

## Workflow
1. **Confirm it runs clean**: install + build + start. Fix any breakers before sharing.
2. **Pick the share method**:
   - **Local** — serve on a port; give the localhost URL + start command (good for solo/local review).
   - **Tunnel** — expose local via a tunnel; only if the user wants external access right now.
   - **Deploy** — push to a preview host (Vercel/Netlify/etc.). **Only with explicit user go-ahead**, since it sends code off-machine.
3. **Write a review note**: what to look at, the happy path to click, known stubs/TODOs, where to leave feedback.
4. **Return** the link + run instructions + review note.

## Worked example
```
method: local serve (user wants to review on their machine)
preflight: `npm install` ok, `npm run build` clean, `npm run dev` boots :5173 ✓
deliverable:
  link: http://localhost:5173
  run:  `npm install && npm run dev`
  review this: complete the onboarding happy path (Welcome → Template → Name → Dashboard);
               check the empty-name error and the loading state on "Create"
  known stubs: templates are 3 fixtures; "Create" writes to in-memory store (no real API yet)
  feedback: leave notes in #design-review or as comments on the Figma frame
```
(If deploy was requested: confirm host, check for secrets/env files, deploy, return the live URL + same review note.)

## Quality bar
- The link actually works and the app boots from a clean clone (you verified install→build→run).
- The reviewer is told exactly what to click and what's stubbed — no guessing.
- Any unresolved QA items are surfaced honestly, not hidden.
- For deploys: confirmed with the user, and no secrets/env files published.

## Common pitfalls
- **Sharing something that doesn't boot** — always run install→build→start from clean first.
- **Deploying without consent** — external deploy/tunnel sends code off-machine; that's a high-impact action requiring explicit go-ahead. Flag if the repo may contain secrets.
- **Publishing secrets** — check for `.env`, keys, credentials before any deploy.
- **No review guidance** — a bare link with no "look at this" yields vague feedback.
- **Hiding known issues** — silently sharing a prototype with HIGH QA failures wastes reviewers' trust.

## Handoff
This is the terminal stage. Feedback typically loops back to `design-prototype` (changes) or `design-ideate` (rethink). If the prototype is approved, it becomes the reference for engineering build-out.

## Tooling
Local serve needs the project's dev server only. Tunnel/deploy needs the relevant CLI (and user consent). No special tool for the review note — it's written guidance.