Repo New

---
name: repo-new
description: |
  Гейт создания любого нового репозитория IWE (экосистемного или личного пространства). Проводит запрос через: классификацию намерения (Pack / SpacePlan / именованный проект / экосистемный DS), проверку имени и класса, разметку данных (типы 2.1-2.6, карантин), объявление писатель/владелец/читатели, решение о публичности, обязательный Decision Gate (по умолчанию — одобрение пилота, для CI — ограниченное делегирование), затем исполнение (создание, регистрация, развёртывание скелета). Используй когда пилот хочет создать новый репозиторий, или спрашивает, куда и как разместить новый вид данных. Не для расширения существующего репозитория (→ Repo-Touch/Residency Gate) и не для Pack-репозиториев (делегируется `/pack-new`).
version: 0.2.0
status: experimental
layer: L2
agents: single
interaction: multi-step
gates_required: [wp]
gates_enforced: []
gates_rationale: "wp — создание нового репозитория: нетривиальный артефакт (>15 мин) с долгоживущими последствиями (имя, размещение данных, запись в реестр), требует согласованного РП до скаффолда. Сам скилл И ЕСТЬ инстанцирование IntegrationGate для рождения репозитория (обещание+сценарии+роль уже решены в WP-527); дополнительно Routing/IntegrationGate на собственный вызов не накладывает. IntegrationGate hard-check самого /skill-creator (Step 3 — поиск DP.SC.*/DP.ROLE.* в Pack) пропущен при создании 01.09.2026 (зафиксировано как косяк агента), затем решён этой же сессией: специальной Pack-записи для 'рождения репозитория' нет и не создаётся, пока скилл в status: experimental/testing — формализация в Pack откладывается до промоции в шаблон (тот же порядок, что у vdv/bottleneck-pick), не блокирует обкатку."
triggers:
  slash:
    - repo-new
  phrases:
    - создай репозиторий
    - новый репозиторий IWE
---

# /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 DS-strategy repo») — создаёт governance-репозиторий при самой первой установке IWE, до того как у пользователя вообще появляется агент со скиллами. Не может идти через гейт по конструкции (курица-яйцо). Имя фиксировано, гейт не нужен.
- **`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 (+2.5/2.6 для диалоговых артефактов, где применимо); вывести `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 со следующими полями — список не сокращать, каждое поле несёт нагрузку для аудита:
```yaml
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`). При успехе зарегистрировать его в `DS-ecosystem-development/0.OPS/REPOSITORY-REGISTRY.md` — эту запись выполняет агент, не пилот (намеренное разделение с 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
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 («обкатка на первом реальном создании репо»), не часть этого файла.