# GStack, /goal и office hours: рабочий цикл для AI-агента без бесконечной простыни текста

## Коротко

Одна из главных ошибок в работе с AI-агентами: просить “сделай проект” и потом читать километровую простыню. Нормальный флоу выглядит как цикл: прожарить идею, зафиксировать цель, дать агенту автономный ран, заставить его показывать прогресс в удобной форме и отдельно ревьюить архитектуру.

Эта страница не про “что такое GStack”. Это про практический рабочий loop, который можно повторить в Codex, Claude Code и похожих агентных инструментах.

## Мой текущий loop

окей, ладно, это имба:

**• /office-hours скилл gstack**
прожарка любой идеи. ответишь на вопросы нафига, а главное зачем

**• [/improve-codebase-architecture](/blog/improve-codebase-architecture-prompt/)**
повысь шанс того, что у твоего вайбкода будет долгая жизнь

**• /goal в Codex или /loop в Claude Code**
ральф луп после брейншторма идеи — пусть пыхтит часами & make no mistakes

• пока лупишься - рисуй html с прогрессом
какие решения принял там, где спека мутная
где отошёл от плана и почему
какие трейдоффы выбрал
что еще не чекнул
выбери лучшую визуализацию под задачу, а не простыню текста

Мой следующий шаг - понять, как неслопно задизайнить что угодно. [Разбирал это отдельно в статье про design engineering и AI-агентов](/articles/ai-tools-for-designers-design-engineering-agents/).

## Рабочий цикл

Вот как это можно собрать без магии:

| Шаг | Что делает |
| --- | --- |
| `/office-hours` | Заставляет сформулировать “зачем”, аудиторию, риск и первый эксперимент |
| `/improve-codebase-architecture` | Ищет неочевидные архитектурные долги после того, как “вроде все работает” |
| `/goal` или `/loop` | Дает агенту длинный автономный ран с понятной целью и критерием готовности |
| HTML progress | Превращает ход работы в читаемый артефакт: решения, трейдоффы, unchecked areas |

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

## Что добавилось из обсуждений

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

HTML-progress решает не “дизайн ради дизайна”, а контроль. Нормальный progress artifact должен отвечать на вопросы:

- какие решения агент уже принял;
- где спека была мутной;
- какие допущения он сделал сам;
- где отошел от первоначального плана;
- что не проверил;
- какие файлы или страницы стоит посмотреть человеку.

Это особенно важно для `okhlopkov.com`: агент может генерировать статьи, но редактору нужен короткий обзор, почему страница создана, какие источники использованы, где текст требует ручной вычитки и какие внутренние ссылки надо поставить.

## Почему это важно для сайта

Такие workflow-посты хорошо ложатся именно в `blog`, а не в `articles`. Они основаны на личном опыте и твоем стиле, но вокруг них можно строить нормальную структуру:

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

## Связанные материалы

- [AI-агенты: с чего начать в 2026](/blog/ai-agents-s-chego-nachat/)
- [Что попросить AI-агента сделать, когда задачи закончились](/blog/improve-codebase-architecture-prompt/)
- [AI-инструменты для дизайнеров: design engineering и агенты](/articles/ai-tools-for-designers-design-engineering-agents/)
- [Markdown мёртв — да здравствует HTML](/articles/markdown-vs-html/)