GStack, /goal и office hours: рабочий цикл для AI-агента без бесконечной простыни текста
Как связать office-hours, improve-codebase-architecture, Codex /goal и HTML-progress в нормальный цикл работы с AI-агентом.
Одна из главных ошибок в работе с AI-агентами: просить “сделай проект” и потом читать километровую простыню. Нормальный флоу выглядит как цикл: прожарить идею, зафиксировать цель, дать агенту автономный ран, заставить его показывать прогресс в удобной форме и отдельно ревьюить архитектуру.
Я использую GStack как guardrail для этого цикла: агент меньше соглашается с мутной идеей и чаще показывает, где принял решение сам.
Мой текущий loop
окей, ладно, это имба:
- /office-hours скилл GStack
- прожарка любой идеи;
- вопросы “нафига” и “зачем” до того, как агент начнет писать код.
- /improve-codebase-architecture
- повышает шанс, что вайбкод проживет дольше одного вечера;
- заставляет смотреть на границы, дублирование и будущую стоимость изменений.
- /goal в Codex или /loop в Claude Code
- длинный ран после брейншторма;
- агент работает автономно, но с понятным критерием готовности.
- HTML-progress вместо простыни
- какие решения принял там, где спека мутная;
- где отошел от плана и почему;
- какие трейдоффы выбрал;
- что еще не чекнул;
- какая визуализация лучше подходит задаче.
Мой следующий шаг - понять, как неслопно задизайнить что угодно. Разбирал это отдельно в статье про design engineering и AI-агентов.
Рабочий цикл
Вот как это можно собрать без магии:
| Шаг | Что делает |
|---|---|
/office-hours | Заставляет сформулировать “зачем”, аудиторию, риск и первый эксперимент |
/improve-codebase-architecture | Ищет неочевидные архитектурные долги после того, как “вроде все работает” |
/goal или /loop | Дает агенту длинный автономный ран с понятной целью и критерием готовности |
| HTML progress | Превращает ход работы в читаемый артефакт: решения, трейдоффы, unchecked areas |
Главный смысл в том, чтобы не смешивать мышление, исполнение и отчетность в один чат. Сначала агент помогает сузить идею. Потом работает. Потом показывает, где именно принимал решения. Потом отдельный агент или тот же агент в свежем контексте ревьюит результат.
Что добавилось из обсуждений
В community много раз всплывала одна и та же боль: агент может работать долго, но человек теряет ощущение контроля. В итоге ты либо прерываешь его слишком рано, либо читаешь гигантский лог и уже не понимаешь, где важное.
HTML-progress возвращает контроль. Нормальный progress artifact должен отвечать на вопросы:
- какие решения агент уже принял;
- где спека была мутной;
- какие допущения он сделал сам;
- где отошел от первоначального плана;
- что не проверил;
- какие файлы или страницы стоит посмотреть человеку.
Это особенно важно для okhlopkov.com: агент может генерировать статьи, но редактору нужен короткий обзор, почему страница создана, какие источники использованы, где текст требует ручной вычитки и какие внутренние ссылки надо поставить.
Почему это важно для сайта
Такие workflow-посты хорошо ложатся именно в blog: личный опыт и твой стиль остаются внутри, а вокруг можно строить нормальную структуру:
- заголовок отвечает на практический запрос;
- живой текст остается ядром статьи;
- обсуждения добавляют мясо;
- внутренние ссылки ведут в статьи, где тема раскрывается глубже;
- короткие прикладные ответы лучше добавлять прямо в текст, если они не ломают тон.