chelch5/pr-review-ticket-bridge
01-package-scaffolding/pr-review-ticket-bridge/SKILL.md
Review a pull request, validate review comments against the actual implementation, and generate follow-up tickets only for findings that survive evidence-based triage. Use after a PR review cycle when comments need to be triaged into actionable work items. Do not use during an in-progress review, when all comments were already addressed in the PR, or for discussions that aren't action items.
testing
Updated Apr 20, 2026
$ install --global
skillsauthnpx skillsauth add chelch5/skilllibrary pr-review-ticket-bridgeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 20, 2026, 3:18 AM16.8s11 files scanned
SKILL.md
- name:
- pr-review-ticket-bridge
- description:
- Review a pull request, validate review comments against the actual implementation, and generate follow-up tickets only for findings that survive evidence-based triage. Use after a PR review cycle when comments need to be triaged into actionable work items. Do not use during an in-progress review, when all comments were already addressed in the PR, or for discussions that aren't action items.
PR Review Ticket Bridge
Use this skill when you need to inspect a pull request and turn valid findings into tracked work items.
This skill produces canonical ticket proposals — it does not bypass the repo's existing ticket lifecycle or create tickets through unguarded paths.
Procedure
1. Gather the full PR surface
Review ALL of these before judging comments:
- PR title and summary
- Full diff
- Commit history
- Check runs or review status (if available)
- Review comments and discussion comments
- Any referenced issue or design context
Do not treat a single comment in isolation as sufficient evidence.
2. Perform a professional review first
Before triaging comments, evaluate the PR yourself:
- Correctness bugs and logic errors
- Behavior regressions
- Security or trust boundary issues
- Missing validation or tests
- Dependency risk
- Breaking API or interface changes
- Type-safety / compilation risk
- Performance implications (when diff changes core loops or concurrency)
- Credential / secret exposure
- Architectural drift from established patterns
3. Triage review comments
For each material review comment, assess:
| Field | Values |
|-------|--------|
| Severity | critical, major, minor |
| Validity | valid, partially valid, outdated, invalid |
| Evidence | Tie judgment to the actual diff and repo contract |
Reject comments that:
- Ask for invalid changes
- Duplicate existing follow-up work
- Conflict with accepted project decisions
- Are purely stylistic with no functional impact
Narrow partially valid comments to the specific surviving issue.
4. Validate findings against the code
For each potentially valid finding:
### Comment: [summary]
**Reviewer claim:** [what they said]
**Code location:** [file:line]
**Validation:**
- [ ] Code at location still exists (not outdated)
- [ ] Issue described is actually present
- [ ] No subsequent commit addressed this
**Verdict:** [VALID | INVALID | OUTDATED]
5. Generate tickets for accepted findings
For each valid, actionable finding:
- Create a ticket proposal in the repo's ticket schema
- Keep the ticket narrow and implementation-ready
- Include: PR number, file reference, severity, reason the finding was accepted
- Do NOT generate tickets for already-fixed or duplicate work
Decision matrix:
| Impact | Effort | Blocks Release? | Action | |--------|--------|----------------|--------| | High | Small | Yes | Address in PR now | | High | Large | Yes | Create P0 ticket | | High | Any | No | Create P1 ticket | | Medium | Small | No | Address now or defer | | Low | Any | No | Defer or won't-fix |
6. Leave an explicit audit trail
Return:
- PR review summary (your own findings + comment triage)
- Valid findings with evidence
- Rejected findings with rationale
- Tickets proposed
- Blockers needing human decision, with owner and reason
Output contract
# PR Review → Ticket Bridge Report
PR: #[NUMBER]
Date: [ISO date]
## Summary
- Comments received: N
- Validated as issues: N
- Tickets created: N
- Addressed in PR: N
- Deferred/Rejected: N
## Tickets Proposed
| ID | Title | Priority | Source Comment |
|----|-------|----------|---------------|
## Rejected Comments
| Comment | Reason |
|---------|--------|
## Blockers for Human Decision
| Finding | Why | Owner |
|---------|-----|-------|
Rules
- Review the implementation first, THEN judge the comments
- Do not create tickets from invalid, stale, or purely stylistic comments
- Preserve the repo's existing ticket contract — do not invent a second backlog format
- If the repo already has a ticket covering the same issue, reference it instead of duplicating
- Keep this skill out of the default greenfield scaffold chain — it's for implementation cycles
Failure handling
- Cannot access PR comments: Use
gh pr viewor extract from GitHub web UI - Comment references deleted code: Mark as OUTDATED, do not create ticket
- Disagreement with reviewer: Create ticket but flag for discussion — don't silently won't-fix
- Too many comments: Batch by file or severity, process in multiple passes
References
- GitHub PR reviews: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
- Not part of scaffold-kickoff flow — used during implementation cycles
Related Skills
chelch5/context-intelligence
testing
VerifiedTrustedCommunity
Manages context window budgets, loading strategies, and compaction techniques for AI-assisted coding sessions. Trigger on 'context window', 'what to load', 'context management', 'context overflow', 'token budget'. DO NOT USE for loading specific project docs into agent context (use project-context) or prompt wording and optimization (use prompt-crafting).
SKILL.mdUpdated Apr 20, 2026
chelch5/auth-patterns
development
VerifiedTrustedCommunity
Implements authentication, session, token, and authorization patterns for the current stack. Trigger on 'add auth', 'JWT', 'OAuth', 'login endpoint', 'session management', 'API key auth'. DO NOT USE for OWASP hardening checklists (use security-hardening), threat modeling (use security-threat-model), or secret rotation/storage (use security-best-practices).
SKILL.mdUpdated Apr 20, 2026
chelch5/api-schema
tools
VerifiedTrustedCommunity
Defines request/response shapes, versioning, validation, and compatibility rules for API-first work. Trigger on 'design API', 'OpenAPI spec', 'REST schema', 'API versioning', 'generate client SDK'. DO NOT USE for GraphQL schemas, gRPC/protobuf definitions (use stack-standards), auth endpoint logic (use auth-patterns), or external API client wrappers (use external-api-client).
SKILL.mdUpdated Apr 20, 2026
chelch5/ticket-pack-builder
development
VerifiedTrustedCommunity
Create a repo-local ticket system with an index, machine-readable manifest, board, and individual ticket files. Use when a repo needs task decomposition that autonomous agents can follow without re-planning the whole project each session. Do not use for executing tickets (use ticket-execution) or quick fixes that don't warrant formal tickets.
SKILL.mdUpdated Apr 20, 2026