
Pr Research
Map an upstream open-source repo’s contribution norms, prior PRs, and maintainer patterns before you file an issue or patch.
Overview
PR Research is an agent skill for the Idea phase that systematically explores an upstream repository so you can contribute without guessing maintainer expectations.
Install
npx skills add https://github.com/boshu2/agentops --skill pr-researchWhat is this skill?
- Blocking prior-work check for existing issues and PRs before new contribution work
- Mandatory CONTRIBUTING.md and template or conduct guideline pass
- PR archaeology on merged PRs and commit patterns for maintainer expectations
- Produces structured research under .agents/research/ with result.json contract
- Fork context window tuned for external-api consumption (git + gh CLI)
- Workflow includes a blocking prior-work check as step −1
- CONTRIBUTING.md analysis is marked mandatory at step 0
Adoption & trust: 745 installs on skills.sh; 384 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want to open a PR upstream but do not know duplicate issues, CONTRIBUTING rules, or how past merges were shaped.
Who is it for?
First-time or infrequent contributors to unfamiliar OSS repos who use git and the GitHub CLI.
Skip if: Teams researching their own monorepo or contributors who already have an approved internal spec and no upstream discovery gap.
When should I use this skill?
Before contributing to an external repository, starting a new open source contribution, or evaluating whether to contribute to a project.
What do I get? / Deliverables
You get a dated research memo and result.json that inform whether to proceed and how to format the next planning or implementation step.
- .agents/research/YYYY-MM-DD-upstream-*.md research memo
- result.json per output contract
Recommended Skills
Journey fit
Upstream exploration belongs in Idea because you are deciding whether and how to contribute before you scope or implement the change. Research subphase fits systematic repo discovery, CONTRIBUTING.md analysis, and PR archaeology ahead of any validate/build work.
How it compares
Structured upstream dossier before chat-based guessing—not a substitute for local codebase research on your own tree.
Common Questions / FAQ
Who is pr-research for?
Solo and indie builders preparing open-source contributions who need maintainer-aligned context before planning or coding.
When should I use pr-research?
Use it in Idea/research before contributing to an external repo, when starting a new OSS contribution, or when deciding if a project is worth your time—in validate/scope only after you already know you will contribute and need upstream facts first.
Is pr-research safe to install?
It uses Read, Write, Bash, Grep, and Glob against clones and APIs; review the Security Audits panel on this page and limit Bash to trusted repos before running.
SKILL.md
READMESKILL.md - Pr Research
# PR Research Skill Systematic exploration of upstream repositories before contributing. ## Overview Research an external codebase to understand how to contribute effectively. This is the FIRST step before planning or implementing an open source contribution. **When to Use**: - Before contributing to an external repository - Starting a new open source contribution - Evaluating whether to contribute to a project **When NOT to Use**: - Researching your own codebase (use `$research`) - Already familiar with the project's guidelines --- ## Workflow ``` -1. Prior Work Check -> BLOCKING: Check for existing issues/PRs 0. CONTRIBUTING.md -> MANDATORY: Find contribution guidelines 1. Repository Setup -> Clone/identify upstream repo 2. Guidelines Analysis -> Templates, CODE_OF_CONDUCT 3. PR Archaeology -> Analyze merged PRs, commit patterns 4. Maintainer Research -> Response patterns, review expectations 5. Issue Discovery -> Find contribution opportunities 6. Output -> Write research document ``` --- ## Phase -1: Prior Work Check (BLOCKING) **CRITICAL**: Before ANY research, check if someone is already working on this. ```bash # Search for open issues on this topic gh issue list -R <owner/repo> --state open --search "<topic keywords>" --limit 20 # Search for open PRs that might address this gh pr list -R <owner/repo> --state open --search "<topic keywords>" --limit 20 # Check for recently merged PRs (might already be fixed) gh pr list -R <owner/repo> --state merged --search "<topic keywords>" --limit 10 ``` | Finding | Action | |---------|--------| | Open issue exists | Link to it, don't create duplicate | | Open PR exists | Don't duplicate work | | Recently merged PR | Verify fix, no work needed | | No prior work found | Proceed to Phase 0 | --- ## Phase 0: CONTRIBUTING.md Discovery (BLOCKING) **CRITICAL**: Do not proceed without finding contribution guidelines. ```bash # Check all common locations cat CONTRIBUTING.md 2>/dev/null cat .github/CONTRIBUTING.md 2>/dev/null cat docs/CONTRIBUTING.md 2>/dev/null # Check README for contribution section grep -i "contribut" README.md | head -10 ``` ### Extract Key Requirements | Requirement | Where to Find | |-------------|---------------| | **Commit format** | "Commit messages" section | | **PR process** | "Pull Requests" section | | **Testing requirements** | "Testing" section | | **Code style** | "Style" section | | **CLA/DCO** | "Legal" or "License" section | --- ## Phase 3: PR Archaeology **CRITICAL**: Understand what successful PRs look like. ```bash # List recent merged PRs gh pr list --state merged --limit 20 # Recent commit style git log --oneline -30 | head -20 # Check for conventional commits git log --oneline -30 | grep -E "^[a-f0-9]+ (feat|fix|docs|refactor|test|chore)(\(.*\))?:" ``` ### PR Size Analysis | Size | Files | Lines | Likelihood | |------|-------|-------|------------| | **Small** | 1-3 | <100 | High acceptance | | **Medium** | 4-10 | 100-500 | Moderate | | **Large** | 10+ | 500+ | Needs discussion first | --- ## Phase 5: Issue Discovery ```bash # Find beginner-friendly issues gh issue list --label "good first issue" --state open gh issue list --label "help wanted" --state open # Issues with no assignee gh issue list --state open --json assignees,title,number | \ jq -r '.[] | select(.assignees |