Add github-pull-requests-manager extension

[mickaelalvs]

Description

Keeping track of pull requests quickly becomes overwhelming. Which ones are waiting for your review? Which ones are ready to merge? Which ones need a rebase or have a CI failure you forgot about?

GitHub Enterprise Pull Requests Manager brings clarity to your PR workflow directly from Raycast. Your pull requests are automatically sorted into focused categories — waiting for merge, waiting for a fix, waiting for review, or parked, so you always know exactly what needs your attention and what can wait.

Review requests are split between new requests you haven't looked at yet and ones you're already engaged with. Approval count, CI status, merge conflicts, and comment activity are all visible at a glance, without opening a browser tab.

Supports both GitHub Enterprise and GitHub.com.

Screencast

Checklist

• I read the extension guidelines
• I read the documentation about publishing
• I ran npm run build and tested this distribution build in Raycast
• I checked that files in the assets folder are used by the extension itself
• I checked that assets used by the README are placed outside of the metadata folder

[raycastbot]

Congratulations on your new Raycast extension! 🚀

We're currently experiencing a high volume of incoming requests. As a result, the initial review may take up to 10-15 business days.

Once the PR is approved and merged, the extension will be available on our Store.

[greptile-apps]

Greptile Summary

This PR adds a new github-pull-requests-manager extension that organises a user's pull requests and review requests into focused categories (Wait For Merge, Wait For Change, Wait For Review, Parked) with inline CI status, approval counts, and conflict indicators. The extension supports both GitHub.com and GitHub Enterprise and is well-structured with correct error handling and pagination for the search endpoint.

Confidence Score: 5/5

Safe to merge; all findings are P2 quality/correctness suggestions that do not affect core functionality.

No P0 or P1 issues found. The three P2 findings (CI total field, review/comment pagination cap, changelog structure) do not break core flows and affect only edge cases (PRs with >100 reviews or check runs).

extensions/github-pull-requests-manager/src/github/extra-info.ts — total field and pagination cap; extensions/github-pull-requests-manager/CHANGELOG.md — multiple {PR_MERGE_DATE} entries.

Important Files Changed

Filename	Overview
extensions/github-pull-requests-manager/src/github/extra-info.ts	Fetches review counts, PR details, and CI status; total uses array length instead of total_count, and both review/CI endpoints lack pagination beyond 100 items.
extensions/github-pull-requests-manager/src/github/search.ts	Correctly paginates search results using a do-while loop until all items are fetched; handles API errors with structured error messages.
extensions/github-pull-requests-manager/src/github/reviewing.ts	Categorizes review requests into pending/in-review; activity detection caps at 100 comments/reviews without pagination, which can miss replies on high-traffic PRs.
extensions/github-pull-requests-manager/src/github/my-prs.ts	Categorizes authored/assigned PRs into wait-for-merge, wait-for-change, wait-for-review, and parked; deduplication and sort logic are correct.
extensions/github-pull-requests-manager/package.json	Well-formed extension manifest with schema, correct category, platform, preferences; all declared dependencies are imported in source.
extensions/github-pull-requests-manager/src/my-pull-requests.tsx	Combined view with category dropdown filter; error handling correctly wrapped in useEffect, loading/empty states handled properly.
extensions/github-pull-requests-manager/src/components/PullRequestItem.tsx	List item component with approve/request-changes actions; approve on own PRs will produce an API error toast, which is acceptable UX.
extensions/github-pull-requests-manager/CHANGELOG.md	All three changelog entries use {PR_MERGE_DATE}; for a first-ever release a single [Initial Release] entry is conventional.
extensions/github-pull-requests-manager/src/github/auth.ts	Minimal auth helpers; getApiUrl correctly handles both GitHub.com and enterprise URLs; no caching, so token rotation is safe.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
extensions/github-pull-requests-manager/CHANGELOG.md:5-19
**Multiple changelog entries with `{PR_MERGE_DATE}`**

Only the topmost (current) entry should use `{PR_MERGE_DATE}`; older entries should carry real dates. Since this is a first-ever release with no prior merge dates to reference, the conventional approach is a single `[Initial Release] - {PR_MERGE_DATE}` entry listing all changes. The two lower entries ("Three Commands and Sort Fix", "Initial Version") represent pre-release iteration history that readers of the store changelog won't be able to correlate to any actual release date.

### Issue 2 of 3
extensions/github-pull-requests-manager/src/github/extra-info.ts:12-13
**Review fetch capped at 100 with no pagination**

`fetchReviewCounts` requests `per_page=100` reviews with no pagination loop. On a long-lived PR with more than 100 review events the function silently returns incomplete counts, which can cause a PR to be miscategorized (e.g., showing "Wait For Review" instead of "Wait For Merge" if the approvals fall beyond the 100-item window). The same pattern applies to `fetchMyReviewActivity` in `reviewing.ts` (comments and reviews endpoints).

### Issue 3 of 3
extensions/github-pull-requests-manager/src/github/extra-info.ts:73
**`total` uses array length instead of API's `total_count`**

`const total = data.check_runs.length` is capped at 100 (the `per_page` limit), while `data.total_count` reflects the true count. If a repo has more than 100 check runs, the tooltip "X failed / Y total" will show a `total` that is lower than reality, and the CI status calculation may also miss uncompleted runs that pushed past the page boundary.

```suggestion
  const total = data.total_count;
```

_{Reviews (3): Last reviewed commit: "fix: wrap showToast in useEffect to prev..." | Re-trigger Greptile}