Git branch management, commit conventions, and PR creation workflow. Use for all tasks that require code changes, regardless of language or scope.
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
skills listSkill Instructions
name: git-workflow description: Git branch management, commit conventions, and PR creation workflow. Use for all tasks that require code changes, regardless of language or scope.
Git Workflow
Standard Git workflow for all tasks in this repository.
⚠️ MANDATORY: Check Branch Before Starting ANY Task
This is the FIRST step for ANY task that involves code changes.
Before writing any code or making any changes, you MUST check the current branch:
git branch --show-current
Decision Flow
Current Branch?
│
├─ main → ❌ DO NOT work here
│ → Create a new branch first (see "Creating a New Branch")
│
├─ Feature branch for this task → ✅ Continue working
│
└─ Different feature branch → ⚠️ Ask user which branch to use
If on main Branch
NEVER make changes directly on main. Always create a new branch first:
# 1. Ensure main is up to date
git fetch origin
git reset --hard origin/main
# 2. Create new branch
git checkout -b {type}/issue-{number}-{description}
If on Wrong Feature Branch
Ask the user:
"You are currently on branch {current-branch}. Should I:
- Continue working on this branch?
- Switch to
mainand create a new branch for this task?"
Example Check Output
$ git branch --show-current
main
# → Must create new branch before any work!
$ git branch --show-current
feature/issue-123-add-taproot
# → OK to continue if this is the correct branch for the task
Branch Management
Creating a New Branch
Always create from latest main:
git fetch origin
git checkout main
git reset --hard origin/main
git checkout -b {type}/issue-{number}-{brief-description}
Branch Naming Convention
| Type | Prefix | Example |
|---|---|---|
| Feature | feature/ | feature/issue-123-add-taproot |
| Bug fix | fix/ | fix/issue-456-db-connection |
| Refactoring | refactor/ | refactor/issue-789-clean-arch |
| Documentation | docs/ | docs/311-update-readme |
| DevOps/CI | ci/ | ci/issue-100-add-workflow |
| Chore | chore/ | chore/issue-200-update-deps |
Branch Rules
- Always from
main: Never branch from feature branches - One issue = One branch: 1つのissueに対して1つのbranchのみ作成
- Short-lived: Merge within days, not weeks
- Delete after merge: Keep repository clean
⚠️ 重要: 複数ブランチ禁止ルール
1つのissueに対して複数のbranchを作成しないでください。
❌ 禁止パターン:
issue-123 → fix/issue-123-first-attempt
→ fix/issue-123-second-attempt ← これは作らない
→ fix/issue-123-another-fix ← これも作らない
✅ 正しいパターン:
issue-123 → fix/issue-123-description
→ PR作成 → レビュー → マージ
→ (必要なら) 新しいissueで新しいbranch
作業開始前の確認
新しいbranchを作成する前に、必ず以下を確認:
# 1. 既存のブランチを確認
git branch -a | grep "issue-{number}"
# 2. 既存のPRを確認
gh pr list --search "issue-{number}"
- 既存branchがある場合: そのbranchで作業を継続
- 既存PRがある場合: PRをmergeしてから新しい作業を開始
- 何もない場合: 新しいbranchを作成してOK
Commit Conventions
This project uses Conventional Commits format.
Commit messages are validated by lefthook commit-msg hook.
Format
{type}({scope}): {brief description}
- {detail 1}
- {detail 2}
Closes #{issue_number}
Types (Required)
| Type | Description | Release Impact |
|---|---|---|
feat | New feature | MINOR |
fix | Bug fix | PATCH |
docs | Documentation only | - |
refactor | Code refactoring (no feature/fix) | - |
test | Adding or updating tests | - |
ci | CI/CD changes | - |
chore | Maintenance tasks | - |
build | Build system changes | - |
perf | Performance improvements | PATCH |
style | Code style (formatting, etc.) | - |
revert | Revert a previous commit | - |
Breaking Changes
Add ! after type/scope to indicate breaking changes:
feat(btc)!: change address format to bech32m only
fix!: remove deprecated API endpoint
Scope (Optional)
The following are suggested scopes, but other alphanumeric scopes are also permitted.
| Scope | Description |
|---|---|
btc | Bitcoin-related |
bch | Bitcoin Cash-related |
eth | Ethereum-related |
xrp | XRP-related |
db | Database |
api | API changes |
cli | CLI changes |
pr | PR review fixes |
Examples
# Feature with scope
git commit -m "feat(btc): add taproot address support
- Add bech32m encoding
- Update address validation
Closes #123"
# Bug fix without scope
git commit -m "fix: resolve database connection timeout
- Increase pool timeout
- Add retry logic
Closes #456"
# Documentation
git commit -m "docs: update architecture guide
- Add layer diagram
- Clarify dependency rules
Closes #789"
# Breaking change
git commit -m "feat(btc)!: require bech32m for all taproot addresses
BREAKING CHANGE: Legacy address format no longer supported
Closes #999"
Validation Error
If commit message validation fails:
ERROR: Commit message does not follow Conventional Commits format.
Expected format: <type>(<scope>): <description>
Types: feat, fix, docs, refactor, test, ci, chore, build, perf, style, revert
Examples:
feat(btc): add taproot address support
fix: resolve database connection timeout
docs: update architecture guide
refactor(api): reorganize endpoint handlers
Your commit message: <your-invalid-commit-message>
Pull Request Creation
⚠️ MANDATORY: Ask Before Creating PR
Always ask the user before creating a PR.
Multi-phase tasks create multiple commits on a single branch. Do not create a PR until all commits are complete.
After commits are pushed, ALWAYS ask:
> "Would you like me to create a PR? Or is there additional work to do?"
When to Ask
| Situation | Action |
|---|---|
| Single commit task | Ask before creating PR |
| Multi-phase task | Ask after ALL phases are complete |
| User explicitly requests PR | Create PR without asking |
Create PR
git push -u origin {branch-name}
# Ask user: "Would you like me to create a PR?"
# Only proceed if user confirms
gh pr create --title "{type}: {description}" --body "$(cat <<'EOF'
## Summary
- {change 1}
- {change 2}
## Test plan
- [ ] Verification commands pass
- [ ] Manual testing completed
Closes #{issue_number}
EOF
)"
PR Title Format
{type}: {description} (Closes #{issue_number})
Examples:
feat: add taproot address support (Closes #123)fix: resolve database connection timeout (Closes #456)docs: update architecture guide (Closes #789)
PR Description Template
## Summary
- Brief description of changes
## Changes
- Change 1
- Change 2
## Test plan
- [ ] Unit tests pass
- [ ] Integration tests pass (if applicable)
- [ ] Manual testing completed
## Related
- Closes #{issue_number}
- Related to #{other_issue}
Pre-Commit Self-Review (Required)
Before EVERY commit, you MUST complete self-review:
Step 1: Run Verification Commands
Execute verification commands for the modified file types:
| File Type | Required Commands |
|---|---|
Go (*.go) | make go-lint && make tidy && make check-build && make gotest |
TypeScript (*.ts) | cd apps/{app} && npm run lint && npm run build |
Shell (*.sh) | make shfmt |
| Makefile | make mk-lint |
| SQL/HCL | make atlas-fmt && make atlas-lint |
Step 2: Complete Self-Review Checklist
Read the applicable language skill and verify ALL checklist items:
| File Type | Skill | Section to Check |
|---|---|---|
Go (*.go) | go-development | Self-Review Checklist |
| TypeScript/JS | typescript-development | Self-Review Checklist |
Shell (*.sh) | shell-scripts | Verification Checklist |
| Makefile | makefile-update | Verification Checklist |
| SQL/HCL | db-migration | Verification Checklist |
Step 3: Confirm Before Commit
Only proceed to commit after:
- All verification commands pass
- Self-review checklist is complete
- No unresolved linter errors
⚠️ DO NOT commit until all steps are verified.
Safety Rules
Allowed Operations
git add- Stage changesgit commit- Create commitsgit push- Push to remotegit checkout -b- Create branches
NOT Allowed Operations
git push --force- Never force pushgit merge- Don't merge locallygit rebaseon shared branches - Avoid rebasing- Direct commits to
main- Always use PRs
Quick Reference
New Issue Workflow
# 0. 既存ブランチ/PRを確認(必須)
git branch -a | grep "issue-{number}"
gh pr list --search "issue-{number}"
# → 既存があれば、そのbranchで作業を継続
# 1. Update main
git fetch origin && git checkout main && git reset --hard origin/main
# 2. Create branch (既存がない場合のみ)
git checkout -b {type}/issue-{number}-{description}
# 3. Make changes...
# 4. Self-Review (REQUIRED - see "Pre-Commit Self-Review" section)
# - Run verification commands for modified file types
# - Complete self-review checklist from language skill
# - Confirm no linter errors
# 5. Commit (only after self-review is complete)
git add <files>
git commit -m "{type}: {description}
Closes #{number}"
# 6. Push
git push -u origin {branch-name}
# 7. Ask user before creating PR (REQUIRED)
# "Would you like me to create a PR? Or is there additional work?"
# Only create PR if user confirms
gh pr create --title "{type}: {description}"
PR Review Fixes
# Already on PR branch
# 1. Make fixes...
# 2. Self-Review (REQUIRED)
# Run verification commands & complete checklist
# 3. Commit and push
git add <files>
git commit -m "fix(pr): address review comments"
git push
More by hiromaily
View allTypeScript/JavaScript development workflow for apps/ directory. Use when modifying TypeScript code in ripple-lib-server or JavaScript in erc20-token.
CI/CD and DevOps workflow. Use when modifying GitHub Actions, Docker configurations, or compose files.
Shell script development workflow. Use when modifying files in scripts/ directory or any *.sh files.
Create GitHub issues with proper task classification. Classification determines which Skills will be used when working on the issue.
