docs: trim repeated boilerplate in git, gitea, and bin skills
Finding 13: five blocks of near-identical wording were repeated across skills within a plugin — the gitea "resolve owner and repo" step (5 skills), the 404-masks-403 note (6 files), the manual pagination explanation (8 files), the git plugin's main/master force-push refusal (7 files, some with multiple internal restatements), and the bin skills' domain-glossary/ADR paragraph (5 skills). Tightened each instance in place — same meaning, fewer words — rather than extracting to a shared file, which ADR-0014's one-file-per-skill install constraint rules out. Left the three git skills' structured-result JSON shapes alone (coupled to the separate, out-of-scope git-orchestrate merge candidate, finding 19). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD
This commit is contained in:
@@ -9,7 +9,7 @@ description: >
|
||||
Not a Gitea remote's branches -> `gitea-branches`.
|
||||
|
||||
metadata:
|
||||
version: "1.0.3"
|
||||
version: "1.0.4"
|
||||
category: git
|
||||
source_keys:
|
||||
- context7-git-htmldocs
|
||||
@@ -22,7 +22,7 @@ metadata:
|
||||
|
||||
- **Uncommitted changes abort a switch.** `git switch` refuses rather than clobbering conflicting local edits. Offer to stash and retry — forcing the checkout past it is how work disappears.
|
||||
- **A branch and a tag can carry the same name.** Detect it before acting — `git branch --list <name>` (bare, not `rtk`: rtk prints a phantom `* ` line even on no match, which reports every name as ambiguous) and `rtk git tag --list <name>`; output from both means the name is ambiguous. Prefer `git switch` over `git checkout`, and where a command accepts either ref, disambiguate with `refs/heads/<name>` or `refs/tags/<name>`.
|
||||
- **`main` and `master` are a refusal, not a gate.** Force-pushing, force-deleting, or renaming them is rejected even when the caller passes `confirm: true` — no flag makes the remote's history recoverable. Offer a new branch instead.
|
||||
- **`main`/`master` are a refusal, not a gate.** Force-pushing, force-deleting, or renaming either is rejected even with `confirm: true` — no flag recovers the remote's history. Offer a new branch instead.
|
||||
|
||||
## Step 1 — Determine the branching pattern
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ description: >
|
||||
Not branch lifecycle -> `git-branches`.
|
||||
|
||||
metadata:
|
||||
version: "0.1.5"
|
||||
version: "0.1.6"
|
||||
category: git
|
||||
source_keys:
|
||||
- conventional-commits-spec
|
||||
@@ -22,7 +22,7 @@ allowed-tools: Bash
|
||||
## Gotchas
|
||||
|
||||
- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too, except where a skill's Gotchas name a specific bare-git case (interactive rebase here).
|
||||
- **Refuse to force-push `main`/`master`** — a rewrite leaves the branch diverged and the reflex is to force it back; safe only where nobody else has based work on it.
|
||||
- **Refuse to force-push `main`/`master`.** A rewrite diverges the branch and the reflex is to force it back — safe only where nobody else has based work on it.
|
||||
- **`reset --hard` is a confirmation gate, not a default.** It overwrites the working tree, and uncommitted edits it discards were never in git, so no reflog recovers them. Name what will be lost and offer a stash first.
|
||||
- **Never add `--no-verify`** — using it when a hook fails bypasses the QA gate the pipeline depends on. Only on the user's explicit demand, with a warning.
|
||||
|
||||
|
||||
@@ -6,14 +6,14 @@ source_keys:
|
||||
|
||||
# Rewriting existing commits
|
||||
|
||||
Every flow on this page rewrites history. None of them runs before the caller has explicitly approved it, and none is followed by a force-push to `main`/`master` — refuse that and explain why instead.
|
||||
Every flow here rewrites history. None runs without explicit approval, and none ends in a force-push to `main`/`master` — refuse that and explain why.
|
||||
|
||||
## Amend the last commit
|
||||
|
||||
1. Stage the new changes, or the changes that undo something.
|
||||
2. Run `rtk git commit --amend`, adding `--no-edit` when the message stays as it is.
|
||||
3. If the message should change, show the current one and prompt for the replacement.
|
||||
4. The branch has now diverged from its remote. Amending is safe only on a branch nobody else has based work on; on `main`/`master`, refuse the force-push and explain, rather than warning and proceeding.
|
||||
4. The branch has diverged from its remote. Amending is safe only where nobody else has based work on it; on `main`/`master`, refuse the force-push and explain rather than warn and proceed.
|
||||
|
||||
## Fold a commit into an earlier one (autosquash — preferred)
|
||||
|
||||
@@ -50,9 +50,8 @@ date without a merge commit.
|
||||
4. `rtk git rebase <newbase>` — for example `rtk git rebase main`. Use
|
||||
`rtk git rebase --onto <newbase> <upstream> <branch>` to replay only the commits after
|
||||
`<upstream>`, which is how a branch started from the wrong base gets moved.
|
||||
5. The branch has now diverged from its remote. It needs
|
||||
`--force-with-lease --force-if-includes` to push, never a bare `--force`, and never on
|
||||
`main`/`master` — refuse that and explain.
|
||||
5. The branch has diverged from its remote. Push needs `--force-with-lease --force-if-includes`,
|
||||
never a bare `--force` — and never on `main`/`master`; refuse that and explain.
|
||||
|
||||
## Move the branch pointer back (`git reset`)
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ description: >
|
||||
Not submodule pointers -> `git-submodules`.
|
||||
|
||||
metadata:
|
||||
version: "1.0.2"
|
||||
version: "1.0.3"
|
||||
category: git
|
||||
source_keys:
|
||||
- git-scm-remote-docs
|
||||
@@ -28,7 +28,7 @@ metadata:
|
||||
|
||||
## Step 1 — Clear the force-push gate
|
||||
|
||||
`main` and `master` are a hard refusal: decline a force-push targeting either, whatever confirmation accompanies it, because no local approval can restore what the remote loses. On any other branch, `rtk git push --force` and `-f` run only after the caller passes `confirm: true` for that specific push — for a human caller, prompt instead of failing.
|
||||
`main`/`master` are a hard refusal: decline a force-push to either regardless of confirmation — no local approval restores what the remote loses. Elsewhere, `rtk git push --force`/`-f` run only after `confirm: true` for that specific push; for a human caller, prompt instead of failing.
|
||||
|
||||
## Step 2 — Dispatch
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ description: >
|
||||
agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
|
||||
|
||||
metadata:
|
||||
version: "1.0.1"
|
||||
version: "1.0.2"
|
||||
category: git
|
||||
source_keys:
|
||||
- nvie-gitflow-post
|
||||
@@ -60,7 +60,7 @@ owns the request.
|
||||
4. **Gate destructive operations** — before force-push, branch deletion, rebase, or
|
||||
force-checkout, show what will happen and ask "Proceed?". Cancel gracefully if the user
|
||||
declines. Never supply the confirmation on the user's behalf. Some operations are refusals, not
|
||||
confirmations: never offer "Proceed?" for a force-push of `main` or `master`.
|
||||
confirmations — never offer "Proceed?" for a force-push of `main`/`master`.
|
||||
5. **Invoke the `git-orchestrate` agent** with `operation`, `parameters` (user-provided or
|
||||
inferred), `context` (step 3 plus the session context), and `confirm: true` only for a
|
||||
destructive op the user approved in step 4.
|
||||
|
||||
Reference in New Issue
Block a user