f[no]

Set a target and walk away.

Say f[no] to mostly done.

footnote drives your coding agent past "looks done" all the way to a merged pull request, green CI and a clean review included. 

curl -fsSL fno.sh | sh
/fno:target "add rate limiting to the API"

# footnote plans it, builds it test-first, reviews its own diff,
# and opens the PR, then stays on it until CI is green and the
# review is clean. you get the URL when it ships.

Installs the fno CLI and offers to wire up your agent. macOS, Linux, and Windows via WSL2.

One pipeline, start to finish

/fno:target is the whole loop in one command. Point it at an idea and it runs the entire thing; point it at a blueprint and it picks up from there, driving the build through review to a merged, green PR, in a single pass or in parallel waves when the work is big enough to need them. It does that whether you're watching or asleep, and every phase below is also its own command if you'd rather drive it yourself.

  1. think /fno:think

    Explore the design and write the acceptance criteria before any code exists.

  2. plan /fno:blueprint

    Break the work into waves of tasks that can run in parallel.

  3. do /fno:do

    Execute test-first, one atomic commit per task, not a single end-of-run dump.

  4. review /fno:review

    An internal panel reads the diff before it ever leaves your machine.

  5. ship /fno:ship

    Open the PR, wait for external review, address it, merge. (/fno:pr is the alias.)

When one target isn't the job

The single-target loop is the front door. Behind it is the part that starts to matter once you have more work than one agent can carry, and more than one agent carrying it: who owns which branch, which result is current, and which of them actually needs you.

A graph, not a queue

The backlog stores delivery nodes and the edges between them. Tasks inside a plan form waves that run in parallel, and a merge unblocks whatever depended on it. The walker picks the next ready node and keeps going, so the scheduling stops living in your head.

  • fno backlog intake, next, ready, done
  • fno megawalk work the backlog until it is done

One contract, several harnesses

Claude Code, Codex and Gemini do not share a lifecycle, so the durable parts stay with the project instead of the provider: claims, backlog state, events and finish lines mean the same thing whichever CLI ran the work. Workers reach each other through a relay that injects straight into a live session when there is one, and falls back to a durable bus when there isn't.

  • fno agents spawn dispatch to claude, codex or gemini
  • fno mail send message a peer or another project

A control room, not seventeen terminals

fno mux hosts every agent as a pane you can watch, drive, or script. Panes are addressable, so checking on a worker is a command rather than a hunt through scrollback, and a finished block from one pane can be piped into another's input. A needs-me queue surfaces only the agents that are actually blocked on a decision.

  • fno mux pane ls, read, run, send, wait
  • fno-agents needs who is waiting on you

Ownership and evidence

Two agents will eventually claim the same node or enter the same worktree. Claims are atomic and they expire, and ambiguous ownership blocks rather than races, because serializing one task costs less than two agents confidently corrupting the same branch. Results get the same treatment: the finish line is checked against the pull request, CI and review state, not against a transcript that says the tests passed.

  • fno event verify-evidence bind the proof to a commit
  • fno pr verify the reviewed SHA is still the current one

Two surfaces that compose

Slash-command workflows

Orchestration that needs reasoning, where each verb folds a stack of steps into a single move.

  • /fno:target idea to PR, end to end
  • /fno:think design and stress-test before building
  • /fno:review a six-agent panel reads your diff
  • /fno:pr drive a PR through its lifecycle
  • /fno:fix repair a broken state, one fix at a time
  • /fno:blueprint break the work into waves of tasks

The fno CLI

Atomic, lock-protected primitives that are fast, scriptable, and callable from anywhere, including from inside the workflows on the left.

  • fno backlog the work graph: intake, next, done
  • fno pr merge, verify, rebase with canonical guards
  • fno agents spawn and watch background workers
  • fno mux every agent as a pane you can drive
  • fno mail message a peer or another project
  • fno status where am I, after a long session

No vibes-based "done."

What it is

A loop that owns the whole job. It reads the plan, writes the code test-first, reviews its own diff, and opens the PR, then refuses to call it done until CI is green and the review comes back clean. When it runs out of plan, it reads the backlog and picks the next thing to build on its own.

What it isn't

It isn't a chat window or a sandbox demo. It works on your real repo with your credentials, and it gets on with what you asked for instead of stopping to confirm every step along the way.

Quickstart

  1. Install footnote

    curl -fsSL fno.sh | sh

    One line: installs the fno CLI and offers to wire the plugin into your agent (Claude Code, Codex, or Gemini).

    Other ways to install

    Package managers

    • brew install bllshttng/fno/fno
    • uv tool install fno
    • pip install fno
    • cargo install fno

    Agent plugins

    • /plugin install fno@footnoteClaude Code, after /plugin marketplace add bllshttng/footnote
    • gemini extensions install https://github.com/bllshttng/footnote
    • codex plugin marketplace add bllshttng/footnote

  2. Describe what you want

    /fno:target "add rate limiting to the API"

    Run that from your agent CLI and footnote plans it, builds it test-first, reviews it, and opens the PR for you.

  3. Review and merge

    You stay in the loop at the PR. footnote waits for external review and addresses it before merge.