メニュー
When a PR is open and needs a fix, push to the same branch or wait for merge before branching. Never branch off the open PR's branch directly -- squash-merge will leave you with a phantom conflict.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when deciding whether to dispatch a runner or a worker for a subtask. Describes the decision boundary, the failure mode when runner is used where worker is intended, and the safe composition pattern.
When a repo has no GitHub remote (or is not yet a git repo) -- use this to route survey, sweep, and dispatch off the GitHub-centric path. Detect with `git remote` empty; treat blank GitHub columns as expected, not an error; route work to commits + CLAUDE.md instead of issues + PRs; degrade a maintenance sweep to the local-only axes.
When the directive is "status check," "what's new across my projects," or "sweep maintenance" -- run a per-project, read-mostly, non-PR sweep. For each project under the owner-prefixed layout, gather stars/forks, open issues/PRs split into mine vs community vs bots, package downloads, release-due (unreleased conventional commits), a test run, a stale-CLAUDE.md flag, and branch-cleanup candidates. Emit a fresh per-project report every sweep; NEVER cache status back into a workspace/manager CLAUDE.md.
Before making any non-trivial code, docs, or config change -- create a feature branch first, then open a PR. Never commit directly to main. Apply by default before any edit; this is the baseline branch discipline that all other git skills build on.
When the issue or PR queue has open unlabeled items -- run a read-only triage pass that labels each one by component, category, priority, and size, flags duplicates, closes noise, and reports the p1 queue before runners are dispatched.
When writing any issue, PR, or commit message, use this for the authoring standard. Covers structure (headings, lists, tables, fenced blocks, the bug block, the before/after) and voice (factual, no emdashes, no editorializing labels, conventional-commit prefixes, no commit trailers).
| name | git-fix-pr-branching |
| description | When a PR is open and needs a fix, push to the same branch or wait for merge before branching. Never branch off the open PR's branch directly -- squash-merge will leave you with a phantom conflict. |
If an open PR needs a fix, do one of:
main.
Cleanest when the project squash-merges (closer matches the
eventual history).Do NOT branch off the open PR's feature branch to make a separate fix PR.
If the open PR squash-merges, the squash commit and the original branch's commits have the same content but different SHAs. Any branch that carries those original commits will conflict against main even though the content matches. The fix branch then needs to be rebased onto main to drop the duplicate commits, which is more work than either option above.
Concrete: caught on roba 2026-05-27. After PR #24 (test/live-perms)
merged with squash, the standalone fix PR #25 conflicted with main
because its branch still carried PR #24's original (pre-squash)
commit. Rebasing the fix branch onto main resolved it by dropping
the duplicate.
When you have a bug, typo, or small change to make against a PR that is currently open OR was just merged.
Before branching to fix a freshly opened PR, check the PR's state:
gh pr view <PR> # or gh pr list --state open
git checkout main && git pull --ff-only && git checkout -b fix/<short-description>. Never branch from the now-
closed feature branch.git-branch-pr-workflow --
the general "branch off main + PR" discipline.