Hand a coding task to a developer for a fixed price.
A failing test, a migration, a flag you keep meaning to flip. Name the files, name the price, and hand it off. The work runs on the developer's machine — their agent, their tokens — and comes back as a change on its own branch. Nothing merges until you read it.
The developers who take this work have had changes accepted by maintainers who are not them, and they can publish that record for you to read.
curl -fsSL terminalhire.com/install.sh | bashThe reason you can say yes to a stranger.
Handing work to someone you do not know is really a question of what they can see, and that is the part we built first. The developer never gets a copy of your repository — only the files you named, put together on our side and refused outright if we find anything secret in them. They never get the ability to push, either. What comes back returns through us and is checked against those same files: anything outside them is refused, and so is anything touching your CI setup or lockfiles. If your repo has no test workflow set up for this, we say so — the change waits on your review rather than on a build.
- ▹You choose what they see — per posting, the developer sees the issue text alone, or the files you name. Your call, every time.
- ▹We check for secrets first — we put the files together on our side and check them, then hand them over — nothing is pulled straight out of your repo.
- ▹Checked against the files you named — the change comes back through us and is checked against the files you named. Anything outside them is refused — and so is anything touching your CI setup or lockfiles, the two ways a change turns into code running on your repo.
Two sides. One boundary between them.
The pool lives on the server. Matching lives on the developer's machine. Nothing a founder did not declare leaves their repo, and nothing a developer did not approve leaves theirs.
You have work you will never get to.
- 01Say what needs doingA failing test, a feature behind a flag, a migration nobody has time for. Name the files it touches — or just hand over the issue text. You set the price.
- 02A developer picks it upThey see the files you named and nothing else. We check those files for anything secret before they leave, and stop the hand-off if we find any. No copy of your repository, and no way to push to it.
- 03You read the change and decideWhat comes back is checked against the files you named. Anything that reaches outside them is refused. Accept it or reject it — the record of which one you chose is what makes the next hand-off easier.
You have an agent and nothing to point it at.
- 01Install the pluginOne bash line installs the Claude Code plugin and CLI. Run terminalhire init for one-time consent — it can sign you into GitHub for richer matches, or skip it. No website account needed.
- 02Matched work finds youOpen-source issues worth merging, live roles, and founders’ paid tasks — matched against a local profile that never leaves your machine. Our server never sees your stack or identity.
- 03Ship it, and keep the recordYou work the job in your own environment, with your own tools. When a maintainer or a founder accepts it, that acceptance lands on your record — attested by someone who is not you.
Anyone can claim senior. You can prove it.
Every job leaves a record of whether the work was taken, and it faces both ways. To a founder it is a filter — the beginning of being able to hand work to someone without reading every line first. To a developer it is a portable history of work that strangers accepted, attested by the maintainers who merged it. Your résumé tells your story; this is the part of it someone else signed off on, one click from the code.
- ▹Someone else merged your code — a maintainer on an established repo (≥50★, ≥10 contributors) accepted your PR — attested by a team that isn’t you, and checkable on GitHub.
- ▹It’s a credential, and it grows — every accepted contribution raises your Proof of Work — 3 merges into repos you don’t own reads as exactly that. Earned, not a skills list you wrote about yourself.
- ▹Three ways to earn it — an open-source issue pays nothing and still counts, a public bounty pays, and a founder’s private task pays. All three land in the same record.
- ▹Claim it without leaving Claude Code —
terminalhire contributefinds an issue matched to your stack; ship it in an isolated worktree, and the merge lands on your public résumé.
Your code stays yours. Structurally.
The credential is only worth something if it’s really yours — so privacy is enforced by architecture, not policy. Matching is local, GitHub scope is read-only public, and the only thing that crosses the wire is a payload you explicitly approved.
- ✓Public GitHub only — we register just the read:user scope. Private repos, org membership, and commit history are structurally inaccessible.
- ✓We never see your code — matching happens in a subprocess that never sends your code anywhere — source code cannot reach our servers.
- ✓Never leaves your machine, zero egress — the broad pool is aggregated server-side; your machine downloads it and matches offline.
- ✓Named consent, per opportunity — never "share with recruiters?" — always "Share with [partner agency name]?", approved explicitly.
Proof of Work, weekly.
Merged-PR receipts, winnable open-source issues, and what actually reads as proof to the people who decide to hire you. Double opt-in — unsubscribing deletes your email entirely.
Proof of Work
One email a week: merged-PR receipts, winnable OSS issues, and what actually counts as proof.
Two commands. One boundary between them.
Founders: hand off a task you will never get to. Developers: install the plugin and matched work surfaces in the tool you already have open. Everything up to accepting the diff runs today.