SlashIt

Mission control for AI coding agents — from "here's a task" to "the PR is merged" without leaving the window.

Delegating code to an AI agent works fine for one task. Doing it for five tasks across three repos, each in its own branch, with reviewer comments coming in on yesterday's PR, is where it falls apart.

SlashIt is a desktop app that turns that into a workflow you can actually run. Stage tasks on a Kanban board, hand each one to an agent in its own isolated Task Checkout, and queue several to run in parallel. Keep a terminal — or several — open next to each one for when you want to take over. When the agent comes back with a draft, review the diff, open a PR, and — when reviewers leave comments — triage them one by one, let the agent propose Fix / Skip / Question per comment, apply the approved fixes, and reply back on the PR without ever opening GitHub.

It's built for people who've already outgrown a single terminal tab and a stack of disposable branches.

What you can do with it

Plan and dispatch work

• Kanban board across Backlog, Queue, In Progress, Review, and Done — per project, fully local.
• Pull issues in from GitHub or Jira instead of retyping them.
• Drop a card into the queue and an agent picks it up; configurable concurrency keeps things sane.

Run many things at once

• Every task gets its own Task Checkout — today, a real Git worktree on its own branch — so parallel agents never trample each other and you can keep reviewing one change while another keeps cooking.
• Each Task Checkout has its own set of PTY-backed terminals — split them, group them by task, drop into one when you need to take over.
• A persistent session model is the long-term goal: close the window, the agents and terminals keep running in the background, reattach later and pick up exactly where you left off (think tmux, but for whole AI workflows).

Coordinate related projects in a Workspace (in progress)

• A Workspace is meant to bring several related projects under one context — useful when your work spans, say, a backend repo, a frontend repo, and a shared library. Each project belongs to at most one Workspace.
• A Workspace has its own root folder. The engine is ready to start a member project's task agent from that folder, so instructions and agent memory kept there are defined once and shared by every project in the Workspace, instead of being scattered as .claude/, .codex/, etc. across every project repo.
• Tasks still execute in their own Task Checkouts; the Workspace adds shared context, not shared mutable state.
• Not yet available: projects cannot be attached to a Workspace yet, so none of the above is reachable in the app today. Also planned: Workspace-wide defaults, an overview across its projects, and coordinated multi-project changes. See docs/architecture/product-model.md.

Close the loop on PRs

• Open pull requests directly from a finished task.
• The PR review assistant pulls every reviewer comment, asks the agent for a per-comment recommendation, lets you edit the reasoning and the proposed change, then applies approved fixes in one pass and posts replies back on the PR.

Stay in flow

• Works with whatever version-control setup you already have — plain Git is fine, and Jujutsu (jj) gets first-class treatment for stacked changes if you use it.
• A slashit CLI controls the running app from any terminal — handy for shell scripts and for other agents to talk to.
• System tray keeps agents and terminals alive when the window closes, and a headless slashitd keeps them running with no window at all — see docs/architecture/daemon.md.
• Updates are downloaded from GitHub Releases and verified against a signing key before they are applied. The installers themselves are not yet code-signed by Windows or Apple, so the first launch of a fresh install shows an OS warning — see docs/releasing.md.

Screenshots

PR review assistant

Triage every reviewer comment on a pull request, decide Fix / Skip / Question per item, edit the agent's reasoning and proposed change inline, then apply all approved fixes in one pass with optional auto-push and auto-reply on the PR.

App overview (in progress)

The screens below preview the rest of the app, parts of which are still being polished.

Status and Roadmap

SlashIt is currently pre-1.0 software. The core app, CLI, IPC server, headless daemon, queue, terminals, updater and CI/release workflows are in place. No release has been published yet — the Releases page below is empty until the first tag ships, so for now, build from source.

Near-term roadmap:

• Publish the first release, with installation walkthroughs. The procedure is written down in docs/releasing.md.
• Code-sign the installers, so a first launch stops triggering SmartScreen and Gatekeeper warnings.
• Cargo workspace layout cleanup (the root crate is both a package and a workspace).
• Continue hardening queue execution, agent recovery, and cross-platform packaging.

Built with

Rust end to end — a Leptos 0.8 frontend compiled to WASM, a Tauri v2 backend on the tokio runtime, and a standalone CLI that talks to the running app over JSON-lines on a per-user Unix domain socket (Linux, macOS) or a named pipe (Windows) — exact locations and access control in docs/architecture/ipc-security.md. Module-level layout is documented in AGENTS.md.

Installation

Pre-built Binaries

There are none yet. The first tagged release will publish these to GitHub Releases; until then, build from source.

Platform	Format
Linux	.AppImage, .deb
macOS	.dmg
Windows	.msi, .exe

Installers are not code-signed yet, so the first launch will show a SmartScreen or Gatekeeper warning. docs/releasing.md explains exactly what is and is not signed.

Build from Source

Prerequisites:

• Rust through rustup; rust-toolchain.toml pins the version
• Trunk (cargo install trunk)
• clippy and rustfmt components (rustup component add clippy rustfmt)
• wasm32-unknown-unknown target (rustup target add wasm32-unknown-unknown)
• System dependencies (Linux): libwebkit2gtk-4.1-dev, libgtk-3-dev, libayatana-appindicator3-dev

# Clone the repository
git clone https://github.com/BarraDev/slashit.git
cd slashit

# Development mode (recommended)
./dev.sh

# Or manually
NO_AT_BRIDGE=1 cargo tauri dev

# Production build
cargo tauri build

# Build CLI only
cargo build -p slashit --release

# Build the headless daemon only
cargo build -p slashit-ui --bin slashitd --release

On non-GNOME Linux desktops such as i3 or sway, NO_AT_BRIDGE=1 prevents a known WebKitGTK AT-SPI accessibility bridge crash.

CLI Usage

The slashit CLI lets you control the running app from any terminal:

slashit status                              # App status overview
slashit projects                            # List projects
slashit tasks [--project ID]                # List tasks
slashit create --project ID "Task title"    # Create task
slashit move TASK_ID queue                  # Move task to status
slashit edit TASK_ID --title "New title"    # Edit task
slashit delete TASK_ID                      # Delete task
slashit queue                               # Queue status
slashit enqueue TASK_ID                     # Add task to queue
slashit terminals                           # List active terminals
slashit show                                # Bring window to front

Add --json to any command for machine-readable output. Use --wait to wait for the app to start.

Configuration

Configuration is stored in your system config directory:

• Linux: ~/.config/slashit-app/
• macOS: ~/Library/Application Support/com.barradev.slashit-app/
• Windows: %APPDATA%\barradev\slashit-app\config\

Your project stays clean

SlashIt writes nothing inside your working tree unless you ask it to. Boards, worktrees, terminal history and logs all live outside the project by default.

Per project, under Settings → Storage, you can choose where the board is kept:

Choice	Where	Use it when
Outside the project (default)	<data_dir>/projects/<project-key>/<project-id>/	You want the repository untouched
Inside the project	<repo>/.slashit/<project-id>/	You want the board committed and shared with your team
Detect automatically	.slashit/ if it already exists and has content, otherwise outside	Upgrading, or moving between machines

Switching between them previews the move first — how many files, how large, and any conflicts — and nothing is moved until you confirm. Your API keys, terminal scrollback and logs are never part of that choice; they always stay outside the project.

Worktrees are created under <data_dir>/worktrees/, not as siblings of your repository, and a task's branch starts from origin's default branch, not from whatever you have checked out. Worktrees other tools already created for a task's branch are used where they are.

Full details in docs/architecture/state-locations.md.

Development

Useful local checks:

cargo fmt --check
cargo clippy -p slashit-ui -p slashit -p slashit-ipc -- -D warnings
cargo test -p slashit-ui -p slashit-ipc
trunk build

Cutting a release is a separate procedure — version bump locations, the version grammar the Windows installer accepts, and the draft-then-publish step are all written down in docs/releasing.md.

This repository uses Jujutsu (jj) as the primary version-control workflow with a colocated Git repository for GitHub compatibility. Plain Git contributions are welcome.

To generate platform icons after updating logo.svg, run:

cargo tauri icon logo.svg

Contributing

Contributions are welcome. Please read CONTRIBUTING.md before opening a pull request.

Security vulnerabilities should be reported privately; see SECURITY.md.

License

Copyright 2025 Barradev Digital Services

Licensed under the Apache License, Version 2.0. See LICENSE for details.