PR Pulse

Inspiration

I contribute to open source for programs like GSoC and OSCI, and I watch dozens of repos at a time. GitHub scatters issues across repo pages, notifications sit in a noisy feed, and there's no single view that answers "what can I work on today?" and "where do my PRs stand?" I wanted one screen that shows me exactly that.

What it does

PR Pulse connects to your GitHub account and gives you:

Auto-import — scans your GitHub for repos you own, forked, or contributed to. One click to add them all.
Good first issues — aggregates issues labeled "good first issue" and "help wanted" across every watched repo, with filtering by repo.
PR tracking — shows all your pull requests across watched repos with live status: open, merged, or closed.
Dashboard — stats at a glance: repos watched, open issues available, PRs opened, PRs merged.

Everything runs client-side. Your GitHub token stays in localStorage and is only sent to api.github.com. No database, no server, no cost.

How I built it

Next.js 16 with the App Router and TypeScript for the framework
Tailwind CSS for styling — intentionally chose a light theme with monospace typography for developer data, breaking from the typical dark dashboard pattern
GitHub REST API called directly from the browser with the user's personal access token
localStorage for persistence — watched repos and token stored locally
Vercel for free deployment

I used the Devpost Learn Skill Pack to scope the project, write the PRD and technical spec before writing any code, and followed the plan through implementation.

Challenges

The GitHub Search API has a 30-requests-per-minute secondary rate limit, so fetching PRs across many repos needed batching with Promise.all instead of sequential calls. Getting the merged/closed/open state right also required checking pull_request.merged_at from the search results since the state field only says "open" or "closed" without distinguishing merged.

What I learned

Planning before building actually saves time. The scope doc and PRD forced me to cut features before I started coding, which meant I shipped a working app instead of an ambitious half-finished one. The skill pack workflow of scope → PRD → spec → build is something I'll reuse.