ce-prototype
The facts
Its description
Build a throwaway prototype to answer how something should work, feel, or read. Use when committing the wrong answer would be expensive to unravel and a cheap sketch cannot settle it. Not a rough visual probe during brainstorming, not for deciding what to build, not polishing a feature that already works, not implementing the real thing.
The description the agent reads to decide when to use it.
When it starts
A person is weighing how something should work, feel, or read — a flow, a state model, a layout, a visual direction — and the choice is expensive to undo, so they want a throwaway artifact built to decide it rather than a sketch or a discussion. The agent picks this when the request is to prototype a named thing, or when the conversation has a question that only a real artifact can settle.
Things a person might say (the model's guesses)
- “I can't decide between a wizard and one long form for onboarding — build both so I can try them”
- “Prototype the settings screen so I can feel whether this density works”
- “Before we plan this, I want to see how the checkout flow should actually go”
A model's summary of when it is used.
What it takes when started
[prompt, brainstorm path, or plan path]
What to type after its name when you start it.
Files it mentions
references/scoping.md, references/build.md, references/preview.md, references/annotation-loop.md, references/craft-floor.md (first 5 of 9 lines)
Files the text names, such as ones to read or write. Found by matching words, so treat them as pointers.
Stops for a person
1 line stops to ask a person
Lines that stop and wait for a person before going on. Found by matching words, so treat them as pointers.
What it leads to
- hands off to ce-brainstorm after a file-free run where product-level questions remain line 59
- hands off to ce-plan after a write-back, or when the session is enough to plan line 59
Other skills this one hands off to, calls, requires or offers instead, as a model read them.
What leads to it
- ce-brainstorm calls this when a decision is expensive to unravel and talk or a sketch cannot settle it ce-brainstorm/interaction-rules.md, line 26
- ce-plan calls this only when a remaining feel-question is expensive to unravel ce-plan/plan-handoff.md, line 75
- lfg calls this only when the result is not a code change lfg/intake.md, line 19
- ce-bakeoff is an alternative to this when the choice depends on experience ce-bakeoff, line 18
Other skills that hand off to this one, call it, require it or offer it instead, as a model read them.
Licence
MIT, from LICENSE
The terms its author shares it under, which let it be shown here.
Other files in this skill (8) Close
The text
Most marks come from matching words in the file, so treat them as pointers.
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/compound-engineering/ce-prototype/<date>-<slug>/, so the prototype survives for the implementation that follows. Fall back to /tmp/compound-engineering-<uid>/ce-prototype/<date>-<slug>/, where survival is best-effort. references/build.md names every case that forces the fallback root.
The .context path has to be gitignored first. Probe it from the repo root with git -C <repo root> check-ignore -q .context/compound-engineering/; 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. Never commit it. 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.
Raw lines 26 to 43Keep 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.mdand follow it. Markdown and HTML both. Usedecisions.mdwhen 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.mdwhen 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.
From EveryInc/compound-engineering-plugin at 3449230, 2026-10-31. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.