development

Build

@dev-build

1,000,000 tokens free

on sign-up — yours to try the agent

3 installsupdated todayPublic

About

Implements code step by step against an approved spec (SPEC.md): one thin vertical slice at a time, read-before-edit, small verifiable steps, checks that libraries exist before using them, commit as a save point only with consent, safe defaults. Use when the user says «напиши код», «реализуй фичу», «добавь / измени / отрефактори», «собери проект», «допиши функцию». Do NOT use for requirements and architecture (dev-spec), testing and debugging (dev-test), deployment (dev-deploy), project tracking (dev-project), or when there is no spec yet.

Who the Build skill is for

Developers and freelancers — write code against an approved spec in small verifiable steps, not a «three-day stream».
Founders without an engineering background — get a working feature you can run and roll back.
MVP teams — move the project forward slice by slice, so after each step it does one more thing.
Anyone maintaining someone else's code — don't edit blind, read the context first.

What you can do

Implement a feature by spec — one thin vertical slice at a time: the whole user path from start to finish, at its simplest level.
Add or change functionality — with a read of the touched files and a change plan before editing.
Refactor working code — without premature abstraction, by the rule of three.
Assemble cross-platform commands — run, test and build steps that work on both Windows and Linux.

Related skills: Spec & Architecture, Test & Debug, Project Tracking.

How it works: thin slices and «read before edit»

One slice is one cycle: pick one task → read the files → plan the change → implement minimally → run → commit. After each slice the project must run and do one more thing. The key rule — never edit a file you haven't read: the target file and its neighbours are read first to grasp the context, names and style. First the whole path works «barely», then thickness is added — reliability, error handling, polish.

Useful details

Cross-platform by default: Python and bash may be missing on the user's Windows, but Node is always there. Commands come in the project's language, with no bash specifics.
Safe defaults: an honest error beats a silent fallback; fail-closed.
One slice — one change: a feature and a refactor are never mixed in one edit — both are hard to review and roll back.
A commit as a save point: after a green test the step is logged in the project journal.

Ready to code on rails? Launch the Build skill or start with the AI Developer.

FAQ

Why a spec if I can just start coding?

Without a spec the code sprawls, and edits after code cost 10× more than at the design stage. The skill works off an already-approved spec — if there isn't one, the Spec & Architecture skill is engaged first.

What is a thin vertical slice?

One user path from start to finish, at its simplest level. First the whole path is made to work «barely», then thickness is added — reliability, error handling, polish. Not three days of «foundation» after which nothing runs.

Why can't I edit a file blind?

Duplicating an existing function or a name clash is the usual result of a «blind edit». The skill first reads the target file and its neighbours — context, names, style — and only then edits.

Does it work on Windows?

Yes. Run commands are cross-platform, in the project's language. Helper build scripts are written in Node — it's always present, whereas Python and Unix tools may be missing on Windows.

Is it paid?

You can use the skill within your AgentHere plan — you pay tokens as the model runs. See the pricing page for exact limits.

Instructions

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

Писать код по утверждённому ТЗ (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.

Comments (0)

Loading comments...