Project Creator

Создание проекта в vault

Ты создаёшь новый проект в 01_now/projects/ и всю стартовую документацию: plan.md, tasks.md, context.md, log.md, README.md, и обновляешь индексы. План и всю документацию ты пишешь сам — по методологии автономного планирования LLM-агентом. Это главная гарантия скилла: владелец получает готовый проект, а не пустой бриф с просьбой заполнить.

Главное правило

Агент сам составляет проектную документацию. Нельзя просить владельца написать план, пункты плана, критерии качества, рубежи или проверить план построчно. Уточняющие вопросы разрешены только тогда, когда без ответа нельзя безопасно выбрать основу проекта (цель, контур, границы, цена ошибки, источник правды). Всё остальное агент выводит из чата, команды и локальных правил и фиксирует как допущение.

Обоснование: методология планирования для LLM-агента и Правило 12 в AGENTS.md.

Что прочитать перед работой

Устойчивые источники правды (не полагайся на память модели):

• Методология планирования для LLM-агента — как писать план против дрифта.
• Шаблон plan.md — канонические секции контракта проекта.
• Инструкция восстановления намерения — как понять недосказанное.
• Протокол записи — frontmatter, ссылки, обновление индексов.
• Task routing — что в plan.md, что в tasks.md, что вне проекта.

Требуется доступ к файлам

Скиллу нужен доступ на запись в vault. В Cowork: подними целевые пути через device-tools, собирай файлы в рабочей папке и записывай на диск владельца через device_commit_files. В Claude Code / локальном агенте: пиши файлы напрямую. Если доступа к файлам нет — не выдумывай, попроси владельца подключить папку vault.

Два сценария входа

Определи сценарий по формулировке владельца и состоянию чата.

A. Проект рождается из текущего чата

Триггеры: «зафиксируй это как проект», «оформи это в проект», «сделай из этого проект», «давай заведём под это проект».

Перед любым вопросом извлеки контекст из уже прошедшей беседы и собери из него бриф:

• Цель — какой результат обсуждали, что должно измениться в мире.
• Идея и суть — что за инициатива, почему она возникла.
• Принятые решения — к чему уже пришли в чате.
• Ограничения и не-цели — что явно исключили или чего избегать.
• Открытые вопросы — что осталось нерешённым.
• Обсуждённые материалы — ссылки, файлы, данные, звучавшие в беседе.
• Предполагаемый контур — к какому направлению относится (по именам, продуктам, доменам из чата).
• Причина отдельного проекта — почему это выделяется в самостоятельный контур, а не строка в существующем.

Запрещено начинать с пустого брифа и запрещено просить владельца заново пересказать то, что уже есть в чате. Извлечённый бриф становится сырьём для Goal, Intent Lock, context.md и первой записи log.md.

B. Проект создаётся с нуля

Триггеры: «создай проект X», «начни проект про Y», «новый проект по Z».

Восстанови намерение из команды, локальных правил и доступного контекста vault (README контуров, соседние проекты). Если данных достаточно для безопасного выбора основы — сразу пиши документацию. Если нет — задай один короткий пакет уточнений (см. ниже).

Правило вопросов (бюджет)

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

• Один пакет за раз, максимум три коротких вопроса.
• Каждый вопрос содержит рекомендуемый вариант агента и формулируется как «подтверди или поправь», а не «напиши за меня».
• Формат: «Я понял цель так: … . Предлагаю А, потому что … . Б имеет смысл, если важнее … . Подтверди или поправь.»
• Нельзя просить владельца писать план, критерии, рубежи; нельзя показывать внутренний чеклист; нельзя объявлять театральную роль.

В Cowork используй инструмент множественного выбора, если он доступен; в неинтерактивном режиме задай пакет обычным текстом. Развилка контуров при неоднозначности — обязательна (Правило 6).

Процедура

Шаг 1. Проверь, что это действительно новый проект. Проект — инициатива с ясным результатом, ограниченным горизонтом и точкой закрытия. Проверь правило владельца данных из AGENTS.md: если это долговременный реестр контура — место в 01_now/ops/<contour>/, сырой импорт — в 00_inbox/, переносимая методология — в 03_knowledge/, а не новый проект. Если контур неоднозначен — останови и спроси, не угадывай.

Шаг 2. Определи год, контур и slug. Год — текущий (узнай через date +%Y, не из памяти). Slug — kebab-case латиницей, описывает суть результата, без дат внутри. Префикс контура включается, если проект принадлежит известному направлению. Путь папки:

01_now/projects/<год>-<slug>/ — например YYYY-demo-product-positioning-strategy, YYYY-sample-trip.

Шаг 3. Выбери режим проекта. operational — ресёрч, анализ, контент, координация, knowledge-work. development — код, скрипты, тесты, schema/data contracts, runtime. Режим пишется в frontmatter plan.md и строкой в tasks.md. Для development дополнительно нужны артефакты dev-протокола (AGENT_WORKFLOW.md, TEST_PLAN.md, RELEASE_CHECKLIST.md, CHANGELOG.md, INCIDENT_RUNBOOK.md) из meta/templates/ — см. dev-protocol; их создание не заменяет пять базовых файлов.

Шаг 4. Восстанови намерение молча (пять вопросов себе): что явно попросили; какой практический результат нужен; какие ограничения видны из контекста; что можно закрыть безопасным предположением; где ошибка предположения сломает результат и нужен вопрос. Разбор владельцу не показывай.

Шаг 5. При необходимости — один пакет вопросов по правилу бюджета. Иначе пропусти.

Шаг 6. Напиши plan.md. Полная процедура и разобранный пример: references/plan-authoring.md. Секции (Правило 12): Goal, Intent Lock, Owner Interaction Policy, Non-goals, Appetite, Source of truth, Milestones (каждый с Acceptance и статусом), Quality Criteria, Blockers (пусто), Blockers — Resolved (пусто), Drift Guard, Contingency, Review Protocol. Цель — как изменение состояния мира, не как список действий агента. Критерии качества и рубежи формулируешь ты.

Шаг 7. Напиши context.md, tasks.md, log.md, README.md. Шаблоны и заполненные примеры: references/starter-files.md. Кратко: context.md — только устойчивые инварианты; tasks.md — производная очередь текущего рубежа из plan.md: Current Milestone, один Active-шаг, локальные Exit Criteria, Drift Guard (short), Next; log.md — первая запись о создании проекта (дата + 3–7 буллетов); README.md — точка входа со ссылками на служебные файлы.

Шаг 8. Обнови индексы. Зарегистрируй проект в 01_now/README.md и убедись, что новая LLM-сессия найдёт его через корневую навигацию. Если в твоём хранилище есть отдельный 01_now/projects/README.md, обнови и его. Снипеты правок: references/starter-files.md. Порядок слоёв записи — по write-protocol §5.

Шаг 9. Проверки и короткий отчёт. Прогони чеклист ниже, затем ответь владельцу коротко: где проект, что в плане, какой первый шаг, какие допущения принял.

Создаваемые файлы

Плюс правки: 01_now/README.md; если в конкретном хранилище есть отдельный индекс проектов, обнови и его.

Проверки перед завершением

• У каждого .md есть frontmatter по write-protocol: id, type, status, created, updated, aliases (≥1 русский), tags, source_path. Дата created/updated — сегодняшняя (через date +%F).
• plan.md содержит все секции Правила 12, включая заполненные Intent Lock, Owner Interaction Policy, Quality Criteria; Blockers и Blockers — Resolved пусты.
• Goal сформулирован как изменение состояния мира, а не как «сделать N действий».
• В tasks.md объявлен Task Mode, указан Current Milestone из plan.md, ровно один Active-шаг, есть локальные Exit Criteria и Drift Guard (short), нет Goal/Milestones/Quality Criteria/Blocked.
• context.md не содержит эпизодику и хронику — только инварианты.
• Первая запись log.md — короткая (3–7 буллетов), без складирования контента.
• Все внутренние ссылки — кликабельные относительные .md, глубина путей проверена.
• Проект зарегистрирован в 01_now/README.md; новая LLM-сессия найдёт его через цепочку README → plan → context.
• Владельцу не задан ни один запрещённый вопрос (написать план/критерии/проверить построчно).

Антипаттерны

• Пустой бриф и просьба к владельцу заполнить план или критерии — прямое нарушение главного правила.
• В сценарии A — просьба пересказать то, что уже есть в чате.
• Театральная роль, показ внутреннего чеклиста, микросогласования по каждому пункту.
• Goal/Milestones/Contingency/Quality Criteria в tasks.md; блокеры в tasks.md (они — в plan.md §Blockers).
• Угадывание контура при неоднозначности вместо одного вопроса (Правило 6).
• Создание проекта под данные, чей дом — ops/, 00_inbox/ или 03_knowledge/ (Правило 2а).
• Английский жаргон без перевода в ответах владельцу (Правило 6а); имена секций плана остаются как есть.

Ссылки

• references/plan-authoring.md — как автономно писать plan.md + пример.
• references/starter-files.md — шаблоны README/context/tasks/log и снипеты индексов.
• references/worked-examples.md — два сквозных примера: из чата и с нуля.