agentsclimarketplace

Design prototype

Skill DKeken/codex-skills-alternative/skills/design-prototype

17 vendor-neutral Agent Skills (SKILL.md) reimplementing the Codex Creative Production + Product Design plugin workflows. Works with Claude Code, opencode, Cursor, Codex CLI, Gemini CLI, Copilot.

Install
npx -y skills add DKeken/codex-skills-alternative --skill design-prototype

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

One thing to look at

  • 13 stars13 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.

What its author says it does

Copied from the file, not written here

Assemble a clickable, runnable prototype from screens/components — wiring navigation, state, and interactions so a team can actually click through it. Use when the user says "make it clickable", "build a prototype", "wire up the flow", "interactive prototype", "make the screens navigate", or has static screens that need to come alive. Part of the Product Design set. Verifies interactions with a browser tool.

SKILL.md

3.8 KB, as published. Nobody here has run it

Design — Prototype

Turn static screens into a working clickable flow that demonstrates the experience end to end. A prototype's job is to let someone experience the flow and give feedback — not to be production-hardened. Stubs are fine and expected; broken navigation is not.

When to use

  • You have screens/components (from image-to-code, url-to-code, or ideate) and need them connected.
  • "Make it clickable", "wire the flow", "let me click through it".
  • Validating a UX flow with stakeholders before real backend work.

When NOT to use

  • No screens exist yet → build them first (design-image-to-code / design-url-to-code).
  • You need production code with real data/auth — that's an engineering task, not a prototype.
  • Just checking a built prototype against the design → design-qa.

Inputs

  • The screens/components to connect.
  • The flow to demonstrate: happy path + key states.
  • ./design/context.md for the JTBD (the flow should make that easy).

Workflow

  1. Map the flow graph: screens are nodes, actions are edges (click → navigate, submit → state change). Write it down before wiring.
  2. Wire routing/navigation between screens.
  3. Add interaction states: hover, active, disabled, loading, empty, error, success. Cover at least the happy path + one error state (the most-skipped, most-important state).
  4. Stub data so it's clickable without a backend; clearly mark where real data plugs in.
  5. Verify: drive the whole happy path in a browser-automation tool — click every step, confirm nothing dead-ends. Fix what breaks.
  6. Keep it runnable with one command.

Worked example

Flow (JTBD: create first project in <2 min): Welcome → Choose template → Name it → Dashboard.

flow graph:
 Welcome --[Get started]--> Template --[select]--> Name --[Create]--> Dashboard
 Name --[empty submit]--> Name(error: "Name required")
 Template --[back]--> Welcome
states wired: hover on cards, loading on Create (300ms stub), error on empty name,
 success → Dashboard with the new project card
stubs: templates = 3 fixtures; "Create" writes to in-memory store (TODO: real API)
verify (browser): clicked Welcome→Template→Name→Create→Dashboard ✓;
 empty-name error shows ✓; back nav works ✓; no dead ends
run: `npm install && npm run dev` → :5173

Quality bar / Definition of done

  • Full happy path is clickable end to end.
  • At least one error/empty state is present and reachable.
  • No dead ends or broken links.
  • Runs locally; build + typecheck clean.
  • A browser walkthrough of the happy path passes.

Common pitfalls

  • Happy-path only — skipping error/empty/loading states; those are where real feedback comes from.
  • Dead ends — a button that goes nowhere kills the demo. Walk every path.
  • Over-engineering — wiring a real backend/auth for a prototype. Stub it, mark the TODO.
  • Style drift — re-styling screens during wiring so they no longer match the locked direction.
  • No verification — assuming it works without clicking through it.

Handoff

Working prototype → design-qa (conformance check vs the design + requirements) → design-share (publish for review). Don't share before QA on anything stakeholder-facing.

Tooling

Needs a browser-automation tool to verify the flow by clicking through it. Without one, wire carefully and manually note that the walkthrough is unverified.

Keep looking

Skills are one crate of 328,083. 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.