Pull Request Enhancement
Selective Reading Rule
Start with:
references/senior-master-standard.mdreferences/usage-routing.mdreferences/quality-checklist.md
Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.
When to Use
- You need to turn a git diff into a reviewer-friendly pull request description.
- You want a PR summary with change categories, risks, testing notes, and a checklist.
- The diff is large enough that reviewers need explicit structure instead of a short ad hoc summary.
Workflow
- Run
git diff <base>...HEAD --stat to identify changed files and scope
- Categorise changes: source, test, config, docs, build, styles
- Generate the PR description using the template below
- Add a review checklist based on which file categories changed
- Flag breaking changes, security-sensitive files, or large diffs (>500 lines)
PR Description Template
## Summary
<!-- one-paragraph executive summary: what changed and why -->
## Changes
| Category | Files | Key change |
|----------|-------|------------|
| source | `src/auth.ts` | added OAuth2 PKCE flow |
| test | `tests/auth.test.ts` | covers token refresh edge case |
| config | `.env.example` | new `OAUTH_CLIENT_ID` var |
## Why
<!-- link to issue/ticket + one sentence on motivation -->
## Testing
- [ ] unit tests pass (`npm test`)
- [ ] manual smoke test on staging
- [ ] no coverage regression
## Risks & Rollback
- **Breaking?** yes / no
- **Rollback**: revert this commit; no migration needed
- **Risk level**: low / medium / high — because ___
Review Checklist Rules
Add checklist sections only when the matching file category appears in the diff:
| File category |
Checklist items |
| source |
no debug statements, functions <50 lines, descriptive names, error handling |
| test |
meaningful assertions, edge cases, no flaky tests, AAA pattern |
| config |
no hardcoded secrets, env vars documented, backwards compatible |
| docs |
accurate, examples included, changelog updated |
security-sensitive (auth, crypto, token, password in path) |
input validation, no secrets in logs, authz correct |
Splitting Large PRs
When diff exceeds 20 files or 1000 lines, suggest splitting by feature area:
git checkout -b feature/part-1
git cherry-pick <commits-for-part-1>
Resources
resources/implementation-playbook.md — Python helpers for automated PR analysis, coverage reports, and risk scoring
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
1---2name: comprehensive-review-pr-enhance3description: ALWAYS use this when the request matches Comprehensive Review PR Enhance: Generate structured PR descriptions from diffs, add review checklists, risk assessments, and test coverage summaries.4---56# Pull Request Enhancement78## Selective Reading Rule910Start with:1112- `references/senior-master-standard.md`13- `references/usage-routing.md`14- `references/quality-checklist.md`1516Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.1718## When to Use19- You need to turn a git diff into a reviewer-friendly pull request description.20- You want a PR summary with change categories, risks, testing notes, and a checklist.21- The diff is large enough that reviewers need explicit structure instead of a short ad hoc summary.2223## Workflow24251. Run `git diff <base>...HEAD --stat` to identify changed files and scope262. Categorise changes: source, test, config, docs, build, styles273. Generate the PR description using the template below284. Add a review checklist based on which file categories changed295. Flag breaking changes, security-sensitive files, or large diffs (>500 lines)3031## PR Description Template3233```markdown34## Summary35<!-- one-paragraph executive summary: what changed and why -->3637## Changes38| Category | Files | Key change |39|----------|-------|------------|40| source | `src/auth.ts` | added OAuth2 PKCE flow |41| test | `tests/auth.test.ts` | covers token refresh edge case |42| config | `.env.example` | new `OAUTH_CLIENT_ID` var |4344## Why45<!-- link to issue/ticket + one sentence on motivation -->4647## Testing48- [ ] unit tests pass (`npm test`)49- [ ] manual smoke test on staging50- [ ] no coverage regression5152## Risks & Rollback53- **Breaking?** yes / no54- **Rollback**: revert this commit; no migration needed55- **Risk level**: low / medium / high — because ___56```5758## Review Checklist Rules5960Add checklist sections only when the matching file category appears in the diff:6162| File category | Checklist items |63|---------------|----------------|64| source | no debug statements, functions <50 lines, descriptive names, error handling |65| test | meaningful assertions, edge cases, no flaky tests, AAA pattern |66| config | no hardcoded secrets, env vars documented, backwards compatible |67| docs | accurate, examples included, changelog updated |68| security-sensitive (`auth`, `crypto`, `token`, `password` in path) | input validation, no secrets in logs, authz correct |6970## Splitting Large PRs7172When diff exceeds 20 files or 1000 lines, suggest splitting by feature area:7374```75git checkout -b feature/part-176git cherry-pick <commits-for-part-1>77```7879## Resources8081- `resources/implementation-playbook.md` — Python helpers for automated PR analysis, coverage reports, and risk scoring8283## Limitations84- Use this skill only when the task clearly matches the scope described above.85- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.86- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
anhvu1107