Imported from ucirello/compound-engineering-plugin (skills/ce-prototype/SKILL.md). Install upstream with npx skills add ucirello/compound-engineering-plugin --skill ce-prototype. Copyright stays with the author.

Prototype

Build a throwaway prototype at the fidelity that can answer this question, before committing an approach later work will treat as given. Then apply the decisions or hand off.

Do not fake the dimension being tested. Modality, fidelity, and medium all follow from that one rule. A question about how a flow or state model behaves is settled by driving it, so a screen that only looks like the product does not answer it. A question about how a layout or a mark reads is settled by seeing it at real finish, so a thin sketch does not answer it either. The user's own perception settles the question, never your judgment of the artifact.

Result: the user decided how the product should work or feel against a prototype that did not fake what they were deciding. Next consumer: an existing markdown Product Contract, or ce-brainstorm / ce-plan with this session as the seed. Done: the user settled the questions that needed an artifact, or they apply and continue into brainstorm or plan. Their choice is the settlement, not a direction you inferred. Not: a decision a cheap sketch settles, polish, or shipping the prototype as a final product.

If there is no person to experience the prototype — mode:pipeline, a headless run, or a calling skill that reports no human is present — stop. Do not start a preview or invent how it should feel. Return that this skill needs a human. A calling skill that has a human present (an interactive lfg run, for example) is an ordinary attended run.

User-runnable invocation rendering. The attended re-run in that refusal and the next-skill recommendation when the user applies print invocation syntax. Default to /ce-prototype, /ce-brainstorm, and /ce-plan; use $ce-prototype, $ce-brainstorm, and $ce-plan only on Codex or a host that documents dollar-prefixed skill invocation. Render only the invocation as inline code; output one form only.

Scope the question

Read references/scoping.md before you ask the user anything or touch the repo. That read is not optional. It defines how the question arrives and the scoped repo read of what the question touches — do not scan the tree. It also defines narrow vs wide, sizing, the go-ahead message, and how the remaining questions change after each decision. Do not build until authorized. A request that already is to prototype a named thing is that authorization after scoping.

Build it

Read references/build.md and references/preview.md before writing anything. Once an isolated web preview is up, load references/annotation-loop.md. Overlay runs and non-web runs stay on chat.

After they proceed, speak only when they can act on something new, in one short line naming what happened: a screen is up, the helper URL is live, or a blocker only they can lift. That annotation loop defines the line after an applied revision and silence while a wait is parked.

A question is settled by seeing when the judgment lands on the rendered result: how a layout reads, what a palette does, how dense a screen feels. It is settled by driving when the judgment lands on what happens as the user moves through it: a flow, a state model, how a control answers. Load references/craft-floor.md for a seeing question. It carries the quality floor and the avenue-difference rule; neither lives here. A question settled by driving does not load it and gains no finish from it.

Default substrate: the web, whatever the product is written in — a native app's navigation feel gets a web approximation, not SwiftUI. references/build.md defines yields and artifacts.

Build under .context/ce-prototype/<date>-<slug>/, so the prototype survives for the implementation that follows. Fall back to .tmp/rocketclaw/ce-prototype/<date>-<slug>/ under the workspace root (jj workspace root, or the current directory if that fails), where survival is best-effort. references/build.md names every case that forces the fallback root.

The .context path has to be listed in .gitignore first. Probe it from the workspace root with git check-ignore -q .context/ce-prototype/ (cwd = jj workspace root); the trailing slash is required. When it is not covered, the offer to add that line comes before the root is resolved, or accepting it cannot help this run.

references/preview.md defines that offer and the resolution that follows it. Do not create the run directory yourself; a second claim splits the screens from the capsule.

Scale into the existing app as a throwaway overlay when the user asks, or when the question is density or chrome on an existing page — an isolated page hides that. It is the one path that touches the product tree. Do not land it as a JJ change. When the try ends, restore only the files you changed. If you cannot undo them cleanly, name the files you left modified rather than handing off a dirty tree. Never delete a kept prototype: throwaway describes the code, not a request to remove it.

Keep the decisions

Keep a run capsule at decisions.md in this run's directory, so the next skill does not need this session. references/build.md lists what it carries. Point at the prototype; do not reproduce it. Include only what changes later planning. Do not treat decisions.md as a plan: applying writes the Product Contract or the recap, and the capsule is only continuity.

Update the capsule when you are confident a choice has settled — the user judged the artifact and chose, including any adjustments they attached. If you are not confident, do not write. Do not pause to confirm every write. Keep the winner and those adjustments in the prototype.

Read decisions.md before building for the next related question, and work out which questions are still worth building for. references/scoping.md defines how that list changes. If what they decided changed what they want to build rather than answering the question you asked, stop and hand back what you learned instead of building for a question they have moved past. Otherwise stay in this skill for it. Do not bounce to brainstorm or plan while a related question still needs an artifact, do not start an unrelated campaign, and do not keep prototyping once they apply.

Apply or continue

When the user applies:

• If this run has a directly related brainstorm or plan — passed on invoke, passed by the calling skill, or named in this session as the file this prototype is for — load references/write-back.md and follow it. Markdown and HTML both. Use decisions.md when present. Do not pick a plan because one exists in the repo.
• If there is no such file or relatedness is unclear: do not mint a plan or a third note. Recap from decisions.md when present, carrying the decisions and, when the run left one behind, the prototype path — an overlay run has none, so say that rather than pointing at something you undid. That recap is a complete outcome, not a degraded one.

Then continue. If a calling skill invoked this, return the choices in decisions.md and let it continue. Otherwise recommend a next skill and pass this session as the seed. After a write-back, recommend ce-plan to regenerate implementation planning for the changed requirements. After a file-free run, recommend ce-brainstorm when product-level questions remain, or ce-plan when the session is enough to plan. Print that recommendation per the rendering rule above.