dev

Development workflow utilities for branching, PR management, and review feedback.

Creating branches

Create a new branch off the latest default branch commit.

Workflow

1. Fetch latest from remote
2. Detect default branch (main or master)
3. Create branch with descriptive name based on task
4. Switch to new branch

Branch naming

Generate a short, kebab-case name from the task:

• add-user-auth not add-user-authentication-feature
• fix-login-bug not fix-the-bug-in-the-login-flow
• refactor-api not refactor-api-endpoints-for-better-performance

Use a prefix if the repo convention requires one (check existing branches).

bash
1# Fetch and get default branch
2git fetch origin
3git remote show origin | sed -n '/HEAD branch/s/.*: //p'
4
5# Create branch from latest default branch
6git checkout -b <branch-name> origin/main
7
8# See existing branch naming patterns
9git branch -r | head -20

If branches use prefixes like feature/, fix/, or username prefixes like wcm/, follow that pattern.

Review feedback

Address GitHub PR review comments and reply to reviewers.

Workflow

1. Get pending review comments - fetch unresolved comments
2. Address each comment - make code changes to resolve feedback
3. Commit with clear message - reference what feedback was addressed
4. Reply to reviewer - concise reply with commit SHA and explanation

Getting review comments

bash
1# All comments on a PR (includes replies)
2gh pr view <pr-number> --comments --json comments
3
4# Review comments (code-level feedback)
5gh api repos/{owner}/{repo}/pulls/{pr}/comments --jq '.[] | {id, path, line, body, user: .user.login, in_reply_to_id}'
6
7# Pending/unresolved comments (no replies yet)
8gh api repos/{owner}/{repo}/pulls/{pr}/comments --jq '[.[] | select(.in_reply_to_id == null)] | .[] | {id, path, body: .body[0:100]}'

Replying to comments

bash
1# Reply to a review comment
2gh api repos/{owner}/{repo}/pulls/{pr}/comments \
3  --method POST \
4  -f body="Fixed in abc1234 - renamed to run-test.js" \
5  -F in_reply_to=<comment-id>

Good reply format

Replies should be:

• Concise - one sentence is often enough
• Reference commit SHA - so reviewer can verify
• Explain how - brief description of the fix

Examples:

• Fixed in abc1234 - renamed to run-test.js as suggested
• Addressed in def5678 - now uses a single rule in cook.mk
• Good catch, fixed in 789abcd - removed the duplicate import

Complete example

bash
1# 1. Get pending comments on PR #269
2gh api repos/whilp/world/pulls/269/comments \
3  --jq '.[] | select(.in_reply_to_id == null) | {id, path, body}'
4
5# Output:
6# {"id":2702089939,"path":"lib/appscript/run-tests.js","body":"run-tests.js should be run-test.js..."}
7
8# 2. Make the fix and commit
9git mv lib/appscript/run-tests.js lib/appscript/run-test.js
10git commit -m "appscript: rename run-tests.js to run-test.js"
11# Commit SHA: abc1234
12
13# 3. Reply to the comment
14gh api repos/whilp/world/pulls/269/comments \
15  --method POST \
16  -f body="Fixed in abc1234 - renamed to run-test.js" \
17  -F in_reply_to=2702089939

Batch processing

For multiple comments:

bash
1# Get all pending comments as JSON
2gh api repos/{owner}/{repo}/pulls/{pr}/comments \
3  --jq '[.[] | select(.in_reply_to_id == null)] | group_by(.path) | .[] | {path: .[0].path, comments: [.[] | {id, body}]}'

This groups comments by file for efficient processing.