Одноразовый прототип

Собирает быстрый одноразовый прототип логики или интерфейса, чтобы проверить идею до настоящей разработки.

Скиллсообщество: Matt PocockClaudeCodexMITНужен терминалПроверено на безопасность

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Собирает быстрый одноразовый прототип логики или интерфейса, чтобы проверить идею до настоящей разработки.
Когда брать: Когда нужно понять, верна ли модель состояний или логика, либо как должен выглядеть экран: прототип даст наглядный ответ.
Когда не брать: Если нужен рабочий код, который пойдёт в продукт: прототип сразу задуман как одноразовый.
Пример запроса: Сделай несколько разных вариантов страницы оформления заказа, чтобы я выбрал, как она должна выглядеть.
Нужно подключить: проект с кодом

Как включить

Скачайте архив и распакуйте его.
Положите папку prototype в ~/.agents/skills/.
Вызовите скилл командой $prototype или найдите его через /skills.

Текст

---
name: prototype
description: Собери одноразовый прототип, чтобы ответить на вопрос о дизайне. Используй, когда пользователь хочет проверить на здравый смысл, верна ли модель состояний или логика, либо понять, как должен выглядеть интерфейс.
---

Прототип

Прототип — это одноразовый код, который отвечает на вопрос. Форму ему задаёт вопрос.

Выбери ветку

Определи, на какой вопрос нужно ответить, по запросу пользователя, окружающему коду или, если пользователь рядом, спросив его:

«Верна ли эта логика / модель состояний?» → [LOGIC.md](LOGIC.md). Собери один HTML-файл, которым легко поделиться (кнопки свободной игры плюс вкладки с пошаговыми сценариями), прогоняющий конечный автомат через случаи, которые трудно осмыслить на бумаге, и которым может управлять не разработчик.
«Как это должно выглядеть?» → [UI.md](UI.md). Сгенерируй несколько радикально разных вариантов интерфейса на одном маршруте, переключаемых параметром поиска в адресе (URL) и плавающей нижней панелью.

Две ветки дают очень разные артефакты, поэтому ошибка здесь обесценивает весь прототип. Если вопрос действительно неоднозначен, а пользователь недоступен, выбери ту ветку, которая лучше подходит окружающему коду (серверный модуль → логика; страница или компонент → интерфейс), и укажи это допущение в самом начале прототипа.

Правила, общие для обеих веток

Одноразовость с первого дня, и это должно быть видно. Размещай код прототипа рядом с тем местом, где он реально будет использоваться (возле модуля или страницы, для которых он делается), чтобы контекст был понятен, но называй его так, чтобы случайный читатель сразу видел: это прототип, а не рабочий код. Для одноразовых маршрутов интерфейса соблюдай то соглашение о маршрутах, которое в проекте уже есть; не изобретай новую структуру верхнего уровня.
Запуск без усилий. Прототип интерфейса запускается одной командой из менеджера задач проекта: pnpm <name>, python <path>, bun <path> и т. п. Демонстрация логики — это один HTML-файл, который пользователь открывает двойным щелчком. В обоих случаях запуск не должен требовать раздумий.
По умолчанию никакого сохранения данных. Состояние живёт в памяти. Сохранение — это то, что прототип _проверяет_, а не то, от чего он должен зависеть. Если вопрос прямо касается базы данных, обращайся к черновой базе или локальному файлу с явным названием вроде «PROTOTYPE, wipe me» («ПРОТОТИП, сотри меня»).
Без доводки. Никаких тестов, никакой обработки ошибок сверх той, что нужна, чтобы прототип _запускался_, никаких абстракций. Смысл — быстро чему-то научиться.
Выводи состояние на экран. После каждого действия (логика) или при каждом переключении варианта (интерфейс) печатай или отрисовывай всё нужное состояние целиком, чтобы пользователь видел, что изменилось.
Зафиксируй, когда закончишь. Перенеси каждое подтверждённое решение в настоящий код, а сам прототип сохрани как первоисточник: закоммить его в одноразовую ветку, мимо основной, и оставь указатель на эту ветку в задаче по реализации. Зафиксируй и ответ (вердикт и вопрос, который он закрыл) в задаче или в коммите. В основной ветке остаётся только подтверждённое решение.

Перевод: iiuniversitet. Оригинал: https://github.com/mattpocock/skills/tree/main/skills/engineering/prototype, лицензия MIT. Изменения: перевод на русский язык.

Оригинал на английском

---
name: prototype
description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
---

# Prototype

A prototype is **throwaway code that answers a question**. The question decides the shape.

## Pick a branch

Identify which question is being answered, using the user's prompt, the surrounding code, or by asking if the user is around:

- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a single shareable HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.

The two branches produce very different artifacts, so getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.

## Rules that apply to both

1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious, but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
2. **Trivial to run.** A UI prototype starts from one command in the project's task runner: `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE, wipe me" name.
4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too (the verdict and the question it settled) in the issue or a commit. The main branch keeps only the validated decision.

Источник: skills / prototype ↗. Ссылка проверена 2026-10-11.

---
name: prototype
description: Собери одноразовый прототип, чтобы ответить на вопрос о дизайне. Используй, когда пользователь хочет проверить на здравый смысл, верна ли модель состояний или логика, либо понять, как должен выглядеть интерфейс.
---

# Прототип

Прототип — это **одноразовый код, который отвечает на вопрос**. Форму ему задаёт вопрос.

## Выбери ветку

Определи, на какой вопрос нужно ответить, по запросу пользователя, окружающему коду или, если пользователь рядом, спросив его:

- **«Верна ли эта логика / модель состояний?»** → [LOGIC.md](LOGIC.md). Собери один HTML-файл, которым легко поделиться (кнопки свободной игры плюс вкладки с пошаговыми сценариями), прогоняющий конечный автомат через случаи, которые трудно осмыслить на бумаге, и которым может управлять не разработчик.
- **«Как это должно выглядеть?»** → [UI.md](UI.md). Сгенерируй несколько радикально разных вариантов интерфейса на одном маршруте, переключаемых параметром поиска в адресе (URL) и плавающей нижней панелью.

Две ветки дают очень разные артефакты, поэтому ошибка здесь обесценивает весь прототип. Если вопрос действительно неоднозначен, а пользователь недоступен, выбери ту ветку, которая лучше подходит окружающему коду (серверный модуль → логика; страница или компонент → интерфейс), и укажи это допущение в самом начале прототипа.

## Правила, общие для обеих веток

1. **Одноразовость с первого дня, и это должно быть видно.** Размещай код прототипа рядом с тем местом, где он реально будет использоваться (возле модуля или страницы, для которых он делается), чтобы контекст был понятен, но называй его так, чтобы случайный читатель сразу видел: это прототип, а не рабочий код. Для одноразовых маршрутов интерфейса соблюдай то соглашение о маршрутах, которое в проекте уже есть; не изобретай новую структуру верхнего уровня.
2. **Запуск без усилий.** Прототип интерфейса запускается одной командой из менеджера задач проекта: `pnpm <name>`, `python <path>`, `bun <path>` и т. п. Демонстрация логики — это один HTML-файл, который пользователь открывает двойным щелчком. В обоих случаях запуск не должен требовать раздумий.
3. **По умолчанию никакого сохранения данных.** Состояние живёт в памяти. Сохранение — это то, что прототип _проверяет_, а не то, от чего он должен зависеть. Если вопрос прямо касается базы данных, обращайся к черновой базе или локальному файлу с явным названием вроде «PROTOTYPE, wipe me» («ПРОТОТИП, сотри меня»).
4. **Без доводки.** Никаких тестов, никакой обработки ошибок сверх той, что нужна, чтобы прототип _запускался_, никаких абстракций. Смысл — быстро чему-то научиться.
5. **Выводи состояние на экран.** После каждого действия (логика) или при каждом переключении варианта (интерфейс) печатай или отрисовывай всё нужное состояние целиком, чтобы пользователь видел, что изменилось.
6. **Зафиксируй, когда закончишь.** Перенеси каждое подтверждённое решение в настоящий код, а сам прототип сохрани как **первоисточник**: закоммить его в одноразовую ветку, мимо основной, и оставь указатель на эту ветку в задаче по реализации. Зафиксируй и ответ (вердикт и вопрос, который он закрыл) в задаче или в коммите. В основной ветке остаётся только подтверждённое решение.

Перевод: iiuniversitet. Оригинал: https://github.com/mattpocock/skills/tree/main/skills/engineering/prototype, лицензия MIT. Изменения: перевод на русский язык.