Hermes agent

Plan

Режим планирования: создать actionable markdown-план в .hermes/plans/ без выполнения. Мелкие задачи, точные пути, готовый код.

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

ИсточникВстроенный (установлен по умолчанию)
Путьskills/software-development/plan
Версия2.0.0
АвторHermes Agent (writing-craft adapted from obra/superpowers)
ЛицензияMIT
Платформыlinux, macos, windows
Тегиplanning, plan-mode, implementation, workflow, design, documentation
Связанные навыкиsubagent-driven-development, test-driven-development, requesting-code-review

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

инфо

Ниже — полное определение навыка, которое Hermes загружает при его активации. Это те инструкции, которые агент видит, когда навык включён.

Plan Mode

Используй этот навык, когда пользователь хочет получить план, а не выполнение.

Основное поведение

В этом ходу ты только планируешь.

  • Не реализуй код.
  • Не редактируй файлы проекта — только markdown-файл плана.
  • Не запускай мутирующие команды терминала, не делай commit, push и не совершай внешних действий.
  • Для получения контекста можно использовать команды и инструменты только для чтения.
  • Результат работы — markdown-план, сохранённый в активном рабочем пространстве в директории .hermes/plans/.

Требования к выводу

Напиши конкретный и actionable markdown-план.

Включи при наличии:

  • Цель
  • Текущий контекст и допущения
  • Предлагаемый подход
  • Пошаговый план
  • Файлы, которые, вероятно, изменятся
  • Тесты и валидация
  • Риски, трейдоффы, открытые вопросы

Если задача связана с кодом — укажи точные пути к файлам, целевые тесты и шаги верификации.

Место сохранения

Сохрани план через write_file по пути:

  • .hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md

Путь указывается относительно активной рабочей директории / бэкенд-воркспейса. Файловые инструменты Hermes учитывают бэкенд, поэтому относительный путь сохраняет план рядом с воркспейсом на любом бэкенде: local, docker, ssh, modal, daytona.

Если среда выполнения указывает конкретный целевой путь — используй его. Если нет — сформируй разумное имя файла с временной меткой в .hermes/plans/.

Стиль взаимодействия

  • Если запрос достаточно ясен — пиши план сразу.
  • Если /plan вызвали без явной инструкции — определи задачу по контексту текущего разговора.
  • Если задача реально не определена — задай короткий уточняющий вопрос, не угадывай.
  • После сохранения плана ответь коротко: что запланировано и по какому пути сохранено.

Как написать хороший план

Остальная часть навыка — это методика написания хорошего плана реализации: содержание, которое попадает в markdown-файл выше.

Обзор

Пиши подробные планы реализации в расчёте на исполнителя с нулевым знанием кодовой базы и сомнительными вкусами. Документируй всё необходимое: какие файлы трогать, готовый код, команды тестирования, документацию для проверки, способы верификации. Дроби задачи на мелкие шаги. DRY. YAGNI. TDD. Частые коммиты.

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

Главный принцип: хороший план делает реализацию очевидной. Если приходится догадываться — план неполный.

Когда нужен полный план реализации

Всегда используй перед:

  • Реализацией многошаговых фич
  • Декомпозицией сложных требований
  • Делегированием субагентам через subagent-driven-development

Не пропускай, даже если:

  • Фича кажется простой (допущения приводят к багам)
  • Планируешь реализовать сам (будущий ты тоже нуждается в руководстве)
  • Работаешь в одиночку (документация имеет значение)

Гранулярность: мелкие задачи

Каждая задача = 2–5 минут сосредоточенной работы.

Каждый шаг — одно действие:

  • «Написать падающий тест» — шаг
  • «Запустить его и убедиться, что он падает» — шаг
  • «Написать минимальный код, чтобы тест прошёл» — шаг
  • «Запустить тесты и убедиться, что они проходят» — шаг
  • «Сделать коммит» — шаг

Слишком крупно:

### Task 1: Build authentication system
[50 lines of code across 5 files]

В самый раз:

### Task 1: Create User model with email field
[10 lines, 1 file]

### Task 2: Add password hash field to User
[8 lines, 1 file]

### Task 3: Create password hashing utility
[15 lines, 1 file]

Структура документа плана

Заголовок (обязательно)

Каждый план ДОЛЖЕН начинаться с:

# [Feature Name] Implementation Plan

> **For Hermes:** Use subagent-driven-development skill to implement this plan task-by-task.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

---

Структура задачи

Каждая задача оформляется так:

### Task N: [Descriptive Name]

**Objective:** What this task accomplishes (one sentence)

**Files:**
- Create: `exact/path/to/new_file.py`
- Modify: `exact/path/to/existing.py:45-67` (line numbers if known)
- Test: `tests/path/to/test_file.py`

**Step 1: Write failing test**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected
```

**Step 2: Run test to verify failure**

Run: `pytest tests/path/test.py::test_specific_behavior -v`
Expected: FAIL — "function not defined"

**Step 3: Write minimal implementation**

```python
def function(input):
    return expected
```

**Step 4: Run test to verify pass**

Run: `pytest tests/path/test.py::test_specific_behavior -v`
Expected: PASS

**Step 5: Commit**

```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```

Процесс написания плана

Шаг 1: Разберись в требованиях

Прочитай и осмысли:

  • Требования к фиче
  • Проектные документы или описание от пользователя
  • Критерии приёмки
  • Ограничения

Шаг 2: Изучи кодовую базу

Используй инструменты Hermes, чтобы понять проект:

# Понять структуру проекта
search_files("*.py", target="files", path="src/")

# Посмотреть на похожие фичи
search_files("similar_pattern", path="src/", file_glob="*.py")

# Проверить существующие тесты
search_files("*.py", target="files", path="tests/")

# Прочитать ключевые файлы
read_file("src/app.py")

Шаг 3: Сформируй подход

Определи:

  • Архитектурный паттерн
  • Организацию файлов
  • Нужные зависимости
  • Стратегию тестирования

Шаг 4: Напиши задачи

Создавай задачи по порядку:

  1. Настройка и инфраструктура
  2. Основная функциональность (TDD для каждой части)
  3. Граничные случаи
  4. Интеграция
  5. Очистка и документация

Шаг 5: Добавь полные детали

Для каждой задачи укажи:

  • Точные пути к файлам — не «конфиг-файл», а src/config/settings.py
  • Полные примеры кода — не «добавь валидацию», а конкретный код
  • Точные команды с ожидаемым выводом
  • Шаги верификации, доказывающие, что задача выполнена

Шаг 6: Проверь план

Убедись:

  • Задачи идут последовательно и логично
  • Каждая задача мелкая (2–5 мин)
  • Пути к файлам точные
  • Примеры кода полные (можно скопировать и вставить)
  • Команды точные с ожидаемым выводом
  • Нет пропущенного контекста
  • Применены принципы DRY, YAGNI, TDD

Принципы

DRY (Don’t Repeat Yourself)

Плохо: копипаст валидации в трёх местах Хорошо: вынести валидацию в функцию, использовать везде

YAGNI (You Aren’t Gonna Need It)

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

# Bad — YAGNI violation
class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email
        self.preferences = {}  # Not needed yet!
        self.metadata = {}     # Not needed yet!

# Good — YAGNI
class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

TDD (Test-Driven Development)

Каждая задача, порождающая код, должна включать полный цикл TDD:

  1. Написать падающий тест
  2. Запустить и убедиться, что тест падает
  3. Написать минимальный код
  4. Запустить и убедиться, что тест проходит

Подробности — в навыке test-driven-development.

Частые коммиты

Коммит после каждой задачи:

git add [files]
git commit -m "type: description"

Типичные ошибки

Размытые задачи

Плохо: «Добавить аутентификацию» Хорошо: «Создать модель User с полями email и password_hash»

Неполный код

Плохо: «Шаг 1: добавить функцию валидации» Хорошо: «Шаг 1: добавить функцию валидации» — и сразу полный код функции

Отсутствие верификации

Плохо: «Шаг 3: проверить, что работает» Хорошо: «Шаг 3: запустить pytest tests/test_auth.py -v, ожидаемо: 3 passed»

Отсутствующие пути к файлам

Плохо: «Создать файл модели» Хорошо: «Create: src/models/user.py»

Передача на исполнение

После сохранения плана предложи подход к выполнению:

«План готов и сохранён. Готов к выполнению через subagent-driven-development — буду запускать свежий субагент на каждую задачу с двухэтапной проверкой (соответствие спецификации, затем качество кода). Продолжаем?»

При выполнении используй навык subagent-driven-development:

  • Свежий delegate_task на каждую задачу с полным контекстом
  • Проверка соответствия спецификации после каждой задачи
  • Проверка качества кода после прохождения первой проверки
  • Переход к следующей задаче только при одобрении обеих проверок

Запомни

Bite-sized tasks (2-5 min each)
Exact file paths
Complete code (copy-pasteable)
Exact commands with expected output
Verification steps
DRY, YAGNI, TDD
Frequent commits

Хороший план делает реализацию очевидной.

⌕ ESC