Fullsend

Fullsend builds greenfield code by running a lot of agents in parallel with the compiler turned off, then reconciling the wreckage against tests written from the spec by agents that never saw the code. Because it's just Markdown, it works with any agent that supports skills.

How it works

Normal agent coding serializes on the compiler. Write, typecheck, fix, write, typecheck, fix. Each stop costs wall clock, and the fix is usually to code that gets deleted later in the run. Running ten agents doesn't help, because they serialize on each other's half-finished interfaces instead.

Fullsend removes both stops. Agents write their whole slice blind, at speed, with no feedback loop, and are told to duplicate each other's work rather than coordinate. The build stays broken on purpose for the first two thirds of the run.

Two ideas carry the weight. Deletion beats coordination: two agents writing the same retry helper costs tokens; two agents coordinating so only one writes it costs wall clock and blocks both, and wall clock is the scarce one. Let them collide, then delete the loser. Overbuilding stops mattering when it's disposable: an agent that invents a generic event bus nobody asked for isn't a problem if nothing in the spec touches it, because Phase 6 deletes it unread.

Red-green-refactor writes one failing test, makes it pass, cleans up, repeats. Fullsend is the other shape:

RED  RED  RED  RED  RED  RED  RED  RED  RED  ...  →  GREEN
        everything broken on purpose                 one pass at the end

What makes it safe is that the test agents launch at the same moment as the builders, holding only the spec. No implementation exists yet, so they're blind to it for free, with no discipline required and no chance of writing tests that ratify whatever the code happens to do. Then the tests arbitrate, and the code is what bends.

The phases

Phases 0, 1 and 3 are yours. The rest is fan-out.

Usage

Call the skill directly:

/fullsend

Build a URL shortener: POST /shorten takes a URL and returns a slug,
GET /:slug redirects, Postgres for storage, hit counts per slug.

Or ask in plain language:

Fullsend a Stripe webhook handler for subscription lifecycle events

It also triggers on "just build it," "don't overthink it," "go fast," and "I don't care if it compiles yet." If you already have a spec, hand it over and Phase 0 collapses to a read: "Fullsend this. Spec is in docs/api-v2.md."

Without subagents

Fullsend degrades. Do the slices yourself in sequence, but keep the parts that carry most of the value: don't run the build until every slice is written, write the tests from the spec before any implementation, and keep reconcile and cull intact. You lose the parallelism and keep the anti-overthinking, so expect a modest speedup, not the full fan-out win.

When not to use it

• An existing production codebase, unless you can isolate it in a git worktree. Fullsend is destructive by design.
• One file, one function. Orchestration costs more than the work.
• Anything you haven't decided the shape of yet. That's discovery, and Fullsend will confidently build the wrong thing eight times in parallel.
• Money, auth, PII, migrations, or shared infrastructure.
• A run you want to follow along with. The middle of a fullsend is unreadable.

What it looks like from outside

Phase 2 is a long stretch of silence, then a build with several hundred errors. That's the run working. The error count sometimes goes up during Phase 4 as deletions expose more seams, which is also fine. Green arrives once, near the end, and then the line count drops.

Two bad signs. If Phase 3 produces fewer than twenty errors, the agents probably ran the compiler despite being told not to, so you paid the coordination cost and got none of the parallelism. If the tests pass on their first run in Phase 5, the test agents saw the implementation somehow, so the tests encode what the code does instead of what the spec says.

What's in here

SKILL.md                      the skill itself
README.md                     this file
AGENTS.md                     repo conventions for agents working on fullsend
LICENSE                       MIT
.gitignore                    web/SKILL.md, .fullsend/, and local scratch
.gitattributes                LF in the repo, so greps and byte compares match
agents/
  builder.md                  Phase 2: write a slice blind, never run the compiler
  spec-tester.md              Phase 2: write tests from the spec, no repo access
  reconciler.md               Phase 4: pick one winner per collision, delete the rest
  culler.md                   Phase 6: delete what no test and no spec line touches
  openai.yaml                 agent interface manifest
.claude-plugin/
  plugin.json                 plugin manifest, points the skill loader at ./
  marketplace.json            lets users add this repo as a Claude marketplace
.github/
  workflows/validate.yml      validator, skill discovery, and plugin check
  workflows/release.yml       tagged release, ZIP, notes cut from this file
  workflows/link-check.yml    links in the Markdown
  dependabot.yml              weekly action bumps, grouped into one pull request
scripts/validate-package.py   package validator CI runs on every push
docs/BUILD-FULLSEND.md        design rationale and build brief
web/index.html                landing page
vercel.json                   deploy config for the landing page

Version history

• 2.2.0 — Removed the per-phase minute budgets. They read as a stopwatch and were only ever rhetorical; phase order and relative emphasis carry the same information without implying a clock.
• 2.1.0 — Repackaged to the standard skill layout (.claude-plugin/, agents/, scripts/, .github/workflows/), added a package validator and CI, and fixed the phase table, which disagreed with SKILL.md.
• 2.0.0 — Interface freeze in Phase 0, fixed assumption keys for mechanical conflict detection, scored winner selection, abort criteria.
• 1.0.0 — First release. Seven phases, four subagent roles.

License

MIT

Installation

With the Skills CLI:

npx skills add jgoetzmann/fullsend --global

Leave off --global to install into the current project only. Add --agent <name> or --agent '*' to choose which agents receive it, then reload their skills.

Claude Code 2.1.142 or newer can install it as a plugin:

/plugin marketplace add jgoetzmann/fullsend
/plugin install fullsend@fullsend

The plugin command is /fullsend:fullsend.

In Claude Desktop, download this repository as a ZIP and upload it as a skill. For a manual install, copy both SKILL.md and agents/ into the agent's skill folder. The four subagent prompts are required, not optional.