Pull Tally is a focused option for browsing your merged GitHub pull requests by month. Worktold is intended to explain the contribution around work and relate it to a company ladder. If your immediate question is “What did I merge?”, start with retrieval. If it is “What does this show about my scope and judgment?”, you need interpretation and supporting evidence too.
A monthly PR history can be useful without being a productivity score. It helps you find the change you forgot, recover a link, and prepare for an update. The mistake is treating the number of merged changes as a direct measure of career readiness. Five small patches and one difficult investigation can tell very different stories.
This is a documentation-based comparison checked November 10, 2026. Worktold publishes it. We have not connected private repositories to either product for a hands-on benchmark. All examples below are hypothetical.
What Pull Tally documents
Pull Tally’s site describes monthly browsing of authored, merged GitHub PRs, with filters and links back to the source. It is labeled an invite-only beta. Its documentation says access to private repository results depends on GitHub and app permissions, and that it does not keep a permanent PR archive.
Those boundaries help define the comparison. A retrieval tool does not have to become a complete career platform to be useful. If it reliably solves the problem you have, a broader system may add work you do not need.
Retrieval and interpretation are separate steps
Scroll sideways to see all columns.
| Question | Pull Tally | Worktold |
|---|---|---|
| What is the starting record? | Authored, merged GitHub PRs | Selected work context and artifacts in the intended product |
| What view is emphasized? | Monthly delivery history | Work timeline and career-ladder evidence |
| What needs extra context? | Your decisions, role, and downstream results | Any claim not established by available sources |
| What happens after access changes? | Source access can change available history; not a permanent archive | Personal-email continuity is intended; released retention behavior is unverified |
| Availability at review date | Invite-only beta | Demo and guide; MVP planned for Nov 26–29, 2026 |
Turn one retrieved PR into a useful record
Suppose you find a merged pull request called “Handle duplicate payment retries.” The title gives you a retrieval anchor. It does not tell a promotion reviewer what made the problem hard, why you chose the approach, or whether customers experienced fewer failures after release.
Open the approved design and review context. You might discover that the key contribution was identifying a case in which retrying a request could create a second charge. You compared alternatives, coordinated with a service owner, and added a test for the failure mode. Those are specific actions. Record them with sources.
Then stop at the boundary of the evidence. A merged fix supports “merged.” A deployment record supports “released.” A reliable before-and-after measurement may support a change in failure rate. Without the latter, do not say you eliminated a class of customer incidents. You can still describe the risk addressed and the verification performed.
Look for work that never became your merged PR
Use a second pass for contributions that a list of your authored merges may not surface: design review, incident coordination, mentoring, migration planning, or an experiment that caused a team to stop a weak approach. This is a property of the evidence set you are examining, not a claim that the tool is defective.
For each candidate, ask whether there is a concrete change to explain. “Attended architecture meetings” is activity. “Identified an incompatible client version and helped the team add a release gate” names a contribution. If all you have is your recollection, label it as such and seek a supporting artifact or confirmation.
The goal is not to inflate the record with every conversation. It is to avoid confusing a convenient source with the whole of engineering work. Some weeks produce useful evidence of judgment without increasing a merge count at all.
Understand the access model before depending on history
Pull Tally’s explanation of changing source access is a useful reminder for any evidence system: a link and a retained record are different things. Before changing jobs, understand what will remain accessible through each account and what you are permitted to retain. Do not copy confidential repository content into a personal archive to solve an access concern.
Worktold’s founder describes a journal linked to a personal email for continuity. The landing-page source does not verify the released behavior or guarantee ongoing access to employer sources. When evaluating it, ask what the journal retains, which links depend on the original service, and what happens when a work account is disconnected.
A practical choice
Choose a narrow retrieval workflow when you mostly need to find PRs and already have a satisfactory way to record their meaning. Evaluate a dedicated evidence journal when repeatedly reconstructing the decisions and ladder relevance is the expensive part. You can also combine a source-retrieval tool with a small manual record.
Use an ordinary month for the trial. Check one known PR, one collaboration contribution, and one non-shipping investigation. Compare coverage, missing context, correction effort, and how easy it is to explain the result to someone who did not work on the project.
- Verify which repositories and dates are covered.
- Check what happens when source access changes.
- Add one contribution outside authored merges.
- Separate merge, release, and measured outcome.
- Map the strongest record to an actual criterion.
- Decide whether you need retrieval, interpretation, or both.
Continue with the BragDoc comparison for a different Git-derived workflow, or documenting AI-assisted judgment for work that a final diff may not explain.
Written for Worktold using public sources and original illustrative examples. Product research checked November 10, 2026. Read our editorial approach and comparison limits.
