Перейти к основному содержимому

Spike

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

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

ИсточникВстроенный (установлен по умолчанию)
Путьskills/software-development/spike
Версия1.0.0
АвторVibeOS (адаптировано из gsd-build/get-shit-done)
ЛицензияMIT
Платформыlinux, macos, windows
Тегиspike, prototype, experiment, feasibility, throwaway, exploration, research, planning, mvp, proof-of-concept
Связанные навыкиsketch, subagent-driven-development, plan

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

к сведению

Ниже приведено полное описание навыка, которое VibeOS загружает при его активации. Это те инструкции, которые видит агент, когда навык активен.

Spike

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

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

Когда НЕ нужно использовать​

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

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

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

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

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

декомпозиция  →  исследование  →  сборка  →  вердикт
   ↑________________________________________________↓
                  итерация на основе находок

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

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

#СпайкПроверяет (Given/When/Then)Риск
001websocket-streamingGiven WS-соединение, когда LLM стримит токены, тогда клиент получает чанки < 100msВысокий
002apdf-parse-pdfjsGiven многостраничный PDF, когда распарсен с pdfjs, тогда извлекается структурированный текстСредний
002bpdf-parse-camelotGiven многостраничный PDF, когда распарсен с camelot, тогда извлекается структурированный текстСредний

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

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

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

Упорядочивайте по риску. Спайк, который с наибольшей вероятностью «убьёт» идею, выполняется первым. Нет смысла прототипировать лёгкие части, если сложная не работает.

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

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

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

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

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

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

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

    ПодходИнструмент/БиблиотекаПлюсыМинусыСтатус
    ............поддерживается / заброшена / бета

  3. Выберите один. Объясните почему. Если 2+ заслуживают доверия, создайте быстрые варианты в рамках спайка.

  4. Пропустите исследование для чистой логики без внешних зависимостей.

Используйте инструменты VibeOS для этапа исследования:

  • web_search("python websocket streaming libraries 2025") — найти кандидатов
  • web_extract(urls=["https://websockets.readthedocs.io/..."]) — прочитать актуальную документацию (возвращает markdown)
  • terminal("pip show websockets | grep Version") — проверить, что установлено в виртуальном окружении проекта

Для библиотек без страниц документации клонируйте и читайте их 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 && python3 main.py")
# Наблюдаем вывод, итерируем.

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

delegate_task(tasks=[
    {"goal": "Собрать 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
    {"goal": "Собрать 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])

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

5. Вердикт​

Каждый README.md спайка завершается:

## Вердикт: VALIDATED | PARTIAL | INVALIDATED

### Что сработало
- ...

### Что не сработало
- ...

### Неожиданности
- ...

### Рекомендация для реальной разработки
- ...

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

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

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

## Сравнение: pdfjs vs camelot

| Характеристика | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Качество извлечения | 9/10 структурированный | 7/10 только таблицы |
| Сложность настройки | npm install, 1 строка | pip + ghostscript |
| Производительность на 100-стр. PDF | 3с | 18с |
| Обрабатывает повёрнутый текст | нет | да |

**Победитель:** pdfjs для нашего случая. Camelot, если позже понадобится извлечение таблиц.

Режим Frontier (выбор следующего спайка)​

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

  • Интеграционные риски — два проверенных спайка, которые затрагивают один и тот же ресурс, но тестировались независимо
  • Передача данных — вывод спайка 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 --vibeos --global.