Prototype Lab

Use quick for a browser UI; picker for live visual directions of the same piece; compare for independently runnable options; ship for a static ZIP. This folder contains the full prototype workflow. One-file explanations, evidence reports and non-browser logic experiments can use the repository's normal tools; no other skill is required.

Quick: edit, observe, verify

Resolve the installed skill root and the target workspace. Call the portable tool with both paths explicit:

node "<skill-root>/scripts/manage-prototype-lab.mjs" <command> --workspace "<workspace>"

1. Reuse the requested or existing owner for this idea. Otherwise run quick --title "<title>" --question "<decision>"; it creates the owner and refreshes inventory. Use its returned id and workspace-relative path. No separate init is needed.
2. Edit inside that owner. Default blank is an empty canvas, not a finished design. Build the composition around the task and product: real content, a clear primary action, deliberate type and spacing, and the states needed to answer the question. Keep runtime and assets local. Done when the main path visibly answers the decision.
3. Read quality-bar.md, then inspect the rendered UI and exercise that path. Use preview --id "<id>" --open when an HTTP origin is needed; reuse a healthy preview first. Repair observed defects. Done when the relevant visual and interaction checks pass.
4. Run verify --id "<id>" for known static references. It checks local HTML/CSS references and literal module imports; generated URLs and runtime requests still need browser checks. A blocked result exits nonzero. Attach an actual browser capture with attach-proof --id "<id>" --file "<absolute-image-path>" when proof is needed. Report the observed state, result and remaining limits. Static verification or a copied screenshot alone cannot prove interaction.

The neutral default blank scaffold comes from assets/prototype-blank/. Choose --profile tool|mobile|canvas only when that scaffold fits the task. adopt --path "<absolute-static-folder>" --question "<decision>" imports an existing build; fork --from "<id>" creates a distinct iteration without copying proof. Keep useful owners until the user authorizes retirement.

Picker: one piece, distinct directions

Use the visual-axis criteria below and the bundled picker guide; no external variant workflow is required.

1. Keep the requested comparison scope: a control, component or coherent screen. Inspect its stack, product tokens, context and decision. Done when all directions can answer the same question with the same content and behavior.
2. Default to three directions, cap five unless requested. Give each a name and a structural axis: hierarchy, layout, density, typography or interaction. Color-only changes do not count as a direction. Done when differences and their costs are visible.
3. Build an isolated route or HTML file using picker.md. One direction at full size in realistic context; reserve space for picker chrome. No dated owner or lab CLI is needed unless the user also wants a catalogued artifact. Done when switching, keyboard use and reload selection work.
4. Apply quality-bar.md to every direction. Show the set with one sentence per tradeoff. If selection is unresolved, let the user choose; if a winner and integration are already authorized, continue. Remove the picker only within the user's cleanup authority.

Compare and package

Compare independently runnable owners with compare --ids "<id>,<id>". Its tab and iframe switcher references the originals; each original still owns its runtime and proof.

Before archive or upload, read portable-run-pack.md. ship --id "<id>" [--include-proof] runs the static checks, writes dist/prototype-lab/<slug>/ plus ZIP, and marks the owner complete. That status means packed; it does not establish browser acceptance or publication. Public sharing retains the session's authorization boundary.

scripts/package-prototype-lab.mjs owns the portable pack. For ChatGPT Sites, use the available Sites building and hosting capabilities within the authorized publication scope.

Ownership and gallery

Each independent artifact lives at prototypes/<YYYY>/<MM>/<NNN>-<slug>/, runs from its index.html, and uses metadata.json as its source of truth. Preserve unmanaged folders.

Creation, init, sync and ship refresh prototypes/index.json. The managed generic gallery updates only while its generated content is unchanged. Existing custom or edited renderers stay byte-for-byte intact; refresh their data through the project's gallery tool. Older unmarked HTML belongs to the project. sync --renderer replace requires explicit authority to replace that renderer.