Files

indifferentketchup c2b3e0a013 skills: committing-changes + using-worktrees judgment skills + AGENTS.md guidance

Two portable agent-judgment skills in data/skills/boocode/, externalizing when/how Opus commits and when it isolates work in a worktree, so weaker agents (opencode build agent, BooCoder) can approximate it. committing-changes: segment by concern, stage explicitly (never git add -A), draft scope-prefix messages, present-and-STOP — commit only on explicit command, never push, identity indifferentketchup. using-worktrees: the when-to-isolate heuristic (just-create-when-clear / propose-when-ambiguous / skip), stable-base mechanics, runtime-isolation caveat — deliberately autonomous vs committing's command-gate. Each has an eval.yaml (matching improving-boocode-guidance) with a negative-trigger task. AGENTS.md gets a parser-safe preamble (the registry throws on bare ## headings) pointing at both skills.

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

2026-05-31 00:04:48 +00:00

4.6 KiB

Raw Blame History

name: committing-changes description: This skill should be used when the user asks to commit, stage, split, or prepare changes for a commit. Examples: "commit this", "stage these", "split this into commits", "help me commit", "prepare a commit", "make a commit for the dcp fix".

Committing Changes

Segment the working tree by concern, stage explicitly, draft messages, present the plan, and STOP. Commit only on the user's explicit command for this turn. Never push — the user pushes manually (Gitea + GitHub mirror).

The default is to prepare and propose, not to commit. A request to "commit X" is a request to get X ready and show the plan, unless the user has, in this turn, told you to actually run the commit. When in doubt, present and wait.

Workflow

Inspect. git status then git diff (and git diff --staged if anything is already staged). Read what actually changed — do not commit from memory of what you wrote.
Segment by concern. Group the changes into buckets, one per coherent concern. State the grouping in plain language before staging anything (e.g. "two concerns: (a) the SSE fix in opencode-server.ts, (b) an unrelated typo in README").
Safety scan. Before staging, scan the diff for: secrets / keys / tokens, debug code, stray console.log/print/dbg!, commented-out experiments, and edits to files the user did not ask you to touch (their in-progress work). Flag anything found; do not silently stage it.
Stage explicitly, per bucket. Stage named files (git add path/a path/b) or hunks (git add -p). Never git add -A, git add ., or git add -u — those sweep up unrelated work. If -p can't cleanly split adjacent hunks, hand-edit the patch (git add -e) or revert the unrelated hunk in the working tree first.
Draft messages. One message per bucket, in the repo's scope-prefix style (see references/message-style.md). Explain why for anything non-obvious — the diff already shows what. Imperative mood. No emojis. Do not impose Conventional-Commits ceremony (type enums, BREAKING CHANGE: footers) unless the user asks.
Present the plan + STOP. Show: the buckets, the files in each, the drafted message for each, and the current staged state. Then wait. Do not run git commit.
On the user's command, execute the agreed git add / git commit exactly as presented, using the identity below. Then report the resulting hashes. Still do not push.

Split heuristic

One commit when the changes are a single coherent concern (a feature + its test; a fix + the comment explaining it).
Multiple commits when concerns are independently revertable or reviewable — a bug fix and an unrelated refactor that happen to share the working tree should be two commits even if they touch the same file.
A migration/schema change and the code that uses it are usually one concern (they're not independently revertable). A doc/changelog update alongside code is usually a separate concern.

Identity (always)

Commit as:

user.name  = indifferentketchup
user.email = sam@indifferentketchup.com

Never use a personal Gmail or the host's default git identity. If unsure the repo config is right, pass it inline: git -c user.name=indifferentketchup -c user.email=sam@indifferentketchup.com commit -m "...".

DO-NOT

Never push. No git push under any circumstances — that is the user's manual step (dual remote: Gitea + GitHub mirror).
Never auto-commit. Preparing ≠ committing. Commit only when told to, this turn.
Never git add -A / git add . / git add -u. Stage by name or by hunk.
Never commit the user's unrelated/in-progress files. If a file changed that the task didn't touch, leave it; surface it.
No emojis in messages.
No amending or rebasing published or shared commits without an explicit instruction.

Red flags — STOP

About to run git commit without having been told to commit this turn → STOP, present the plan instead.
About to git add -A "to save time" → STOP, stage by concern.
About to git push "to finish the job" → STOP, that is never part of this skill.
A secret or debug line is in the diff and you're staging anyway → STOP, surface it.

Anti-patterns this skill avoids

Committing the moment changes look done (the user reviews diffs and commits on command).
Collapsing several concerns into one "WIP" commit because staging separately is tedious.
Pushing after committing because the work "feels finished."
Reformatting the message into strict Conventional Commits when the repo uses freeform scope-prefixes.

4.6 KiB Raw Blame History