feat: drop the kettle plugin; the binary writes its own skills

The plugin and the binary shipped on two release cadences and nothing on an
operator's machine ever checked that the one they installed described the other.
The generated flag block existed precisely so a renamed flag could not ship with
documentation recommending the old one — and then shipped one version behind the
registry it came from, which is the same bug one hop downstream.

So the prose moved into the binary. `internal/scaffold` embeds every document;
`kettle init` and `kettle gen scaffold` write them into a project's own
`.claude/`. The two cannot disagree because there is one artefact.

The namespace survived the move. A project's skills are flat, so the prefix is
spelled into the directory name (`kettle-issue`); a project's *commands* take
their namespace from a subdirectory, so `commands/kettle/init.md` is still
`/kettle:init`. Four of the six command files are thin pointers at a skill, and
that is what kept ~1,600 lines of `/kettle:…` cross-references true without a
rewrite. `init` and `auth` lost `disable-model-invocation: true` — being a
command is that property — and `auth` now restricts `allowed-tools` so a model
cannot reach `kettle auth add` at all.

`gen scaffold` writes files whole rather than splicing a region. The old
refusal protected somebody's hand-written prose around the block; that prose is
embedded now, so there is none to protect, and preserving local edits would
freeze a project's documentation at whatever version first initialized it.
`--check` warns before an upgrade discards one.

The plugin's `agents-sync.sh` — 141 lines of Python behind a filename that said
`.sh` — became `internal/mirror` and `kettle mirror`. Same seven branches, same
refusal to merge two real files that differ, now with a table test per branch
and a check that a repair converges in one pass. `--hook` is the PreToolUse
form and exits 0 on every path including a panic. It is opt-in per project,
which is strictly narrower than the plugin hook that was on for everybody who
installed it.

`kettle init --interactive` walks a person through the login, the token (read
with the echo off, so it lands in no history and no file), the repository, the
`.claude/` tree and the mirror hook. It refuses a stdin that is not a terminal
and names the flags instead: every question it asks has one, and it performs
nothing itself, so an interactive run and a flag run are one code path.

Two rules that used to be prose are now the binary's: init refuses a linked
worktree and names the main checkout, and writing into an existing
`.claude/settings.json` is refused with the snippet printed rather than
reformatting a file the operator commits.

The scaffold version stamp went to its own `.kettle/scaffold.yaml` rather than
into `config.yaml`, because unknown keys there are a hard error and that file
may be committed and read by whatever build each machine has.

golang.org/x/term becomes a direct dependency; it was already in the tree
indirectly, so no module was added.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

cli/internal/scaffold/assets/commands/kettle/api.md

@@ -0,0 +1,14 @@
+---
+description: Reach everything Gitea has that is not an issue — pull requests, releases, tags, milestones, branches, commits, actions, webhooks — with `kettle api`.
+argument-hint: "[the endpoint, or what you want from the tracker]"
+---
+
+Load the **`kettle-api`** skill and follow it. Which endpoint answers which
+question, which of them paginate, and what `-X DELETE` requires are all mapped
+there.
+
+$ARGUMENTS
+
+One request, under the login this project already pins — no second tool and no
+second credential. Issues are not handled here: `/kettle:issue` works on them
+offline and `/kettle:sync` moves them.

cli/internal/scaffold/assets/commands/kettle/auth.md

@@ -0,0 +1,130 @@
+---
+description: Give `kettle` a Gitea credential and choose which login this project runs under — `kettle auth list/add/remove` manages the machine-wide token file, `kettle init --login <name>` pins one of those names into `.kettle/config.yaml`. Invoke when a sync command reports no login, a 401, or an unknown login name, or to switch the account this project's issues are pushed under. The OPERATOR picks the login; you never type a token.
+allowed-tools: Bash(kettle auth list:*), Bash(kettle config:*)
+---
+
+# /kettle:auth — the credential a project runs under
+
+Two files, and the split is the whole design.
+
+| where | what is in it | who writes it |
+|---|---|---|
+| `~/.config/kettle/logins.yaml` | the tokens, one file per machine, mode 0600, outside every working tree | `kettle auth add` |
+| `<project>/.kettle/config.yaml` | the **name** of one of those logins, and the tracker repo | `kettle init --login … --repo …` |
+
+A name is worth nothing on its own, which is what makes it safe to keep in a
+file inside a repository. A token in a working tree ends up in a commit
+eventually, and a secret that has ever been pushed has to be rotated.
+`$KETTLE_CONFIG_HOME` or `$XDG_CONFIG_HOME` move the machine file;
+`KETTLE_LOGIN`, `KETTLE_URL` and `KETTLE_TOKEN` override it outright, which is
+how CI runs with no token on disk.
+
+**No credential is pinned in `.claude/` anywhere, and no hook rewrites a
+`--login` argument.** That mechanism is gone with the Python scripts. If you find
+a `GITEA_LOGIN` in a settings file, it is dead weight from the old plugin — the
+only thing `kettle` ever writes into `.claude/settings.json` is the optional
+`AGENTS.md` mirror hook, which holds no identity of any kind.
+
+## The one hard rule: the operator chooses, and holds the token
+
+- **Never pick a login.** Not from memory, not from the repo URL, not from a
+  previous session. Present the choice with `AskUserQuestion` — name, url and
+  user out of `kettle auth list` — and let the operator answer. Exactly one login
+  on the machine is the only case where you may propose, and you still confirm.
+- **Never type, echo, paste or read a token.** `kettle auth add` takes it on
+  stdin precisely so it does not land in shell history; a token that goes through
+  a model's context is a token in a transcript. Adding a login is the operator's
+  own terminal, not a Bash call you make for them.
+
+## Steps
+
+1. See what this machine holds. It never prints a token, and there is no flag to
+   make it:
+
+   ```bash
+   kettle auth list
+   ```
+
+2. **Nothing there** — stop and hand the operator the command to run themselves:
+
+   ```bash
+   kettle init --interactive                                    # prompts for it, echo off
+   kettle auth add --name noodles --url https://git.example.com --user naudachu < token.txt
+   pass show gitea/token | kettle auth add --name noodles --url https://git.example.com
+   ```
+
+   The first is the one to suggest to a person at a terminal: it reads the token
+   with the echo turned off, so it is in no history, no file and no scrollback.
+   **It is not a command for you to run** — it refuses a stdin that is not a
+   terminal, and that refusal is correct. `--user` is documentation only, and
+   `kettle auth remove <name>` forgets one.
+
+3. **Pin the choice into the project.** Ask `kettle config` first and only
+   proceed if it answers with a project — `kettle init` in a directory that is
+   not one would *create* a project there, which is the one statement that is
+   never yours to make (`/kettle:init`):
+
+   ```bash
+   kettle config
+   kettle init --login noodles
+   ```
+
+   `init` on an initialized project prints `already initialized — nothing to do`
+   and rewrites only the settings it was given, so the repo pinned earlier stays.
+
+4. Confirm with `kettle config`. Tell the operator which login is pinned and
+   which file it went in. It is live immediately — nothing caches it, no restart.
+
+```
+login     noodles
+url       https://git.example.com
+token     (set)
+repo      claude-skills/marketplace
+```
+
+## When it goes wrong
+
+| what you see | what it means |
+|---|---|
+| `no login "X" in …/logins.yaml — known: …` | the project pins a name this machine does not hold. Either add it (step 2) or pin one that is there |
+| `no .kettle/ found — searched up from …` | not a project. `/kettle:init`, and it is the operator's to run |
+| `401` / `403` from a sync command | report it verbatim. Do **not** try another login, and do not edit or remove one to route around it — that is somebody's identity, not a setting |
+| `token none` in `kettle config` | a name is pinned but no credential answers to it |
+
+## Scopes: what the token is allowed to do
+
+Gitea mints a token with scopes, spelled `<read|write>:<category>`. A token made
+for issues carries `write:issue` — and that is enough for everything
+`/kettle:issue` and `/kettle:sync` do, and **not** enough for anything
+`/kettle:api` reaches: releases, pull requests, branches, tags and actions all
+sit under `repository`.
+
+| doing | needs |
+|---|---|
+| pull, push, comment, close, evict | `write:issue` |
+| `kettle labels` | `write:issue` |
+| `kettle api` on releases, PRs, tags, branches, actions | `write:repository` too |
+| reading any of those without writing | the `read:` half is enough |
+
+`kettle auth add --scopes write:issue,write:repository` writes that down beside
+the login. **It is a note and nothing else** — nothing is checked against it and
+nothing is refused because of it. It is worth writing down because the instance
+will not answer the question: Gitea's own token listing needs a password rather
+than a token, so a token cannot be asked what it may do. `kettle auth list` and
+`kettle config` show what was recorded; `(not recorded)` means nobody wrote it
+down, never "none".
+
+A **403** from a sync command or from `kettle api` is usually this and says so.
+Minting a new token is the operator's job in the web UI — the same flow as step
+2 above, with both scopes ticked this time. Never remove or re-point a login to
+route around a 403.
+
+**No `kettle` on PATH?** `command not found: kettle` is the whole story — and it
+means the binary that wrote this file has since moved or been removed, because
+nothing else could have put it here. Stop and tell the operator to reinstall it:
+`go install git.noodles.cam/claude-skills/marketplace/cli/cmd/kettle@latest`, or
+`cd cli && make install` in a checkout of that repository (go.mod requires
+**go 1.26**).
+
+The full flag table for `auth`, `config` and `init` is the generated block in
+`/kettle:project`.

cli/internal/scaffold/assets/commands/kettle/init.md

@@ -0,0 +1,90 @@
+---
+description: Make THIS directory a project that tracks issues — run `kettle init`, which creates the `.kettle/` marker every other command resolves the store from, migrates an older store in, gitignores it, and writes this command file and its skills. Carries the rules the binary cannot enforce — never an `--at` nobody named, never a migration clash resolved for them.
+argument-hint: "[--at DIR] [--interactive] [--login NAME] [--repo owner/name] [--dry-run]"
+allowed-tools: Bash(kettle init:*), Bash(kettle config:*), Bash(git rev-parse:*)
+---
+
+# /kettle:init — make this directory a project
+
+Initializing is a statement, and the operator makes it: *this* directory is the
+project whose issues live in it. Nothing infers it — `.git` is in every clone,
+and a tool that inferred its root from one wrote other projects' issues into its
+own versioned cache. It is answered once, by a person, and every command
+downstream reads the answer instead of guessing.
+
+**This is a command, not a skill, and that is the point.** It is invoked by an
+operator who typed it. There is no `description:` here for a model to match on,
+because "which directory is the project" is not a question a model gets to answer
+on its own.
+
+The binary does the work and is idempotent. What this file carries is what it
+cannot decide.
+
+## Steps
+
+1. Run it, passing the operator's arguments through unchanged:
+
+   ```bash
+   kettle init $ARGUMENTS
+   ```
+
+   With no `--at` it initializes the current directory. **Never supply an `--at`
+   the operator did not name.** Which directory is the project is the one
+   question this command exists to have a person answer; picking a plausible one
+   is the failure the marker replaces.
+
+2. Report what it printed, verbatim. `already initialized — nothing to do` is a
+   success, not something to work around.
+
+`--login` pins a login by name and `--repo` names the tracker repository; both
+are optional and both can be added later by running `init` again — it writes the
+config without disturbing settings it was not given. Neither is a credential:
+the tokens live in one file per machine, `/kettle:auth`.
+
+## `--interactive` is for a person at a terminal
+
+It walks the operator through the login, the repository, this `.claude/` tree and
+the `AGENTS.md` mirror hook, one question at a time.
+
+**Do not run it.** It refuses a stdin that is not a terminal and says so, which is
+the right failure — but the right move is not to reach for it in the first place.
+Every question it asks has a flag: `--login`, `--repo`, `--scaffold`,
+`--mirror-hook`. Pass the flags the operator named and let the binary answer the
+rest.
+
+## When it stops
+
+- **A linked worktree.** The binary refuses, and it is right to: `.kettle/` is
+  gitignored, so a worktree has no marker by design and reaches the main
+  checkout's store on its own — the walk crosses to it through the `gitdir:` in
+  the `.git` *file*. A marker here would give one project two stores, and the
+  second is deleted with the branch. What needs initializing, if anything, is the
+  main checkout, and the refusal names it.
+- **A name clash on the migration** — the same file name on both sides. It exits
+  having changed nothing and names the files. Report that. Do **not** move,
+  delete, or merge either side: one of them may be an `origin: local` issue,
+  which *is* the issue and the only copy of that work. The operator decides
+  which survives.
+- **A marker already exists above this directory.** A second one gives that
+  project a second store and the nearer one wins. Confirm with the operator
+  before going ahead; usually they are standing in a subdirectory and there is
+  nothing to do.
+
+**No `kettle` on PATH?** `command not found: kettle` is the whole story — and it
+means the binary that wrote this file has since moved or been removed, because
+nothing else could have put it here. Stop and tell the operator to reinstall it:
+`go install git.noodles.cam/claude-skills/marketplace/cli/cmd/kettle@latest`, or
+`cd cli && make install` in a checkout of that repository (go.mod requires
+**go 1.26**).
+
+## After
+
+- `/kettle:issue` works now — offline, no login, no network.
+- `/kettle:auth` puts a token on this machine and pins the login this project
+  runs under; needed only for the tracker side, `/kettle:sync`.
+- `kettle config` prints every path and setting this directory resolved to, and
+  is the first thing to run when something looks like it landed in the wrong
+  place. It also reports when this `.claude/` tree was written by an older
+  `kettle` than the one now installed.
+
+The full flag table for `init` is the generated block in `/kettle:project`.

cli/internal/scaffold/assets/commands/kettle/issue.md

@@ -0,0 +1,14 @@
+---
+description: Work on this project's issues offline — create, read, grep, validate, tick checkboxes, evict, and walk the dependency graph.
+argument-hint: "[what you want to do with an issue]"
+---
+
+Load the **`kettle-issue`** skill and follow it. Everything about what an issue is
+— the format, the taxonomy, validation, checkboxes, the dependency graph — lives
+there, along with the canonical format reference it points at.
+
+$ARGUMENTS
+
+This half is entirely offline: issues are markdown files under
+`<project>/.kettle/issues/` and need no login and no network. Moving them to or
+from the tracker is `/kettle:sync`.

cli/internal/scaffold/assets/commands/kettle/project.md

@@ -0,0 +1,13 @@
+---
+description: Look up the exact flags and defaults of the project-level kettle commands — init, auth, config, gen, mirror.
+argument-hint: "[the command whose flags you want]"
+---
+
+Load the **`kettle-project`** skill and follow it. It carries the generated flag
+table for every project-level command, written from the registry the binary was
+built from.
+
+$ARGUMENTS
+
+`kettle help <command>` prints the same thing in a terminal, and is the faster
+answer when the operator is already in one.

cli/internal/scaffold/assets/commands/kettle/sync.md

@@ -0,0 +1,13 @@
+---
+description: Move issues between this project's local store and its Gitea tracker — pull, push, list, comment, close, evict.
+argument-hint: "[what to pull, push, comment on or close]"
+---
+
+Load the **`kettle-sync`** skill and follow it. The round trip and the rule that
+holds it — the store keeps what has not left this machine, so a successful push
+deletes the local file — are stated there in full.
+
+$ARGUMENTS
+
+What an issue *is* belongs to `/kettle:issue` and needs no network. Everything
+Gitea has that is not an issue is `/kettle:api`.