Flownix
Начать
Разделы
На этой странице

Первый проект

Сквозной путь: от подключённого агента до первой закрытой задачи, с конкретными командами на каждом шаге.

Эта страница проходится один раз и целиком. К её концу у вас будет проект с деревом задач, одна выполненная задача и след работы, по которому следующий агент — или вы через месяц — восстановит контекст без расспросов.

Всё, что ниже, — реальные команды. Скиллы вызываются как слэш-команды Claude Code: /имя-скилла, при необходимости с аргументом в той же строке.

Предполагается, что уже сделано:

Шаг 1. Заведите проект

Перейдите в каталог с кодом (можно пустой) и вызовите:

в сессии агента
/flownix-init

Что произойдёт по шагам:

  1. Агент ищет рядом файл .flownix — если его нет, идёт дальше.
  2. list_organizations — показывает ваши организации или предлагает создать (create_organization).
  3. list_projects — то же с проектами. Новый заводится через create_project, и вы называете ключ проекта: две-три заглавные буквы, из которых потом собираются слаги задач. Ключ AF даёт AF-TASK-1, ключ SHOP — SHOP-TASK-1.
  4. Записывает .flownix в текущий каталог.
.flownix
spec_mode: "off"
org:
  id: "62c39018-..."
  name: "Mementai"
project:
  id: "d13b9da0-..."
  name: "Мой продукт"
  key: "AF"
  spec: |
    ## Goal
    ...

Дальше все скиллы читают этот файл сами, и вы больше никогда не вводите идентификаторы руками.

Затем агент задаст три вопроса: включить ли строгий режим спецификаций, собрать ли спеку по существующему коду (/bootstrap-spec), настроить ли совет агентов. На первом проекте на все три отвечайте «нет» — вернуться к ним можно в любой момент.

Шаг 2. Опишите замысел

Не задачу — замысел. Раскладка на задачи — работа агента, и делать её за него значит терять его сильную сторону.

в сессии агента
/plan-feature Авторизация по магической ссылке: письмо со ссылкой вместо пароля,
срок жизни ссылки 15 минут, одна ссылка — один вход.

Что произойдёт по шагам:

  1. Сначала поиск, потом создание. rag_query по смыслу вашей формулировки и rag_context по предметной области. Если похожее уже планировалось, агент найдёт это и предложит расширить существующее, а не завести второе такое же. Пустой ответ он не считает доказательством отсутствия — сверяется с rag_status.
  2. Раскладка сверху вниз через create_node: feature → plan → task. Эпик заводится только под действительно большой объём: лишний уровень никому не помогает.
  3. Спека отдельным документом — create_doc_node: каким продукт станет после этой фичи, а не что нужно сделать. Каждая задача связывается с ней через set_references.
  4. Зависимости — add_dependency. Читается как предложение: «from зависит от to», то есть to — блокер и делается первым.
  5. Теги (add_tag) и, если система размечена компонентами, set_node_components.

На выходе агент называет созданные слаги — примерно так:

shell
AF-FEAT-1  — Авторизация по магической ссылке
  AF-PLAN-1  — Реализация одноразовых ссылок
    AF-TASK-1  — Модель токена и миграция
    AF-TASK-2  — Выдача ссылки и отправка письма   (зависит от AF-TASK-1)
    AF-TASK-3  — Обмен ссылки на сессию            (зависит от AF-TASK-1)
AF-DOC-1   — Спецификация: вход по ссылке

Шаг 3. Посмотрите, что получилось

Откройте проект в веб-интерфейсе: дерево слева, граф справа — зависимости и связи видно глазами. Здесь вы правите то, с чем не согласны; это ваша половина работы, и её нельзя делегировать.

Что стоит проверить, пока не начали делать:

  • Задачи действительно самостоятельные? Задача, которую нельзя выполнить за один заход, — это план, а не задача.
  • Зависимости отражают реальный порядок? Лишняя зависимость останавливает работу на пустом месте.
  • Спека описывает результат, а не пересказывает задачи?

Править можно и словами, не выходя из сессии:

в сессии агента
AF-TASK-2 слишком крупная — разбей её на две и перенеси зависимость

Шаг 4. Выполните первую задачу

в сессии агента
/execute-task AF-TASK-1

Что произойдёт по шагам:

  1. get_node(slug: "AF-TASK-1") — описание и все комментарии: там решения, принятые раньше.
  2. get_dependencies — если блокер не закрыт, агент не начнёт, а скажет об этом.
  3. rag_context — окружающий контекст: похожие задачи, принятые решения, соседние модули.
  4. update_node_status(status: "in_progress") — на доске видно, чем он занят.
  5. Собственно работа, по ходу — add_comment с пометками: [progress] что сделано, [decision] почему именно так, [blocker] что мешает.
  6. update_node_status(status: "testing") с хэшем коммита и комментарием [done] о том, как проверить.

Задача останавливается в testing, а не в done, намеренно: сделал и проверил — разные роли. Кто переводит дальше — вы или отдельный проход проверки, — на шаге 6.

Этот след — не отчётность. Тикет здесь работает как память агента: между сессиями агент не помнит ничего, и всё, что не записано в ноду, потеряно. Отсюда правило, на котором держится продукт: решение, не записанное в тикет, не принято.

Шаг 5. Посмотрите, что осталось

Откройте AF-TASK-1 в веб-интерфейсе. Там:

  • статус — что реально происходит, а не «в процессе» месяцами;
  • комментарии [progress], [decision], [done] — ход работы и принятые решения;
  • хэш коммита — связь с кодом;
  • прогресс AF-PLAN-1 пересчитался сам по статусам задач внутри.

Следующий агент, взяв AF-TASK-2, прочитает это и не начнёт с нуля.

Шаг 6. Закройте задачу

Задача в testing ждёт проверки. Проверить её можно самому, а можно вторым проходом агента — тем, который не писал этот код:

в сессии агента
/review-work AF-TASK-1

Что произойдёт по шагам:

  1. Агент читает критерии приёмки из описания задачи и комментарии исполнителя.
  2. Поднимает rag_query записанные решения по затронутой подсистеме: изменение, противоречащее чьему-то [decision], — это замечание, а не мелочь.
  3. Проходит по критериям поимённо, а не «в целом выглядит нормально».
  4. Записывает результат комментарием [review] и переводит задачу: в done, если критерии выполнены, или обратно в regression с перечнем того, что не так.
  5. Если работа того стоит — создаёт документ по ней (create_doc_node) и связывает его с фичей и задачами через set_references.

Когда AF-TASK-1 уходит в done, прогресс AF-PLAN-1 пересчитывается сам.

Что дальше