Issues and notes
File the work, run it on this machine, review what comes back, and give agents the context they need.
The Issues view
A project's Issues has three tabs. The Board has four columns, Backlog, In progress, In review and Done; the List shows the same issues grouped the same way; Routines file issues on a schedule.
File an issue
Press New issue. Give it a title and, when they help, a description, criteria for what done looks like, a repository and a priority, then press Create. The composer stays open for the next one and keeps the repository and priority.
The title, description and criteria are what the agent is told, so write them the way you would brief a teammate.
Several at once
Press Paste several at once in the composer, or paste text of several lines into its title. Each issue starts with its own front-matter block, and lines that start with a checkbox become its criteria:
---
priority: high
---
# Rate-limit the login endpoint
What done looks like, and anything the agent should read first.
- [ ] Ten failed sign-ins lock the account for a minuteThe desktop keeps each issue's title, description, criteria and priority, and says which other keys it did not use. Files agents leave in a repository's .splitterm/issues folder are not read.
From a pane
In a terminal of a project's tab, Ctrl+I, or File an issue from this pane in the pane's menu, opens a new issue with the pane's repository and branch filled in. The shortcut takes Ctrl+I from the shell, which reads it as Tab; the Tab key itself still completes.
The pane's last command output is offered, cleaned first: escape codes out, this machine's paths and names replaced, secrets redacted. It is attached only when you turn on Attach it to this issue, and only what the preview shows is filed. The last output needs shell integration to find it.
Run it on this machine
Open the issue. Under Run it on a machine, choose this machine and press its Dispatch button. While the runner is off, the button queues the issue instead, and it starts once you switch the runner on. The runner must be set up first: see The Runner.
Review and approve
When the agent presents its work, the issue moves to In review. Its sheet shows what the agent says it did, its screenshots and the files its branch changed. Comment, ask the agent a question, or request changes to send it back to work with your note.
Approve asks you to confirm, then tells the agent to wrap up and get the pull request ready. With Open a pull request on approve on in the project's Settings, the default, it opens the pull request with the GitHub CLI, or opens GitHub's compare page when the CLI is not there. A project with no remote keeps the branch on this machine.
When an agent needs you
A question, a plan waiting for your approval, or a permission ask waits in Needs you, the bell in the top bar, and in the issue's sheet. Answer in either and the run goes on. A terminal where Claude Code waits on you is counted on the sidebar's Terminals entry instead.
Notes
Notes are the project's shared context, written by people and agents and organised like a file explorer. Each note is filed in a folder of your own or bound to one of the project's repositories, never both. The Repositories group lists the notes bound to each.
Pin a note to put it into agent context. An agent can suggest a note as it works; it reaches no run until you keep it.
What a run reads
A run starts with the project's pinned notes and the notes bound to its issue's repository, and can search only those. A note bound to another repository, or filed in a folder and not pinned, is not in the run. The line under the notes' tree says how much is in context.
Routines
A routine files an issue on a schedule. On this machine the issue is filed when its time comes, and its run waits until you start it. Run now, on the routine, files one and starts it at once. See Work while nobody is at the machine.