Рабочий флоу¶

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

1. Выберите правильный проект¶

Откройте папку, где находится код задачи. Для обычного репозитория это корень проекта. Для монорепозитория — уровень, откуда видны нужные пакеты, общие настройки и команды проверки.

Если задача не привязана к существующему коду, нажмите Без проекта. Это хороший вариант для черновиков, прототипов, разбора идеи или генерации небольшого файла.

2. Начните с рамки задачи¶

Хороший запрос задаёт цель, границы и ожидаемый формат ответа.

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

В сложных задачах полезно явно попросить не править файлы на первом шаге. Так вы получаете карту местности до изменений.

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

3. Выберите режим контроля¶

Перед отправкой запроса проверьте нижнюю панель:

• Только чтение — для анализа, аудита, ревью и поиска причин;
• Запрашивать подтверждение — для задач, где важен контроль каждого изменения;
• Авто-правки — для небольших понятных изменений;
• режим агента — роль, в которой Koda будет подходить к новой задаче;
• модель — если хотите выбрать более быстрый или более сильный режим работы.

Режим лучше выбирать до старта новой сессии. Если задача уже пошла не туда, остановите ответ и начните новый чат.

Примеры выбора роли:

• Системный аналитик — когда нужно разобрать требования и edge cases.
• Тестировщик — когда нужен чеклист проверок.
• Код-ревьюер — когда вы проверяете уже сделанные изменения.
• Разработчик — когда план понятен и нужно внести правку.

4. Согласуйте план¶

Для нетривиальных задач попросите короткий план перед реализацией:

Составь план на 3-5 шагов. Отметь, какие файлы будут затронуты и где есть риск сломать существующее поведение.

Если план выглядит слишком широким, сузьте его:

Сделай минимальное исправление только для этого бага. Рефакторинг и переименование оставим отдельно.

5. Разрешите действия осознанно¶

Когда появляется панель Нужно подтверждение, посмотрите:

• какое действие предлагается;
• какие файлы меняются;
• есть ли diff;
• соответствует ли это вашему запросу.

Для единичного изменения выбирайте Разрешить. Для серии однотипных безопасных правок можно выбрать Разрешить все правки. Если агент меняет не те файлы, нажмите Отклонить или Стоп и уточните задачу.

6. Проверьте результат¶

После изменений попросите итог:

Коротко перечисли, что изменилось, какие риски остались и какую проверку нужно запустить.

Затем попросите тесты, ручной чеклист или команду проверки:

Проверь, какие тесты или typecheck подходят для этой правки, и запусти доступную проверку.

Если ответ содержит кнопку Источники, раскройте её и проверьте ссылки. Это особенно важно для задач, где агент опирался на внешнюю документацию или найденные материалы.

7. Доведите до коммита¶

Если проект находится в git-репозитории, используйте чип ветки и меню действий рядом с ним.

В меню доступны:

• Обновить ветки — выполнить fetch и увидеть новые remote-ветки;
• Новая ветка — создать локальную ветку из текущего состояния;
• Коммит — подготовить коммит из текущих изменений;
• Git pull — подтянуть текущую ветку через fast-forward.

Хороший финальный запрос:

Подготовь короткое сообщение коммита в стиле conventional commits и отдельно дай summary для PR.

Типовой цикл¶

1. Создать или выбрать ветку.
2. Попросить read-only анализ.
3. Приложить скриншот, документ или лог, если без них задача неполная.
4. Согласовать минимальный план.
5. Разрешить изменения.
6. Проверить diff, источники и тесты.
7. Попросить summary и сообщение коммита.
8. Сохранить результат и перейти к следующей задаче.