banatie-content/desktop-agents/002-architect/agent-guide.md

173 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# @architect — Agent Guide
## Что я делаю
Превращаю briefs в детальные структуры (outlines) с word budgets.
Создаю Validation Request — список claims для проверки фактов.
Хороший outline = хороший article. Плохая структура создаёт проблемы на всех этапах.
---
## Начало работы
```
/init
```
---
## Команды
| Команда | Что делает |
|---------|------------|
| `/init` | Загрузить контекст, показать файлы |
| `/review` | Оценить готовую статью на structural integrity |
| `/rus` | Перевести текущую работу на русский |
---
## Что могу делать
**Создать outline из brief**
"Сделай outline для 1-planning/nextjs-images.md"
→ Читаю brief и style guide автора, создаю структуру + Validation Request
**Пересмотреть структуру**
"Слишком много секций, упрости"
→ Переструктурирую по твоим указаниям
**Объяснить решения**
"Почему такой порядок секций?"
→ Объясню логику reader journey
**Исправить после валидации**
"@validator вернул REVISE, исправь claims"
→ Читаю Validation Results, обновляю Outline
**Review готовой статьи**
"Сделай /review для 4-human-review/article.md"
→ Проверка структуры, добавление комментария в Review Chat
---
## /review — Финальная проверка
После human editing, перед публикацией:
1. Читаю статью (Text section)
2. Сравниваю с Outline (моя структура)
3. Смотрю комментарии коллег в Review Chat
4. Оцениваю:
- Idea alignment — решает исходную проблему?
- Outline compliance — структура соблюдена?
- Section balance — word budgets в норме?
- Reader journey — flow логичный?
- Scope integrity — не ушли в сторону?
- Code/visuals — всё запланированное на месте?
5. Обсуждаю с тобой
6. После твоего OK — добавляю комментарий в Review Chat
Если всё хорошо, заканчиваю комментарий словом "APPROVED."
---
## Что создаю
**Outline** — полная структура статьи:
- Все секции с заголовками
- Word budget для каждой секции
- Цель каждой секции (что читатель узнает)
- Где будут code examples
- Какие visual assets нужны
- SEO заметки (куда ключевые слова)
**Validation Request** — список claims для проверки:
- Статистика и цифры
- Цитаты
- Технические утверждения
- Рыночные claims
- Сравнительные claims
---
## Word Budgets
| Тип контента | Типичный объём |
|--------------|----------------|
| Tutorial | 1500-2500 слов |
| Explainer | 1200-2000 слов |
| Comparison | 1500-2500 слов |
| Listicle | 1000-1800 слов |
---
## Pipeline: где мои файлы
```
1-planning/{slug}.md ← читаю отсюда (Brief)
2-outline/{slug}.md ← перемещаю после создания outline
← файл ОСТАЁТСЯ здесь для @validator
3-drafting/{slug}.md ← после PASS от @validator
```
---
## Перед handoff
Всегда показываю summary и спрашиваю подтверждение:
```
Outline готов.
Структура:
- Intro: {hook}
- 4 основных секции
- 3 code examples
- 2 диаграммы
Общий объём: 2000 words
Validation Request: 5 claims для проверки
Хочешь посмотреть детали или готово для @validator?
```
---
## После меня
**@validator** проверяет факты из Validation Request.
Если **PASS** → файл переходит в 3-drafting/ → @writer пишет Draft.
Если **REVISE** → я исправляю Outline по результатам валидации.
Если **STOP** → обсуждаем с тобой, возможно статья убивается.
---
## Когда Validation Request не нужен
Для чистых tutorials без фактических утверждений:
```markdown
# Validation Request
**Status:** Not required
This article is a technical tutorial with no factual claims requiring external verification.
```
---
## Примеры запросов
- "Покажи что есть в 1-planning"
- "Сделай outline для placeholder-api.md"
- "Это слишком длинно, сократи до 1500 слов"
- "Поменяй местами секции 2 и 3"
- "Добавь секцию про error handling"
- "@validator вернул REVISE, исправь claims 2 и 4"
- "/review для статьи в 4-human-review/"