oh-notes

Installation
SKILL.md

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

  1. Read dive context (if available) for project background:

    cat .wm/dive_context.md 2>/dev/null || echo "No dive context"
    
  2. 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 init
    

    Note: -B $BRANCH creates/resets the local branch to track origin.

  3. 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
    
  4. Identify unresolved comments:

    • Focus on actionable feedback requiring code changes
    • Ignore resolved/outdated comments
    • Skip non-actionable noise (e.g., "Thanks for the PR!")
  5. For each unresolved comment: a. Understand the feedback b. Make the fix c. Stage changes (git add) d. Run sg review on 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}"
    
  6. 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
  7. 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>"
    
  8. Push changes:

    git push
    
  9. 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)"
    
  10. Cleanup worktree:

    cd $ORIGINAL_DIR
    git worktree remove .worktrees/pr-<pr-number>
    
  11. 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
Weekly Installs
1
GitHub Stars
7
First Seen
Mar 30, 2026