ПРАВИЛА:

СОХРАНИ всю markdown-разметку: заголовки, списки, таблицы, ссылки — без изменений
НЕ переводи содержимое блоков кода (тройные обратные кавычки) и инлайн-кода (одиночные обратные кавычки)
НЕ переводи технические термины: MCP, Model Context Protocol, API, Docker, Kubernetes, Python, npm, pip, GPT, Claude, Gemini, OpenAI, Anthropic, GitHub, skills, agent, npx, URL, имена файлов, пути, команды
НЕ переводи названия продуктов, брендов, библиотек
Переводи только обычный текст в заголовках, абзацах, элементах списков
Ссылки: переведи текст ссылки, но НЕ меняй URL
Верни ТОЛЬКО переведённый markdown, без пояснений

Summary

Комплексные планы реализации для многошаговых задач, разбиение спецификаций на небольшие, тестируемые шаги.

Разбивает требования на узконаправленные задачи (по 2–5 минут каждая), следуя TDD: написать падающий тест, убедиться в падении, реализовать, проверить прохождение, зафиксировать изменения
Задает структуру файлов заранее с четкими границами и ответственностями, гарантируя, что каждый файл имеет одну цель, а файлы, которые изменяются вместе, остаются вместе
Содержит точные пути к файлам, полные примеры кода и конкретные команды с ожидаемыми выводами на каждом шаге
Требуется обзор плана через subagent перед выполнением; поддерживает два режима выполнения (управляемый subagent по задаче или встроенный пакетный режим выполнения)

Написание планов

Обзор

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

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

Объявление в начале: "Я использую навык writing-plans для создания плана реализации."

Контекст: Если вы работаете в изолированном рабочем дереве (worktree), оно должно было быть создано с помощью навыка superpowers:using-git-worktrees на момент выполнения.

Сохранить планы в: docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md

(Пользовательские предпочтения по месту хранения плана переопределяют это значение)

Проверка области

Если спецификация охватывает несколько независимых подсистем, её следовало разбить на спецификации под-проектов во время мозгового штурма. Если этого не произошло, предложите разделить это на отдельные планы — по одному плану на подсистему. Каждый план должен приводить к работоспособному, тестируемому программному обеспечению сам по себе.