🏠 Главная › user guide › software development spike

{/ Эта страница автоматически создается на основе файла SKILL.md навыка с помощью сайта site/scripts/generate-skill-docs.py. Редактируйте исходный код SKILL.md, а не эту страницу. /}

Спайк

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

Метаданные навыков
Источник В комплекте (устанавливается по умолчанию)
Путь навыки/разработка программного обеспечения/спайк
Версия 1.0.0
Автор Агент Гермеса (адаптировано из gsd-build/get-shit-done)
Лицензия Массачусетский технологический институт
Платформы Linux, MacOS, Windows
Теги спайк, прототип, эксперимент, технико-экономическое обоснование, одноразовый, разведка, исследования, планирование, MVP, проверка концепции
Сопутствующие навыки sketch, writing-plans, разработка-под агентом, plan

Ссылка: полная версия SKILL.md:::информация

Ниже приведено полное определение навыка, которое Гермес загружает при активации этого навыка. Это то, что агент видит в качестве инструкций, когда навык активен.

Спайк

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

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

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

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

Если gsd-spike отображается как родственный навык (устанавливается через npx get-shit-done-cc --hermes), отдайте предпочтение gsd-spike, когда пользователю нужен полный рабочий процесс GSD: постоянное состояние .planning/spikes/, отслеживание MANIFEST между сеансами, формат вердикта «Дано/Когда/Тогда» и шаблоны фиксации, которые интегрируются с остальной частью GSD. Этот навык представляет собой облегченную автономную версию для пользователей, у которых нет (или не нужна) полная система.

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

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

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

1. Разложить

Разбейте идею пользователя на 2–5 независимых вопросов о осуществимости. Каждый вопрос — это один спайк. Представьте их в виде таблицы с рамкой «Дано/Когда/Тогда»:

# Спайк Проверяет (Дано/Когда/Тогда) Риск
001 потоковая передача через веб-сокет При подключении WS, когда LLM передает токены, клиент получает фрагменты < 100 мс Высокий
002а pdf-разбор-pdfjs Учитывая многостраничный PDF-файл, при анализе с помощью pdfjs структурированный текст можно извлечь Средний
002б PDF-разбор-Камелот Учитывая многостраничный PDF-файл, при анализе с помощью Camlot можно извлечь структурированный текст Средний

Типы шипов: - стандарт — один подход, отвечающий на один вопрос - сравнение — один и тот же вопрос, разные подходы (общее число, буквенный суффикс a/b/c)

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

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

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

2. Выравнивание (для идей с несколькими шипами)

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

3. Исследования (за шип, перед постройкой)

Шипы не обходятся без исследований: вы исследуете достаточно, чтобы выбрать правильный подход, а затем строите. На шип:

  1. Коротко. 2–3 предложения: что это за всплеск, почему он важен, ключевой риск.
  2. Поверхностные конкурирующие подходы, если есть реальный выбор:
Подход Инструмент/Библиотека Плюсы Минусы Статус
... ... ... ... поддерживается / заброшен / бета-версия
  1. Выберите один. Скажите, почему. Если 2+ заслуживают доверия, создайте быстрые варианты внутри шипа.
  2. Пропускайте исследования для чистой логики без внешних зависимостей.

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

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

ПОДТВЕРЖДЕНО = на основной вопрос был дан утвердительный ответ с доказательствами. 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.

Режим Frontier (выбор того, что добавить дальше)

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

Предложите 2–4 кандидата в формате «Дано/Когда/Тогда». Пусть пользователь выбирает.

Вывод

Атрибуция

Адаптировано из рабочего процесса /gsd-spike проекта GSD (Get Shit Done) — MIT © 2025 Лекс Кристоферсон (gsd-build/get-shit-done). Полная система GSD обеспечивает постоянное пиковое состояние, отслеживание МАНИФЕСТОВ и интеграцию с более широким конвейером разработки на основе спецификаций; установите с помощью npx get-shit-done-cc --hermes --global.