creating-branch
Git Branch Creation Workflow
Execute feature branch creation with intelligent naming, automatic type detection, and sequential numbering.
Usage
This skill is invoked when:
- User runs
/create-branchor/git:create-branchcommand - User requests to create a new feature branch
- User asks to start a new branch for a task
Two Operation Modes
Mode 1: With Description (Manual)
The command takes a description and automatically detects the commit type.
Format: /create-branch <description>
Examples:
/create-branch add user authentication
→ Creates: feat/001-user-authentication
/create-branch fix login bug
→ Creates: fix/002-login-bug
/create-branch refactor auth service
→ Creates: refactor/003-auth-service
/create-branch remove deprecated code
→ Creates: chore/004-remove-deprecated
/create-branch document api endpoints
→ Creates: docs/005-document-api
Mode 2: Auto-Generate from Changes (No Arguments)
When no arguments provided and no sdlc-develop specs exist, analyze uncommitted changes to generate branch name automatically.
Format: /create-branch (no arguments)
Process:
- Check for sdlc-develop specs (see Mode 3)
- If no specs, check for uncommitted changes (both staged and unstaged)
- If no changes exist, display error and require description
- If changes exist, analyze to generate description
- Create branch with auto-generated name
Examples:
# After modifying authentication files
/create-branch
→ Auto-detected from changes: feat/006-authentication-system
→ (based on: login.py, auth_service.ts, user_model.py)
# After fixing payment bug
/create-branch
→ Auto-detected from changes: fix/007-payment-processing
→ (based on: payment.js, checkout.py)
Mode 3: From SDLC-Develop Spec (Arkhe Integration)
When no arguments provided and sdlc-develop specs exist, the skill can create branches linked to existing feature specs.
Detection Flow:
- Check if
.arkhe.yamlexists → readdevelop.specs_dir(default:arkhe/specs) - Scan
{specs_dir}/for existing spec directories - If specs found → present selection via
AskUserQuestion - Use spec directory name for branch name
Example:
# Specs exist: arkhe/specs/01-user-auth/, arkhe/specs/02-dashboard/
/create-branch
# Prompt: "Select a feature spec for this branch"
# Options: 01-user-auth, 02-dashboard, None (auto-generate from changes)
# User selects 01-user-auth
→ Creates: feat/01-user-auth
Commit Type Detection
The workflow automatically detects commit types from keywords in the description:
| Type | Keywords |
|---|---|
| feat | add, create, implement, new, update, improve |
| fix | fix, bug, resolve, correct, repair |
| refactor | refactor, rename, reorganize |
| chore | remove, delete, clean, cleanup |
| docs | docs, document, documentation |
If no keyword is detected, defaults to feat.
Branch Naming Format
Pattern: {type}/{number}-{keyword1}-{keyword2}
Components:
- type: Auto-detected commit type (feat, fix, refactor, chore, docs)
- number: Auto-incremented 3-digit number (001, 002, 003...)
- keywords: First 2-3 meaningful words from description (lowercase, hyphenated)
Examples:
-
Input: "add user authentication system"
-
Output:
feat/001-user-authentication -
Input: "fix null pointer in login"
-
Output:
fix/002-null-pointer
Important Notes
- Sequential Numbering: Finds next available number by scanning existing branches
- Keyword Extraction: Filters common words, keeps 2-3 meaningful terms
- Lowercase Convention: All branch names are lowercase with hyphens
- Conventional Commits: Aligns with conventional commit types
- SDLC-Develop Integration: Detects feature specs from
.arkhe.yaml
Supporting Documentation
- WORKFLOW.md - Detailed step-by-step process with bash scripts
- EXAMPLES.md - Real-world examples for all branch types
- TROUBLESHOOTING.md - Common issues and solutions
More from joaquimscosta/arkhe-claude-plugins
skill-validator
Validate skills against Anthropic best practices for frontmatter, structure, content, file organization, hooks, MCP, and security (62 rules in 8 categories). Use when creating new skills, updating existing skills, before publishing skills, reviewing skill quality, or when user mentions "validate skill", "check skill", "skill best practices", "skill review", or "lint skill".
30domain-driven-design
Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.
26code-explanation
Explains complex code through clear narratives, visual diagrams, and step-by-step breakdowns. Use when user asks to explain code, understand algorithms, analyze design patterns, wants code walkthroughs, or mentions "explain this code", "how does this work", "code breakdown", or "understand this function".
22generating-changelog
Analyzes git commit history and generates professional changelogs with semantic versioning, conventional commit support, and multiple output formats (Keep a Changelog, Conventional, GitHub). Use when editing CHANGELOG.md, CHANGELOG.txt, or HISTORY.md files, preparing release notes, creating releases, bumping versions, updating changelog, documenting changes, writing release notes, tracking changes, version bump, tag release, or when user mentions "changelog", "release notes", "version history", "release", "semantic versioning", or "conventional commits".
21workflow-orchestration
>
19generating-stitch-screens
>
19