| name | charter |
| description | Родить новый проект по канону Огорода — собрать стартовую документацию (brief/RFC, карточка с JTBD, roadmap, пустые decisions/scenarios) ДО первой задачи. Используй для greenfield «с нуля»; триггеры — «заведи новый проект», «начни проект X», «charter», «рождение проекта». Для уже существующего кода без доки — это onboard, не charter. |
| user_invocable | true |
charter
Greenfield-вход: проекта ещё нет, есть замысел. charter фиксирует замысел как
канон до первой задачи — чтобы проект не родился голым (как бывает, когда
внешний агент строит код без брифа, метрик и фаз). Самодостаточно: можно дать
любому агенту.
Двойник onboard: тот поднимает канон существующего проекта из артефактов и кода
(человек-SME последним); charter — наоборот, владелец-замысел первый источник,
потому что фиксировать пока нечего, кроме намерения.
Гейт рождения: проект не считается заведённым, пока нет трёх артефактов —
brief.md, карточка <slug>.md (с audience и jtbd), roadmap.md. Первая задача
создаётся только после них.
Шаг 0 — прочитай правила и канон
Прочитай в корне vault: _rules.md (методология), docs/doc-canon.md (состав
документации по зрелости проекта: секции «Артефакты жизненного цикла» и «Состав по
статусу»), docs/styleguide.md (как писать — без воды, под адресата). Стартовый
набор, который ты собираешь, — это уровень status: idea из «Состава по статусу».
Принцип: замысел — первый источник, но не выдумка
Бриф собирается из того, что владелец уже сказал или написал. Чего для брифа
не хватает — спроси у владельца коротко и точечно (рождение проекта — единственное
место, где владелец-источник первый; это не «вопрос по задаче»). Чего владелец не
знает сейчас — не выдумывай: оставь явный пробел > TODO: <вопрос> и не выдавай
догадку за решение. Метрики и фазы без основания не сочиняй — лучше пробел.
Шаги
- Собери замысел. Из сказанного владельцем извлеки: проблема и чья она;
зачем сейчас (цена бездействия); аудитория (роль/тип, не «человек, который
хочет…») и её JTBD («когда я …, хочу …, чтобы …»); метрики успеха; крупные
фазы; границы (не-цели); риски. Пробелы — точечный вопрос владельцу или
TODO.
- Выбери slug и статус.
slug — латиница, kebab-case, в -ush-семье если
уместно (см. как названы существующие проекты). status обычно idea. Проверь,
что папки projects/<slug>/ ещё нет.
- Создай
brief.md (RFC) из _templates/docs/brief.md: проблема, зачем,
аудитория+JTBD, метрики (таблица), фазы (список → детали уйдут в roadmap),
границы, риски. Статус брифа — draft. Это застывший замысел; текущее состояние
дальше живёт в карточке.
- Создай карточку
projects/<slug>/<slug>.md из _templates/project.md:
frontmatter status/type/priority/audience/jtbd; тело — Суть, ЦА и
боль, Видение (из замысла). Топ-задача пока пустая (появится после первой задачи).
- Создай
roadmap.md из _templates/roadmap.md: фазы из брифа как ## Фаза N — … с **Цель:** и пунктами - [ ]. Бриф и roadmap согласованы по фазам.
- Создай пустые
decisions.md и scenarios.md из шаблонов _templates/docs/ —
с APC-шапкой и заголовком, готовые к наполнению (наполнятся на active, когда
появятся решения и smoke). Не выдумывай записи на старте.
- Заведи каркас задач: папка
projects/<slug>/tasks/ (+ tasks.md-индекс при
принятой конвенции). Первые задачи — через backlog (RICE, роли, грейд), после
того как brief+карточка+roadmap на месте.
- Зафиксируй в vault: если vault — git, закоммить стартовый набор (только файлы
нового проекта — перечислением путей, не
git add -A).
Границы
charter поднимает стартовый каркас уровня idea, не финальную доку.
architecture.md, наполненные scenarios.md/decisions.md, runbook появляются по
мере роста (active+) обычным циклом — см. «Состав по статусу» в doc-canon.md.- Метрики/фазы фиксируются, а не угадываются: непонятное —
TODO, не пух.
Самопроверка
