Manage git operations for spec-driven development. Use when creating branches for specs/features, generating commits, or creating PRs. Provides consistent git workflow across specify, implement, and refactor commands. Handles branch naming, commit messages, and PR descriptions based on spec context.
/plugin marketplace add rsmdt/the-startup/plugin install start@the-startupThis skill is limited to using the following tools:
You are a git workflow specialist that provides consistent version control operations across the development lifecycle.
Activate this skill when you need to:
| Context | Pattern | Example |
|---|---|---|
| Specification | spec/[id]-[name] | spec/001-user-auth |
| Implementation | feature/[id]-[name] | feature/001-user-auth |
| Migration | migrate/[from]-to-[to] | migrate/react-17-to-18 |
| Refactor | refactor/[scope] | refactor/auth-module |
<type>(<scope>): <description>
[optional body]
[optional footer]
Co-authored-by: Claude <claude@anthropic.com>
Types:
feat - New featurefix - Bug fixdocs - Documentationrefactor - Code refactoringtest - Adding testschore - MaintenanceWhen: Before any git operation
# Check if git repository
git rev-parse --is-inside-work-tree 2>/dev/null
# Get current branch
git branch --show-current
# Check for uncommitted changes
git status --porcelain
# Get remote info
git remote -v
Output:
š Repository Status
Repository: ā
Git repository detected
Current Branch: [branch-name]
Remote: [origin-url]
Uncommitted Changes: [N] files
Ready for git operations: [Yes/No]
When: Starting new spec or implementation
Input Required:
context: "spec" | "feature" | "migrate" | "refactor"identifier: Spec ID, feature name, or migration descriptionname: Human-readable name (will be slugified)Process:
# Ensure clean state or stash changes
if [ -n "$(git status --porcelain)" ]; then
echo "Uncommitted changes detected"
# Ask user: stash, commit, or abort
fi
# Get base branch
base_branch=$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')
# Create branch based on context
case $context in
"spec")
branch_name="spec/${identifier}-${name_slug}"
;;
"feature")
branch_name="feature/${identifier}-${name_slug}"
;;
"migrate")
branch_name="migrate/${name_slug}"
;;
"refactor")
branch_name="refactor/${name_slug}"
;;
esac
# Create and checkout
git checkout -b "$branch_name"
Output:
š Branch Created
Branch: [branch-name]
Base: [base-branch]
Context: [spec/feature/migrate/refactor]
Ready to proceed.
When: After creating/updating specification documents
Input Required:
spec_id: Spec identifier (e.g., "001")spec_name: Spec namephase: "prd" | "sdd" | "plan" | "all"Commit Messages by Phase:
# PRD phase
git commit -m "docs(spec-${spec_id}): Add product requirements
Defines requirements for ${spec_name}.
See: docs/specs/${spec_id}-${spec_name_slug}/product-requirements.md
Co-authored-by: Claude <claude@anthropic.com>"
# SDD phase
git commit -m "docs(spec-${spec_id}): Add solution design
Architecture and technical design for ${spec_name}.
See: docs/specs/${spec_id}-${spec_name_slug}/solution-design.md
Co-authored-by: Claude <claude@anthropic.com>"
# PLAN phase
git commit -m "docs(spec-${spec_id}): Add implementation plan
Phased implementation tasks for ${spec_name}.
See: docs/specs/${spec_id}-${spec_name_slug}/implementation-plan.md
Co-authored-by: Claude <claude@anthropic.com>"
# All phases (initial spec)
git commit -m "docs(spec-${spec_id}): Create specification for ${spec_name}
Complete specification including:
- Product requirements (PRD)
- Solution design (SDD)
- Implementation plan (PLAN)
See: docs/specs/${spec_id}-${spec_name_slug}/
Co-authored-by: Claude <claude@anthropic.com>"
When: After implementing spec phases
Input Required:
spec_id: Spec identifierspec_name: Spec namephase: Current implementation phasesummary: Brief description of changesCommit Message:
git commit -m "feat(${spec_id}): ${summary}
Implements phase ${phase} of specification ${spec_id}-${spec_name}.
See: docs/specs/${spec_id}-${spec_name_slug}/
Co-authored-by: Claude <claude@anthropic.com>"
When: After completing spec or implementation
Input Required:
context: "spec" | "feature"spec_id: Spec identifierspec_name: Spec namesummary: Executive summary (from PRD if available)PR Templates:
gh pr create \
--title "docs(spec-${spec_id}): ${spec_name}" \
--body "$(cat <<'EOF'
## Specification: ${spec_name}
${summary}
## Documents
- [ ] Product Requirements (PRD)
- [ ] Solution Design (SDD)
- [ ] Implementation Plan (PLAN)
## Review Checklist
- [ ] Requirements are clear and testable
- [ ] Architecture is sound and scalable
- [ ] Implementation plan is actionable
- [ ] No [NEEDS CLARIFICATION] markers remain
## Related
- Spec Directory: \`docs/specs/${spec_id}-${spec_name_slug}/\`
EOF
)"
gh pr create \
--title "feat(${spec_id}): ${spec_name}" \
--body "$(cat <<'EOF'
## Summary
${summary}
## Specification
Implements specification [\`${spec_id}-${spec_name}\`](docs/specs/${spec_id}-${spec_name_slug}/).
## Changes
[Auto-generated from git diff summary]
## Test Plan
- [ ] All existing tests pass
- [ ] New tests added for new functionality
- [ ] Manual verification completed
## Checklist
- [ ] Code follows project conventions
- [ ] Documentation updated if needed
- [ ] No breaking changes (or migration path provided)
- [ ] Specification compliance verified
EOF
)"
When branch creation is appropriate, present options via AskUserQuestion:
š Git Workflow
This work could benefit from version control tracking.
Options:
1. Create [context] branch (Recommended)
ā Creates [branch-name] from [base-branch]
2. Work on current branch
ā Continue on [current-branch]
3. Skip git integration
ā No branch management
When uncommitted changes exist:
ā ļø Uncommitted Changes Detected
[N] files have uncommitted changes.
Options:
1. Stash changes (Recommended)
ā Save changes, create branch, restore later
2. Commit changes first
ā Commit current work, then create branch
3. Proceed anyway
ā Create branch with uncommitted changes
4. Cancel
ā Abort branch creation
When work is complete:
š Work Complete
Ready to create a pull request?
Options:
1. Create PR (Recommended)
ā Push branch and create PR with description
2. Commit only
ā Commit changes without PR
3. Push only
ā Push branch without PR
4. Skip
ā Leave changes uncommitted
Call this skill for:
spec/[id]-[name] branchCall this skill for:
feature/[id]-[name] branchCall this skill for:
refactor/[scope] branchmigrate/[from]-to-[to] for migrationsš Git Operation Complete
Operation: [Branch Created / Commit Made / PR Created]
Branch: [branch-name]
Status: [Success / Failed]
[Context-specific details]
Next: [What happens next]
š Pull Request Created
PR: #[number] - [title]
URL: [github-url]
Branch: [source] ā [target]
Status: Ready for review
Reviewers: [if auto-assigned]
Labels: [if auto-added]
| Error | Cause | Resolution |
|---|---|---|
| "Not a git repository" | Not in git repo | Skip git operations or init |
| "Branch already exists" | Duplicate name | Offer to checkout or rename |
| "Uncommitted changes" | Dirty working tree | Stash, commit, or proceed |
| "No remote configured" | No upstream | Skip push/PR or configure |
| "gh not installed" | Missing GitHub CLI | Use git push, skip PR |
ā ļø Git Operation Limited
Issue: [What's wrong]
Impact: [What can't be done]
Available Options:
1. [Alternative 1]
2. [Alternative 2]
3. Proceed without git integration
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.