skills/pr-info/SKILL.md
Fetch PR details from GitHub (reviews, inline comments, conversations, diff). Use when user asks to view a PR, check PR comments, review PR feedback, or when any workflow needs to read PR data. Provides reliable repo-aware commands. Do NOT use for creating PRs (use create-pr skill instead).
npx skillsauth add nicolas-codemate/claudecodeconfig pr-infoInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetches comprehensive PR information from GitHub, handling repo detection and all comment sources automatically.
<context> Direct `gh` commands often fail because: - Claude hardcodes wrong `owner/repo` in API paths (404 errors) - `--jq` returns exit code 1 on empty results - Inline review comments require a separate API endpoint from PR reviews - Three distinct comment sources must be combined for a complete pictureThis skill solves all of these by using a tested wrapper script. </context>
<instructions>Run the helper script from the project directory:
# Basic: overview + reviews + all comments
~/.claude/scripts/gh-pr-info.sh <PR_NUMBER>
# With diff included
~/.claude/scripts/gh-pr-info.sh <PR_NUMBER> --diff
# From a different repo path
~/.claude/scripts/gh-pr-info.sh <PR_NUMBER> --repo-path /path/to/repo
The script auto-detects owner/repo from the current git context. No need to
hardcode repository paths.
If you need to run individual commands, always detect the repo first:
# Step 1: detect repo (MANDATORY before any gh api call)
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
# Step 2: use $REPO in API paths
gh api "repos/$REPO/pulls/<N>/reviews" --paginate
gh api "repos/$REPO/pulls/<N>/comments" --paginate # inline comments
gh api "repos/$REPO/issues/<N>/comments" --paginate # conversation comments
| Endpoint | What it contains |
|----------|-----------------|
| pulls/<N>/reviews | Review verdicts (APPROVED, CHANGES_REQUESTED, COMMENTED) with optional body |
| pulls/<N>/comments | Inline comments on specific code lines (path + line number) |
| issues/<N>/comments | General conversation comments on the PR discussion tab |
tools
--- name: deep-review description: Performs deep code review via an isolated fresh agent (triple perspective, anti-bias). Use when the user asks for an in-depth review of current branch changes, or when invoked by /resolve step 08. Do NOT use for reviewing PRs from GitHub (use review-pr skill instead) or for a quick correctness scan with effort levels (use bundled /code-review instead). argument-hint: [--ticket <id>] [--base <branch>] [--fix] [--severity <level>] allowed-tools: Read, Glob, Grep,
tools
Resolve git rebase conflicts methodically. Classifies each conflict (imports/namespace cleanup vs real logic clash), analyzes the commit introducing the change against the current ticket context, auto-fixes only trivial cases with a per-file summary, and asks the user when ambiguous. Verifies static analysis tools pass at the end and optionally runs functional tests. Use after `git rebase` triggers conflicts, or when the user asks to "resolve conflicts", "fix rebase", "j'ai des conflits", "aide-moi sur ce rebase".
development
Synchronize the markdown test plan in docs/qa/ with the current state of the codebase. Use after adding or modifying features to keep the plan up to date, or to bootstrap a test plan for the first time. Do NOT use to execute tests (use /qa-run instead) and do NOT use to design product specs (use /express-need instead).
tools
Execute the markdown test plan in docs/qa/ via Playwright MCP and create a ticket on each failing scenario. Use after /qa-sync, before a release, or to validate a feature end-to-end. Do NOT use to design or update scenarios (use /qa-sync instead) and do NOT use for visual regression (use visual-verify agent instead).