skip to content

Contribute — issues where a merged PR counts

terminalhire contribute is a feed of open-source issues where landing a pull request actually builds your Proof of Work credential — matched to your stack, from a profile that never leaves your machine. It's on by default: if you see jobs, you see contributions too.

Why it leads

Contribute pays in credential: it surfaces issues on established repos (the CLI shows the bar — roughly 50+ stars and 10+ contributors, unassigned, merit-merged) where a merged, substantive PR is exactly the kind of third-party-attested work your résumé is built from. It's the on-ramp to minting new verified contributions, not just displaying old ones — which is why it's the default surface. Paid public bounties still exist (off the default surface, behind --priced), but a cash payout says nothing about whether a maintainer will merge you; the credential does.

The credential weight of a merged PR is the same however you found the issue, and Terminalhire claims no exclusivity. Payment terms still depend on the source: For a TerminalHire founder bounty, the founder saves a card before posting but is charged only after explicitly accepting completed work. The developer receives 90%; TerminalHire retains 10% and absorbs Stripe's processing fee. External bounties keep their source platform's terms. The feed's job is to point you at issues that clear the bar and fit what you already do.

Using it

terminalhire contribute                      # your matched feed
terminalhire contribute andrewyng/aisuite    # one project you already care about

Contribute is on by default — no prompt, no extra step. Seeing the feed changes nothing about the privacy model: your profile and skill fingerprint never leave the machine, and only the anonymous job index plus public GitHub search ever cross the wire. Prefer to hide it? Set contributeEnabled: false in ~/.terminalhire/config.json — the explicit opt-out zeroes the contribute lane everywhere. See Privacy architecture.

Naming the project yourself

The feed only knows repos the crawl has reached. When you already know where you want to work, name it — pass owner/repo (or paste the GitHub URL) to either surface, and you get that project's open, unassigned issues ranked against your stack, each with a ready-to-run claim command:

terminalhire contribute andrewyng/aisuite

The dashboard's work on a project box takes the same thing: paste a repo URL instead of an issue URL and you get the same list, with the repo's AI-assistance policy shown once above it.

Two things worth knowing. First, a repo you name is added to the shared index, so the next person looking for work finds it without pasting anything — the crawl reaches submitted repos on a rotation, ahead of repos nobody has asked about. Second, being added is not the same as clearing the bar: the same 50★ / 10-contributor gate still decides what enters the shared index, and a smaller repo will be listed for you while never joining the feed. Both surfaces say so rather than implying a merge there builds the credential when it doesn't.

What you'll see

Each listing is an issue you could plausibly land: the repo, the issue, why it matched your stack, and a link to the source. An empty feed is intentional — the list only shows issues where a merge would genuinely count, so it stays honest rather than padded.

Projects, and what "open right now" means

The dashboard's contributions tab leads with projects rather than individual issues, because the repo is the better place to start: opening one is what lets us go and check what is actually open there. Our index samples issues broadly across GitHub rather than enumerating any single repo deeply, so the one or two issues we list for a repo are usually a fraction of what it really has waiting. "Browse all issues" switches back to the flat list at any time.

The ranking of those projects is computed in your browser, against the skill tags in your local profile. Your profile is not sent anywhere to make it happen.

When you open a project, what you see depends on what we are able to check:

  • "N open right now" — we asked GitHub just now, using your own connected account. This is the full current set, not our sample.
  • "N we indexed" — we did not ask, because there is no connected account with live enrichment enabled. These are the issues our indexer happened to catch. Turning on live enrichment upgrades this.
  • "couldn't reach GitHub" — we asked and got no answer. This is never presented as "nothing is open", because those are different facts.

Live checks use your own GitHub account's rate budget, which is why they need a connected account: there is no shared server-side token, and the anonymous budget is shared across every visitor at once.

From issue to credential

Found one worth doing? Before you write code, know the unwritten rules — when to stake a claim, how to pace, what to do if someone beats you to the merge: The social layer. If it's also a paid bounty, track it through the claim lifecycle. Either way, once your PR merges it flows into your Proof of Work page automatically — the merge itself is the verification, no self-reporting required.