draft-pr-review

Post review findings as a pending (draft) GitHub review with inline comments. Use AFTER reviewing code (via /reviewing-code or manually) when Tim says "draft review", "post as draft", "create pending review", "leave draft comments", or asks to put review findings on the PR as inline comments.

6 stars

Best use case

draft-pr-review is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Post review findings as a pending (draft) GitHub review with inline comments. Use AFTER reviewing code (via /reviewing-code or manually) when Tim says "draft review", "post as draft", "create pending review", "leave draft comments", or asks to put review findings on the PR as inline comments.

Teams using draft-pr-review should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/draft-pr-review/SKILL.md --create-dirs "https://raw.githubusercontent.com/tdhopper/dotfiles2.0/main/.claude/skills/draft-pr-review/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/draft-pr-review/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How draft-pr-review Compares

Feature / Agentdraft-pr-reviewStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Post review findings as a pending (draft) GitHub review with inline comments. Use AFTER reviewing code (via /reviewing-code or manually) when Tim says "draft review", "post as draft", "create pending review", "leave draft comments", or asks to put review findings on the PR as inline comments.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Draft PR Review

Post review findings as a **pending** GitHub review with inline comments on specific lines. The review is only visible to Tim until he edits and submits from the GitHub UI.

This skill handles the **output** step — it assumes findings already exist from a prior review (via `/reviewing-code`, Codex, or manual analysis). It does not re-analyze the code.

## Input

The skill needs:
1. A PR number (from argument, current conversation, or current branch)
2. A list of findings, each with: file path, line number, and description

If findings haven't been triaged yet, ask Tim which to include before posting.

## Comment format

Each inline comment has two sections:

```markdown
### [Short title]

[Author-facing feedback. Clear, actionable, respectful. 2-6 sentences.]

---

<details><summary>🔍 <b>Context for Tim</b></summary>

[Deeper analysis: code paths, snippets from the codebase, data flow,
concrete examples, Codex vs Claude agreement. Helps Tim understand
the issue fully before deciding whether to submit the comment.]

</details>
```

## Line numbers

- **New files**: `line` = line number in the file, `side` = `"RIGHT"`
- **Modified files** (added/changed lines): `line` = line number in the **new** file version, `side` = `"RIGHT"`
- **Deleted lines** (rare): `line` = line number in the **old** version, `side` = `"LEFT"`

Verify line numbers before posting:
```bash
git show origin/BRANCH:path/to/file.py | sed -n 'Np'
```

## Creating the pending review

```bash
# 1. Get the head commit SHA
COMMIT=$(gh pr view NUMBER --json headRefOid --jq '.headRefOid')

# 2. Post the review — omitting "event" makes it PENDING
gh api repos/{owner}/{repo}/pulls/NUMBER/reviews \
  -X POST --input /tmp/review-payload.json
```

Write the JSON payload to a file first (avoids shell escaping issues with backticks/quotes in comment bodies):

```json
{
  "commit_id": "abc123...",
  "body": "Overall summary — one or two sentences.",
  "comments": [
    {
      "path": "path/to/file.py",
      "line": 42,
      "side": "RIGHT",
      "body": "### Title\n\nAuthor-facing.\n\n---\n\n<details>..."
    }
  ]
}
```

Use the Write tool to create the JSON file, then pass it with `--input`. Do NOT construct the JSON inline in a shell heredoc — markdown in comment bodies will break.

## API reference

| Action | Command |
|--------|---------|
| Create pending review | `gh api repos/OWNER/REPO/pulls/N/reviews -X POST --input file.json` |
| Submit a pending review | `gh api repos/OWNER/REPO/pulls/N/reviews/ID/events -f event="COMMENT"` |
| Delete a pending review | `gh api repos/OWNER/REPO/pulls/N/reviews/ID -X DELETE` |
| List reviews (find ID) | `gh api repos/OWNER/REPO/pulls/N/reviews --jq '.[] \| {id,state,user: .user.login}'` |

## Constraints

- **Never submit the review.** Always leave it PENDING.
- **Never use `gh pr review --comment`** — that submits immediately and can't be batch-edited.
- If the API call fails (line out of range, bad path), diagnose and retry. Don't silently drop comments.
- If a finding spans multiple lines or files, pick the single most relevant line and reference other locations in the body.
- After success, report the review ID + comment count. Do NOT open the browser automatically.

Related Skills

reviewing-writing

6
from tdhopper/dotfiles2.0

Review and critique writing using Michael Nielsen's principles on craft. Analyzes text for purpose focus, brevity, danger words, opening strength, originality, reader psychology, truthfulness, and title impact. Use when the user says "review my writing", "nielsen review", "writing review", "review this writing", "critique my writing", or asks for feedback on prose quality.

reviewing-code

6
from tdhopper/dotfiles2.0

Review pull requests, branch changes, or code diffs. Triggers on "review this PR", "review my changes", "code review", "review branch", or GitHub PR URLs. Focuses on bugs, tests, complexity, and performance - not linting.

stop-slop

6
from tdhopper/dotfiles2.0

Use this skill when writing or editing prose to eliminate predictable AI writing patterns. Helps make writing more direct, authentic, and human.

sonos-control

6
from tdhopper/dotfiles2.0

Control Sonos speakers on Tim's home network. Use when the user wants to (1) play, pause, or stop music on Sonos speakers, (2) change volume on speakers, (3) skip tracks, (4) check what's playing, (5) see speaker status, (6) group or ungroup speakers, (7) any Sonos or music/audio playback task involving home speakers. Triggers on "sonos", "speakers", "play music", "what's playing", "volume", "turn up", "turn down", "pause music", "stop music".

slack-message

6
from tdhopper/dotfiles2.0

Draft and send Slack messages in Tim's natural voice. Use when the user wants to (1) post an update to a channel, (2) draft a Slack message, (3) share something on Slack, (4) send a DM, (5) reply in a thread. Applies Tim's Slack writing style and prose principles automatically.

skill-creator

6
from tdhopper/dotfiles2.0

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

sending-to-codex

6
from tdhopper/dotfiles2.0

Delegate tasks or ask questions to OpenAI's Codex CLI from within Claude Code. Use this skill when the user says "ask codex", "send to codex", "delegate to codex", "have codex do this", "get codex's opinion", "run this in codex", or wants to offload a coding task or question to the Codex agent. Supports both fire-and-forget coding tasks (fix bugs, add features, refactor) and research questions (analyze code, explain behavior, get a second opinion).

resend-email

6
from tdhopper/dotfiles2.0

Send emails via Resend.com API. Use when the user wants to (1) send an email, (2) email someone, (3) send a message to an email address, (4) send email with attachments, (5) schedule an email for later. Requires RESEND_API_KEY environment variable.

refresh-dotfiles

6
from tdhopper/dotfiles2.0

Full sync of personal (yadm) and work (yadm-work) dotfiles. Pulls remote changes, commits and pushes local changes, and audits for untracked files that should be tracked. Use when the user says 'refresh yadm', 'sync dotfiles', 'dotfiles sync', or 'update dotfiles'.

omnifocus

6
from tdhopper/dotfiles2.0

Interact with OmniFocus task manager via the command-line interface (@stephendolan/omnifocus-cli). Use when the user wants to: (1) Add tasks or projects to OmniFocus, (2) List, view, or search tasks/projects, (3) Update or complete tasks, (4) Manage inbox items, (5) Work with tags and analyze tag usage, (6) Process or organize their OmniFocus database from the command line.

omnifocus-triage

6
from tdhopper/dotfiles2.0

Interactively process OmniFocus inbox items using AskUserQuestion. Use when the user wants to (1) triage their inbox, (2) process inbox items, (3) organize their OmniFocus inbox, (4) clear out their inbox, (5) do a GTD-style inbox review. Triggers on "triage inbox", "process inbox", "organize inbox", "clear inbox", "inbox zero".

Nightshift

6
from tdhopper/dotfiles2.0

Manage and interact with Nightshift, an AI-powered development automation tool that runs coding tasks during off-hours.