create-branch
Create a git branch following Sentry naming conventions. Use when asked to "create a branch", "new branch", "start a branch", "make a branch", "switch to a new branch", or when starting new work on the default branch.
About this skill
This skill empowers an AI agent to efficiently create new Git branches, ensuring adherence to standardized Sentry naming conventions. The process involves dynamically retrieving the user's GitHub username to form a consistent branch prefix. The descriptive part of the branch name is derived either from direct arguments provided by the user or intelligently inferred from the context of the user's request. By automating this common development task, the skill promotes consistent Git hygiene and streamlines the initial setup for new features, bug fixes, or general development tasks.
Best use case
Initiating new development tasks, creating feature branches, setting up branches for bug fixes, or any scenario requiring a new Git branch with a standardized naming structure.
Create a git branch following Sentry naming conventions. Use when asked to "create a branch", "new branch", "start a branch", "make a branch", "switch to a new branch", or when starting new work on the default branch.
A new Git branch will be successfully created in the user's local repository. The branch name will adhere to the Sentry convention, typically structured as `type/username/description` (e.g., `feature/johndoe/add-login-page`), utilizing the GitHub login for the username prefix and a descriptive name derived from the user's input.
Practical example
Example input
Create a new branch for the user profile page redesign.
Example output
Agent: Successfully created branch: `feature/johndoe/user-profile-redesign`.
When to use this skill
- Use when a user explicitly requests to 'create a branch', 'new branch', 'start a branch', 'make a branch', or 'switch to a new branch'. It's also suitable when an AI agent detects the user is initiating new work that requires a dedicated branch, especially when maintaining consistent Git naming conventions is important.
When not to use this skill
- Avoid using when complex Git operations beyond simple branch creation are needed (e.g., rebasing, merging with conflicts, cherry-picking), when an organization's branch naming conventions significantly differ from Sentry's, or in environments where the `gh` (GitHub CLI) tool is not installed or the agent lacks proper GitHub authentication.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/create-branch/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How create-branch Compares
| Feature / Agent | create-branch | Standard Approach |
|---|---|---|
| Platform Support | Claude | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | easy | N/A |
Frequently Asked Questions
What does this skill do?
Create a git branch following Sentry naming conventions. Use when asked to "create a branch", "new branch", "start a branch", "make a branch", "switch to a new branch", or when starting new work on the default branch.
Which AI agents support this skill?
This skill is designed for Claude.
How difficult is it to install?
The installation complexity is rated as easy. You can find the installation instructions above.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
Top AI Agents for Productivity
See the top AI agent skills for productivity, workflow automation, operational systems, documentation, and everyday task execution.
SKILL.md Source
# Create Branch Create a git branch with the correct type prefix and a descriptive name following Sentry conventions. ## When to Use - You need to create a new git branch that follows the repository's naming convention. - You are starting a new piece of work from the default branch and need help classifying it as `feat`, `fix`, `docs`, or another branch type. - You want the branch name proposed from either the task description or the current local diff. ## Step 1: Get the Username Prefix Run `gh api user --jq .login` to get the GitHub username. If the command fails (e.g. not authenticated), ask the user for their preferred prefix. ## Step 2: Determine the Branch Description **If `$ARGUMENTS` is provided**, use it as the description of the work. **If no arguments**, check for local changes: ```bash git diff git diff --cached git status --short ``` - **Changes exist**: read the diff content to understand what the work is about and generate a description. - **No changes**: ask the user what they are about to work on. ## Step 3: Classify the Type Pick the type from this table based on the description: | Type | Use when | | --------- | --------------------------------------------------------------------- | | `feat` | New user-facing functionality | | `fix` | Broken behavior now works | | `ref` | Same behavior, different structure | | `chore` | Deps, config, version bumps, updating existing tooling — no new logic | | `perf` | Same behavior, faster | | `style` | CSS, formatting, visual-only | | `docs` | Documentation only | | `test` | Tests only | | `ci` | CI/CD config | | `build` | Build system | | `meta` | Repo metadata changes | | `license` | License changes | When unsure: `feat` for new things (including new scripts, skills, or tools), `ref` for restructuring existing things, `chore` only when updating/maintaining something that already exists. ## Step 4: Generate and Propose Build the branch name as `<username>/<type>/<short-description>`. Rules for `<short-description>`: - Kebab-case, lowercase - 3 to 6 words, concise but clear - Describe the change, not file names - Only use ASCII letters, digits, and hyphens — no spaces, dots, colons, tildes, or other git-forbidden characters Present it to the user and ask if they want to use it, modify it, or change the type. ### Examples | Work description | Branch name | | ------------------------------------------ | ------------------------------------------- | | Dropdown menu not closing on outside click | `priscila/fix/dropdown-not-closing-on-blur` | | Adding search to conversations page | `priscila/feat/add-search-to-conversations` | | Restructuring drawer components | `priscila/ref/simplify-drawer-components` | | Updating test fixtures | `priscila/chore/update-test-fixtures` | | Bumping @sentry/react to latest version | `priscila/chore/bump-sentry-react` | | Adding a new agent skill | `priscila/feat/add-create-branch-skill` | ## Step 5: Create the Branch Once confirmed, detect the current and default branch: ```bash git branch --show-current git remote | grep -qx origin && echo origin || git remote | head -1 git symbolic-ref refs/remotes/<remote>/HEAD 2>/dev/null | sed 's|refs/remotes/<remote>/||' | tr -d '[:space:]' ``` If `symbolic-ref` fails, fall back to `git branch --list main master`: use the one that exists; if both or neither exist, ask the user. If `git branch --show-current` is empty (detached HEAD), show the current commit (`git rev-parse --short HEAD`) and ask whether to branch from it or switch to the default branch first. Otherwise, if the current branch is not the default branch, warn the user and ask whether to branch from the current branch or switch to the default branch first. If the user wants to switch to the default branch, handle any uncommitted changes appropriately (offer to stash them if present), then run `git checkout <default-branch>`. On any failure, restore stashed changes if applicable and stop. Before creating the branch, check that the name doesn't already exist locally or on the remote (`git show-ref`). If it does, ask the user to choose a different name. Create the branch: ```bash git checkout -b <branch-name> ``` Restore any stashed changes after the branch is created. ## References - [Sentry Branch Naming](https://develop.sentry.dev/sdk/getting-started/standards/code-submission/#branch-naming)
Related Skills
create-pr
Alias for sentry-skills:pr-writer. Use when users explicitly ask for "create-pr" or reference the legacy skill name. Redirects to the canonical PR writing workflow.
n8n-expression-syntax
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.
mermaid-expert
Create Mermaid diagrams for flowcharts, sequences, ERDs, and architectures. Masters syntax for all diagram types and styling.
mcp-builder-ms
Use this skill when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
makepad-deployment
CRITICAL: Use for Makepad packaging and deployment. Triggers on: deploy, package, APK, IPA, 打包, 部署, cargo-packager, cargo-makepad, WASM, Android, iOS, distribution, installer, .deb, .dmg, .nsis, GitHub Actions, CI, action, marketplace
macos-menubar-tuist-app
Build, refactor, or review SwiftUI macOS menubar apps that use Tuist.
kaizen
Guide for continuous improvement, error proofing, and standardization. Use this skill when the user wants to improve code quality, refactor, or discuss process improvements.
issues
Interact with GitHub issues - create, list, and view issues.
hugging-face-tool-builder
Your purpose is now is to create reusable command line scripts and utilities for using the Hugging Face API, allowing chaining, piping and intermediate processing where helpful. You can access the API directly, as well as use the hf command line tool.
git-pushing
Stage all changes, create a conventional commit, and push to the remote branch. Use when explicitly asks to push changes ("push this", "commit and push"), mentions saving work to remote ("save to github", "push to remote"), or completes a feature and wants to share it.
git-hooks-automation
Master Git hooks setup with Husky, lint-staged, pre-commit framework, and commitlint. Automate code quality gates, formatting, linting, and commit message enforcement before code reaches CI.
gh-review-requests
Fetch unread GitHub notifications for open PRs where review is requested from a specified team or opened by a team member. Use when asked to "find PRs I need to review", "show my review requests", "what needs my review", "fetch GitHub review requests", or "check team review queue".