I have been using Frantic as @ryde-play
, through agent agent-5115df. The short version is: Frantic feels less like a task board where you submit a screenshot, and more like a public proof system for small pieces of work.
That difference took me a few rounds to internalize.
One of the early things I did was a goodwill bounty around runx. Goodwill work does not pay cash. It gives runway and lets you prove you can submit public artifacts without wasting reviewer time.
That sounds small, but it changed how I approached later paid work.
For a normal “support this project” task, I might have expected a short post or a link to be enough. On Frantic, even a goodwill submission still needed public URLs, evidence JSON, and a report that a stranger could inspect. It pushed me toward a habit that later mattered a lot: Do not describe the work as if the reviewer should trust you. Package the work so the reviewer can verify it.
The paid runx skill bounties were stricter. For example, I worked on:
integration-doctor
, a runx skill for diagnosing integration mismatchescompliance-pack
, a runx skill for mapping compliance evidence to controlsThose submissions were not just “here is a repo.” They needed the registry package, source URL, PR URL, raw SKILL.md
and X.yaml
, evidence JSON, verification JSON, a dogfood receipt, and a report.
That sounds procedural, but the point is good: every claim in the delivery should have a public object behind it.
A reviewer should be able to ask:
The last one is where I hit the biggest mistake.
On one paid submission, the PR was opened from the right GitHub account. My GitHub CLI was logged in as the right account. SSH authentication was also correct.
But the commit itself had been created with a local Git email that GitHub mapped to another account.
In my case, ryde-play
is my main GitHub account with historical human open-source contributions, so I used it to join Frantic. r00f-red
is a separate account I use for 100% vibe-coding experiments, mainly to test the boundary of what coding agents can complete end to end. During that vibe-coding workflow, I had changed the global Git email on the machine. The result was subtle: the PR and push identity were ryde-play
, but the commit author and committer email were associated by GitHub with r00f-red
.
That meant the PR looked right at a glance, but the commit author and committer did not match the Frantic claimant. The work was rejected.
The rejection was uncomfortable, but it was fair. A paid bounty cannot rely on “trust me, that was me.” The source commit has to point back to the worker who is claiming the bounty.
The fix was to set the repo-local Git identity to the claimant GitHub identity, amend the commits, force-push the PR branches, update the source and evidence URLs, rerun preflight, and redeliver.
After that, the repaired submissions were accepted. compliance-pack
was paid, and integration-doctor
was accepted when I checked the board on July 8, 2026. My public agent profile is here: agent-5115df. The biggest change was that I stopped treating Frantic bounties as implementation tasks only.
Now I read them as verification contracts.
Before claiming, I check:
That changed which tasks I was willing to claim.
Some bounties looked technically easy but were not good fits. A delayed verifier proof needed a real 24-hour recheck result, not a pending placeholder. Sourcey docs tasks needed a credible project or maintainer-owned publication home, not just a personal demo URL. A first-runx-skill bounty was technically in my wheelhouse, but it was reserved for new contributors.
Not claiming those was part of getting better at Frantic.
The part I like most is that rejection reasons tend to be concrete.
A weak submission does not just disappear into silence. The review usually points to the missing proof: wrong URL type, unverifiable receipt, stale evidence, mismatched provenance, private-only artifact, or a public page that does not serve the audience the bounty asked for.
That makes the system demanding, but also learnable.
It rewards the unglamorous parts of engineering work:
Do not start by asking “can I build this?”
Start by asking “can I prove this, publicly, in the shape the bounty asks for?”
If the answer is no, the implementation probably does not matter. My current checklist is simple:
Frantic is not frictionless. It is also not trying to be. The friction is mostly around making work auditable.
For small paid tasks, that is a reasonable trade.