oh-notes
oh-notes
Like notes, but for PRs from oh-task (GitHub issues). Address feedback on a PR - work in isolated worktree, resolve comments, push fixes. Uses GitHub issues for descendant tasks instead of ba.
Invocation
/oh-notes <pr-number>
<pr-number>- the pull request number to address comments on
Prerequisites
- Repo context: Run from the repo root where the PR exists
- GitHub issue PR: The PR should be from an oh-task session (branch
issue/<number>)
Flow
-
Read dive context (if available) for project background:
cat .wm/dive_context.md 2>/dev/null || echo "No dive context" -
Get PR branch info and create worktree:
# Save original directory for cleanup ORIGINAL_DIR=$(pwd) # Get the PR branch name and linked issue BRANCH=$(gh pr view <pr-number> --json headRefName -q .headRefName) # Extract issue number from branch (issue/<number>) PARENT_ISSUE=${BRANCH#issue/} # Fetch and create worktree tracking the remote branch git fetch origin git worktree add .worktrees/pr-<pr-number> -B $BRANCH origin/$BRANCH cd .worktrees/pr-<pr-number> sg initNote:
-B $BRANCHcreates/resets the local branch to track origin. -
Fetch PR comments (both top-level and inline review comments):
gh pr view <pr-number> --json comments,reviews gh api repos/{owner}/{repo}/pulls/<pr-number>/comments -
Identify unresolved comments:
- Focus on actionable feedback requiring code changes
- Ignore resolved/outdated comments
- Skip non-actionable noise (e.g., "Thanks for the PR!")
-
For each unresolved comment: a. Understand the feedback b. Make the fix c. Stage changes (
git add) d. Runsg reviewon staged changes e. Handle review findings:- P1-P3 trivial (one-liner fix): fix inline, re-stage, re-review
- P1-P3 non-trivial (significant change): create GitHub issue as descendant
- P4: discard (nitpick)
Creating descendant issues (instead of ba tasks):
# Create issue linked to parent NEW_ISSUE=$(gh issue create \ --title "Fix: <brief description>" \ --body "Spawned from #${PARENT_ISSUE} during PR #<pr-number> review. ## Context <what sg review found> ## Acceptance - [ ] Fix applied - [ ] sg review passes" \ --assignee @me | grep -oE '[0-9]+$') echo "Created descendant issue #${NEW_ISSUE}" -
Complete ALL descendant issues before commit. Any GitHub issue created during this session = descendant that blocks push.
Note: If feedback requires significant architectural changes, consider escalating back to the original task author rather than creating many descendant issues.
While ANY unclosed issues created in this session:
- Work on the fix (same worktree, same branch)
- Stage changes
- Run
sg review(each issue gets its own review!) - Handle findings (may spawn more descendants)
- Commit with "Fixes #" to auto-close
- Loop until zero unclosed descendants
-
Commit all fixes:
# If there are descendant issues to close, include them in commit git commit -m "address PR #<pr-number> feedback - <summary of each addressed comment> Fixes #<descendant-issue-1> Fixes #<descendant-issue-2>" -
Push changes:
git push -
Reply to addressed comments (optional but helpful):
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies \ -f body="Fixed in $(git rev-parse --short HEAD)" -
Cleanup worktree:
cd $ORIGINAL_DIR git worktree remove .worktrees/pr-<pr-number> -
Exit and report:
- List addressed comments
- Note any unresolved items that need human decision
- Provide PR URL
Comment Handling
Actionable Comments (address)
- "This should handle null case"
- "Missing error handling"
- "Variable name is confusing"
- "Add test for edge case"
Non-Actionable (skip, report)
- Questions without clear ask: "Why did you do it this way?" (can address with code comment if helpful)
- Design debates: "Have you considered X approach?"
- Requests requiring human decision: "Should we use A or B?"
When in doubt, address it. Better to over-fix than under-fix.
Review Handling
- P1-P3 findings: Create as GitHub issues, work them in this session
- P4 findings: Discard as nitpicks (don't create issues)
Exit Conditions
- Success: All actionable comments addressed, changes pushed
- Blocked: Comment requires human decision - report and stop
- Safety: Max 10 issue iterations (prevent runaway)
Completion Signaling (MANDATORY)
CRITICAL: You MUST signal completion when done. Call the signal_completion tool as your FINAL action.
Signal based on outcome:
| Outcome | Call |
|---|---|
| All comments addressed | signal_completion(status: "success", pr: "<pr-url>") |
| Needs human decision | signal_completion(status: "blocked", blocker: "<reason>") |
| Unrecoverable failure | signal_completion(status: "error", error: "<reason>") |
| If you do not signal, the orchestrator will not know you are done and the session becomes orphaned. |
Fallback: If the signal_completion tool is not available, output your completion status as your final message in the format: COMPLETION: status=<status> pr=<url> or COMPLETION: status=<status> error=<reason>.
Example
$ /oh-notes 42
Getting PR #42 info...
Branch: issue/123
Parent issue: #123
Creating worktree .worktrees/pr-42 on branch issue/123
Initializing superego...
Fetching comments...
Found 4 comments:
1. "Add null check before accessing user.email" (line 45)
2. "This error message could be clearer" (line 72)
3. [coderabbit] "Consider using optional chaining" (line 45)
4. "Why not use the existing validate() function?" -> needs decision
Addressing comment 1: Add null check...
Staging changes...
Running sg review...
No issues found.
Addressing comment 2: Improve error message...
Staging changes...
Running sg review...
No issues found.
Addressing comment 3: Use optional chaining...
Staging changes...
Running sg review...
No issues found.
Skipping comment 4: Requires human decision
(Unsure whether to refactor to use validate() or keep current approach)
Committing fixes...
[issue/123 a1b2c3d] address PR #42 feedback
- Add null check before accessing user.email
- Improve error message clarity
- Use optional chaining per CodeRabbit suggestion
Pushing...
To github.com:org/repo.git
f1e2d3c..a1b2c3d issue/123 -> issue/123
Cleaning up worktree...
signal_completion(status: "blocked", blocker: "Comment about validate() function needs decision")
Done.
Addressed: 3 comments
Blocked: 1 (comment about validate() function)
PR: https://github.com/org/repo/pull/42
With Descendant Issue
$ /oh-notes 43
Getting PR #43 info...
Branch: issue/456
Parent issue: #456
Creating worktree .worktrees/pr-43 on branch issue/456
Initializing superego...
Fetching comments...
Found 1 comment:
1. "Add input validation" (line 12)
Addressing comment 1: Add input validation...
Staging changes...
Running sg review...
sg review found P2 issue:
"Validation should also handle edge case X"
Creating descendant issue...
Created issue #457: "Fix: Handle validation edge case X"
Working on #457...
Making fix...
Staging...
Running sg review...
No issues found.
Committing all fixes...
[issue/456 b2c3d4e] address PR #43 feedback
- Add input validation per review
- Handle validation edge case X
Fixes #457
Pushing...
Cleaning up worktree...
signal_completion(status: "success", pr: "https://github.com/org/repo/pull/43")
Done.
Addressed: 1 comment
Descendant issues closed: #457
PR: https://github.com/org/repo/pull/43