На этой странице Одноразовые эксперименты для проверки идеи перед разработкой.
Метаданные навыка¶
|---|---
|Источник| Встроенный (установлен по умолчанию)
|Путь| skills/software-development/spike
|Версия| 1.0.0
|Автор| Hermes Agent (адаптировано из gsd-build/get-shit-done)
|Лицензия| MIT
|Теги| spike, prototype, experiment, feasibility, throwaway, exploration, research, planning, mvp, proof-of-concept
|Связанные навыки| sketch, writing-plans, subagent-driven-development, plan
Справочник: полный SKILL.md¶
info Ниже представлено полное описание навыка, которое Hermes загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.
Spike¶
Используйте этот навык, когда пользователь хочет проверить идею перед тем, как браться за настоящую разработку — оценить реализуемость, сравнить подходы или выявить неизвестные факторы, которые не выявит никакое исследование. Spike'ы одноразовы по замыслу. Выбрасывайте их, как только они отдали свой долг. Активируйте, когда пользователь говорит что-то вроде «дай попробовать», «хочу проверить, работает ли X», «сделай спайк», «прежде чем браться за Y», «быстрый прототип Z», «это вообще возможно?» или «сравни A и B».
Когда НЕ использовать этот навык¶
- Ответ можно получить из документации или чтения кода — просто изучите, не надо ничего строить
- Работа идёт в production-направлении — используйте
writing-plans/plan - Идея уже проверена — переходите сразу к реализации
Если у пользователя установлена полная система GSD¶
Если gsd-spike присутствует как смежный навык (установлен через npx get-shit-done-cc --hermes), используйте gsd-spike, когда пользователь хочет полный рабочий процесс GSD: постоянное состояние .planning/spikes/, отслеживание MANIFEST между сессиями, формат вердикта Given/When/Then и схемы коммитов, интегрированные с остальной частью GSD. Данный навык — это облегчённая автономная версия для пользователей, у которых нет (или которым не нужна) полная система.
Основной метод¶
Независимо от масштаба, каждый спайк следует этому циклу:
[code]
decompose → research → build → verdict
↑______↓
iterate on findings
[/code]
1\. Декомпозиция¶
Разбейте идею пользователя на 2–5 независимых вопросов реализуемости. Каждый вопрос — это один спайк. Представьте их в виде таблицы в формате Given/When/Then:
| Спайк| Проверяет (Given/When/Then)| Риск¶
|---|---|---|---
001| websocket-streaming| Given — WS-соединение, When — LLM стримит токены, Then — клиент получает чанки < 100 мс| Высокий
002a| pdf-parse-pdfjs| Given — многостраничный PDF, When — разобран с помощью pdfjs, Then — извлекается структурированный текст| Средний
002b| pdf-parse-camelot| Given — многостраничный PDF, When — разобран с помощью camelot, Then — извлекается структурированный текст| Средний
Типы спайков:
* стандартный — один подход, отвечающий на один вопрос
* сравнительный — один и тот же вопрос, разные подходы (общий номер, буквенный суффикс a/b/c)
Хорошие вопросы для спайка: конкретная реализуемость с наблюдаемым результатом. Плохие вопросы для спайка: слишком общие, без наблюдаемого результата, или просто «почитай документацию об X». Сортируйте по риску. Спайк, который с наибольшей вероятностью может убить идею, выполняется первым. Нет смысла прототипировать лёгкие части, если сложная часть не работает. Пропускайте декомпозицию, только если пользователь уже точно знает, что хочет проверить, и говорит об этом. В этом случае примите его идею как единый спайк.
2\. Согласование (для идей с несколькими спайками)¶
Покажите таблицу спайков. Спросите: «Строить всё в этом порядке или скорректировать?» Дайте пользователю возможность убрать, переупорядочить или переформулировать до того, как вы напишете хоть строчку кода.
3\. Исследование (для каждого спайка, перед сборкой)¶
Спайки — это не работа без исследований: вы изучаете ровно настолько, чтобы выбрать правильный подход, а затем собираете. Для каждого спайка:
1. Опишите. 2–3 предложения: что это за спайк, почему он важен, ключевой риск.
2. Перечислите конкурирующие подходы, если есть реальный выбор:
Подход| Инструмент/Библиотека| Плюсы| Минусы| Статус
|---|---|---|---|---
...| ...| ...| ...| поддерживается / заброшена / бета
3. Выберите один. Укажите почему. Если 2+ подходов выглядят достойно, создайте быстрые варианты в рамках спайка.
4. Пропустите исследование для чистой логики без внешних зависимостей.
Используйте инструменты Hermes для этапа исследования:
* web_search("python websocket streaming libraries 2025") — найти кандидатов
* web_extract(urls=["https://websockets.readthedocs.io/..."]) — прочитать документацию (возвращает markdown)
* terminal("pip show websockets | grep Version") — проверить, что установлено в venv проекта
Для библиотек без страниц документации клонируйте и читайте их README.md / examples/ через read_file. Context7 MCP (если он настроен у пользователя) тоже хороший источник — mcp_*_resolve-library-id, затем mcp_*_query-docs.
4\. Сборка¶
Одна директория на спайк. Держите автономно.
[code]
spikes/
├── 001-websocket-streaming/
│ ├── README.md
│ └── main.py
├── 002a-pdf-parse-pdfjs/
│ ├── README.md
│ └── parse.js
└── 002b-pdf-parse-camelot/
├── README.md
└── parse.py
[/code] Стремитесь к чему-то, с чем пользователь может взаимодействовать. Спайки проваливаются, когда единственный результат — это строка в логе «работает». Пользователь хочет почувствовать, что спайк работает. Варианты по умолчанию, в порядке предпочтения: 1. Запускаемый CLI, который принимает ввод и выводит наблюдаемый результат 2. Минимальная HTML-страница, демонстрирующая поведение 3. Небольшой веб-сервер с одним эндпоинтом 4. Юнит-тест, проверяющий вопрос с понятными assertion'ами
Глубина важнее скорости. Никогда не объявляйте «работает» после одного happy-path прогона. Тестируйте граничные случаи. Следуйте за неожиданными находками. Вердикт заслуживает доверия, только если исследование было честным.
Избегайте (если только спайк этого специально не требует): сложного управления пакетами, сборочных инструментов/бандлеров, Docker, env-файлов, систем конфигурации. Всё хардкодьте — это же спайк.
Сборка одного спайка — типичная последовательность инструментов:
[code]
terminal("mkdir -p spikes/001-websocket-streaming")
write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
write_file("spikes/001-websocket-streaming/main.py", "...")
terminal("cd spikes/001-websocket-streaming && python3 main.py")
# Observe output, iterate.
[/code]
Параллельные сравнительные спайки (002a / 002b) — делегируйте. Когда два подхода могут выполняться параллельно и оба требуют реальной разработки (а не 10-строчных прототипов), распределите с помощью delegate_task:
[code]
delegate_task(tasks=[
{"goal": "Build 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
{"goal": "Build 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])
[/code] Каждый подчинённый агент возвращает свой вердикт; вы пишете сравнение.
5\. Вердикт¶
Каждый README.md спайка завершается:
[code]
## Verdict: VALIDATED | PARTIAL | INVALIDATED
### What worked
- ...
### What didn't
- ...
### Surprises
- ...
### Recommendation for the real build
- ...
[/code] VALIDATED = на ключевой вопрос получен утвердительный ответ с доказательствами. PARTIAL = работает при условиях X, Y, Z — задокументируйте их. INVALIDATED = не работает по такой-то причине. Это успешный спайк.
Сравнительные спайки¶
Когда два подхода отвечают на один и тот же вопрос (002a / 002b), стройте их последовательно, затем в конце проведите сравнение лицом к лицу: [code] ## Head-to-head: pdfjs vs camelot
| Dimension | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Extraction quality | 9/10 structured | 7/10 table-only |
| Setup complexity | npm install, 1 line | pip + ghostscript |
| Perf on 100-page PDF | 3s | 18s |
| Handles rotated text | no | yes |
**Winner:** pdfjs for our use case. Camelot if we need table-first extraction later.
[/code]
Режим разведки (выбор следующего спайка)¶
Если спайки уже существуют и пользователь спрашивает «что мне проверить следующим?», просмотрите существующие директории и поищите: * Интеграционные риски — два проверенных спайка, затрагивающих один и тот же ресурс, но протестированные независимо * Передача данных — предполагалось, что выход спайка A совместим со входом спайка B, но это не доказано * Пробелы в видении — возможности, которые предполагались, но не проверены * Альтернативные подходы — разные углы для спайков с PARTIAL или INVALIDATED
Предложите 2–4 кандидата в формате Given/When/Then. Пусть пользователь выберет.
Результат¶
- Создайте
spikes/(или.planning/spikes/, если пользователь использует соглашения GSD) в корне репозитория - Одна директория на спайк:
NNN-descriptive-name/ README.mdдля каждого спайка содержит вопрос, подход, результаты, вердикт- Держите код одноразовым — спайк, который требует 2 дней на «причесывание под production», был плохим спайком
Атрибуция¶
Адаптировано из рабочего процесса /gsd-spike проекта GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Полная система GSD предлагает постоянное состояние спайков, отслеживание MANIFEST и интеграцию с более широким конвейером спецификаций; установка: npx get-shit-done-cc --hermes --global.
* Метаданные навыка
* Справочник: полный SKILL.md
* Когда НЕ использовать этот навык
* Если у пользователя установлена полная система GSD
* Основной метод
* 1\. Декомпозиция
* 2\. Согласование (для идей с несколькими спайками)
* 3\. Исследование (для каждого спайка, перед сборкой)
* 4\. Сборка
* 5\. Вердикт
* Сравнительные спайки
* Режим разведки (выбор следующего спайка)
* Результат
* Атрибуция