Sona is an agentic development environment for working with coding agents across repositories. Use the desktop app to discuss new work, inspect changes and findings, and control runs. Its local runtime plans and implements features, audits acceptance criteria, reviews code, runs your project's checks, and opens pull requests. Supported projects can also run QA against the built app.

A run records its progress locally, so interrupted work can resume. You can run a complete feature workflow or choose an individual review, validation, QA, or PR task. You review the result before merging. The project is pre-1.0.

Why Sona

• Desktop workspace. Prepare new work in chat, launch it with an explicit start action, and inspect progress, changes, and findings across repositories.
• Durable runs. Phase outputs and continuation state live in a local database. Resume with any compatible agent, because Sona stores the state independently of the agent session.
• Acceptance criteria are checked, not assumed. An audit compares the code and tests to each criterion and repairs gaps before review.
• Review that fixes. Findings are verified, Blocker and Major ones are fixed, and the rest are reported with a verdict.
• Your project's real checks. Validation discovers the required checks from your instructions, build files, scripts, and CI, then runs and repairs them.
• Mobile QA. On Android and iOS projects, an agent drives the built app on a device or simulator and fixes what it finds before the PR.
• Stack-aware. Platform packs route review to specialists for Go, iOS, Kotlin, KMP, PHP, Python, Rust, and TypeScript.
• Large work splits cleanly. Bigger features become dependency-ordered subtasks, each with a fresh context and one commit.

Quickstart

1. Install and sign in to a supported coding agent's CLI. Follow the installation guide to install the desktop app and matching local runtime.
2. Open Sona, select your repository, and describe the work in chat. Include observable acceptance criteria, constraints, and any design references.
3. Resolve scope and open questions, accept an issue key, then click the goal start card to launch the workflow.
4. Follow the run in the desktop app. Inspect changes and findings, then review the resulting pull request before merging.

Feature work needs the target project's build tools and credentials for Git push and PR creation. See the installation guide for supported hosts, source builds, updates, and recovery.

How it works

A goal is a complete feature workflow. A small feature is one subtask; larger work splits into dependency-ordered subtasks. Each subtask is implemented, checked, and committed on its own. When every subtask is done, the goal runs applicable QA and opens the PR.

flowchart LR
    A[Intake] --> B[Preplan] --> C[Plan]
    C --> S

    subgraph S [Each subtask]
        direction LR
        D[Implement + simplify] --> E[Audit] --> F[Code review] --> G[Validate] --> H[Write history] --> I[Commit]
    end

    S --> Q[QA] --> P[Push + PR] --> M[Monitor CI]

QA runs when the routed platform pack declares a QA target. Specs live under .feature-specs/ as a parent spec, per-subtask specs, and a decomposition manifest. Local specs are the default; Linear-backed preparation is optional.

Chat preparation gathers context before a run starts. Only clicking the goal start card launches a goal from chat. A standalone planning run writes the spec bundle and stops before implementation.

Individual tasks

You can also run selected phases or operations without launching a full feature goal:

See runtime command guidance for command syntax, available operations, and confirmation behavior.

Watching and controlling runs

The desktop app lists live, recent, and stalled work across repositories. Open a goal to inspect its subtasks, pipeline, recent activity, and review, audit, and QA results. Use the run controls to pause, stop, resume, or re-run work.

Follow an active goal through its subtasks and phase pipeline. The goal view shows the current phase, elapsed time, and recent activity.

See active goals and finished runs across repositories. The work list shows each run's phase, subtask progress, repository, and recent activity.

Open a subtask's details to inspect its spec file, dependencies, review findings, audit status, and execution information.

The optional Linux display companion puts tray counters and run details on a Turing 3.5-inch USB screen, with automatic paging.

Platform packs

Packs live under platform-packs/<slug>/. Each manifest declares routing signals, review areas, add-ons, a validation gate, and optional QA support. Routing reads the manifests, so you can add or replace a pack without touching a hard-coded list.

The ten failure-review areas are architecture, performance, platform-correctness, security, testing, api-contracts, persistence, reliability, ui, and ux-accessibility. Every shipped pack also owns a required code-quality lane.

KMP declares seven areas and takes performance, testing, and api-contracts from Kotlin. KMP's code-quality lane overrides Kotlin's, and KMP has its own quality gate with no Kotlin fallback. The other packs declare all ten areas.

Concrete path ownership beats the generic fallback, and content signals break ties between equal path matches. The fallback owner is declared in a manifest; declaring more than one fails validation.

Review specialists run within the selected workflow. See the source-generation guide and review substance standard to author a pack.

Configuration

Choose models and reasoning effort per phase, add project instructions, and extend review guidance through platform packs and add-ons. Repository instructions belong in AGENTS.md; boundary history and decisions live next to the code in agent/history.md and agent/decisions.md.

See the getting started guide for configuration paths and project customization. The source-generation guide covers authoring skills, packs, and add-ons.

Supported agents

Junie's adapter rejects governed review launches that need tool and MCP isolation.

Telemetry

Telemetry defaults to anonymous; the installer also offers full and off. Events go to the shipped relay unless you self-host the proxy.

Some diagnostic events still queue locally while telemetry is off. Workflow state is always local. Telemetry privacy lists every field, destination, and retention rule.

Documentation

Contributing

See Contributing, the source-generation guide, and the scaffold payload contract before changing contracts. The runtime and desktop app build separately.

License

MIT. See the licensing summary for details.