Pr Retro
Run a structured retro on merged, rejected, or heavily reviewed PRs so your agent captures lessons in a dated learnings file.
Overview
PR Retro is an agent skill most often used in Ship (also Operate, Build) that analyzes merged or rejected pull requests and writes dated learning reports under `.agents/learnings/`.
Install
npx skills add https://github.com/boshu2/agentops --skill pr-retroWhat is this skill?
- Six-phase workflow: PR discovery → outcome analysis → feedback extraction → patterns → lessons → markdown output
- Writes `.agents/learnings/YYYY-MM-DD-pr-{repo}-{outcome}.md` per output contract
- Uses `gh pr view` JSON for state, reviews, comments, and merge/close timestamps
- Supports merged success patterns, rejections, and significant review feedback
- Aligns with DORA, SRE, and lean-startup practices for continuous improvement
- Six-phase workflow from PR discovery through lesson extraction
- Output path pattern `.agents/learnings/YYYY-MM-DD-pr-*`
Adoption & trust: 613 installs on skills.sh; 384 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You finish PRs but repeat the same review misses because feedback and outcomes never become searchable, reusable lessons.
Who is it for?
Maintainers and solo builders who use `gh` and want agent-written retros after merge, reject, or heavy review cycles.
Skip if: Teams without GitHub CLI access or anyone who only needs a one-off PR description without outcome analysis.
When should I use this skill?
After a PR is merged, after a PR is rejected, after significant review feedback, or periodically to review contribution patterns.
What do I get? / Deliverables
You get a structured retro markdown file with extracted feedback, patterns, and actionable lessons tied to a specific PR outcome.
- .agents/learnings/YYYY-MM-DD-pr-{repo}-{outcome}.md retro document
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
PR outcomes are evaluated right after the review/merge cycle, which maps to Ship → review as the canonical shelf. The six-step workflow centers on reviewer feedback, accept/reject patterns, and contribution quality—not generic ops monitoring.
Where it fits
After a PR merges, run a retro to capture what reviewers praised so you repeat it on the next change.
When a PR is rejected, extract objections and policy gaps into a dated learnings file.
Quarterly sweep of recent PRs to spot recurring review themes across repos.
Turn heavy review threads into internal contribution guidance linked from `.agents/learnings/`.
How it compares
Use for post-PR learning documents, not in place of inline code review or automated CI gates.
Common Questions / FAQ
Who is pr-retro for?
Solo builders and small teams who contribute via GitHub pull requests and want persistent learnings in the repo, especially with the `gh` CLI available.
When should I use pr-retro?
After a PR merges, after a rejection, after significant review feedback, or periodically to review contribution patterns; in Ship/review after merge, in Operate/iterate when improving process, and in Build when refining how you open future PRs.
Is pr-retro safe to install?
It uses Read, Write, Bash, Grep, and Glob and calls GitHub via `gh`; review the Security Audits panel on this page before granting repo and shell access.
SKILL.md
READMESKILL.md - Pr Retro
# PR Retro Skill Learn from PR outcomes by analyzing accept/reject patterns. ## Overview After a PR is merged or rejected, analyze what worked and what didn't to improve future contributions. **Output:** `.agents/learnings/YYYY-MM-DD-pr-{repo}-{outcome}.md` **When to Use**: - After a PR is merged (capture success patterns) - After a PR is rejected (understand why) - After receiving significant review feedback - Periodically to review contribution patterns --- ## Workflow ``` 1. PR Discovery -> Find the PR to analyze 2. Outcome Analysis -> Merged/rejected/changes requested 3. Feedback Extraction -> What did reviewers say? 4. Pattern Identification -> What worked/didn't 5. Lesson Extraction -> Reusable learnings 6. Output -> Write retro document ``` --- ## Phase 1: PR Discovery ```bash # If PR number provided gh pr view <number> --json state,reviews,comments,mergedAt,closedAt # Find recent PRs by you gh pr list --state all --author @me --limit 10 # Find PRs to a specific repo gh pr list -R <owner/repo> --state all --author @me --limit 10 ``` --- ## Phase 2: Outcome Analysis | Outcome | Meaning | Focus | |---------|---------|-------| | **Merged** | Success | What worked? | | **Closed (not merged)** | Rejected | Why? | | **Open (stale)** | Ignored/abandoned | What went wrong? | | **Changes requested** | Needs work | What feedback? | ```bash # Get PR outcome gh pr view <number> --json state,mergedAt,closedAt,reviews ``` --- ## Phase 3: Feedback Extraction ```bash # Get all review comments gh pr view <number> --json reviews --jq '.reviews[] | "\(.author.login): \(.body)"' # Get all comments gh api repos/<owner>/<repo>/pulls/<number>/comments --jq '.[].body' # Get requested changes gh pr view <number> --json reviews --jq '.reviews[] | select(.state == "CHANGES_REQUESTED")' ``` ### Feedback Categories | Category | Examples | |----------|----------| | **Style** | Naming, formatting, conventions | | **Technical** | Algorithm, architecture, patterns | | **Scope** | Too big, scope creep, unrelated changes | | **Testing** | Missing tests, coverage, edge cases | | **Documentation** | Missing docs, unclear comments | | **Process** | Wrong branch, missing sign-off | --- ## Phase 4: Pattern Identification ### Success Patterns (If Merged) | What Worked | Evidence | |-------------|----------| | Small, focused PR | < 5 files | | Followed conventions | No style comments | | Good tests | No "add tests" requests | | Clear description | Quick approval | ### Failure Patterns (If Rejected) | What Failed | Evidence | |-------------|----------| | Too large | "Please split this PR" | | Scope creep | "This is out of scope" | | Missing tests | "Please add tests" | | Wrong approach | "Consider using X instead" | --- ## Phase 5: Lesson Extraction ### Lesson Template ```markdown ## Lesson: [Title] **Context**: [When does this apply?] **Learning**: [What did we learn?] **Action**: [What to do differently?] **Evidence**: - PR #N: [quote or summary] ``` ### Common Lessons | Lesson | Action | |--------|--------| | PR too large | Split PRs under 200 lines | | Missing context | Add "## Context" section | | Style mismatch | Run linter before PR | | Missing tests | Add tests for new code | | Slow review | Ping after 1 week | --- ## Phase 6: Output Write to `.agents/learnings/YYYY-MM-DD-pr-{repo}-{outcome}.md` ```markdown # PR Retro: {repo} #{number} **Date**: YY