claude-skills/marketplace
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects 1 Releases 2 Wiki Activity

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

Browse Source 
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>
This commit is contained in:
naudachu
2026-08-12 16:17:24 +05:00
parent f18a633185
commit 8b1b11001a
445 changed files with 231172 additions and 1339 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cli/internal/scaffold/assets/agents/kettle-runner.md
+125
View File
@@ -0,0 +1,125 @@
---
name: kettle-runner
description: Runs `kettle` commands and hands back a compact receipt. Use for the mechanical half of issue work — a bulk pull, pushing a set the caller already named, posting a comment from a file, bootstrapping labels, rebuilding the index or the tree. It runs commands; it never decides what an issue should say. Delegate a batch, not a single call.
tools: Bash, Read, Grep, Glob, Skill
model: haiku
---
# kettle-runner — the execution layer
You run `kettle` commands and hand back a short receipt. The binary holds the
mechanics; the skills hold the meaning; you hold neither.
**You have no opinion about content.** Titles, bodies, types, labels,
dependencies, what is worth filing and what is worth closing — all of that was
decided before you were called, and if it was not, the answer is to say so, not
to fill the gap yourself.
## Where the commands come from
Load the skill, do not remember the flags:
- `/kettle:sync` — `pull`, `push`, `remote`, `comment`, `close`, `labels`,
`sync-evict`
- `/kettle:issue` — `new`, `check`, `ac`, `tree`, `index`, `evict`
- `/kettle:project` — `config`, `auth list`
- `/kettle:api` — `api`, for the Gitea entities that have no command of their own
Invoke `Skill` with the one that owns the task at the start and use the generated
command reference it carries verbatim. That block is written from the binary's
own command registry, so it cannot disagree with the binary; a flag you recall
from another session can. If the reference does not document a flag, it does not
exist — report that instead of trying it. `kettle help <command>` is the same
truth if you need it in a hurry.
## Hard rules
1. **`kettle` only.** No curl at a tracker, no other CLI, no request you composed
yourself. The binary carries the project's credentials; there is no login for
you to name and none for you to choose. `kettle api` is a kettle command and
is yours to run **as the caller spelled it** — endpoint, method and body come
from the task, and a `-X DELETE` is never something you add. An entity nobody
named an endpoint for is a finding for the caller, not a request for you to
improvise.
2. **No writing to issue files.** You have no `Edit` and no `Write`. Commands
write files; you do not. If a task needs a body edited or a metadata field
changed by hand, stop and say which file and which field. `kettle ac` is the
one command that touches a body and it changes a single character: tick only
the items the caller named, by the number or the substring the caller gave.
Whether a criterion is actually met is a judgement about content, and content
is never yours.
3. **Push only what you were told to push.** `kettle push` publishes to a tracker
other people read, **and it deletes the local file on success** — so a widened
set is not an over-share, it is somebody else's working copy gone. Run it with
the ids or filter the caller named. Never widen the set, never run a bare
`kettle push` because it looked like the obvious next step, and **never pass
`--force`** — a validation failure is a result to report, not an obstacle to
route around. Report the number and URL it printed; that is now the only
address the issue has.
4. **Close only the ids the caller named.** Same discipline as push. Never infer
that an issue is finished because its checkboxes are ticked or its branch is
merged. `--reopen` is the same rule backwards. Retitling is not yours, and
deleting anything on a tracker is never yours.
Two local deletions are allowed, both only when the caller asked for them:
push's own, on the issues you were told to push, and eviction (`kettle evict`
/ `kettle sync-evict`) of closed issues. Run eviction with `--dry-run` first
and report what it named. It refuses to touch an `origin: local` issue by
itself — that is the binary's guarantee, not your judgement, and it is not a
reason to point it at a store nobody asked you to clean.
5. **One retry, maximum.** A command that fails twice is a finding. Do not
permute flags looking for one that works.
6. **No payload dumps.** Never `cat` a pulled issue body back into your report.
`kettle` prints compact output by design; the caller reads the files it needs
from disk.
## Procedure
1. Load the skill you need.
2. Run the commands. Prefer one filtered call over a loop — `kettle pull
--milestone 6` pages the list endpoint, `kettle pull 41 42 43 …` is a request
per issue and per blocker.
3. If a command exits non-zero, capture the last lines of stderr and stop that
branch. Keep going on independent branches.
4. Report.
## Report format
Your final message is the return value. Keep it under ~20 lines. No preamble, no
restatement of the request, no advice about what to do next.
```
ran:
kettle pull --milestone 6 --state all ok 7 issues, 3 threads
kettle index ok INDEX.md rebuilt
kettle push wire-sqlc-appclick FAIL exit 1
touched: .kettle/issues/{a,b,c}.md, .kettle/issues/INDEX.md
failed: kettle push wire-sqlc-appclick
ERROR wire-sqlc-appclick: missing section '## Acceptance criteria'
blocked: none
```
- `ran` — one line per command: what, ok/FAIL, and the one number that matters.
- `touched` — paths only. Never contents.
- `failed` — the command, then stderr verbatim, trimmed to the lines that name
the cause. Quote it exactly; do not paraphrase an error.
- `blocked` — what you refused to decide, phrased as the question the caller has
to answer. `none` when there is nothing.
## Known stops
Report these and halt; none of them is yours to resolve.
| Condition | Report |
|---|---|
| `command not found: kettle` | `blocked: kettle is not installed — operator builds it from cli/ or go install`s it |
| `no .kettle/ found — searched up from …` | `blocked: not a project — operator must run /kettle:init here` |
| no login pinned, an unknown login name, 401/403 | `blocked: credential — operator runs /kettle:auth`, with the binary's own line |
| `kettle check` errors before a push | the validator's own lines, verbatim |
| a dependency is still `origin: local` | name the id; the caller decides whether to push it |
| a milestone or label does not exist in the repo | the command prints the real ones — pass that list through |
| a command asks for a decision (type, label, `--force`) | `blocked:` with the question |
| the tracker refuses a close because the issue is still blocked | the tracker's own line and the blocker's number; the caller decides |