/init

name: init
description: Stand up a kraken coordination repo end to end — verify or create the private repo, install the bundled task template, remove everything an earlier release installed to be executed server-side, and create the canonical labels. Strictly setup, the write-side twin of status's read-only console; it reads and writes no issues.

Kraken — raise the head

You are the setup step for kraken: given a coordination-repo slug, you make that repo ready to receive tasks — the private repo exists, the task template is committed, everything an earlier release installed to be executed there is deleted, and the state-machine labels are created. Under `kraken-protocol/9` the coordination repo runs nothing of its own, so it needs no GitHub Actions and carries no copy of the transition program. This is the symmetric partner to `status` (the read-only console): `init` builds the queue, `status` reads it. You touch no issues — none read, none written.

Invocation

/kraken:init OWNER/tasks [--project <name>]

The prefix is the harness's spelling (Pi: `/skill:init`); the arguments are the same everywhere.

The `OWNER/tasks` argument is REQUIRED — the coordination repo to stand up. Missing? Do not guess. Ask for it and stop.

A slug that is still the doc placeholder (`OWNER/...`, or anything wearing `<`/`>`) is refused by the program itself, before any read or write: substitute your real `owner/repo` and re-run.

When the repo does not exist yet, `init` creates it under the account the token authenticates as — so if that account is not the slug's owner, it refuses (exit 2) and names both, instead of creating a repo nobody asked for. Relay that message: the operator switches account (`gh auth switch`) or creates the repo under the owner first, then re-runs.

`--project <name>` is optional. When passed, also create the `project:<name>` label so the first project is ready to queue against.

There is no repair flag, and no version handshake between the plugin and the coordination repo: under `kraken-protocol/9` the repo holds no copy of the transition program, so there is no second copy to fall out of date.

Design decisions

• **The mechanics live in `kraken.py init`, not in this prose.** Standing a repo

up — verify-or-create it private, install the bundled assets, upsert the canonical labels — is deterministic, zero-judgment work, so it is executed by the bundled `kraken.py` (the same program `unleash` and `status` use), once, identically, token-free, and testable against the conformance stub. This skill only invokes it, renders its report, and prints the settings reminder. Same rule that produced `claim-next` and `status`.

• **Assets ship in the plugin, never fetched from the network.**

`task-template.yml` lives in this plugin's `skills/unleash/` folder — `kraken.py init` reads it from there and commits it via the GitHub contents API. The bundled copies match the installed plugin version and work offline. Never `curl` from `raw.githubusercontent.com`.

• **Idempotent and non-destructive by construction.** `kraken.py init` creates

the repo only if absent, creates each asset only if absent, and upserts the labels with their canonical color/description. An existing file is reported `present` and left exactly as it is. Re-running is safe.

• **Nothing installed is executed, so nothing has to stay in sync.** The one

asset is an issue form — it shapes a task on the way in and runs no code. A template the operator tuned is their business, not drift to police, which is why there is no `--upgrade`, no byte comparison and no refusal path.

• **Re-running init is the migration.** A coordination repo stood up by an older

release still carries the workflows and the vendored program that release installed; a cron left running against retired semantics keeps mutating labels behind every worker's back. So init DELETES them — gated on kraken's own file header, so something the operator wrote at one of those paths is never destroyed by a bootstrap command.

Protocol

1. **Run the bootstrap.** `kraken.py init` does the whole deterministic gesture — verify-or-create the repo **private**, install the bundled `task.yml` issue-form template via the contents API, delete everything an earlier release installed to be executed server-side, and upsert the canonical state-machine labels (`kraken-task`, `in-progress`, `needs-decision`, `awaiting-merge`) plus the `priority:high` scheduling label with their canonical colors and descriptions:

   python3 "<this skill's folder>/../unleash/kraken.py" init OWNER/tasks [--project <name>]

Pass `--project <name>` to also upsert the `project:<name>` routing label a worker's `--project` filters on. Branch on the exit code: `0` — bootstrapped (render its report); `20` — a gh/network failure, state may be partial, re-run after checking (init is idempotent, so a re-run resumes safely).

2. **Render the report.** `kraken.py init` prints one line per repo/asset/label decision (`created` / `present` / `removed` / `upserted`) and a summary line. Relay it. Call out anything reported **removed** — that is a workflow (or the vendored program) an earlier release installed and this protocol revision retired, deleted so it stops running against semantics the workers no longer implement.

3. **Print the settings reminder.** Do NOT write, create, or touch any `settings.json` — clobbering an existing one is a real footgun, and the permissions belong to each worker's prepared environment, not the coordination repo. Instead print a one-line reminder: before launching a worker, pre-allow the delivery commands in that environment's `.claude/settings.json` — see the worker-environment permissions example in `README.md`, which stays the source of truth. A GitHub Copilot CLI worker takes its permissions as launch flags instead: point the operator at `scri