/review-pr
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
$ npx -y skills add carloshpdoc/ios-workflow-claude --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/review-pr
Context preview
What this command does when you run it.
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Command definition
review-pr.mdCode Review PR
> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.
Review the pull request **$ARGUMENTS** and post inline comments using the authenticated GitHub user.
**$ARGUMENTS** can be a branch name (e.g., `feature/<JIRA_KEY>-XXXX`) or a PR number (e.g., `4012`).
Tone & Style
- **Informal and friendly.** Use casual greetings like "Hey, dev!", "Yo dev,", "Nice one, dev!", etc.
- Always address the PR author as **"dev"** (since they are the one who opened the PR).
- Keep it light — you're a teammate, not an auditor.
- Examples of good tone:
- "Hey dev, this looks solid! Just a small thing here..."
- "Yo dev, heads up — this might bite us later because..."
- "Nice work, dev! One suggestion though..."
- "Hey dev, nothing blocking here, just a thought..."
Steps
1. Find the PR
If `$ARGUMENTS` is a number, use it directly. If it's a branch name, find the PR:
gh pr list --head $ARGUMENTS --json number,title,url --jq '.[0]'
If no PR is found, inform the user and stop.
2. Gather PR Context
Run these in parallel:
# PR metadata
gh pr view <number> --json title,body,state,reviewDecision,reviews,additions,deletions,changedFiles,baseRefName,headRefName
# Full diff
gh pr diff <number>
# Existing inline comments (avoid duplicating)
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | {path, line, body, user: .user.login}'
# Existing reviews
gh api repos/{owner}/{repo}/pulls/<number>/reviews --jq '.[] | {state, body, user: .user.login}'3. Analyze the Diff
Review the diff looking for these categories of issues:
**Blocking (must fix before merge):**
- Security vulnerabilities (OWASP top 10)
- Crashes or force unwraps without safety
- Data loss or race conditions
- Broken functionality
**Non-blocking (suggestions, nice-to-haves):**
- Template & process (pre-checked boxes, missing description sections)
- Hardcoded values that could be constants
- DRY violations
- Missing `weak self` in closures
- Inconsistent patterns vs. the rest of the codebase
- Missing accessibility modifiers
- Minor code quality improvements
4. Prepare Review Comments
For each issue found, prepare an inline comment with:
- **path**: the file path relative to the repo root
- **line**: the line number in the diff (new file side)
- **body**: casual, friendly description addressing "dev". Use suggestion blocks when proposing fixes.
Use GitHub suggestion blocks when proposing concrete fixes:
```suggestion
corrected code here
### 5. Post the Review
Post all comments as a single review using the GitHub API:
```bash
gh api repos/{owner}/{repo}/pulls/<number>/reviews \
-X POST \
--input - <<'EOF'
{
"event": "<EVENT>",
"body": "<BODY>",
"comments": [
{
"path": "file.swift",
"line": 42,
"body": "Hey dev, ..."
}
]
}
EOF**Important:** Use `--input -` with a heredoc for the JSON body. Do NOT use `--field` for the comments array.
6. Decide: Approve or Request Changes
**Auto-approve** the PR if there are **no blocking issues**, even if inline comments were posted. Non-blocking suggestions are not a reason to hold the PR.
- **No issues at all:** Approve with a friendly message like "Hey dev, LGTM! Clean and ready to ship."
- **Only non-blocking comments:** Approve with something like "Hey dev, looks good! Left a few suggestions but nothing blocking. Ship it!"
- **Blocking issues found:** Request changes with a message like "Hey dev, almost there! Just a couple of things we need to fix before merging."
Use:
# Approve
gh pr review <number> --approve --body "message"
# Request changes (only for blocking issues)
gh pr review <number> --request-changes --body "message"
Do NOT ask the user what action to take. Decide automatically based on the severity of findings.
Guidelines
- Be constructive, not nitpicky. Focus on issues that matter.
- Don't comment on style preferences unless they violate project conventions.
- If the diff is clean, say so — don't invent problems.
- If there are existing inline comments from others, read them to avoid duplicating feedback.
- Group related issues into a single comment when they affect the same line.
- Keep comment bodies concise. One issue per comment unless tightly related.
Read more
Code Review PR
> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.
Review the pull request **$ARGUMENTS** and post inline comments using the authenticated GitHub user.
**$ARGUMENTS** can be a branch name (e.g., `feature/<JIRA_KEY>-XXXX`) or a PR number (e.g., `4012`).
Tone & Style
- **Informal and friendly.** Use casual greetings like "Hey, dev!", "Yo dev,", "Nice one, dev!", etc.
- Always address the PR author as **"dev"** (since they are the one who opened the PR).
- Keep it light — you're a teammate, not an auditor.
- Examples of good tone:
- "Hey dev, this looks solid! Just a small thing here..."
- "Yo dev, heads up — this might bite us later because..."
- "Nice work, dev! One suggestion though..."
- "Hey dev, nothing blocking here, just a thought..."
Steps
1. Find the PR
If `$ARGUMENTS` is a number, use it directly. If it's a branch name, find the PR:
gh pr list --head $ARGUMENTS --json number,title,url --jq '.[0]'
If no PR is found, inform the user and stop.
2. Gather PR Context
Run these in parallel:
# PR metadata
gh pr view <number> --json title,body,state,reviewDecision,reviews,additions,deletions,changedFiles,baseRefName,headRefName
# Full diff
gh pr diff <number>
# Existing inline comments (avoid duplicating)
gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | {path, line, body, user: .user.login}'
# Existing reviews
gh api repos/{owner}/{repo}/pulls/<number>/reviews --jq '.[] | {state, body, user: .user.login}'3. Analyze the Diff
Review the diff looking for these categories of issues:
**Blocking (must fix before merge):**
- Security vulnerabilities (OWASP top 10)
- Crashes or force unwraps without safety
- Data loss or race conditions
- Broken functionality
**Non-blocking (suggestions, nice-to-haves):**
- Template & process (pre-checked boxes, missing description sections)
- Hardcoded values that could be constants
- DRY violations
- Missing `weak self` in closures
- Inconsistent patterns vs. the rest of the codebase
- Missing accessibility modifiers
- Minor code quality improvements
4. Prepare Review Comments
For each issue found, prepare an inline comment with:
- **path**: the file path relative to the repo root
- **line**: the line number in the diff (new file side)
- **body**: casual, friendly description addressing "dev". Use suggestion blocks when proposing fixes.
Use GitHub suggestion blocks when proposing concrete fixes:
```suggestion corrected code here
### 5. Post the Review
Post all comments as a single review using the GitHub API:
```bash
gh api repos/{owner}/{repo}/pulls/<number>/reviews \
-X POST \
--input - <<'EOF'
{
"event": "<EVENT>",
"body": "<BODY>",
"comments": [
{
"path": "file.swift",
"line": 42,
"body": "Hey dev, ..."
}
]
}
EOF**Important:** Use `--input -` with a heredoc for the JSON body. Do NOT use `--field` for the comments array.
6. Decide: Approve or Request Changes
**Auto-approve** the PR if there are **no blocking issues**, even if inline comments were posted. Non-blocking suggestions are not a reason to hold the PR.
- **No issues at all:** Approve with a friendly message like "Hey dev, LGTM! Clean and ready to ship."
- **Only non-blocking comments:** Approve with something like "Hey dev, looks good! Left a few suggestions but nothing blocking. Ship it!"
- **Blocking issues found:** Request changes with a message like "Hey dev, almost there! Just a couple of things we need to fix before merging."
Use:
# Approve gh pr review <number> --approve --body "message" # Request changes (only for blocking issues) gh pr review <number> --request-changes --body "message"
Do NOT ask the user what action to take. Decide automatically based on the severity of findings.
Guidelines
- Be constructive, not nitpicky. Focus on issues that matter.
- Don't comment on style preferences unless they violate project conventions.
- If the diff is clean, say so — don't invent problems.
- If there are existing inline comments from others, read them to avoid duplicating feedback.
- Group related issues into a single comment when they affect the same line.
- Keep comment bodies concise. One issue per comment unless tightly related.
Reusable Claude Code slash-commands, skills, and workflows extracted from real iOS / backend projects. Packaged as three installable plugins - register the marketplace and /plugin install what you need.
Repo: carloshpdoc/ios-workflow-claude
Other commands on ios-workflow-claude.
- /apollo-check
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-migrate
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-review
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-status
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-tasks
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /bump
Bump the app version or build number across all targets in the current project.
Open command