Ce Prototype

OrganizationPopular

EveryInc

ce-prototype

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.

Overview

Publisher	EveryInc
Repository	`compound-engineering-plugin`
Skill name	`ce-prototype`
Stars	25.1K
Forks	2.1K
Bundled files	9
License	MIT
Links	Skill source Repository Homepage

Markdown instructions
A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.
Works with any LLM
AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.
9 bundled files
Scripts, templates, and references the model can read while it works. Files are read-only and never executed.
Open source
Published by EveryInc on GitHub. Read the source before you install it.

Installation

Install the Ce Prototype AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

Open the app and go to Plugins → Skills.
Choose "Install from GitHub".
Paste the skill folder URL below and confirm.
Enable the skill in any chat where you want it available.

Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills

git clone --depth 1 https://github.com/EveryInc/compound-engineering-plugin.git /tmp/compound-engineering-plugin
mkdir -p .claude/skills
cp -r /tmp/compound-engineering-plugin/skills/ce-prototype .claude/skills/ce-prototype

Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Ce Prototype in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Ce Prototype on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Ce Prototype is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

Loaded only when it is needed
The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.
Switch models mid-chat
Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

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.

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.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Ce Prototype AI skill do?

Why use Ce Prototype on TypingMind?

Because you install it once and use it with any model. Ce Prototype is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Ce Prototype in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/EveryInc/compound-engineering-plugin/tree/main/skills/ce-prototype. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Ce Prototype?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Ce Prototype?

As many as you like. As long as a model supports skills, you can use Ce Prototype with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Ce Prototype AI skill free?

Yes. It is published on GitHub by EveryInc under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Code Review

mattpocock

CommunityPopular

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what…

Codebase Design

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or…

Diagnosing Bugs

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Implement

Implement a piece of work based on a spec or set of tickets.

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

Prototype

Scope the question

Build it

Keep the decisions

Apply or continue

Bundled files

Frequently asked questions

Related AI Skills

Set up your own AI workspace now