init

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.