/repo-new

Область действия: создать НОВЫЙ репозиторий IWE (экосистемный DS или личное пространство данных) через обязательный гейт имя/данные/владение, с результатом — созданный репозиторий, запись в реестре, развёрнутый скелет. Не входит: расширение существующего репозитория (→ Repo-Touch/Residency Gate); Pack-репозитории (делегировать /pack-new на Шаге 1 и остановиться); одномоментное развёртывание всей структуры 5 семей (это setup.sh / WP-559 — этот скилл обрабатывает один репозиторий за вызов). Роль: R6 Кодировщик выполняет гейт и записи фазы Execute; носитель авторизации Decision Gate по умолчанию — пилот (WP-527 Ф0 п.3, решено round-loop сессией 01.09.2026, зафиксировано STAGING.md S-60) — новая Pack-роль не вводится, self-approval со стороны R6 запрещён.

When to use

• Пилот хочет создать новый репозиторий (экосистемный DS-*/instrument/surface, или личное пространство данных PD-*/MC-*/PACK-*).
• Пилот спрашивает, где и как разместить новый вид данных, а подходящего репозитория ещё нет.
• Автоматизации/CI нужно создать репозиторий по уже одобренной ограниченной политике (пилота в моменте нет).

Preconditions

1. WP Gate precondition. Задача должна быть привязана к согласованному РП в плане недели (этот скилл — продукт WP-527).
2. Карта доменов данных должна быть актуальна. docs/adr/ADR-004-data-domain-map.md + docs/DATA-DOMAINS-REGISTRY.yaml (FMT-exocortex-template) должны существовать и быть читаемы — у скилла нет запасной карты доменов, и он не должен изобретать её.
3. Намерение Pack — немедленный выход. Если запрошенный репозиторий — это Pack, делегировать /pack-new на Шаге 1 и остановиться; не выполнять остаток гейта этого скилла (авторитет там — Pack Creation Gate, не этот).

Известные исключения (не гейтуются этим скиллом)

Инвентаризация 01.09 (WP-527, в авторской рабочей копии): голые вызовы gh repo create/create_repository вне этого гейта. Скилл вызывает LLM-агент, читающий SKILL.md — сырой bash-скрипт его вызвать не может; поэтому найденные каналы — документированные исключения, не кандидаты на переподключение.

• setup.sh (шаг «Create {{GOVERNANCE_REPO}} repo», по умолчанию DS-strategy) — создаёт governance-репозиторий при самой первой установке IWE, до того как у пользователя вообще появляется агент со скиллами. Не может идти через гейт по конструкции (курица-яйцо). Имя задаётся при установке ($GOVERNANCE_REPO), гейт не нужен.
• setup/optional/setup-agent-workspace.sh — опциональный ручной скрипт создания DS-agent-workspace, вызывается после онбординга (гейт уже доступен). Уже самостоятельно пишет REPO-TYPE.md+CLAUDE.md при создании — не переподключён к /repo-new сознательно (переписывать рабочий bash-скрипт на вызов агентского скилла архитектурно не оправдано), задокументирован здесь как известное исключение, не как разрыв.

Algorithm

<!-- Каждый шаг: Input (что должно быть готово), Action (что делает агент), Output (артефакт или состояние). Для multi-step скиллов — прогнать /vdv audit по этой секции перед финализацией. -->

Восемь шагов в трёх фазах (Plan → Decision Gate → Execute) — см. ниже.

Фаза 1 — Plan (без мутаций)

Step 1 — Классифицировать намерение и выбрать путь создания

Input: запрос на создание репозитория; read-only доступ (если доступен) к каталогу/API SpacePlan и memory/repo-type-rules.md.

Action: подтвердить, что это запрос на создание НОВОГО репозитория — если речь о расширении существующего, остановиться и направить в Repo-Touch/Residency Gate. Затем явное ветвление:

• Pack → делегировать /pack-new, стоп.
• Намерение SpacePlan → статус planId: verified устанавливается только после read-only проверки по каталогу, с фиксацией источника и ревизии/fingerprint каталога, по которому проверено; если проверка недоступна — статус planId: unverified, Decision Gate (Step 5) блокируется. Одобрение пилота не подменяет техническую валидацию. Единственный выход из unverified — явная переклассификация в именованный проект с новым согласованным Plan; автоматический downgrade запрещён.
• Именованный проект вне SpacePlan → create_repository(template_type="project") по умолчанию. Для запроса, подпадающего под активную policy-запись machine/repo-new-policies.yaml (Step 5) с известным bounds.repo_class, template_type — конвенция, зашитая в текст ЭТОГО скилла для конкретного repo_class (не поле самой policy-записи — 7 обязательных границ Step 5 её не включают): для repo_class: personal-subscriber — template_type: "notes". Запрет на namespace-shadowing зарезервированных семейных префиксов PD-*, DS-*, PACK-*, MC-* — если только имя не является константой, зафиксированной в самой policy-записи (та же personal-subscriber фиксирует DS-personal-guide).
• Экосистемный DS (governance/instrument/surface) → ручной путь gh repo create; этот скилл только выдаёт чеклист для этой ветки и НЕ автоматизирует её — ни на этом шаге, ни на Execute (Step 7/8 к этой ветке не применяются, см. там).

Output: классифицированное намерение, выбранный путь создания, и (для SpacePlan) явный статус planId: verified | unverified с доказательством проверки при verified.

Step 2 — Определить класс и имя репозитория

Input: классифицированное намерение и путь из Step 1.

Action: сверить класс и предложенное имя с memory/repo-type-rules.md + ADR-004. Принудительный семейный префикс — только для известной семьи репозиториев. Существующее пользовательское имя сохраняется без изменений, если оно не нарушает применимое правило или зарезервированный namespace.

Output: проверенный класс и финальное предложенное имя, с любым ограничением на имя, зафиксированным в Plan.

Step 3 — Разметить данные, затем писатель/владелец/читатели

Input: проверенный класс и предполагаемое содержимое репозитория.

Action, в двух явных подчастях (разделены нарочно, чтобы ни одна не выпала):

• Разметка данных: классифицировать данные по типам 2.1-2.4 (канон — DATA-RESIDENCY.md, источник WP-442: шесть типов всего, из них четыре личных; отдельного типа для диалоговых артефактов нет — личные диалоги/заметки в git-репозитории пользователя укладываются в тип 2.4 «неформализуемая личная практика»). Для диалоговых источников (переписка с ИИ) дополнительно применяется профиль обработки conversation (РП-427 Ф8): отдельные цели согласия, запрет служебного содержимого инструментов по умолчанию, границы объёма/срока хранения, скан секретов и персональных данных — это профиль обработки, не отдельный тип резидентности. Вывести homes/sensitivity/quarantine из DATA-DOMAINS-REGISTRY.yaml. Отдельно проверить карантин «вне оси» (секреты, платёжные данные, чужие PII) по эвристикам WP-483 — это не та же ось, что 2.1-2.4, и её нельзя молча сворачивать в неё.
• Ответственность: явно назвать писателя, владельца и читателей для каждого класса. Для CI/автоматизации — writer = «система», owner = пилот.

Output: декларация размещения данных (включая флаг карантина вне оси) и полное назначение writer/owner/readers.

Step 4 — Решить публичность и состав скелета

Input: класс, декларация данных, назначение ответственности.

Action: решить публичный/приватный СЕЙЧАС, не позже — если публичный, publication-gate в CI обязателен в скелете (прецедент WP-493). Набросать манифест скелета: README-паспорт (класс, назначение — одно предложение простыми словами, домены данных, writer/owner/readers, проекция gate receipt) и заглушку CLAUDE.md.

Output: решение о публичности, требование publication-gate (если публичный), запланированный манифест скелета.

Фаза 2 — Decision Gate

Step 5 — Получить ограниченную авторизацию

Input: полный неизменный Plan из Steps 1-4, без нерешённого planId: unverified.

Action: показать полный Plan носителю авторизации. По умолчанию — пилот, approval_scope: instance. Для CI/автоматизации approval_scope: policy допустим только если политика явно ограничивает ВСЕ из: классы репозитория, namespace имён, privacy, owner (с проверяемым owner_selector, не произвольным аргументом), домены данных, лимит инстанций/период, срок действия. Запрос вне любой из этих границ → STOP, не тихий откат: отчёт с конкретной нарушенной границей и числами (например «usage_log: 50/50 за 90 дней, следующий слот доступен <дата>»), и явный новый вопрос пилоту — продлить/расширить policy (новая запись decision_ref) или инициировать отдельный instance-проход. Вызывающий скилл не переключает scope молча сам.

Хранение и проверка policy (спецификация, WP-527 01.09 — инвентаризация не нашла ни одного живого CI-канала, которому это нужно сегодня; файл создаётся лениво при первой реальной выдаче политики, не провизионируется заранее; первый реальный потребитель — repo_class: personal-subscriber, WP-527 Ф4):

• Файл: <governance-репо>/machine/repo-new-policies.yaml, одна запись на policy_id с полями bounds (все 7 границ), decision_ref (approved_by/decision_session/decision_date/wp_ref — ссылка на решение пилота ВНЕ этого файла; без неё запись самоодобрена агентом, который её же и проверяет) и usage_log (append-only, одна строка на каждый успешно созданный НОВЫЙ репозиторий по этой политике: timestamp + itemized-факт; idempotent-reuse на 409 и неудачные попытки в usage_log не попадают).
• Проверка при каждом запросе: перечитать файл заново (не кэшировать между вызовами), найти policy_id, проверить срок действия, decision_ref присутствует, и что запрошенные namespace/privacy/owner_selector/домены попадают в объявленные границы, посчитать записи usage_log за текущий период и сравнить с лимитом. Любой из этих чеков не прошёл → STOP (см. выше), никогда не fail-open.
• Атомарность (гонка параллельных policy-исполнений): чтение usage_log, сравнение с лимитом и последующая дозапись после Execute — под тем же файловым локом, что уже используется для shared-файлов governance-репо (gateway-lock.py acquire <файл политики> на время check+write, release сразу после). Без лока два параллельных запроса, оба прошедших чтение до того, как любой записал свой факт, могут вместе превысить лимит.
• После успешного Execute (Step 7) — дописать факт в usage_log той же политики (внутри того же лока).

Output: явное одобрение или отказ с approval_scope: instance | policy. Исполнение остаётся заблокированным, если одобрение не покрывает именно этот Plan.

Step 6 — Зафиксировать gate receipt

Input: одобренный, неизменённый Plan и решение об авторизации.

Action: создать machine-readable gate receipt со следующими полями — список не сокращать, каждое поле несёт нагрузку для аудита:

approved_by: pilot | <policy_id>
approved_at: <ISO-8601 timestamp>
approval_scope: instance | policy
request_fingerprint: <stable id/hash запроса>
plan_fingerprint: <stable id/hash полного Plan из Steps 1-4>
wp_ref: WP-527

Receipt ссылается на неизменный полный Plan, сохранённый в исходной WP/сессии, по fingerprint — не заменяет и не пересказывает Plan. README и запись в реестре получают на Step 8 проекцию этого receipt, а не полный набор полей: проекция сохраняет approved_by, approved_at, approval_scope, wp_ref — человеку эти четыре поля дают понимание «кто/когда/как/по какому РП», а request_fingerprint/plan_fingerprint остаются только в исходной записи (WP/сессия), где и находится полный Plan для машинной сверки; дублировать их в человекочитаемый паспорт незачем.

Output: gate receipt, привязанный к точному авторизованному Plan; разблокирует Фазу 3.

Фаза 3 — Execute (только после действительного gate receipt)

Step 7 — Создать и зарегистрировать репозиторий

Input: действительный gate receipt, путь создания из Step 1, финальное имя репозитория из Step 2 — кроме ветки «экосистемный DS», для которой Execute (Step 7/8) не выполняется этим скиллом: агент передаёт пилоту/R6 итоговый чеклист (класс, имя, разметка данных, writer/owner/readers, gate receipt) и останавливается ДО этого шага, сама команда gh repo create и последующая регистрация выполняются вручную по этому чеклисту, не автоматически скиллом.

Action (для остальных трёх путей — Pack уже вышел на Step 1, значит здесь SpacePlan и именованный проект): создать репозиторий через выбранный путь (SpacePlan MCP-вызов / create_repository). При успехе зарегистрировать его в 0.OPS/REPOSITORY-REGISTRY.md своего ecosystem-development репозитория, если он есть — эту запись выполняет агент, не пилот (намеренное разделение с Decision Gate: пилот авторизует, R6 исполняет). Нет такого репозитория → пропустить регистрацию, записи неоткуда взяться. Исключение — bounds.repo_class активной policy равен personal-subscriber (или любому будущему классу с тем же свойством «персональный репозиторий подписчика, не инфраструктура экосистемы»): регистрация в REPOSITORY-REGISTRY.md не выполняется — тот реестр про инфраструктуру самой экосистемы; учёт per-подписчика уже ведётся через github_status/personal_list_sources, дублирование не нужно.

Конфликт имени (409): reuse существующего репозитория разрешён только после проверки, что он одновременно (а) принадлежит owner из авторизованного Plan (не просто совпадение имени), (б) private совпадает с Plan, (в) не противоречит ожидаемой сигнатуре template_type (например, для notes — структура inbox/, docs/, README.md). Не совпало хотя бы одно (типичный случай — старый репозиторий с другим значением private, созданный до текущей policy) → STOP, reuse запрещён, отдельная задача миграции — не решается этим скиллом молча.

Output: созданный (или безопасно переиспользованный) репозиторий и запись в реестре (кроме исключения выше), либо зафиксированное частичное состояние при сбое любой из операций.

Step 8 — Развернуть скелет и завершить

Input: созданный репозиторий, состояние реестра, манифест скелета, решение о публичности, gate receipt. Не применяется к ветке «экосистемный DS» (см. Step 7).

Action: развернуть README-паспорт (с проекцией gate receipt), заглушку CLAUDE.md, и publication-gate в CI, если публичный — только на пути реального создания Step 7. На пути безопасного 409-reuse (Step 7) скелет НЕ разворачивается заново: у переиспользуемого репозитория уже есть собственные README/CLAUDE.md, слепая перезапись затёрла бы то, что там реально накопилось. При сбое любой операции фазы Execute — немедленно остановиться и сообщить точно, что создано, а что нет; не пытаться автоматически откатывать — неудачный откат это вторая неавторизованная мутация поверх первого сбоя.

Output: инициализированный репозиторий с обязательным скелетом governance, либо явный отчёт о частичном сбое со списком завершённых и незавершённых артефактов.

Bundled resources

• assets/repository-skeleton/README.md — шаблон README-паспорта, используется на Step 8 (плейсхолдеры для класса, назначения одной строкой, доменов данных, writer/owner/readers, проекции gate receipt).
• assets/repository-skeleton/CLAUDE.md — минимальная заглушка CLAUDE.md, разворачивается на Step 8, чтобы Repo-Touch Gate не встретил пустой репозиторий.

Anti-patterns

• Не позволять ветке SpacePlan на Step 1 трактовать planId: unverified как «наверное, нормально» — неподтверждённый план блокирует Decision Gate полностью, без обхода пилотом кроме явной переклассификации.
• Не сворачивать карантин «вне оси» (секреты, платёжные данные, чужие PII) в обычную проверку размещения 2.1-2.4 на Step 3 — это разные оси с разными последствиями.
• Не позволять одобрению Decision Gate пилотом одновременно засчитываться за шаг записи в реестр — запись реестра на Step 7 всегда выполняет агент, никогда не считать её «уже сделанной», потому что пилот сказал «да».
• Не пытаться автоматически откатывать частичный сбой Step 7/8 — сообщить и остановиться.
• Не выдавать approval_scope: policy без всех семи обязательных границ (классы, namespace, privacy, owner, домены данных, лимит инстанций/период, срок действия) — частичная политика не политика, а неограниченное разрешение с лишними шагами.
• Не выполнять Step 7/8 (создание, регистрация, скелет) для ветки «экосистемный DS» — там скилл выдаёт только чеклист, исполнение ручное.

Verification

bash .claude/skills/skill-creator/scripts/verify-skill.sh repo-new

Ожидается: PASS по всем структурным проверкам (поля frontmatter, поля gates, наличие секций ## When to use / ## Algorithm, существование bundled resources). У этого скилла пока нет verification_class выше closed-loop структурных проверок — живой смок-тест с реальным созданием репозитория — это WP-527 Ф3 («обкатка на первом реальном создании репо»), не часть этого файла.