Рабочие процессы

Рабочие процессы — это структурированные многоэтапные процессы, запускаемые слеш-командами или ключевыми словами в естественном языке. Они определяют, как агенты совместно работают над задачами — от однофазных утилит до сложных 5-фазных шлюзов качества.

Всего 16 рабочих процессов, 4 из которых — постоянные (сохраняют состояние и не могут быть случайно прерваны).

Постоянные рабочие процессы

Постоянные рабочие процессы работают до завершения всех задач. Они сохраняют состояние в .agents/state/ и повторно внедряют контекст [OMA PERSISTENT MODE: ...] при каждом сообщении пользователя до явной деактивации.

/orchestrate

Описание: Автоматизированное параллельное выполнение агентов через CLI. Запускает субагентов, координирует через MCP-память, отслеживает прогресс и запускает циклы верификации.

Постоянный: Да. Файл состояния: .agents/state/orchestrate-state.json.

Ключевые слова-триггеры:

Язык	Ключевые слова
Универсальные	"orchestrate"
Английский	"parallel", "do everything", "run everything"
Корейский	"자동 실행", "병렬 실행", "전부 실행", "전부 해"
Японский	"オーケストレート", "並列実行", "自動実行"
Китайский	"编排", "并行执行", "自动执行"
Испанский	"orquestar", "paralelo", "ejecutar todo"
Французский	"orchestrer", "parallèle", "tout exécuter"
Немецкий	"orchestrieren", "parallel", "alles ausführen"
Португальский	"orquestrar", "paralelo", "executar tudo"
Русский	"оркестровать", "параллельно", "выполнить всё"
Нидерландский	"orkestreren", "parallel", "alles uitvoeren"
Польский	"orkiestrować", "równolegle", "wykonaj wszystko"

Шаги:

Шаг 0 — Подготовка: Чтение навыка координации, руководства по загрузке контекста, протокола памяти. Определение вендора.
Шаг 1 — Загрузка/Создание плана: Проверка .agents/results/plan-{sessionId}.json. Если отсутствует, предложение запустить /plan.
Шаг 2 — Инициализация сессии: Загрузка oma-config.yaml, генерация ID сессии (session-YYYYMMDD-HHMMSS), создание orchestrator-session.md и task-board.md в памяти.
Шаг 3 — Запуск агентов: Для каждого приоритетного уровня (P0 первый) запуск агентов соответствующим вендору методом. Не превышать MAX_PARALLEL.
Шаг 4 — Мониторинг: Опрос файлов progress-{agent}.md, обновление task-board.md.
Шаг 5 — Верификация: Запуск verify.sh для каждого завершённого агента. При сбое — повторный запуск (макс. 2 попытки). После 2 попыток — цикл исследования.
Шаг 6 — Сбор: Чтение всех файлов result-{agent}.md, составление сводного отчёта.
Шаг 7 — Финальный отчёт: Резюме сессии с Quality Score и Experiment Ledger при наличии.

Когда использовать: Большие проекты, требующие максимального параллелизма.

/work

Описание: Пошаговая мульти-доменная координация с подтверждением пользователя на каждом шлюзе, QA-ревью и циклом устранения замечаний.

Постоянный: Да. Файл состояния: .agents/state/work-state.json.

Ключевые слова-триггеры:

Язык	Ключевые слова
Универсальные	"work", "step by step"
Корейский	"코디네이트", "단계별"
Японский	"コーディネート", "ステップバイステップ"
Китайский	"协调", "逐步"
Испанский	"coordinar", "paso a paso"
Французский	"coordonner", "étape par étape"
Немецкий	"koordinieren", "schritt für schritt"

Шаги:

Шаг 0 — Подготовка: Чтение навыков, загрузки контекста, протокола памяти.
Шаг 1 — Анализ требований: Определение задействованных доменов.
Шаг 2 — Планирование PM-агентом: Декомпозиция требований, API-контракты, сохранение в .agents/results/plan-{sessionId}.json.
Шаг 3 — Ревью плана: Подтверждение пользователем обязательно.
Шаг 4 — Запуск агентов: По приоритетным уровням, параллельно в пределах уровня.
Шаг 5 — Мониторинг: Верификация соответствия API-контрактов.
Шаг 6 — QA-ревью: Безопасность (OWASP), производительность, доступность, качество кода.
Шаг 6.1 — Quality Score (условный).
Шаг 7 — Итерация: При CRITICAL/HIGH — повторный запуск. При повторении — цикл исследования.

Когда использовать: Фичи, охватывающие несколько доменов, с пошаговым контролем.

/ultrawork

Описание: Рабочий процесс максимального качества. 5 фаз, 17 шагов, 11 шагов ревью. Каждая фаза имеет шлюз.

Постоянный: Да. Файл состояния: .agents/state/ultrawork-state.json.

Ключевые слова-триггеры: "ultrawork", "ulw" (универсальные).

Фазы и шаги:

Фаза	Шаги	Агент	Перспектива ревью
PLAN	1-4	PM-агент (инлайн)	Полнота, Мета-ревью, Избыточность/Простота
IMPL	5	Dev-агенты (запущенные)	Реализация
VERIFY	6-8	QA-агент (запущенный)	Соответствие, Безопасность (OWASP), Регрессии
REFINE	9-13	Debug-агент (запущенный)	Разбиение файлов, Переиспользование, Каскад, Консистентность, Мёртвый код
SHIP	14-17	QA-агент (запущенный)	Качество кода, UX-поток, Связанные проблемы, Готовность к деплою

Определения шлюзов:

PLAN_GATE: План задокументирован, допущения перечислены, альтернативы рассмотрены, подтверждение пользователя.
IMPL_GATE: Сборка успешна, тесты проходят, изменены только запланированные файлы, базовый Quality Score записан.
VERIFY_GATE: Реализация соответствует требованиям, ноль CRITICAL, ноль HIGH, Quality Score >= 75.
REFINE_GATE: Нет больших файлов/функций, побочные эффекты проверены, код очищен, Quality Score не регрессировал.
SHIP_GATE: Проверки пройдены, UX проверен, чек-лист деплоя выполнен, финальный Quality Score >= 75.

Поведение при провале: Первый — вернуться и исправить. Второй — цикл исследования (2-3 гипотезы).

Условие пропуска REFINE: Простые задачи до 50 строк.

Когда использовать: Production-critical код с всесторонним ревью.

/ralph

Описание: Постоянный самоссылающийся цикл выполнения. Оборачивает ultrawork независимым верификатором, который после каждой итерации проверяет критерии завершения. Цикл продолжается, пока все критерии не пройдут или не сработают предохранители.

Постоянный: Да. Файл состояния: .agents/state/ralph-state.json.

Ключевые слова-триггеры:

Язык	Ключевые слова
Универсальные	"ralph"
Английский	"don't stop", "until done", "keep going", "finish everything", "run to completion"
Корейский	"랄프", "멈추지마", "끝까지", "완료될때까지", "끝장내"
Японский	"止まるな", "完了まで", "最後まで", "全部終わらせて"
Китайский	"不要停", "直到完成", "全部完成", "做完为止"
Испанский	"no pares", "hasta completar", "termina todo"
Французский	"n'arrête pas", "jusqu'à complétion", "termine tout"
Немецкий	"hör nicht auf", "bis zur fertigstellung", "alles fertigstellen"

Фазы:

Фаза 0 — INIT: Загрузить предпосылки (context-loading, протокол памяти, протокол судьи). Определить проверяемые критерии завершения (каждый должен быть механически проверяемым — тест проходит, сборка успешна, файл существует). Представить критерии пользователю для подтверждения. Инициализировать сессию с max_iterations: 5.
Фаза 1 — WORK: Выполнить ultrawork (PLAN → IMPL → VERIFY → REFINE → SHIP) как одну итерацию.
Фаза 2 — JUDGE: Независимый верификатор сверяет каждый критерий завершения с фактическим состоянием проекта (запускает тесты, проверяет сборки, верифицирует наличие файлов). Оценивает каждый критерий как PASS/FAIL с доказательствами.
Фаза 3 — DECIDE: Если все критерии PASS → завершить цикл, сгенерировать итоговый отчёт. Если есть FAIL → увеличить счётчик итераций, передать контекст неудачи обратно, вернуться к Фазе 1.
Предохранители: Цикл останавливается, если current_iteration >= max_iterations (по умолчанию 5), или если один и тот же критерий проваливается 3 раза подряд по одной и той же коренной причине (обнаружение застревания).

Ключевое отличие от /ultrawork: Ultrawork — это одноразовый 5-фазный рабочий процесс. Ralph оборачивает ultrawork в цикл повторных попыток с независимым judge, который объективно верифицирует завершение — работа продолжается, пока она действительно не будет сделана, а не просто «отревьюена».

Читаемые файлы: .agents/workflows/ralph/resources/judge-protocol.md, все файлы ultrawork. Записываемые файлы: session-ralph.md (память), логи итераций, итоговый отчёт.

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

Непостоянные рабочие процессы

/plan

Описание: PM-управляемая разбивка задач с API-контрактами.

Триггеры: "task breakdown" (универсальный), "plan" (английский), "계획" (корейский), "計画" (японский), "计划" (китайский).

Шаги: Сбор требований -> Анализ целесообразности -> Определение API-контрактов -> Декомпозиция -> Ревью с пользователем -> Сохранение. Вывод: .agents/results/plan-{sessionId}.json. Выполнение: инлайн.

/exec-plan

Описание: Управление планами выполнения как артефактами репозитория в docs/exec-plans/.

Триггеры: Нет (только явный вызов).

Шаги: Подготовка -> Анализ объёма (оценка сложности: Simple/Medium/Complex) -> Создание плана выполнения (markdown в docs/exec-plans/active/) -> Определение API-контрактов (если кросс-доменное взаимодействие) -> Ревью с пользователем -> Выполнение (передача в /orchestrate или /work) -> Завершение (перемещение в completed/).

Вывод: docs/exec-plans/active/{plan-name}.md с таблицей задач, журналом решений, заметками о прогрессе.

Когда использовать: После /plan для сложных фич, требующих отслеживаемого выполнения с журналом решений.

/brainstorm

Описание: Идеация «сначала дизайн» с 2-3 подходами и документом проектирования.

Триггеры: "brainstorm" (универсальный), "ideate" (английский), "브레인스토밍" (корейский), "ブレインストーミング" (японский), "头脑风暴" (китайский).

Правила: Без реализации до утверждения дизайна. Без кода. YAGNI.

/architecture

Описание: Рабочий процесс архитектуры ПО — диагностика проблем архитектуры, выбор подходящего метода анализа (диагностическая маршрутизация / design-twice / ATAM / CBAM / ADR), сравнение вариантов, синтез мнений заинтересованных сторон и выработка рекомендации, ревью или ADR.

Триггеры: "architecture", "ADR", "ATAM", "CBAM" (универсальные), "architecture review", "architectural tradeoff" (английский), "아키텍처", "설계 검토" (корейский), "アーキテクチャ" (японский), "架构" (китайский).

Шаги: Обрамление решения (новая архитектура / ревью / анализ компромиссов / приоритизация инвестиций / составление ADR) -> Выбор методологии через диагностическую маршрутизацию -> Анализ текущей архитектуры через MCP-анализ кода (get_symbols_overview, find_symbol, find_referencing_symbols) -> Синтез мнений заинтересованных сторон (только когда решение достаточно сквозное, чтобы оправдать затраты) -> Выработка рекомендации с явными допущениями, компромиссами, рисками и шагами валидации -> Передача в /plan, когда требуется реализация.

Правила: НЕ писать код реализации или планы задач в этом рабочем процессе. Передавать в /plan после принятия архитектурного решения. Использовать MCP-инструменты на всём протяжении; не заменять сырыми чтениями файлов или grep.

Когда использовать: Выбор архитектуры системы, решения о границах модулей/сервисов/владения, приоритизация рефакторинга, составление ADR, исследование архитектурной боли (усиление изменений, скрытые зависимости, неудобные API).

/deepinit

Описание: Полная инициализация проекта. Генерация AGENTS.md, ARCHITECTURE.md и базы знаний docs/.

Триггеры: "deepinit" (универсальный), "프로젝트 초기화" (корейский), "プロジェクト初期化" (японский), "项目初始化" (китайский).

/review

Описание: Полный пайплайн QA-ревью: OWASP Top 10, производительность, WCAG 2.1 AA, качество кода.

Триггеры: "code review", "security audit" (универсальные), "review" (английский), "리뷰" (корейский), "レビュー" (японский), "审查" (китайский).

Опциональный цикл исправления с --fix: до 3 итераций.

/debug

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

Триггеры: "debug" (универсальный), "fix bug" (английский), "디버그" (корейский), "デバッグ" (японский), "调试" (китайский).

Критерии запуска субагента: Ошибка в нескольких доменах, объём > 10 файлов, глубокая трассировка.

/design

Описание: 7-фазный рабочий процесс: SETUP -> EXTRACT -> ENHANCE -> PROPOSE -> GENERATE -> AUDIT -> HANDOFF.

Триггеры: "design system", "DESIGN.md" (универсальные), "design", "landing page" (английский), "디자인" (корейский), "デザイン" (японский), "设计" (китайский).

Обязательно: Весь вывод responsive-first (мобильные 320-639px, планшет 768px+, десктоп 1024px+).

/scm

Описание: Conventional Commits с автоматическим разбиением по фичам.

Триггеры: Нет (только явный вызов).

Правила: Никогда git add -A. Никогда не коммитить секреты. HEREDOC для многострочных. Co-Author: First Fluke <our.first.fluke@gmail.com>.

/tools

Описание: Управление видимостью MCP-инструментов.

Триггеры: Нет (только явный вызов).

Группы: memory, code-analysis, code-edit, file-ops.

/pdf

Описание: Конвертация PDF в Markdown с помощью opendataloader-pdf — извлекает текст, таблицы, заголовки и изображения в правильном порядке чтения.

Триггеры: Нет (вызывается явно с путём к входному файлу).

Шаги: Валидация ввода (подтвердить существование файла) -> Определение места вывода (указано пользователем или тот же каталог, что и вход) -> Запуск uvx opendataloader-pdf (установка не требуется) -> Для отсканированных PDF использовать гибридный режим с OCR -> Нормализация вывода через uvx mdformat -> Проверка читаемости и структуры -> Отчёт о проблемах конвертации (отсутствующие таблицы, искажённый текст).

Правила: По умолчанию место вывода — тот же каталог, что и у входного PDF. Никогда не пропускайте шаги. Язык ответа соответствует .agents/oma-config.yaml.

Когда использовать: Конвертация PDF-документов в Markdown для контекста LLM или приёма в RAG, извлечение структурированного содержимого (таблицы, заголовки, списки) из PDF.

/stack-set

Описание: Автоопределение стека и генерация языко-специфичных справочников.

Триггеры: Нет (только явный вызов).

Вывод: Файлы в .agents/skills/oma-backend/stack/.

Навыки vs. Рабочие процессы

Аспект	Навыки	Рабочие процессы
Что это	Экспертиза агента	Оркестрированные процессы
Расположение	`.agents/skills/oma-{name}/`	`.agents/workflows/{name}.md`
Активация	Автоматическая через ключевые слова	Слеш-команды или триггеры
Область	Один домен	Многоэтапный, часто мультиагентный
Примеры	«Создать React-компонент»	«Спланировать -> реализовать -> ревью -> коммит»

Автодетекция: Как это работает

Система хуков

oh-my-agent использует хук UserPromptSubmit, состоящий из:

triggers.json: Маппинг ключевых слов к рабочим процессам для 11 языков.
keyword-detector.ts: Сканирует ввод пользователя и внедряет контекст активации.
persistent-mode.ts: Проверяет активные файлы состояния и подкрепляет постоянный режим.

Поток обнаружения

Пользователь вводит текст
Хук проверяет наличие явной /command
Сканирование по ключевым словам triggers.json
Проверка информационных паттернов
Если информационный — фильтрация (без запуска)
Если действенный — внедрение [OMA WORKFLOW: {name}]
Агент загружает соответствующий файл рабочего процесса

Фильтрация информационных паттернов

Язык	Информационные паттерны
Английский	"what is", "what are", "how to", "how does", "explain", "describe", "tell me about"
Корейский	"뭐야", "무엇", "어떻게", "설명해", "알려줘"
Японский	"とは", "って何", "どうやって", "説明して"
Китайский	"是什么", "什么是", "怎么", "解释"

Исключённые рабочие процессы

Требуют явной /command: /scm, /tools, /stack-set, /exec-plan, /pdf.

Механика постоянного режима

Файлы состояния

.agents/state/
├── orchestrate-state.json
├── ultrawork-state.json
└── work-state.json

Содержат: имя рабочего процесса, текущую фазу/шаг, ID сессии, временную метку и незавершённое состояние.

Подкрепление

Хук persistent-mode.ts внедряет [OMA PERSISTENT MODE: {name}] в каждое сообщение.

Деактивация

Для деактивации скажите «workflow done» (или эквивалент на настроенном языке). Это удаляет файл состояния из .agents/state/, прекращает внедрение контекста постоянного режима и возвращает к обычной работе.

Рабочий процесс также может завершиться естественным образом при выполнении всех шагов и прохождении финального шлюза.

Типичные последовательности

Быстрая фича

/plan -> ревью -> /exec-plan

Сложный проект

/work -> PM планирует -> подтверждение -> агенты -> QA -> исправления -> релиз

Максимальное качество

/ultrawork -> PLAN (4 ревью) -> IMPL -> VERIFY (3 ревью) -> REFINE (5 ревью) -> SHIP (4 ревью)

Отладка

/debug -> воспроизведение -> корневая причина -> исправление -> регрессионный тест -> сканирование

От дизайна к реализации

/brainstorm -> документ -> /plan -> задачи -> /orchestrate -> параллельная реализация -> /review -> /scm

Настройка новой кодовой базы

/deepinit -> AGENTS.md + ARCHITECTURE.md + docs/

Постоянные рабочие процессы​

/orchestrate​

/work​

/ultrawork​

/ralph​

Непостоянные рабочие процессы​

/plan​

/exec-plan​

/brainstorm​

/architecture​

/deepinit​

/review​

/debug​

/design​

/scm​

/tools​

/pdf​

/stack-set​

Навыки vs. Рабочие процессы​

Автодетекция: Как это работает​

Система хуков​

Поток обнаружения​

Фильтрация информационных паттернов​

Исключённые рабочие процессы​

Механика постоянного режима​

Файлы состояния​

Подкрепление​

Деактивация​

Типичные последовательности​

Быстрая фича​

Сложный проект​

Максимальное качество​

Отладка​

От дизайна к реализации​

Настройка новой кодовой базы​

Постоянные рабочие процессы

/orchestrate

/work

/ultrawork

/ralph

Непостоянные рабочие процессы

/plan

/exec-plan

/brainstorm

/architecture

/deepinit

/review

/debug

/design

/scm

/tools

/pdf

/stack-set

Навыки vs. Рабочие процессы

Автодетекция: Как это работает

Система хуков

Поток обнаружения

Фильтрация информационных паттернов

Исключённые рабочие процессы

Механика постоянного режима

Файлы состояния

Подкрепление

Деактивация

Типичные последовательности

Быстрая фича

Сложный проект

Максимальное качество

Отладка

От дизайна к реализации

Настройка новой кодовой базы