Пакет связывает методологию BMAD (фазы от анализа до кода) с репозиторием результатов BLAGOROST (Markdown + GitHub) и русским контекстом. Скиллы подсказывают агенту, куда писать файлы и какую роль играть, чтобы артефакты потом нормально импортировались в систему.

Классическая цепочка BMAD (концептуально)

В жизни проектов шаги сжимают, переставляют или пропускают; ниже — идеальный скелет: зачем каждая роль и что именно она передаёт следующей (всё в каноне c9s: сначала issues/*.md на шаг работы, затем текст — в requirements/*.md как story, плюс обновления project.md / component.md при уточнении видения).

1. Аналитик (analyst) и при необходимости CIS (creative-intelligence)
Зачем первыми: до «что строим» нужно понять проблему, пользователя, контекст, ограничения и гипотезы — иначе PRD и архитектура будут про несуществующую задачу.
Что формируют: задачи под шаг («исследование…», «бриф…») и story в requirements/: бриф, заметки интервью, исследование рынка/конкурентов, формулировка проблемы, гипотезы ценности. CIS добавляет варианты идей, SWOT, мозговой штурм — тоже через задачу и story, если это отдельная смысловая сессия.
Передача PM: не «сырой чат», а согласованный слой смысла в файлах: кто страдает, от чего, что уже пробовали, какие допущения, какие открытые вопросы. PM опирается на это, чтобы не выдумывать требования в вакууме.

2. PM (pm), параллельно или следом — UX (ux-designer)
Что получает от аналитики: проблему, контекст, гипотезы (и при необходимости — идеи из CIS).
Что формирует: задачи «Подготовить PRD…», «Техспека…» и сами story в requirements/: PRD (цели, scope, приоритеты, риски в продуктовой логике), техспека на уровне «что система должна уметь» без привязки к конкретным сервисам. UX — задачи на сценарии, CJM, потоки (текст/diagram в story), критерии доступности; пересечение с PM: продуктовые формулировки и границы опыта.
Передача архитектору / см: что должно получиться для пользователя и бизнеса, в каком порядке важнее, какие нефункциональные ожидания уже видны (без детальной внутренней схемы).

3. Архитектор (architect)
Что получает: утверждённое или черновое видение из PRD/техспеки и UX (границы возможностей, интеграции на словах).
Что формирует: задачу на архитектурный срез и story с границами системы, компонентами, потоками данных, ADR, схемами (MERMAID и т.д. по FORMAT). Здесь отвечают на «как это устроено внутри», сохраняя совместимость с тем, что уже решили PM/UX.
Передача см / разработке: картина для декомпозиции на работы и оценки рисков реализации (что тянуть первым, где неопределённость).

4. Scrum Master (scrum-master)
Что получает: бэклог смысла из предыдущих фаз (часто уже есть черновые issues от PM).
Что формирует: цели спринта (в т.ч. через .c9s/sprint-status.yaml), уточнение формулировок задач, готовность к разработке (todo / in_progress, estimate: 0 по политике c9s, если не оговорено иное).
Передача developer: issues с полным телом под один сеанс выполнения, ссылки на нужные requirements/*.md.

5. Developer (developer)
Что получает: конкретную задачу и связанные требования.
Что формирует: код в монорепозитории, обновления в issues/*.md (итог в теле, in_progress до команды оператора); on_review — только после /c9s-submit-for-review; не дублирует продуктовую прозу в .c9s/.

Связка цепочки: analyst / CIS → pm (+ при необходимости ux-designer) → architect → scrum-master → developer. Переходы фиксируйте через /c9s-status и workflow-status.yaml, чтобы следующий сеанс знал фазу; при малом объёме несколько ролей может взять один сеанс, но артефакты и задачи лучше не смешивать без явной пометки в файлах.

С чего начать (минимум для теста)

Установите скиллы и команды из корня репозитория claude-code-bmad-skills:
- macOS/Linux: ./install-v6.sh
- Windows: .\install-v6.ps1
  В ~/.claude/ после ./install-v6.sh: v6 — skills/bmad/, c9s — skills/bmad-c9s/, команды-обёртки — commands/bmad/, конфиг и шаблоны — config/bmad/ (в т.ч. bmad-v6-bundle/commands/ — полные тексты команд v6).
Откройте в IDE репозиторий результатов (тот, где лежит дерево results/ или тестовый клон) — либо сам claude-code-bmad-skills, если гоняете только методологию на пустой заготовке.
Скопируйте конфиг
bmad-c9s/config/c9s-config.template.yaml → в корень репозитория результатов как c9s-config.yaml и заполните:
- results_root — абсолютный путь к корню клона с results/
- active_project_slug — имя папки проекта первого уровня под results/ (как в Capital)
- coopname, username — для новых issues/*.md в frontmatter: created_by, submaster, creators (см. TASKS-DOCUMENTS-TIME-POLICY.md §1)
Перезапустите Claude Code (или Cursor с подключёнными скиллами), откройте проект с c9s-config.yaml.
Первый запрос к агенту (выберите формулировку):
- Вызов команды: /c9s-init
- или: «Инициализируй bmad-c9s по c9s-config.yaml»
  Агент должен опереться на скилл bmad-master-c9s, создать {кореньАктивногоПроекта}/.c9s/ (операционка), стартовый workflow-status.yaml и при необходимости пустой requirements/ для будущих story.
Проверка состояния: /c9s-status — должен показать пути, фазу и какой скилл логично включить дальше.

Главная точка входа в методологию — скилл bmad-master-c9s. Остальные скиллы — «роли» по фазам; без конфига и .c9s/ оркестратору не за что зацепиться.

Что вы получите после инициализации

Что	Где	Зачем
`c9s-config.yaml`	корень репозитория результатов	Пути к `results`, slug проекта, идентификаторы
`.c9s/workflow-status.yaml` (и при необходимости другие YAML)	внутри папки активного Capital-проекта	Только операционка BMAD: фазы, спринт — не текст требований
*`requirements/.md`**	`{base}/requirements/`	Все содержательные артефакты: бриф, PRD, техспека, мозговой штурм, UX — как story (`type: story`, `content_format`, frontmatter по FORMAT)
Задачи (dev-единица, контекст в теле)	`issues/*.md`	Канон Capital; без подпапок `*-requirements/`
`project.md` / `component.md`	под `results_root`	Описание проекта/компонента

Правило: агент создаёт story в requirements/ и ведёт их до реализации (обновляет текст и updated_at); цикл «сформулировал требование → реализовал» идёт по этим же файлам и связанным issues/. Длинные списки — только в .md, не в чате.

Скиллы и когда их звать

Скилл (папка)	Когда использовать
bmad-master-c9s	Старт, `/c9s-init`, `/c9s-status`, «с чего начать», смена фазы
c9s-master-review	Только роль мастера: задача в `on_review` → `done` (исполнители не ставят `done`)
c9s-submit-for-review	Оператор: явная команда → задача `on_review` + commit/push (агент не ставит ревью сам)
analyst	Фаза 1: проблема, бриф, исследование
creative-intelligence	Фаза 1: мозговой штурм, идеи, SWOT
pm	Фаза 2: PRD, приоритеты, tech-spec в контексте плана
ux-designer	Фаза 2: сценарии, UX, доступность
architect	Фаза 3: архитектура, границы, схемы (mermaid и т.д. в разрешённых местах)
scrum-master	Фаза 4: спринт, разбиение, истории
developer	Фаза 4: реализация (код — в монорепе, не в `results`)
builder	Мета: новые скиллы/шаблоны под c9s

В Cursor можно явно написать: «Следуй скиллу bmad-master-c9s» или «Роль analyst из bmad-c9s».

Сценарии использования

Сценарий A — Первый прогон «с нуля»

Заполнить c9s-config.yaml.
/c9s-init.
/c9s-status — убедиться, что фаза и пути верные.
Сформулировать цель (например: «Опиши проблему и гипотезы для фичи X») и работать через analyst / creative-intelligence по политике c9s: сначала задача issues/*.md, затем story в requirements/{slug}.md (не только проза в requirements/ без issue).
Дальше — pm / architect дополняют или дробят story и задачи по FORMAT; импорт в Capital проверяется по каноническим путям.

Сценарий B — Уже есть проект в `results/`

Проверить, что active_project_slug совпадает с папкой проекта.
/c9s-init (добавит .c9s/ и при отсутствии — requirements/, не ломая существующие md).
/c9s-status → дальше по рекомендованной фазе (часто pm или architect).

Сценарий C — Только методология, без реального Capital-дерева

Временно задать results_root на любую папку и создать минимальную структуру вручную или завести requirements/ и писать story даже без полного дерева Capital.
Иметь в виду: без канонических путей импорт в Capital не проверить — это режим «отладка промптов и скиллов».

Сценарий D — От агента к мастеру (два шага)

Агент закончил черновик — задача остаётся в in_progress (оператор читает PRD, правит вручную, просит доработки и т.д.).
Когда оператор готов передать задачу мастеру: явная команда (/c9s-submit-for-review, «отправь задачу … на ревью») → агент ставит on_review, updated_at, commit/push в results (TASKS-DOCUMENTS-TIME-POLICY.md §2).
Мастер вызывает c9s-master-review: done или возврат в in_progress.

Команды (slash)

Файлы в commands/ — короткие сценарии; полная логика в соответствующих SKILL.md.

Команда	Скилл	Назначение
`/c9s-init`	bmad-master-c9s	Конфиг, `.c9s/` (YAML), при необходимости каталог `requirements/`
`/c9s-status`	bmad-master-c9s	Сводка и рекомендация следующего скилла
`/c9s-submit-for-review`	c9s-submit-for-review	Оператор: задача → `on_review` + commit/push (не автоматически после агента)
`/prd`, `/architecture`, `/create-story`, …	роли BMM и др.	Как в BMAD v6, но с опорой на c9s и русские обёртки

Подробные англоязычные тексты команд — в bmad-v6/commands/ (эталон, не менять в рамках c9s).

Документация рядом

Файл	Содержание
CLAUDE.md	Обзор пакета, таблица фаз, правила хранения
FORMAT-CAPITAL-GITHUB.md	Канон путей и frontmatter
utils/helpers-ru.md	Разрешение корня проекта, `updated_at`, hash
commands/_README.md	Общие шаги перед работой по командам

Частые вопросы

Почему агент «не знает», куда писать?
Нет c9s-config.yaml в корне открытого проекта или не вызван /c9s-init — оркестратор не привязан к дереву.

Можно ли обойтись одним скиллом?
Для навигации и инициализации — да, bmad-master-c9s. Для качественной роли (архитектор, PM) лучше явно переключать скилл фазы.

Где эталон BMAD на английском?
Каталог bmad-v6/ в родительском репозитории — только справка; рабочая логика для Coopenomics — в bmad-c9s/.

Удачного теста: /c9s-init → /c9s-status → одна короткая задача для analyst с новым файлом requirements/brief-*.md (полный frontmatter story по FORMAT).

README.md Unescape Escape

BMAD-c9s — как пользоваться