Local-first task tracker
From plan to done.
staple turns an implementation plan into an epic and tickets that carry the whole context. Agents work them one by one, and a new session picks up where a dead one stopped.
npx staple-cliNode 22.5 or later. One SQLite file per repository.
What it is
staple is a local-first task tracker for coding agents: one SQLite file per repository, next to your team’s tracker.
From plan to done in three steps
Write the plan.
The plan you and your agent agreed on: its steps, and what depends on what.
Agents work the tickets.
Each step is a ticket. An agent claims one, keeps a worklog on it and finishes it.
You approve.
You set the order and choose what needs your sign-off. Gated work waits for you.
The problem
A folder of plans is not a backlog.
Every brainstorm and implementation plan becomes a Markdown file, and the files point at each other. Checkboxes drift because an agent forgot to tick them, and work found halfway through goes into whichever file was open.
Then a session ends in the middle of a feature: the five-hour limit, the weekly quota, a closed terminal. The next one rereads the files, guesses where things stand, and asks you.
Why stapleThe walk-through
One feature at a time.
Nine features, in the order a plan meets them.
Step 1: Write the plan
Plans become tickets
A plan becomes an epic. Its steps are tickets.
Brainstorm and write the implementation plan as you do today. Each step becomes a ticket under the epic, with what it waits on, and the plan is stored on the epic as a document.
Plans become ticketsStep 1: Write the plan
Ticket context
All an agent needs is on the ticket.
- The plan, the worklog and the comments sit on the ticket, next to the tickets it waits on.
- An agent that opens a ticket finds everything it needs there.
- Work the plan did not foresee is filed as a ticket under the same epic, not in a file.
Step 2: Agents work the tickets
Pickup queue
Agents always know what comes next.
The pickup queue is the order agents take work in. An agent that asks what to take next gets the first ticket in that order it can actually work. Rank never lifts a blocker or a live claim.
The pickup queueStep 2: Agents work the tickets
Handoff
When a session dies, the ticket still knows.
- The ticket shows who held it and how long they have been silent.
- The worklog says what is done, what is next and which files were touched.
- Taking it over is a deliberate step, and it is logged: a claim never expires on its own.
Step 2: Agents work the tickets
Autopilot runs
Ticket after ticket, then stop.
A run lets one agent work an epic, a milestone or the whole queue, one ticket after another, until the work is done, a budget runs out or something needs you. A run never merges: it leaves branches and draft pull requests for you.
Autopilot runsStep 2: Agents work the tickets
CLI, MCP and web UI
One store. Three ways in.
The CLI, the MCP tools and the web UI work on the same tickets, and the rules are enforced by the store, not by a prompt, so they hold for every agent and every person. A change made anywhere shows up in the web UI within seconds.
MCP toolsStep 3: You approve
Approval gates
You decide. You don’t babysit.
- A gate holds an epic, or any ticket with children, on a named person.
- Until that person approves, no agent can start the work under it, and the epic cannot close.
- Approve it, let part of it through, or send it back.
Step 3: You approve
Milestones and goals
A date and a definition of done.
A milestone gathers epics and tickets from anywhere in the tree without moving them, and gives them an order, a target date and a goal. The goal is a list of criteria, and each one is judged with evidence: met, unmet or unknown.
Milestones and goalsStep 3: You approve
Budget and estimates
Know what the work costs.
- Estimate a ticket when you plan it, not when it is finished.
- staple measures the agent work that went into it, and learns how far off your estimates run.
- It records your provider’s usage limits on this machine and warns when your pace eats into a reserve.
Next to Linear, GitHub and ClickUp
Keep your team’s board. Give agents their own.
staple does not replace your team’s tracker. It is the execution layer: the place where agents do the work, locally, ticket by ticket. Your team’s board stays where people plan, discuss and report.
PlannedIntegrations that keep the two in sync, with GitHub Issues, ClickUp and Linear, are planned, not shipped. Today staple does not read from or write to any of them: use it alongside them and carry items across yourself.
| Your team’s tracker | staple | |
|---|---|---|
| Used by | People planning and reporting | Agents doing the work, and you watching it |
| Runs | Hosted, over the network | Locally, one file per repository |
| Holds | Features, priorities, discussion | Epics, tickets, plans, worklogs, claims |
Underneath
Small enough to carry. Strict where it counts.
The rules are enforced by the store, not by a prompt, so they hold for every agent and every person.
- SQLite file per repository: no account, no server to run
- 1
- MCP tools, each calling the same store method as the CLI
- 65
- views in the web UI, from Tasks to Usage
- 6
- network calls until you opt in to sync or live usage checks
- 0
FAQ
Questions, answered.
The short answers. Each one ends at the page of the docs that has the long one.
Does staple replace Linear, GitHub Issues or ClickUp?
No. staple is the execution layer: the place where agents do the work, locally, ticket by ticket. Your team’s board stays where people plan, discuss and report. Integrations that keep the two in sync are planned, not shipped: today staple does not read from or write to any of them.
Next to Linear, GitHub and ClickUpWhich agents does it work with?
Claude Code, Codex or any MCP client. Agents work the tracker through staple’s MCP server, which the same package starts. You set it up once per machine, and every repository with a .staple/ folder works.
What happens when a session dies in the middle of a ticket?
The ticket still shows who held it and how long they have been silent, and the worklog says where to continue. Another session, or another agent in a different harness, takes it over and carries on. Takeover is a deliberate step, and it is logged.
Handoff and resumeCan two agents take the same ticket?
No. The claim is atomic: when two agents race for one ticket, exactly one gets it, and the other is told to pick a different one. A ticket with open blockers cannot be claimed at all.
How an agent works a ticketWhere do my tickets live? Do I need an account?
Each repository keeps its tickets in one SQLite file, .staple/staple.db. There is no account, no server and no network call between an agent and its next ticket, and it works offline. Cloud sync between machines is optional and off until you turn it on.
How do I stay in control of what agents do?
You set the order agents take work in with the pickup queue, make work wait for your sign-off with an approval gate, and follow everything in the local web UI that staple open starts.
Can an agent keep going without me?
Yes, with an autopilot run: every ticket in an epic, a milestone or the whole queue, one after another, until the work is done, a budget runs out or something needs you. After each ticket, staple decides whether the run goes on, not the prompt. A run never merges.
Autopilot runsWhat do I need to install?
Node 22.5 or later, nothing else. Run npx staple-cli at the root of a git repository: the first run asks a few questions, sets the repository up and opens the web UI.
Get started
Move the plan out of Markdown.
npx staple-cliOne command sets up the repository and opens the web UI. Your agents connect over MCP. Node 22.5 or later, one SQLite file per repository.