Your tickets. Your agents. One board.
A local-first Kanban plugin for Orca, with agent sessions, column prompts, and Jira, Linear, and GitHub integrations.
- Make work visible. Create tickets, customize columns, drag cards between stages, and switch between board and list views.
- Keep sessions attached to tickets. Link existing Orca terminals or start an agent in a dedicated worktree. Open a linked session without hunting through tabs.
- Give every stage its instructions. Send a column's prompt when a ticket enters it, on a cron schedule, when its pull request changes, or manually.
- Bring your issue tracker. Import Jira boards, Linear teams, and GitHub Projects or repositories. Work with sprints, cycles, and iterations; review pending changes before pushing them upstream.
- Keep your board local. A standalone Rust service stores board data in SQLite and serves the UI inside an Orca browser tab. No separate hosted board account is required.
Early release · Validated on macOS Apple Silicon with Orca 1.4.209 and 1.4.223. Orca's plugin API is experimental. Other Orca versions and operating systems are not yet verified. This is an independent community plugin, not an official Orca product.
No Node.js, Rust, or local compilation is required for this distribution. In Orca → Settings → Plugins → Install plugin → Git URL, paste:
https://github.com/clioo/orca-kanban.git#macos-arm64-v0.2.5
Click Install, review the permissions, then enable the plugin. Press Command + J and run Open Work board.
The #macos-arm64-v0.2.5 tag contains the compiled plugin at the repository
root. The default main branch contains source code and is not directly
installable. Keep the #tag suffix: Orca requires a pinned tag or commit.
This package is for M-series Macs only, not Intel Macs, Windows, or Linux.
Each laptop keeps its own local board; installing does not transfer another
machine's tickets, credentials, or agent sessions.
- Orca installed at
/Applications/Orca.app, with plugins enabled. - Node.js 24 and pnpm 11.19.0 on your
PATH. - A current stable Rust toolchain, including Cargo, rustfmt, and Clippy.
- Xcode Command Line Tools for native compilation and
codesign. - An installed, configured agent CLI if you want to launch agent sessions.
git clone https://github.com/clioo/orca-kanban.git
cd orca-kanban
pnpm --dir web install --frozen-lockfile
./scripts/package-plugin.sh- Open Orca → Settings → Plugins → Install plugin.
- Select the generated
dist/clioo.work-boardfolder. - Review the requested permissions and enable the plugin.
- Press Command + J, search for Open Work board, and run it.
The board opens in an Orca browser tab. To update, build again and install the
same folder. The plugin ID remains clioo.work-board so existing installations
keep their data.
- Create a ticket in My work and drag it between columns.
- Reload the tab to check that its position persists.
- Open the ticket and link an existing session, or create a new one.
- Open a column's Configure prompt… menu and write a short instruction.
- Use Preview to inspect the message, then Send now to deliver it.
Agent launches can consume your provider quota. Creating an issue on an imported board writes to the real provider; Push sends pending changes upstream. Start with local tickets if you are just exploring.
Orca plugin worker
├── starts the local service
├── forwards agent events
└── opens the board in an Orca browser tab
│
▼
React UI ── HTTP RPC ── Rust service ── SQLite
│
├── Orca CLI: worktrees, terminals, agent state
└── Jira / Linear / GitHub: import, sync, push
The service listens on 127.0.0.1 and stores its data under:
<Orca user data>/plugins-data/clioo.work-board/
Column schedules and source sync can continue between board visits. The service stops when the plugin is disabled or removed; updates attempt to reuse its port. It does not require another desktop application to run.
Use ticket and column placeholders to keep instructions reusable:
Implement {ticket.key}: {ticket.title}.
Keep changes focused, add regression tests, and report what you verified.
When ready for review, run:
{board.cli} ticket move --ticket {ticket.key} --column "{column.next}"
{board.cli} expands to the shell-quoted path of the board's command-line
launcher. Agents can inspect tickets, move them, and call the service's RPC:
work-board ticket show ATL-4
work-board ticket move --ticket ATL-4 --column "Review"
work-board board
work-board rpc work.sourcesUse the generated launcher's full path outside a column prompt; work-board
is not automatically added to your shell's PATH.
Agents work in (on an imported board's notice, or Sync options → Agents
work in) is one picker with your Orca repositories and your Orca
folder projects, such as a pre-sales folder project with one folder
workspace per ticket:
- In a repository, a ticket's New session gets its own git worktree.
- In a folder project, a ticket works in its own folder workspace: one already
named for its key (
MODPRESALE-1149,MODPRESALE-1149-…), else a new one named<key> <title>. - A workspace chosen for the ticket (Links → Workspace) wins; one that is archived or removed produces an error rather than a launch elsewhere.
Folder projects and folder workspaces have no orca CLI command; the plugin
reaches them through Orca's own runtime client (bin/orca-rpc.cjs, run by
Orca's bundled Node). Without it, folder projects that already have a folder
workspace still appear and existing ones are used, but new ones are not made.
Upgrading from 0.2.0 adds a field to the local database; first the service
makes an owner-readable backup, work-board-before-v7-<id>.db, in its data
directory. 0.2.0 cannot open the upgraded database: restore that backup
before downgrading.
Launches use Orca's agent settings. A stopped session resumes its own
conversation, never the folder's latest (folder workspaces share one folder,
and a conversation can last days): Claude and Pi sessions the board starts
carry a board-chosen id, and for any linked session the board records the
conversation Orca reports for its terminal while it runs (or the one Orca kept
when it put the workspace to sleep). Resume then uses Claude --resume <id>,
Pi --session <file>, Codex resume <id> or OpenCode --session <id>; only
a session with nothing recorded falls back to the folder's latest
conversation. When Orca cannot be reached, session state is reported as
unverifiable rather than assumed exited.
Claude and Pi sessions started or resumed from a ticket are named after it
(--name "<key> <title>", e.g. MODPRESALE-1149 incomeDistribution field not supported…), so they are easy to find in the agent's session list. Codex and
OpenCode have no session-name option and keep their own titles.
Connect providers in Sources, import a board, and choose the Orca project
its agents should work in. Supported flows include source synchronization,
pending local moves, conflict resolution, and creating issues from a column.
Some integrations also require external tools such as an authenticated gh
CLI. Never expose the local service through a public tunnel or reverse proxy.
These are captures of the running UI with synthetic tickets and fixture agent states—not customer data, live provider accounts, or real model runs.
| Path | Purpose |
|---|---|
plugin/ |
Orca manifest and worker |
service/ |
Rust service, SQLite persistence, provider integrations, CLI |
web/ |
React UI and typed RPC bridge |
tests/fixtures/ |
Fake Orca, agents, and provider servers |
tests/e2e/ |
Acceptance against a separate, hidden Orca instance |
scripts/ |
Build, test, and screenshot tools |
# Install the browser used by acceptance and screenshot capture.
pnpm --dir web exec playwright-core install chromium
# Formatting, linting, Rust/web/fixture tests, and plugin packaging.
./scripts/test-all.sh --no-orca
# Also run acceptance against the installed Orca, in an isolated profile.
./scripts/test-all.sh
# Verify the public Git distribution through Orca's real installer.
WORK_BOARD_INSTALL_GIT=https://github.com/clioo/orca-kanban.git#macos-arm64-v0.2.5 \
node tests/e2e/accept-orca.mjs
# Regenerate screenshots from synthetic data; build the plugin first.
node scripts/capture-screenshots.mjsThe automated suites cover the engine, HTTP service and CLI, persistence, provider workflows, UI interactions, migration, and plugin lifecycle. Real-Orca acceptance uses fixture agents and local provider servers: it does not run paid model inference or establish compatibility with every live provider account. The full macOS acceptance also requires Swift to monitor OS focus.
The screenshot script uses headless Chromium, a temporary home directory, and the fixture CLI. It verifies process cleanup before deleting its temporary data.
Open Work board shows the board in the worktree or folder workspace in front, reusing that worktree's board tab; with nothing selected in Orca it reveals an existing board tab.
The tab cannot reach the server: run Open Work board again. Use the
http://127.0.0.1:<port> address opened by the plugin, not HTTPS or an old
bookmark. Service state and logs are in the plugin data directory.
Agents cannot start: make sure the board has an Orca project selected and the configured agent command works in that project's terminal.
A provider rejects a request: check its connection in Sources and the permissions on the account or token. Do not include tokens, private tickets, or raw provider responses in public issues.
MIT. See LICENSE and THIRD_PARTY_NOTICES.md for required copyright and third-party attribution.