BREAKING: the plugin is `kettle`, not `tea`, and its commands are `/kettle:*`. It also now needs a binary on PATH that it did not need before; the README and every skill say how to get one and what a missing one looks like. The plugin was 3800 lines of Python doing what a compiled binary does better, and the name pointed at a tool that no longer takes part: `tea` is Gitea's CLI, and since the transport moved into the binary nothing here shells out to it for issues at all. A plugin named after it was going to keep suggesting otherwise. Deleted: 19 scripts, the 14-file unittest suite, and the tea-guard hook. The guard blocked any `tea` invocation that would run under a login the model picked instead of the operator; the binary holds its own credentials and reads the pinned login out of the project's own config, so that failure is no longer expressible and there is nothing left to police. agents-sync stays — it is about AGENTS.md symlinks and has nothing to do with any of this. What the plugin keeps is what only a plugin can carry: the rules an operator states and a binary cannot enforce. `init` still refuses to run inside a linked worktree and still may not be model-invoked, because which directory is the project is a statement a person makes. The issue format reference stays here and stays the source of truth. The runner subagent is still for batches and still may not decide what an issue says. The command reference in the issue, sync and project skills is GENERATED from the binary's own command registry, between markers, so a flag that changed cannot ship with a skill that recommends the old one. `kettle gen skills --check` exits non-zero when they drift. The generator owns the region and nothing outside it: the frontmatter description, which is what decides whether a skill loads at all, stays hand-written. `use` survives and is the one place `tea` is still named — for releases, webhooks and actions, which kettle does not cover. Its instruction to write `--login "$GITEA_LOGIN"` and let the hook substitute the pin was true until this commit and is now rewritten: `tea` keeps its own configuration, kettle keeps its own, and configuring one configures nothing in the other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.8 KiB
name, description, argument-hint, disable-model-invocation, allowed-tools
| name | description | argument-hint | disable-model-invocation | allowed-tools |
|---|---|---|---|---|
| init | 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, and gitignores it. Operator-invoked only; carries the rules the binary cannot enforce — never inside a linked worktree, never an `--at` nobody named, never a migration clash resolved for them. | [--at DIR] [--login NAME] [--repo owner/name] [--dry-run] | true | 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.
The binary does the work and is idempotent. What this skill carries is the three things it cannot decide for itself.
Steps
-
Refuse inside a linked worktree. Two different paths mean one:
git rev-parse --path-format=absolute --git-dir --git-common-dirStop and say so.
.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 thegitdir:in the.gitfile. A marker here gives one project two stores, and the second is deleted with the branch. If anything needs initializing it is the main checkout, which is the second path's parent. -
Run it, passing the operator's arguments through unchanged:
kettle init $ARGUMENTSWith no
--atit initializes the current directory. Never supply an--atthe 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. -
Report what it printed, verbatim.
already initialized — nothing to dois 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.
When it stops
- 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: localissue, 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. Stop and
tell the operator to install it: cd cli && go build -o ~/.local/bin/kettle ./cmd/kettle in the marketplace repository (go.mod requires go 1.26), or
go install git.noodles.cam/claude-skills/marketplace/cli/cmd/kettle@latest.
After
/kettle:issueworks now — offline, no login, no network./kettle:authputs a token on this machine and pins the login this project runs under; needed only for the tracker side,/kettle:sync.kettle configprints 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.
The full flag table for init is the generated block in /kettle:project.