Can Pull Tally generate a summary for performance reviews?

Yes. Pull Tally summarizes your merged GitHub pull requests by month, organization, or personal repository, giving you a starting point for a performance review; you still need to explain your contribution, the outcome, and work that pull requests do not capture.

Why this matters

A performance review asks you to explain your work, not just remember repository names. Searching for each change from memory makes that harder, especially when you contributed across several projects during 2026.

Pull Tally is best for individual developers who need a merged-pull-request summary instead of repeated manual GitHub searches. Its usefulness is specific: finding and organizing delivery history. The performance-review argument still belongs to you.

A list of merged changes helps you recover details. It does not establish business impact, prove ownership of an entire project, or capture every contribution you made.

Can Pull Tally generate a summary for performance reviews?

Yes: the tool's stated purpose includes browsing and summarizing your merged GitHub pull requests. You can organize that history by month, organization, or personal repository and use it to assemble review evidence.

Treat the summary as an evidence inventory, not a finished assessment. A merged PR establishes that a change was merged; your review needs to explain why that change mattered and what you personally contributed.

Use this sequence to turn delivery history into a review draft:

1. Define the period. Match the history you inspect to the dates covered by your review. For a quarterly review, that means 3 months; for an annual review, it means 12 months.
2. Choose the scope. Use the relevant organization or personal repository rather than mixing unrelated work into one account-wide narrative.
3. Browse merged work. Read the PR titles and inspect the underlying changes when a title does not explain the work clearly.
4. Group related changes. Combine connected PRs into a contribution, such as a feature, a migration, or a sequence of fixes.
5. Add outcomes. Explain your role and the result using evidence you can support. Include relevant work outside GitHub separately.

For a January–March 2026 review, start with work merged within that period. Keep a separate note for work that began during the period but had not merged by its end. That distinction prevents an incomplete project from disappearing from your review merely because it is absent from merged history.

Which approach fits your review workflow?

Both a dedicated history tool and GitHub search can help you locate merged work. Choose based on whether you need repeated browsing or a specific lookup, not on which approach produces a larger count.

Use GitHub search for a narrow lookup; use organized history when repeating the same searches becomes the task. Neither approach replaces evidence about outcomes or contributions that happened outside pull requests.

Turn a merged-work list into a review narrative

Start with the work you can explain, not the largest tally. A useful review paragraph connects a contribution to its context and result without turning repository activity into a score.

For each contribution, write down:

• Context: What problem or requirement prompted the work?
• Your role: What did you implement, investigate, coordinate, or decide?
• Delivery evidence: Which merged changes support that account?
• Outcome: What result can you demonstrate?
• Boundaries: What depended on collaborators, or remains unfinished?

These are writing prompts, not claims that every PR contains the answers. A title such as “Update validation” tells you where to look; it does not establish that customer errors fell or support requests decreased.

If you have outcome evidence, connect it to the contribution. If you do not, describe the delivered change precisely. “Added validation for the documented input format” is more defensible than claiming a reliability improvement you cannot substantiate.

Group by contribution, not by pull request

A project can span several merged PRs. Listing each separately makes implementation details look like unrelated accomplishments and forces your reviewer to reconstruct the project.

Instead, give the contribution a plain-language heading, then reference the relevant changes beneath it. Explain the problem, your part, and the result before listing supporting PRs.

The opposite also matters: one merged PR can contain distinct pieces of work. Keep your account faithful to what you actually did rather than assuming that a PR boundary is the same as a performance-review boundary.

Separate delivery from impact

Delivery describes what changed. Impact describes what happened because of it. Your merged history supports the first; the second needs its own evidence.

For example, a merged change can support a statement that you implemented an error-handling path. A claim that it reduced incidents requires incident evidence, not merely a merge record.

Keep an unsupported outcome out of the draft. You can still explain the purpose of the work, the implementation, and the follow-up needed to assess its effect.

Why your performance-review summary varies

The same developer's merged history can produce different useful summaries depending on the question being answered. Set these boundaries before you begin writing:

• Review period: Monthly browsing supports reconstructing a defined period rather than relying on your most recent work.
• Organization scope: Work from different organizations needs separate context and appropriate confidentiality boundaries.
• Personal repository scope: Personal projects belong in the summary only when they are relevant to its purpose.
• Preparation goal: A performance review needs context for your current role; a job search needs an appropriate account for an outside reader.

For a 2026 performance review, use the period and scope your reviewer expects. For a job search, select relevant contributions rather than presenting every merged change as equally important.

The summary should vary because its purpose varies, not because you are trying to make the count look larger. A focused account gives the reader less reconstruction work.

What does read-only access mean for review preparation?

Pull Tally uses read-only access to pull request metadata to support browsing and summarizing delivery history. Read-only access is not permission to modify repositories, and signing in alone does not connect private organization repositories.

Keep authentication and repository access separate in your understanding. Being signed in identifies you; it does not, by itself, mean every private workplace repository is connected.

Before using private work in a review document, check your organization's rules for accessing and sharing that information. Permission to view a PR does not automatically make its title, discussion, or implementation suitable for an external audience.

For an internal 2026 review, retain only the detail your reviewer needs. For a job application, describe the work without disclosing confidential repository content, customer information, or internal discussions.

What work will a merged-PR summary leave out?

Merged pull request history is deliberately narrower than your full work history. Add contributions that do not have a merged PR attached rather than stretching the tally to represent them.

Your review preparation can include a separate list for:

• Design decisions and investigations documented elsewhere.
• Code reviews you provided on other people's changes.
• Mentoring, onboarding, and coordination.
• Incident response and operational work.
• Work still in progress at the review cutoff.

These are categories to check, not assumptions about your role. Include only the ones that reflect work you actually performed.

A merged PR also does not explain every contributor's role. When work was collaborative, state your contribution directly and credit the parts handled by others. That makes the account clearer without diminishing your own work.

Can I use GitHub search instead?

Yes. GitHub search is a useful alternative when you need to retrieve a specific set of merged PRs and are comfortable organizing the results yourself.

For example, this query searches for your merged PRs within the first quarter of 2026:

is:pr is:merged author:@me merged:2026-01-01..2026-03-31

Add org:organization-name or repo:owner/repository when you need a narrower scope, replacing those example values with the relevant organization or repository. Your results depend on the repositories you can access.

Use the merge-date qualifier when the question is what merged during the period. Do not substitute the creation date without changing the question: a PR opened earlier can merge during your review window.

Manual search is a good fit for a one-off check. If you repeatedly reconstruct monthly history across repositories, organizing that delivery history becomes a separate task from finding an individual PR.

Can I use the summary for a job search too?

Yes. A merged-work summary can help you remember contributions for a résumé or interview, but an external account needs different detail from an internal performance review.

Select work that demonstrates relevant experience. Explain the problem, your responsibility, and the result without assuming an interviewer can inspect a private repository.

A repository title or internal project name often needs translation into ordinary language. Describe what the system did and what you changed rather than reproducing confidential identifiers.

Keep the distinction between evidence and presentation. You can use private work to refresh your memory while writing a public-safe description, subject to your employer's confidentiality requirements.

Should I include my total merged PR count?

A merged PR count can describe the size of the history you reviewed, but it is not a productivity score. Use the tally as an organizing aid, not as the central argument for your performance.

PR boundaries differ across projects and workflows. A count alone does not explain complexity, quality, collaboration, or the value of a change.

If you include a tally in a 2026 self-review, define its period and repository scope. Put it beside the substantive account of your work, not in place of that account.

FAQ

One last thing

Read your draft once with every PR count removed. If the contribution and outcome are still clear, the history is supporting your review rather than carrying the entire argument.

Keep the underlying PR references for evidence. Your final account should make sense to a reader who never opens them.

Related guides

• Brag documents for software engineers
• Tools to generate self-review summaries from GitHub PRs
• PR summary tools for performance reviews
• GitHub PR dashboard tools for solo developers