* feat: add PRP workflow commands adapted from PRPs-agentic-eng
Add 5 new PRP workflow commands and extend 2 existing commands:
New commands:
- prp-prd.md: Interactive PRD generator with 8 phases
- prp-plan.md: Deep implementation planning with codebase analysis
- prp-implement.md: Plan executor with rigorous validation loops
- prp-commit.md: Quick commit with natural language file targeting
- prp-pr.md: GitHub PR creation from current branch
Extended commands:
- code-review.md: Added GitHub PR review mode alongside local review
- plan.md: Added cross-reference to /prp-plan for deeper planning
Adapted from PRPs-agentic-eng by Wirasm. Sub-agents remapped to
inline Claude instructions. ECC conventions applied throughout
(YAML frontmatter, Phase headings, tables, no XML tags).
Artifacts stored in .claude/PRPs/{prds,plans,reports,reviews}/.
* fix: address PR #848 review feedback
- Remove external URLs from all 6 command files (keep attribution text)
- Quote $ARGUMENTS in prp-implement.md to handle paths with spaces
- Fix empty git add expansion in prp-commit.md (use xargs -r)
- Rewrite sub-agent language in prp-prd.md as direct instructions
- Fix code-review.md: add full-file fetch for PR reviews, replace
|| fallback chains with project-type detection, use proper GitHub
API for inline review comments
- Fix nested backticks in prp-plan.md Plan Template (use 4-backtick fence)
- Clarify $ARGUMENTS parsing in prp-pr.md for base branch + flags
- Fix fragile integration test pattern in prp-implement.md (proper
PID tracking, wait-for-ready loop, clean shutdown)
* fix: address second-pass review feedback on PR #848
- Add required 'side' field to GitHub review comments API call (code-review.md)
- Replace GNU-only xargs -r with portable alternative (prp-commit.md)
- Add failure check after server readiness timeout (prp-implement.md)
- Fix unsafe word-splitting in file-fetch loop using read -r (code-review.md)
- Make git reset pathspec tolerant of zero matches (prp-commit.md)
- Quote PRD file path in cat command (prp-plan.md)
- Fix plan filename placeholder inconsistency (prp-plan.md)
- Add PR template directory scan before fixed-path fallbacks (prp-pr.md)
7.9 KiB
description, argument-hint
| description | argument-hint | |
|---|---|---|
| Code review — local uncommitted changes or GitHub PR (pass PR number/URL for PR mode) |
|
Code Review
PR review mode adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series.
Input: $ARGUMENTS
Mode Selection
If $ARGUMENTS contains a PR number, PR URL, or --pr:
→ Jump to PR Review Mode below.
Otherwise: → Use Local Review Mode.
Local Review Mode
Comprehensive security and quality review of uncommitted changes.
Phase 1 — GATHER
git diff --name-only HEAD
If no changed files, stop: "Nothing to review."
Phase 2 — REVIEW
Read each changed file in full. Check for:
Security Issues (CRITICAL):
- Hardcoded credentials, API keys, tokens
- SQL injection vulnerabilities
- XSS vulnerabilities
- Missing input validation
- Insecure dependencies
- Path traversal risks
Code Quality (HIGH):
- Functions > 50 lines
- Files > 800 lines
- Nesting depth > 4 levels
- Missing error handling
- console.log statements
- TODO/FIXME comments
- Missing JSDoc for public APIs
Best Practices (MEDIUM):
- Mutation patterns (use immutable instead)
- Emoji usage in code/comments
- Missing tests for new code
- Accessibility issues (a11y)
Phase 3 — REPORT
Generate report with:
- Severity: CRITICAL, HIGH, MEDIUM, LOW
- File location and line numbers
- Issue description
- Suggested fix
Block commit if CRITICAL or HIGH issues found. Never approve code with security vulnerabilities.
PR Review Mode
Comprehensive GitHub PR review — fetches diff, reads full files, runs validation, posts review.
Phase 1 — FETCH
Parse input to determine PR:
| Input | Action |
|---|---|
Number (e.g. 42) |
Use as PR number |
URL (github.com/.../pull/42) |
Extract PR number |
| Branch name | Find PR via gh pr list --head <branch> |
gh pr view <NUMBER> --json number,title,body,author,baseRefName,headRefName,changedFiles,additions,deletions
gh pr diff <NUMBER>
If PR not found, stop with error. Store PR metadata for later phases.
Phase 2 — CONTEXT
Build review context:
- Project rules — Read
CLAUDE.md,.claude/docs/, and any contributing guidelines - PRP artifacts — Check
.claude/PRPs/reports/and.claude/PRPs/plans/for implementation context related to this PR - PR intent — Parse PR description for goals, linked issues, test plans
- Changed files — List all modified files and categorize by type (source, test, config, docs)
Phase 3 — REVIEW
Read each changed file in full (not just the diff hunks — you need surrounding context).
For PR reviews, fetch the full file contents at the PR head revision:
gh pr diff <NUMBER> --name-only | while IFS= read -r file; do
gh api "repos/{owner}/{repo}/contents/$file?ref=<head-branch>" --jq '.content' | base64 -d
done
Apply the review checklist across 7 categories:
| Category | What to Check |
|---|---|
| Correctness | Logic errors, off-by-ones, null handling, edge cases, race conditions |
| Type Safety | Type mismatches, unsafe casts, any usage, missing generics |
| Pattern Compliance | Matches project conventions (naming, file structure, error handling, imports) |
| Security | Injection, auth gaps, secret exposure, SSRF, path traversal, XSS |
| Performance | N+1 queries, missing indexes, unbounded loops, memory leaks, large payloads |
| Completeness | Missing tests, missing error handling, incomplete migrations, missing docs |
| Maintainability | Dead code, magic numbers, deep nesting, unclear naming, missing types |
Assign severity to each finding:
| Severity | Meaning | Action |
|---|---|---|
| CRITICAL | Security vulnerability or data loss risk | Must fix before merge |
| HIGH | Bug or logic error likely to cause issues | Should fix before merge |
| MEDIUM | Code quality issue or missing best practice | Fix recommended |
| LOW | Style nit or minor suggestion | Optional |
Phase 4 — VALIDATE
Run available validation commands:
Detect the project type from config files (package.json, Cargo.toml, go.mod, pyproject.toml, etc.), then run the appropriate commands:
Node.js / TypeScript (has package.json):
npm run typecheck 2>/dev/null || npx tsc --noEmit 2>/dev/null # Type check
npm run lint # Lint
npm test # Tests
npm run build # Build
Rust (has Cargo.toml):
cargo clippy -- -D warnings # Lint
cargo test # Tests
cargo build # Build
Go (has go.mod):
go vet ./... # Lint
go test ./... # Tests
go build ./... # Build
Python (has pyproject.toml / setup.py):
pytest # Tests
Run only the commands that apply to the detected project type. Record pass/fail for each.
Phase 5 — DECIDE
Form recommendation based on findings:
| Condition | Decision |
|---|---|
| Zero CRITICAL/HIGH issues, validation passes | APPROVE |
| Only MEDIUM/LOW issues, validation passes | APPROVE with comments |
| Any HIGH issues or validation failures | REQUEST CHANGES |
| Any CRITICAL issues | BLOCK — must fix before merge |
Special cases:
- Draft PR → Always use COMMENT (not approve/block)
- Only docs/config changes → Lighter review, focus on correctness
- Explicit
--approveor--request-changesflag → Override decision (but still report all findings)
Phase 6 — REPORT
Create review artifact at .claude/PRPs/reviews/pr-<NUMBER>-review.md:
# PR Review: #<NUMBER> — <TITLE>
**Reviewed**: <date>
**Author**: <author>
**Branch**: <head> → <base>
**Decision**: APPROVE | REQUEST CHANGES | BLOCK
## Summary
<1-2 sentence overall assessment>
## Findings
### CRITICAL
<findings or "None">
### HIGH
<findings or "None">
### MEDIUM
<findings or "None">
### LOW
<findings or "None">
## Validation Results
| Check | Result |
|---|---|
| Type check | ✅ Pass / ❌ Fail / ⏭️ Skipped |
| Lint | ✅ / ❌ / ⏭️ |
| Tests | ✅ / ❌ / ⏭️ |
| Build | ✅ / ❌ / ⏭️ |
## Files Reviewed
<list of files with change type: Added/Modified/Deleted>
Phase 7 — PUBLISH
Post the review to GitHub:
# If APPROVE
gh pr review <NUMBER> --approve --body "<summary of review>"
# If REQUEST CHANGES
gh pr review <NUMBER> --request-changes --body "<summary with required fixes>"
# If COMMENT only (draft PR or informational)
gh pr review <NUMBER> --comment --body "<summary>"
For inline comments on specific lines, use the GitHub review comments API:
gh api "repos/{owner}/{repo}/pulls/<NUMBER>/comments" \
-f body="<comment>" \
-f path="<file>" \
-F line=<line-number> \
-f side="RIGHT" \
-f commit_id="$(gh pr view <NUMBER> --json headRefOid --jq .headRefOid)"
Alternatively, post a single review with multiple inline comments at once:
gh api "repos/{owner}/{repo}/pulls/<NUMBER>/reviews" \
-f event="COMMENT" \
-f body="<overall summary>" \
--input comments.json # [{"path": "file", "line": N, "body": "comment"}, ...]
Phase 8 — OUTPUT
Report to user:
PR #<NUMBER>: <TITLE>
Decision: <APPROVE|REQUEST_CHANGES|BLOCK>
Issues: <critical_count> critical, <high_count> high, <medium_count> medium, <low_count> low
Validation: <pass_count>/<total_count> checks passed
Artifacts:
Review: .claude/PRPs/reviews/pr-<NUMBER>-review.md
GitHub: <PR URL>
Next steps:
- <contextual suggestions based on decision>
Edge Cases
- No
ghCLI: Fall back to local-only review (read the diff, skip GitHub publish). Warn user. - Diverged branches: Suggest
git fetch origin && git rebase origin/<base>before review. - Large PRs (>50 files): Warn about review scope. Focus on source changes first, then tests, then config/docs.