Building UI Prototypes with Claude Code: How to Use the prototype Skill
機械翻訳 / Machine-translated
機械翻訳 / Machine-translated
Original article: Building UI Prototypes with Claude Code: How to Use the prototype Skill (cccskills)
Skill page: prototype
Key takeaways from this article
prototype is a skill that instructs agents like Claude Code to build throwaway, interactive prototypes you can actually operate.
It's suited for developers and designers who want to verify screen designs or process flows before implementation.
The first half of this article introduces what the finished prototype looks like and how to install the skill.
The second half covers example requests and things to keep in mind when working with prototypes.
Send a single request and you'll receive an interactive prototype you can try out right away.
For example, when you want to verify a process flow, your request might look like this:
I'm thinking through a process where an order's status moves through "Draft → Awaiting Confirmation → Confirmed → Cancelled."
Please let me try this state model in an interactive HTML so I can check whether it works.
The agent produces a single HTML file you can open with a double-click.
The screen presents freely clickable action buttons alongside a tabbed walkthrough with step-by-step instructions.
The step-by-step walkthrough is there to guide you through states that are easy to overlook on paper.
Every time you press a button, all relevant state is displayed on screen.
It's immediately clear what changed when you pressed what, making it easy to hand off to non-engineers for exploration.
If the request was ambiguous when the prototype was built, the interpretation used is written at the top of the prototype.
When you're discussing the visual appearance of a screen, what gets produced changes accordingly.
Multiple UI designs with significantly different directions are created within a single screen, switchable via a URL parameter or a floating bar at the bottom of the screen.
Each time you switch between designs, the state is also displayed, so you can verify both appearance and behavior side by side.
prototype is a skill that generates throwaway code to answer design questions.
Depending on what you want to verify, two different types of output are produced.
| What you want to verify | What gets built | How to interact |
|---|---|---|
| Whether a process or state model feels natural | A shareable, self-contained HTML file | Freely clickable buttons and a tabbed walkthrough with step-by-step instructions |
| How a screen should look | Multiple UI designs with significantly different directions, shown together in one screen | Switch via URL parameter or a floating bar at the bottom of the screen |
Which type to build is determined from the request and the surrounding code.
If the user is available, the agent will ask for clarification.
When clarification isn't possible, the default is a process prototype for backend modules and a screen prototype for pages or components.
Prototypes are placed right next to the module or page being verified.
They're also named in a way that makes it immediately obvious they are prototypes.
For screen prototypes, the project's existing routing (URL-to-screen mapping) is followed, and no new structure is introduced.
Screen prototypes are launched with a single command from the project's task runner.
It takes a form like pnpm <name> or bun <path>.
Process prototypes are HTML files, so they work by simply double-clicking to open.
Verified decisions are reflected in production code, while the prototypes themselves remain on the prototype branch.
Prototypes are kept out of the main branch, and a reference to the prototype branch is added to the implementation issue.
What was verified and how it was concluded is also recorded in the issue or commit, so you can trace the reasoning behind decisions later.
Use the following command to install.
When you run it, you can choose the target agent, such as Claude Code or Codex.
npx skills add https://github.com/mattpocock/skills --skill prototype
If you'd like the agent to handle installation for you, send the following message as-is.
You can leave everything from reviewing the contents to placing the files entirely to the agent.
次の Agent Skill をインストールしてください。
https://github.com/mattpocock/skills/tree/main/skills/engineering/prototype
まず SKILL.md と付属ファイルの中身を確認し、不審な処理（外部への送信、認証情報の読み取りなど）がないことを確かめてから、Claude Code なら ~/.claude/skills/prototype/、Codex なら ~/.agents/skills/prototype/ に配置してください。
Where you place it depends on whether you want to use it across all projects or only in a specific project.
| Agent | Use across all projects | Use in a specific project only |
|---|---|---|
| Claude Code | ~/.claude/skills/prototype/ | .claude/skills/prototype/ in the project |
| Codex | ~/.agents/skills/prototype/ | .agents/skills/prototype/ in the project |
prototype is one of the skills included in the GitHub repository mattpocock/skills.
The source is written in English, and you can read SKILL.md from the distribution page.
During the membership registration flow, I want to check the state when a user changes their plan before completing email verification.
Please prototype the state model in an interactive HTML.
What comes back is an HTML file equipped with free-action buttons and a step-by-step walkthrough.
Follow the walkthrough to advance the state all the way through ambiguous edge cases.
After each action, the full state is displayed, so you'll quickly notice any unexpected changes.
I can't decide on the look of the settings screen.
Please create several designs with significantly different directions and make it possible to switch between them for comparison.
A single prototype screen containing multiple UI designs is created inside the existing project.
Switch between designs using the floating bar at the bottom or a URL parameter, and compare the differences on the spot.
All you need to launch it is a single command from the project's task runner.
I'd like to have a planner operate the return-request status flow and get their feedback.
Please make it an HTML that they can try out just by opening it in a browser.
Process prototypes are single HTML files, so you just hand over the file and the recipient can open it with a double-click.
State is displayed after each action, so even people who don't read code can follow along with the changes.
Once feedback is gathered and a conclusion is reached, you can also ask the agent to record that decision in an issue or commit.
Prototypes are throwaway and are kept separate from production code.
No tests are written, and error handling is only included to the minimum needed to run.
There is no abstraction either, so prototypes are not intended to be carried over directly into production.
Data is kept in memory by default.
This is because the persistence mechanism itself may be what's under investigation.
Only when the database itself is the focus of verification will a throwaway DB or a local file with a name like PROTOTYPE, wipe me be used to signal that it's safe to delete.
Prototypes are saved to a prototype branch outside the main branch.
Since the workflow assumes Git branches and implementation issues as the places to record decisions, confirm that this fits your process beforehand.
The license is MIT.
Before installing, read SKILL.md and the three accompanying files to confirm there are no external transmissions or credential reads.
The same mattpocock/skills repository includes skills you can use before and after prototype.
domain-modeling is a skill that clarifies the boundaries of business terms and concepts by cross-referencing concrete examples with code.
When the names or meanings of states aren't settled yet, it can be used before prototyping to align terminology.
The reasoning behind important design decisions can also be preserved as needed.
codebase-design assists with module design that keeps the surface area callers need to learn as small as possible.
It's a good fit for after prototyping has settled on a state model and you're working out how to structure the production modules.
ask-matt acts as a guide that recommends relevant skills and the order to use them for your situation.
It serves as a starting point when you're unsure how to proceed from prototyping to implementation.
A prototype built with prototype is real, working code.
In a process prototype you can move state by pressing buttons; in a screen prototype you can switch between multiple designs inside an existing project.
The difference is that you can verify not just the appearance but also the state after each interaction.
No.
It's built as throwaway code with tests and polish omitted.
Only the decisions verified through prototyping are reflected in production code; the prototype itself stays on the prototype branch.
Not necessarily — the type is determined from your request and the surrounding code.
When the agent can't tell, it will ask for clarification.
If a prototype is built without being able to confirm, the interpretation used is written at the top of the prototype.
prototype is a skill for anyone who wants to verify screen designs or state transitions before implementation.
For process verification, an interactive single HTML is produced; for screen verification, a screen that lets you switch between multiple designs is produced.
Prototypes are treated as throwaway artifacts, and the decisions and conclusions verified through them are preserved in a form that can be referenced later.
Read SKILL.md before installing, and obtain the skill from the cccskills page.
This article is a reprint of the cccskills article "Building UI Prototypes with Claude Code: How to Use the prototype Skill."
Details about the skill and installation instructions can be found on the cccskills prototype page.