F[no]

Set the targets. Your agents do the rest.

Lead agents hand out the work, check it against GitHub, and bring you only the decisions.1 Claude Code, Codex and OpenCode on one team.

curl -fsSL fno.sh | sh
Other ways to install

The fno mux in a terminal: a sideline roster of agent sessions on the left, four open portals on the right, and a live status row along the bottom.
fno mux with four portals open, the sideline roster, and the questions that wait on you.

No wall of terminals.

Agents run in the background. Open a portal onto any of them when you want to look, several at once, and close it when you're done. The work keeps going either way.

Done means GitHub says so.

A coding agent will tell you the tests passed. footnote checks for itself: it reads the pull request, the CI checks and the review, and keeps working until all three are done.

The merge stays yours until you opt in.2

pr
A pull request exists for the current head.
ci
Every check on that head is green.
review
Review has had its rounds.3
fno do pr status
One verdict for the pull request: green, red, pending or unknown.

One command, five stages

/fno:target is the whole loop. Point it at an idea and it runs every stage. Point it at a plan and it picks up from there. Each stage is also its own command when you want to run it by hand.

  1. think

    /fno:think

    Researches the question against the code and writes cited findings before anyone commits to a plan.

  2. blueprint

    /fno:blueprint

    Turns the approved direction into a plan: waves, tasks, acceptance criteria.

  3. target

    /fno:target

    Builds the plan test-first and keeps going until the pull request, CI and review are done.

  4. review

    /fno:review

    Reads the diff before it ships and pins its verdict to the commit it read.

  5. ship

    /fno:ship

    Opens the pull request, answers external review, and runs the post-merge steps.

When one target isn't the job

With more than one agent running, you need to know who owns which branch, which result is current, and which session is waiting on you.

The mux sideline roster: one row per agent session with its harness, its state (Work, Done or Stop), its pull request number and its last message.
The sideline roster has one row per session, whatever harness runs it.
The questions panel under the roster: a count of open questions, then one line per question an agent is waiting on.
The questions panel lists only the decisions an agent is waiting on.

The backlog is a graph

The backlog stores pieces of work and the dependencies between them. When a pull request merges, the work that waited on it becomes ready, so an unattended loop always has something to pick up next.

fno backlog list ready

Same rules on every harness

Claims, backlog state and the finish line mean the same thing whichever agent CLI did the work.4 Workers can message each other across sessions and projects.

fno agents spawn fno agents mail send

Every agent in one terminal

fno mux runs every agent in a pane you can watch, type into or script. Each pane has an address, so checking on a worker takes one command.

fno mux pane send

Claims expire

Sooner or later two agents reach for the same piece of work. Claims are atomic and they expire. When ownership is unclear the second agent waits, because a queued task costs less than two agents editing one branch.

fno agents claim status

The backlog view in the mux: nodes in Now, In Progress, Next and Later lanes on the left, and one node's children, sessions, notes and document on the right.
The backlog inside the mux, with lanes on the left and one piece of work, its children, sessions and notes on the right.

Slash commands and a CLI

Slash commands

You run these inside your agent. Each one handles a job that needs judgment, like planning or review.

/fno:target
idea to pull request, end to end
/fno:think
investigate against primary sources
/fno:blueprint
write the plan an agent can execute
/fno:review
read the diff before it ships
/fno:fix
repair a broken state, one fix at a time

The fno CLI

You run these in any shell or script. The slash commands call the same verbs.

fno backlog
the work graph: add, list, move
fno do pr
status, verify and merge, with guards
fno agents
spawn, list and message workers
fno mux
every agent as a pane you can drive
fno whoami
project, fleet and session, in one read

It runs on your machine.5

footnote works in your real repository, with your credentials. It does what you asked without stopping to confirm each step, so read where the trust boundary sits before you walk away.

Quickstart

  1. Install footnote

    curl -fsSL fno.sh | sh

    Installs the fno CLI and offers to wire the plugin into your agent. macOS, Linux, and Windows through WSL2.

    Other ways to install

    Package managers

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

    Agent plugins

    • /plugin marketplace add bllshttng/footnoteClaude Code, then /plugin install fno@footnote
    • codex plugin marketplace add bllshttng/footnoteCodex, then codex plugin add fno@footnote
    • Other harnesses

  2. Describe what you want

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

    Run it from your agent CLI. footnote plans the work, builds it test-first, reviews the diff and opens the pull request.

  3. Review and merge

    You come back to a pull request with green CI and a finished review. The merge is your call.

Notes

  1. Done means three things the loop reads from GitHub: the pull request exists, CI is green, and review has had its rounds. A transcript that says so does not count. back
  2. Auto-merge is off until you turn it on. fno agents autonomy status shows what can run without you, gate by gate. back
  3. config.review.max_rounds caps the rounds, two by default. Findings still open at the cap go into the pull request conversation. back
  4. Claude Code, Codex, OpenCode and agy are wired today. footnote runs as a plugin on any harness that accepts plugins and hooks. back
  5. The security posture document draws the trust boundary. back