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 scripts/kraken-copilot.sh (interactive) or scripts/kraken-loop.sh (the ambush, on every harness — --harness claude passes Claude Code's own) in a kraken checkout, which pass them.
4. Nothing else. No issues are read or written; no worker is launched. Point the operator at status (the queue's console, with ready-to-paste launch lines) or unleash (to start draining) as the next step.

Authorization boundaries

• Invoking this skill is my authorization to, on the coordination repo only: (a) create the repo private if it does not exist; (b) commit the bundled task.yml template via the contents API, creating it only — never overwriting a file that already exists; (b2) delete everything an earlier release installed to run server-side (reclaim-stale.yml, requeue-on-reply.yml, cleanup-closed.yml, validate-task.yml, and the vendored .github/kraken.py they exec'd — their jobs are now derived by the reader on the queue read it already performs, PROTOCOL.md §2.1 and §6), and only when the file still carries kraken's own header, so something I wrote at that path is never touched; (c) upsert the canonical labels (and the project:<name> label when --project is passed).
• It is NOT authorization to read or write issues, modify settings.json, delete anything, change repo visibility on an existing repo, or launch a worker.
• init never overwrites an existing file, and never deletes one that does not carry kraken's own header — kraken.py init enforces both, it is not left to judgment.

Coordination repo / flags / extra context: $ARGUMENTS (if that reads as a literal placeholder, they follow this skill as the request text)