원클릭으로
git-branch
Create repository-compliant branches with efficient issue naming, base selection, and safety checks.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Create repository-compliant branches with efficient issue naming, base selection, and safety checks.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Generate a local static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions.
Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.github/issue-triage/config.json` and `.github/CODEOWNERS`. Use when setting up triage automation on a new or existing repository for the first time.
Compare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available.
Create a product spec from a GitHub issue in this repository by applying the local shared `write-product-spec` workflow with issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/issue-<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or pull requests itself.
Create a technical spec from a GitHub issue in this repository by applying the local shared `write-tech-spec` workflow with issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/issue-<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or pull requests itself.
Repo-specific dedupe guidance . Only the categories declared overridable by the core dedupe-issue skill may be specialized here.
| name | git-branch |
| description | Create repository-compliant branches with efficient issue naming, base selection, and safety checks. |
Create a development branch with the fewest checks needed to avoid wrong names, wrong bases, or overwrites.
<type>/<short-desc>-<issueID>.<type>/<user-provided-name>; never invent an issue ID.feat, fix, refactor, docs, test, perf, chore.chore.-; remove punctuation, filler words, repeated separators, and non-branch characters.If the user gives an issue reference, run one gh call:
gh issue view <issueID> --json title,body,number
Use the title for short-desc; fall back to body or user context only when needed. If no issue is mentioned, do not call gh. If gh fails but context is enough, continue and report that issue metadata was not verified.
Validate:
git check-ref-format --branch <branch-name>
Prefer one shell call for local checks:
git status --short
git branch --show-current
git branch --list <branch-name>
Add remote/freshness checks only when they affect the result:
git branch --remotes --list '*/<branch-name>'
git fetch origin <base>
git rev-list --left-right --count <base>...origin/<base>
Base policy:
<base> to main unless repo guidance or the user names another base.origin/<base> over upstream/<base>.upstream only for fork workflows or explicit guidance.git-push sets upstream later.Stop only when the target branch exists, dirty worktree intent is ambiguous, the current/base branch is clearly unsafe, or freshness checks show the selected base is stale.
Use one of:
git switch -c <branch-name> <base>
git switch --no-track -c <branch-name> origin/<base>
Then verify with:
git branch --show-current
main, master, develop, release branches) unless explicitly asked.