Menu
Create repository-compliant branches with efficient issue naming, base selection, and safety checks.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.