fix(git): restore router coverage and commands the retrofit dropped

git-workflow calls itself a router but named two of the six domains it routes to;
the other four appeared nowhere in the file. All six are now named, with a
routing table in the always-loaded body.

git-submodules lost the foreach shell-variable semantics -- only the bare names
survived, though $sm_path and $displaypath differ solely by which directory you
are in. The table is back. Its relocated commands had also dropped the rtk git
prefix its own SKILL.md mandates; 24 of them are re-prefixed. The wider rtk
inconsistency across the plugin stays with #113.

Also restores git-commits' body and footers output fields, git-branches' tag/
branch detection commands, git-worktrees' git config --worktree, pc-run's
ambiguity fallback, git-remotes' git-history boundary, and git-history's pickaxe
triggers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJJrm5YmacbwMdzZpXcoti
This commit is contained in:
2026-08-31 19:46:35 +00:00
parent 1a971ee003
commit ae791781c2
28 changed files with 198 additions and 86 deletions

View File

@@ -3,8 +3,9 @@ name: git-workflow
description: >
Use when a human's local git request is general or ambiguous — it routes to the owning
domain skill. Not an unambiguous commit -> `git-commits`. Not an unambiguous branch ->
`git-branches`. Not an agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
domain skill: `git-commits`, `git-branches`, `git-history`, `git-remotes`, `git-submodules`
or `git-worktrees`. An unambiguous request goes straight to its domain skill instead. Not an
agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
metadata:
category: git
@@ -25,10 +26,27 @@ metadata:
mandated org wrapper, not a style preference. Submodule-specific commands run from inside the
submodule's own directory instead.
## Domains
Every request resolves to exactly one of these six. An unambiguous one should have gone straight
to the domain skill; this skill exists for the ones that did not.
| The request is about | Domain |
|---|---|
| Writing, amending, squashing, or cherry-picking a commit, and its message | `git-commits` |
| Creating, switching, deleting, renaming, tracking, or merging a local branch | `git-branches` |
| When a change landed, which commit broke something, what to revert or backport | `git-history` |
| Anything touching a remote — remote config, fetch, push, pull — even unnamed | `git-remotes` |
| A nested repository pinned inside this one by a recorded commit | `git-submodules` |
| Several branches checked out at once, in separate directories, without stashing | `git-worktrees` |
`git-orchestrate` executes whatever this resolves to (step 5); the table only decides which domain
owns the request.
## Workflow
1. **Parse intent** — extract the operation (commit, create branch, rebase, inspect history, …)
and any options the user named.
1. **Parse intent** — extract the operation and, from the table above, the domain that owns it,
plus any options the user named.
2. **Check the hard rules** — if the request creates, amends, or rewrites a commit, pushes, or
touches hooks, config, or credentials, read `references/hard-rules.md`. Raise the relevant rule
before acting, not after.