Spike

Одноразовые эксперименты для проверки идеи перед разработкой.

Метаданные навыка

Справочник: полный SKILL.md

Spike

Используй этот навык, когда пользователь хочет прощупать идею до начала настоящей разработки — проверить осуществимость, сравнить подходы или выявить неизвестные, которые никакое чтение документации не раскроет. Спайки одноразовые по природе. Выброси их, как только они сделали своё дело.

Загружай навык, когда пользователь говорит что-то вроде: «хочу попробовать», «посмотрим, работает ли X», «спайкни это», «прежде чем делать Y», «быстрый прототип Z», «это вообще реально?» или «сравни A и B».

Когда НЕ использовать

• Ответ можно найти в документации или просто прочитав код — делай исследование, не нужно ничего строить
• Работа идёт на продакшн-путь — используй вместо этого навык plan
• Идея уже проверена — переходи сразу к реализации

Если у пользователя установлена полная система GSD

Если gsd-spike появляется как соседний навык (установлен через npx get-shit-done-cc --hermes), предпочти gsd-spike, когда пользователь хочет полный GSD-воркфлоу: постоянное состояние в .planning/spikes/, отслеживание MANIFEST между сессиями, формат вердикта Given/When/Then и паттерны коммитов, интегрированные с остальной частью GSD. Текущий навык — облегчённая автономная версия для тех, у кого нет (или кому не нужна) полная система.

Основной метод

Независимо от масштаба, каждый спайк проходит по этому циклу:

decompose  →  research  →  build  →  verdict
   ↑__________________________________________↓
                  iterate on findings

1. Декомпозиция

Разбей идею пользователя на 2–5 независимых вопросов осуществимости. Каждый вопрос — один спайк. Представь их таблицей в формате Given/When/Then:

Типы спайков:

• standard — один подход, один вопрос
• comparison — один вопрос, разные подходы (общий номер, буквенный суффикс a/b/c)

Хорошие вопросы для спайка: конкретная осуществимость с наблюдаемым результатом. Плохие вопросы: слишком широкие, без наблюдаемого результата или просто «почитай доки про X».

Сортируй по риску. Спайк, способный убить всю идею, запускается первым. Незачем прототипировать простые части, если сложная не работает.

Пропускай декомпозицию только если пользователь уже точно знает, что именно хочет проверить, и прямо говорит об этом. Тогда берёшь его идею как один спайк.

2. Согласование (для идей с несколькими спайками)

Покажи таблицу спайков. Спроси: «Строим в таком порядке или скорректируем?» Дай пользователю убрать, переставить или переформулировать — прежде чем писать код.

3. Исследование (для каждого спайка, до сборки)

Спайки не обходятся без исследования — сначала разбираешься достаточно, чтобы выбрать подход, потом строишь. Для каждого спайка:

1. Краткая вводная. 2–3 предложения: что за спайк, почему важен, главный риск.

2. Конкурирующие подходы — если реальный выбор есть:

   Подход	Инструмент/библиотека	Плюсы	Минусы	Статус
   …	…	…	…	maintained / abandoned / beta

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. Сборка

Один каталог на спайк. Держи его автономным.

spikes/
├── 001-websocket-streaming/
│   ├── README.md
│   └── main.py
├── 002a-pdf-parse-pdfjs/
│   ├── README.md
│   └── parse.js
└── 002b-pdf-parse-camelot/
    ├── README.md
    └── parse.py

По умолчанию делай что-то, с чем пользователь может взаимодействовать. Спайки проваливаются, когда единственный результат — строчка в логе «работает». Пользователь хочет почувствовать спайк в действии. Порядок предпочтений:

1. Запускаемый CLI, который принимает ввод и выдаёт наблюдаемый результат
2. Минимальная HTML-страница, демонстрирующая поведение
3. Небольшой веб-сервер с одним эндпоинтом
4. Юнит-тест, проверяющий вопрос с понятными утверждениями

Глубина важнее скорости. Никогда не объявляй «работает» после одного успешного запуска. Тестируй граничные случаи. Следуй неожиданным находкам. Вердикт заслуживает доверия только если расследование было честным.

Избегай, если только спайк прямо этого не требует: сложного управления пакетами, систем сборки/бандлеров, Docker, env-файлов, конфигурационных систем. Хардкодь всё — это спайк.

Сборка одного спайка — типичная последовательность инструментов:

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 && python main.py")
# Observe output, iterate.

Параллельные сравнительные спайки (002a / 002b) — делегируй. Когда два подхода можно запустить параллельно и оба требуют настоящей инженерии (не 10-строчные прототипы), раздай через delegate_task:

delegate_task(tasks=[
    {"goal": "Build 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
    {"goal": "Build 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])

Каждый субагент возвращает свой вердикт; ты пишешь итоговое сравнение.

5. Вердикт

README.md каждого спайка завершается блоком:

## Verdict: VALIDATED | PARTIAL | INVALIDATED

### What worked
- ...

### What didn't
- ...

### Surprises
- ...

### Recommendation for the real build
- ...

VALIDATED = основной вопрос получил ответ «да», с доказательствами. PARTIAL = работает при условиях X, Y, Z — задокументируй их. INVALIDATED = не работает, по такой-то причине. Это тоже успешный спайк.

Сравнительные спайки

Когда два подхода отвечают на один вопрос (002a / 002b), собирай их один за другим, затем делай итоговое сравнение:

## 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.

Режим «следующий рубеж» (что проверить следующим)

Если спайки уже есть и пользователь спрашивает «что проверить следующим?», пройди по существующим каталогам и ищи:

• Интеграционные риски — два проверенных спайка обращаются к одному ресурсу, но тестировались независимо
• Передача данных — выход спайка A считался совместимым с входом спайка B, но это не доказано
• Пробелы в концепции — возможности, которые подразумеваются, но не проверены
• Альтернативные подходы — другие углы для спайков со статусом PARTIAL или INVALIDATED

Предложи 2–4 кандидата в формате Given/When/Then. Пусть пользователь выбирает.

Результат

• Создай spikes/ (или .planning/spikes/, если используются соглашения GSD) в корне репозитория
• Один каталог на спайк: NNN-descriptive-name/
• README.md для каждого спайка фиксирует вопрос, подход, результаты и вердикт
• Оставляй код одноразовым — спайк, требующий двух дней «чистки для продакшена», был плохим спайком

Авторство

Адаптировано из воркфлоу /gsd-spike проекта GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Полная система GSD предлагает постоянное состояние спайков, отслеживание MANIFEST и интеграцию с более широким конвейером спецификационной разработки; устанавливается командой npx get-shit-done-cc --hermes --global.