The #113 sweep rested on CLAUDE.md's premise that rtk either filters or passes through unchanged, so prefixing is always safe. Measured against rtk 0.42.4, that premise is false for several of the commands the sweep prefixed, and two skills were left giving wrong answers silently. Why: - `rtk git worktree list --porcelain -z` discards both flags and renders its own format. The `locked`/`lock_reason` fields git-worktrees Step 2 must emit are absent entirely, and paths under $HOME are abbreviated to `~/`. - `rtk git branch --list <name>` prints a phantom `* ` line even when nothing matches, so git-branches' stated ambiguity test — "output from both means the name is ambiguous" — reported every name as ambiguous. `tag --list` is a clean passthrough, so only one half broke. - `rtk git diff --name-only`/`--name-status` append a `Changes:` trailer to output documented as "one per line"; `--word-diff` emits none of the `[-removed-] {+added+}` markers its table describes; `rtk git log -L` truncates each line at ~72 chars, on the one command whose purpose is showing line content. - `rtk git stash pop` prints only `FAILED: git stash pop`, swallowing the conflict diagnostic and retained-entry message the surrounding prose tells the agent to rely on. Implementation notes: - Eleven sites reverted to bare `git`, each carrying its reason inline so the next sweep does not undo it. `mergetool` and `rebase -i` are reverted on clause 3's interactive limb only: the TTY defect does not reproduce — rtk filters exactly twelve subcommands and execs the rest — and ADR-0023 records that measurement rather than a convenient one. - ADR-0023 states the rule repo-wide with a third clause: a command whose output the skill parses, or which is interactive, stays bare. `plugins/git/README.md` is reduced to a pointer; its claim that gitea skills "contain no git/rtk mentions at all" was false, and its citation of `hard-rules.md` pointed at a file containing no occurrence of "rtk". - Eight gitea sites swept, all verified byte-identical passthroughs first. - `scripts/check-rtk-prefix.sh` gates clause 1. Run against main's pre-sweep corpus it reports 99 findings including every gitea site, so it would have caught the drift #113 was filed about. Impact: the gate covers clause 1 only, in shell-tagged fences and the opening span of Run cells. Clause 2 is not gateable — "Run `git switch`" and "`git switch` refuses" are the same tokens — and prose bullets are invisible to it. Both limits are recorded in gates.md rather than left implied. Refs: #113 ADR: 0023 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
3.5 KiB
3.5 KiB
name, description, metadata, allowed-tools
| name | description | metadata | allowed-tools | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| git-history | Use when investigating git history — pickaxe (`-S`/`-G`) or `-L` line-range log queries, tracing when a change landed, bisecting what broke something, or locating a commit to revert or backport. Not authoring or rebasing commits -> `git-commits`. Not a Gitea server's history -> `gitea-branches`. |
|
Bash |
Gotchas
-S"string"matches only where the string's count changed, so a line edited in place matches-G"regex"and not-S. Reach for-Gwhenever the string may have moved rather than appeared.--followtraces renames for exactly one path. Given several paths or a glob it fails instead of degrading, so run it once per file.- Under
git bisect run, exit128or above aborts the session rather than marking the commit bad, so a crashing test script ends the search silently. - Bisect answering "cannot find exact culprit" beside skipped commits is a complete result: it is as precise as the skip range allows.
Step 1 — Pick the entry procedure
| What is known | Procedure |
|---|---|
| Content, a file, or a line range to search for | Query the log — Step 2 |
| Nothing to search for — only that the behaviour changed between two points | Bisect — read references/bisect.md |
| The commit itself, already identified | Step 3 |
Step 2 — Query the log
Default to rtk git log --oneline, then narrow by whatever is known:
- Content:
rtk git log -S"string", or-G"regex"to match any diff line.--pickaxe-regexmakes the-Sargument a POSIX ERE;--pickaxe-allshows every file in a matching changeset. - A line or function:
git log -L <start>,<end>:<file>orgit log -L :<function>:<file>— bare, notrtk: rtk truncates each diff line at ~72 characters (ADR-0023). Confirm the range resolves before reporting on it — an off-by-one silently omits the target. - A file across renames:
rtk git log --follow -- <file>. Without--followthe history stops at the rename boundary. - Mainline only:
--first-parentfollows the integration branch and skips commits merged in from side branches. - Structured output:
rtk git log --format="%h | %s | %an (%ar)".
If you need the placeholder catalogue, format presets, --diff-filter letters, full -L syntax, ancestry filters, pickaxe binary-file behaviour, or git diff output-control flags such as --stat, --word-diff and the whitespace options, read references/git-log-format.md.
Step 3 — Act on a located commit
Offer the operation and its consequence; run it only once the user has chosen.
- Backporting the commit to another branch is a cherry-pick, and cherry-pick is
git-commits' — it owns the destination-branch check, thertk gitwrapper and the--abortpath. Hand it the SHA; do not rungit cherry-pickfrom here. rtk git revert <commit>adds a new commit undoing it — for un-applying merged work without rewriting history.rtk git blame <file>attributes each line to the commit that last touched it, when the question is which commit introduced one specific line.
For diff output control on the located commit, read references/git-log-format.md.
Step 4 — Return the result
Report each located commit in this shape, so a calling agent can act on it without reparsing raw log output:
<sha> — <subject>
<author> (<relative date>)
Recommendation: <action or "none">