# Kpi Pr Throughput

> KPI for measuring and improving PR throughput. Defines metrics, measurement methods, and improvement strategies. Use to optimize how many quality PRs get merged.

- Skill: `majiayu000/kpi-pr-throughput` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/kpi-pr-throughput`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/kpi-pr-throughput/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/kpi-pr-throughput

---


# KPI: PR Throughput

**Definition**: The rate at which quality PRs are merged to main.

## Why This Matters

PR throughput measures productive output. High throughput with maintained quality indicates efficient development. Low throughput suggests blockers in the development pipeline.

## Metrics

### Primary Metric
**PRs Merged Per Session** - Count of PRs successfully merged during an agent session.

### Supporting Metrics
| Metric | What It Measures |
|--------|------------------|
| Time to Merge | Latency from PR creation to merge |
| Review Cycles | Number of review rounds needed |
| First-Pass Approval Rate | PRs approved without changes requested |
| Revert Rate | PRs reverted due to issues |

## Measurement

### During Session

Track:
```bash
# Count merged PRs by this agent
gh pr list --state merged --author @me --json number | jq length
```

### Quality Gate

Throughput only counts if:
- PR was not reverted
- Main branch stayed green
- No follow-up fix PRs needed

## Target Benchmarks

| Performance | PRs/Session |
|-------------|-------------|
| Struggling | 0 |
| Normal | 1-2 |
| High | 3-5 |
| Exceptional | 5+ |

## Improvement Strategies

### 1. Scope Down Aggressively

Large PRs take longer to review and have higher failure rates. Target:
- <300 lines changed per PR
- Single logical change per PR
- Clear, focused description

### 2. Front-load Verification

Run `./verify.sh --ui=false` before creating PR. Catching issues early avoids review cycles.

### 3. Write Good PR Descriptions

Clear descriptions reduce review time:
- What changed and why
- How to test
- Any risks or trade-offs

### 4. Stack PRs When Possible

For dependent changes, create stacked PRs that can be reviewed in parallel.

### 5. Address Feedback Promptly

When review feedback arrives, address it immediately while context is fresh.

## Blockers to Watch

| Blocker | Detection | Mitigation |
|---------|-----------|------------|
| Review delay | PR open >1 hour | Request review explicitly |
| Verification failures | verify.sh fails | Fix before PR, not after |
| Scope creep | PR grows beyond original intent | Split into multiple PRs |
| Merge conflicts | Can't merge cleanly | Rebase frequently |

## Anti-Patterns

- **Quantity over quality** - Merging broken code destroys throughput
- **Mega-PRs** - One 1000-line PR is worse than five 200-line PRs
- **Skipping review** - Unreviewed code accumulates debt
- **Ignoring CI** - Broken verification means broken code