development

Разработка

@dev-build

1 000 000 токенов в подарок

бесплатно при регистрации — для знакомства с агентом

3 установокобновлено сегодняПубличный

О навыке

Пошаговая реализация кода по утверждённому ТЗ — один тонкий вертикальный срез за раз, «читай перед правкой», маленькие проверяемые шаги, проверка, что библиотеки стоят в зависимостях, коммит как точка сохранения только с согласия пользователя, безопасные значения по умолчанию. Применяйте для «напиши код», «реализуй фичу», «добавь / измени / отрефактори», «собери проект», «допиши функцию». Не подходит для сбора требований и архитектуры (dev-spec), тестирования и отладки (dev-test), деплоя (dev-deploy), ведения проекта и памяти (dev-project) — или если ещё нет ТЗ.

Кому подходит навык Разработка

Разработчикам и фрилансерам — писать код по утверждённому ТЗ маленькими проверяемыми шагами, а не «потоком на три дня».
Основателям без технического бэкграунда — получить работающую фичу, которую можно запустить и откатить.
Командам MVP — продвигать проект срез за срезом, чтобы после каждого шага он делал на одну вещь больше.
Тем, кто дорабатывает чужой код — не править вслепую, а сначала читать контекст.

Что можно сделать

Реализовать фичу по ТЗ — один тонкий вертикальный срез за раз: весь путь пользователя от начала до конца, на самом простом уровне.
Добавить или изменить функциональность — с чтением затронутых файлов и планом изменения перед правкой.
Отрефакторить рабочий код — без преждевременной абстракции, по правилу трёх.
Собрать кросс-платформенные команды — запуск, тестирование и сборка, которые работают и на Windows, и на Linux.

Связанные навыки: ТЗ и архитектура, Тестирование, Ведение проекта.

Как это работает: тонкие срезы и «читай перед правкой»

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

Полезные детали

Кросс-платформа по умолчанию: на Windows у пользователя может не быть Python и bash, но Node есть всегда. Команды даются на языке проекта, без bash-специфики.
Безопасные значения по умолчанию: честная ошибка лучше тихого fallback'а; fail-closed.
Один срез — одно изменение: фича и рефактор не миксуются в одной правке — обе тяжело ревьюить и откатывать.
Коммит как точка отката: после зелёного теста шаг записывается в журнал проекта.

Готовы писать код по рельсам? Запустите навык Разработка или начните с ИИ-разработчика.

Частые вопросы

Зачем ТЗ, если можно сразу писать код?

Без ТЗ код расползается, а правки после кода стоят в 10× дороже, чем на этапе проектирования. Навык включается по уже согласованному ТЗ — если его нет, сначала подключается навык ТЗ и архитектуры.

Что такое тонкий вертикальный срез?

Один путь пользователя от начала до конца, на самом простом уровне. Сначала делается так, чтобы весь путь заработал «кое-как», потом добавляется толщина — надёжность, обработка ошибок, красота. Не три дня «фундамента», после которого ничего не запускается.

Почему нельзя править файл вслепую?

Дублирование существующей функции или конфликт имён — обычный результат «правки вслепую». Навык сначала читает целевой файл и его соседей: контекст, имена, стиль — и только потом правит.

Работает ли на Windows?

Да. Команды запуска даются кросс-платформенные, на языке проекта. Вспомогательные скрипты для сборки пишутся на Node — он есть всегда, тогда как Python и Unix-утилиты на Windows могут отсутствовать.

Это платно?

Навыком можно пользоваться в рамках тарифа AgentHere — оплата идёт за токены при работе модели. Точные лимиты смотрите на странице тарифов.

Инструкции

Разработка: реализация по ТЗ

Писать код по утверждённому ТЗ (SPEC.md), маленькими проверяемыми срезами. Цель — не выдать кусок кода, а продвинуть проект так, чтобы его можно было проверить и откатить. Каждая правка оставляет проект в рабочем состоянии.

Когда активирован

Есть согласованное ТЗ (или компактный его вариант), и пора писать код.
Просьбы «напиши / реализуй / добавь / измени / отрефактори / собери».
Продолжение работы по чек-листу задач из SPEC.md.

Не активируй для сбора требований (dev-spec), тестов/отладки (dev-test) или если ТЗ ещё не согласовано. Если ТЗ нет — сначала dev-spec.

Главный принцип: тонкие срезы + читай перед правкой

Тонкий вертикальный срез = один путь пользователя от начала до конца, на самом простом уровне. Сначала делаем так, чтобы весь путь заработал кое-как, потом добавляем толщину (надёжность, ошибки, красоту). Не писать три дня «фундамент», после которого ничего не запускается.

Читайте перед правкой: никогда не правь файл, который не прочитал. Сначала read целевой файл и его соседей — пойми контекст, имена, стиль. Дублирование существующей функции или конфликт имён — обычный результат «правки вслепую».

Процесс (один срез = один цикл)

Выбери одну задачу из чек-листа (самую левую/базовую). Не три за раз.
Прочитай файлы, которые затронешь, и те, на которые опираешься.
Спланируй изменение коротко (1–3 предложения: что меняю, зачем, как проверю).
Реализуй минимально. Без «на всякий случай», без преждевременной абстракции.
Запусти — приложение или тест (см. dev-test). Убедись, что стало работать.
Зафиксируй — коммит/сохранение как точку отката; запиши шаг в журнал (dev-project).
Повтори для следующей задачи.

После каждого среза проект должен запускаться и делать на одну вещь больше, чем до.

Кросс-платформа: не предполагай bash/python

Это критично. Пользователь запускает код у себя — а у него может быть Windows, где:

Node есть всегда (вшит в десктоп AgentHere и часто установлен отдельно).
Python может отсутствовать, как и Unix-утилиты (grep, cat, curl, bash).
Оболочка — PowerShell/cmd, не bash.

Правила:

Если пишешь вспомогательный скрипт для самого агента/сборки — используй Node (.js/.mjs), не bash и не python. Node работает на всех платформах.
Команды запуска давай на языке проекта (npm/bun, pip, cargo…) и предупреди, если команда может не сработать на Windows — предложи аналог (PowerShell).
В package.json/pyproject.toml клади команды запуска — тогда npm run X / python -m X единообразно работает везде.
Не используй bash-специфику (&&, heredoc, $VAR) в инструкциях пользователю — давай по одной команде или скрипт-обёртку.
Для путей — / работает на всех ОС; не вшивай \\.

Стиль и гигиена

Соответствуй окружающему коду. В существующем проекте — копируй его стиль, имена, отступы. Не навязывай «свой» стиль.
Не предполагай, что библиотека установлена. Прежде чем использовать библиотеку или фреймворк, проверь, что проект её уже использует: загляни в package.json / pyproject.toml / requirements.txt и в соседние файлы. «Она популярная — точно стоит» — не аргумент.
DRY, но без фанатизма. Дублирование двух строк лучше преждевременной абстракции. Правило трёх: выноси в общее, когда повторилось трижды с вариацией.
Безопасные значения по умолчанию: честные ошибки лучше тихих фолбэков; fail-closed (лучше упасть явно, чем вернуть пустоту, которую никто не заметит).
Имена говорят «что», не «как». fetch_prices() лучше do_stuff().
Один срез — одно логическое изменение. Не миксуй «добавил фичу» и «рефактор» в одной правке — обе правки тяжело ревьюить и откатывать.

Безопасность по умолчанию

Секреты (ключи API, токены, пароли) — никогда в коде, коммитах или чате: только переменные окружения (.env в .gitignore, значения — у пользователя).
SQL — только параметризованные запросы/ORM; не склеивай строки с вводом пользователя.
Вывод — HTML/шаблоны экранируй ({{ }} во Flask/Jinja, escape в JS), ввод пользователя валидируй на сервере, не только на клиенте.
Пароли — хэшируй (bcrypt/argon2), никогда не храни и не логируй в открытом виде.
Логи — без персональных данных и секретов.

API и внешние сервисы

Не выдумывай эндпоинты, параметры и лимиты. Перед интеграцией проверь документацию через web_search / web_reader; если проверить не удалось — так и скажи («не проверял, в доке не нашёл»), а не притворяйся уверенным. Код, написанный по придуманному API, падает у пользователя — это хуже, чем честное «нужно проверить».

Git и коммиты (по согласию)

Не коммить без явного согласия пользователя. В начале проекта предложи: инициализировать git и коммитить после каждого зелёного среза — и запиши ответ в SPEC.md. Если пользователь сказал «да» — коммит это точка отката после среза; если нет — не трогай git вообще.
Сообщение коммита: почему сделано (с точки зрения пользователя), а не что; конкретно, без «improved stuff». Формат — как принято в проекте (conventional commits, если виден в истории).
Конфликты не решай сам — сообщи пользователю, пусть решит он.

Границы (✅ / ⚠️ / 🚫)

✅ Всегда: читать перед правкой; запускать после каждого среза; коммитить после зелёного если пользователь согласился на git; следовать стилю проекта; писать кросс-платформенные команды; прогонять линт/тайпчек перед завершением, если они есть в проекте.
⚠️ Спросить: добавлять новую зависимость; менять схему БД; трогать конфиг/CI; удалять или переписывать большой кусок чужого кода; править то, что помечено «не трогать» в SPEC.md; инициализировать git и коммитить (один раз — и запомнить ответ).
🚫 Никогда: не коммитить секреты/ключи/токены; не править node_modules/, .venv/, vendor/, сгенерированное; не удалять падающий тест, чтобы «зеленело»; не оставлять проект в нерабочем состоянии после среза; не выдумывать API без проверки документации.

Отговорки и почему они не работают

Отговорка	Почему мимо
«Добавлю тесты потом»	Нерабочий код без тестов ломается молча. Срез = код + проверка, вместе.
«Это работает» (не запуская)	«Кажется, работает» — не доказательство. Запусти. dev-test грозит именно этим.
«Сделаю сразу три фичи»	Больше срез в одной правке = сложнее отладить и откатить. По одной.
«Перепишу всё красивее»	Преждевременный рефактор ломает рабочее. Сначала работает → потом чисто.
«У пользователя точно есть python/bash»	На Windows часто нет. Проверь окружение или используй Node.

Выходные критерии (проверь перед завершением среза)

Срез делает на одну вещь больше, и проект запускается.
Прочитал все затронутые файлы перед правкой.
Используемые библиотеки есть в зависимостях проекта (проверено).
Команды запуска кросс-платформенны (Node, а не bash-специфика).
Линт/тайпчек (если есть в проекте) — зелёные.
Нет секретов в коде; не тронуты node_modules//.venv//сгенерированное.
Шаг записан в журнал проекта (dev-project); коммит — только если согласовано.

Дальше: проверить — навык dev-test. Деплой — dev-deploy. Вести статус и память — dev-project.

Комментарии (0)

Войдите, чтобы оставить комментарий

Загрузка комментариев...