On this page Пишите планы реализации: задачи небольшого объёма, пути, код.
Skill metadata¶
|---|---
Source| Встроенный (установлен по умолчанию)
Path| skills/software-development/writing-plans
Version| 1.1.0
Author| Hermes Agent (адаптировано из obra/superpowers)
License| MIT
Tags| planning, design, implementation, workflow, documentation
Related skills| subagent-driven-development, test-driven-development, requesting-code-review
Reference: full SKILL.md¶
info Ниже приведено полное определение навыка, которое Hermes загружает при активации этого навыка. Именно эти инструкции видит агент, когда навык активен.
Написание планов реализации¶
Обзор¶
Пишите подробные планы реализации, предполагая, что исполнитель не имеет никакого контекста о кодовой базе и сомнительный вкус. Документируйте всё, что им нужно: какие файлы трогать, полный код, команды для тестирования, документацию для проверки, способы верификации. Давайте им задачи небольшого объёма. DRY. YAGNI. TDD. Частые коммиты. Предполагайте, что исполнитель — опытный разработчик, но почти ничего не знает об инструментарии или предметной области. Предполагайте, что он не очень хорошо знает, как проектировать тесты. Основной принцип: Хороший план делает реализацию очевидной. Если кому-то приходится гадать — план неполный.
Когда использовать¶
Всегда используйте перед: * Реализацией многошаговых функций * Декомпозицией сложных требований * Делегированием субагентам через subagent-driven-development
Не пропускайте когда: * Функция кажется простой (предположения вызывают ошибки) * Вы планируете реализовать её самостоятельно (будущий вы нуждается в руководстве) * Работаете в одиночку (документация важна)
Размер задач: небольшой объём¶
Каждая задача = 2–5 минут целенаправленной работы. Каждый шаг — одно действие: * «Напишите падающий тест» — шаг * «Запустите его, чтобы убедиться, что он падает» — шаг * «Реализуйте минимальный код, чтобы тест прошёл» — шаг * «Запустите тесты и убедитесь, что они проходят» — шаг * «Закоммитьте» — шаг
Слишком крупно:
[code]
### Задача 1: Создание системы аутентификации
[50 строк кода в 5 файлах]
[/code]
Правильный размер:
[code]
### Задача 1: Создание модели User с полем email
[10 строк, 1 файл]
### Задача 2: Добавление поля хеша пароля в User
[8 строк, 1 файл]
### Задача 3: Создание утилиты хеширования паролей
[15 строк, 1 файл]
[/code]
Структура документа плана¶
Заголовок (обязательно)¶
Каждый план ОБЯЗАТЕЛЬНО должен начинаться с: [code] # План реализации [Название функции]
> **Для Hermes:** Используйте навык subagent-driven-development для выполнения этого плана задача за задачей.
**Цель:** [Одно предложение, описывающее что создаётся]
**Архитектура:** [2–3 предложения о подходе]
**Технологический стек:** [Ключевые технологии/библиотеки]
---
[/code]
Структура задачи¶
Каждая задача следует этому формату: [code] ### Задача N: [Описательное название]
**Цель:** Что эта задача выполняет (одно предложение)
**Файлы:**
- Создать: `exact/path/to/new_file.py`
- Изменить: `exact/path/to/existing.py:45-67` (номера строк, если известны)
- Тест: `tests/path/to/test_file.py`
**Шаг 1: Напишите падающий тест**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
**Шаг 2: Запустите тест, чтобы убедиться, что он падает**
Запустите: `pytest tests/path/test.py::test_specific_behavior -v`
Ожидаемый результат: FAIL — «function not defined»
**Шаг 3: Напишите минимальную реализацию**
```python
def function(input):
return expected
```
**Шаг 4: Запустите тест, чтобы убедиться, что он проходит**
Запустите: `pytest tests/path/test.py::test_specific_behavior -v`
Ожидаемый результат: PASS
**Шаг 5: Закоммитьте**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: добавить конкретную функцию"
```
[/code]
Процесс написания¶
Шаг 1: Поймите требования¶
Прочитайте и осмыслите: * Требования к функции * Проектные документы или описание пользователя * Критерии приёмки * Ограничения
Шаг 2: Исследуйте кодовую базу¶
Используйте инструменты Hermes для понимания проекта:
[code]
# Понять структуру проекта
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")
[/code]
Шаг 3: Спроектируйте подход¶
Решите: * Архитектурный паттерн * Организацию файлов * Необходимые зависимости * Стратегию тестирования
Шаг 4: Напишите задачи¶
Создавайте задачи по порядку: 1. Настройка/инфраструктура 2. Базовая функциональность (TDD для каждой) 3. Граничные случаи 4. Интеграция 5. Очистка/документация
Шаг 5: Добавьте полные детали¶
Для каждой задачи укажите:
* Точные пути к файлам (не «файл конфигурации», а src/config/settings.py)
* Полные примеры кода (не «добавьте валидацию», а actual код)
* Точные команды с ожидаемым выводом
* Шаги верификации, которые подтверждают, что задача работает
Шаг 6: Проверьте план¶
Проверьте: * Задачи последовательны и логичны * Каждая задача небольшого объёма (2–5 мин) * Пути к файлам точны * Примеры кода полны (можно скопировать и вставить) * Команды точны с ожидаемым выводом * Нет пропущенного контекста * Применены принципы DRY, YAGNI, TDD
Шаг 7: Сохраните план¶
[code]
mkdir -p docs/plans
# Сохраните план в docs/plans/YYYY-MM-DD-feature-name.md
git add docs/plans/
git commit -m "docs: добавить план реализации для [функции]"
[/code]
Принципы¶
DRY (Don't Repeat Yourself — не повторяйся)¶
Плохо: Копировать-вставить валидацию в 3 места Хорошо: Выделить функцию валидации, использовать везде
YAGNI (You Aren't Gonna Need It — вам это не понадобится)¶
Плохо: Добавлять «гибкость» для будущих требований Хорошо: Реализовывать только то, что нужно сейчас
[code]
# Плохо — нарушение YAGNI
class User:
def init(self, name, email):
self.name = name
self.email = email
self.preferences = {} # Пока не нужно!
self.metadata = {} # Пока не нужно!
# Хорошо — YAGNI
class User:
def __init__(self, name, email):
self.name = name
self.email = email
[/code]
TDD (Test-Driven Development — разработка через тестирование)¶
Каждая задача, которая создаёт код, должна включать полный цикл TDD: 1. Напишите падающий тест 2. Запустите, чтобы убедиться, что он падает 3. Напишите минимальный код 4. Запустите, чтобы убедиться, что он проходит
Подробнее см. в навыке test-driven-development.
Частые коммиты¶
Коммитьте после каждой задачи:
[code]
git add [files]
git commit -m "type: описание"
[/code]
Распространённые ошибки¶
Расплывчатые задачи¶
Плохо: «Добавить аутентификацию» Хорошо: «Создать модель User с полями email и password_hash»
Неполный код¶
Плохо: «Шаг 1: Добавить функцию валидации» Хорошо: «Шаг 1: Добавить функцию валидации» с последующим полным кодом функции
Отсутствие верификации¶
Плохо: «Шаг 3: Проверить, что работает» Хорошо: «Шаг 3: Запустить pytest tests/test_auth.py -v, ожидается: 3 passed»
Отсутствие путей к файлам¶
Плохо: «Создайте файл модели» Хорошо: «Создать: src/models/user.py»
Передача на исполнение¶
После сохранения плана предложите подход к выполнению:
«План готов и сохранён. Готовы выполнять с использованием subagent-driven-development — я отправлю свежего субагента на каждую задачу с двухэтапной проверкой (соответствие спецификации, затем качество кода). Начинаем?»
При выполнении используйте навык subagent-driven-development:
* Новый delegate_task на каждую задачу с полным контекстом
* Проверка соответствия спецификации после каждой задачи
* Проверка качества кода после прохождения спецификации
* Продолжайте только после одобрения обеих проверок
Запомните¶
[code]
Задачи небольшого объёма (2–5 мин каждая)
Точные пути к файлам
Полный код (можно скопировать)
Точные команды с ожидаемым выводом
Шаги верификации
DRY, YAGNI, TDD
Частые коммиты
[/code] Хороший план делает реализацию очевидной. * Skill metadata * Reference: full SKILL.md * Обзор * Когда использовать * Размер задач: небольшой объём * Структура документа плана * Заголовок (обязательно) * Структура задачи * Процесс написания * Шаг 1: Поймите требования * Шаг 2: Исследуйте кодовую базу * Шаг 3: Спроектируйте подход * Шаг 4: Напишите задачи * Шаг 5: Добавьте полные детали * Шаг 6: Проверьте план * Шаг 7: Сохраните план * Принципы * DRY (Don't Repeat Yourself — не повторяйся) * YAGNI (You Aren't Gonna Need It — вам это не понадобится) * TDD (Test-Driven Development — разработка через тестирование) * Частые коммиты * Распространённые ошибки * Расплывчатые задачи * Неполный код * Отсутствие верификации * Отсутствие путей к файлам * Передача на исполнение * Запомните