Files
dotfiles/.config/opencode/skills/git-workflow/SKILL.md
2026-03-08 14:37:55 +00:00

3.6 KiB

name, description
name description
git-workflow Procedures for git commits, worktrees, branches, and GitHub PRs — load before any git operation

Git Commit Procedure

  1. Run git status to see all untracked and modified files.
  2. Run git diff (staged + unstaged) to review changes that will be committed.
  3. Run git log --oneline -5 to see recent commit message style.
  4. Draft a Conventional Commit message (feat:, fix:, chore:, refactor:, docs:, test:):
    • Focus on why, not what.
    • 1-2 sentences max.
    • Match the repository's existing style.
  5. Check for secrets: do NOT commit .env, credentials, key files, or .megamemory/ contents.
  6. If .megamemory/ is not in .gitignore, add it before the first commit.
  7. Stage relevant files: git add <files> (not blindly git add .).
  8. Commit: git commit -m "<message>".
  9. Run git status after commit to verify success.

Git Worktree Procedure

When to use worktrees:

  • Always use a worktree for new feature work to keep main clean.
  • One worktree per independent workstream. If implementing multiple unrelated features, create separate worktrees for each.

Deciding on worktree count:

  • 1 worktree: Single feature, or 2 tightly-coupled features sharing state/files.
  • 2+ worktrees: Features that touch different domains, have different risk profiles, or could ship independently. Each gets its own worktree, branch, and PR.

Creating a worktree for a new feature:

# From project root
git worktree add .worktrees/<feature-name> -b <branch-name>

Creating multiple worktrees for independent workstreams:

# From project root — create all worktrees upfront
git worktree add .worktrees/<workstream-1> -b feat/<workstream-1>
git worktree add .worktrees/<workstream-2> -b feat/<workstream-2>

Working in a worktree:

  • All file edits, test runs, and dev server starts must use the worktree path.
  • Example: workdir="/path/to/project/.worktrees/my-feature" for all bash commands.
  • Each coder invocation must target a specific worktree — never mix worktrees in one coder dispatch.

Completing a worktree:

# From main working tree
git checkout main
git merge <branch-name>
git worktree remove .worktrees/<feature-name>
git branch -d <branch-name>  # optional cleanup

Completing multiple worktrees (independent PRs):

Complete and merge each worktree independently. If workstream-2 depends on workstream-1, merge workstream-1 first, then rebase workstream-2 before merging.

GitHub PR Procedure

Push and create PR:

# Push branch
git push -u origin <branch-name>

# Create PR with heredoc body
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
- <bullet 1>
- <bullet 2>

## Changes
- <file/area>: <what changed>

## Testing
- <how it was validated>
EOF
)"

Check CI status:

gh run list                    # List recent workflow runs
gh run view <run-id>           # View specific run details
gh pr checks <pr-number>       # Check statuses on a PR

Issue operations:

gh issue list                  # List open issues
gh issue view <number>         # View specific issue
gh issue comment <number> -b "<comment>"  # Add comment

Safety Rules

  • Never git push --force to main/master unless the user explicitly confirms.
  • Never skip hooks (--no-verify) unless the user explicitly requests it.
  • Never git commit --amend unless: (1) explicitly requested OR pre-commit hook auto-modified files, (2) HEAD was created in this session, AND (3) commit has NOT been pushed to remote.
  • If commit fails due to pre-commit hook, fix the issue and create a NEW commit.