omni-dev

omni-dev is a developer tool centered on intelligent Git commit messages, written in Rust and distributed as a single binary file.

I. Purpose and Positioning According to the materials, omni-dev mainly targets two types of scenarios: AI commit message toolchains, and MCP servers related to Atlassian / development workflows. It uses Claude AI to analyze code changes, provide meaningful commit messages and PR description suggestions, and understand project structure, conventions, and work patterns.

II. Main Capabilities

1. AI commit improvement (twiddle): analyzes code changes and rewrites commit messages, supports safe revision of single or multiple commits, automatically detects and formats Conventional Commits, and automatically batches larger commit ranges. It has safety mechanisms, including working directory validation, preventing modification of commits that already exist on the remote main branch, and error recovery.
2. PR creation: creates professional Pull Requests based on AI-generated descriptions.
3. Analysis commands: the materials mention providing in-depth analysis capabilities for commits, branches, and file changes.
4. Atlassian integration: can read, write, and manage JIRA issues and Confluence pages from the command line; supports PAT authentication for self-hosted instances (atlassian auth login --auth-mode bearer, no email required), while most service operations still target the Cloud API. Its Markdown/ADF conversion undergoes schema validation, and when content model violations are encountered, it reports an error rather than silently dropping nodes.
5. Datadog integration (read-only): queries metrics, monitors, dashboards, logs, events, SLOs, hosts, and downtime. DATADOG_SITE defaults to datadoghq.com, and also recognizes datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, ap1.datadoghq.com, ddog-gov.com; environment variables DATADOG_API_KEY, DATADOG_APP_KEY, DATADOG_SITE can be used to override local settings, and DATADOG_API_URL can be used to override for self-hosted or proxied deployments. All Datadog subcommands are also exposed as MCP tools (datadog_*).
6. Browser bridge: through authenticatedinitiates HTTP requests from browser tabs to access SSO-protected internal dashboards such as Grafana and Loki, without exporting cookies or tokens; supports binary and streaming response bodies, multi-tab routing, per-request credential and origin overrides, and a transparent proxy for pure HTTP tools.
7. Supervised daemon: hosts long-running services in a single supervised process, managed via a per-user private Unix domain control socket; the browser bridge is the first service migrated to this daemon, with Snowflake and the worktrees registry joining later. An optional menu bar app on macOS. daemon start installs a launchd LaunchAgent for login autostart. The daemon supports Unix systems only.
8. Snowflake SQL service: after a single external browser SSO authentication, arbitrary SQL can be executed concurrently across any account, with no SSO popup for every query; the daemon holds the session in memory and reuses a bounded connection pool, and each query can still set its own warehouse/role/database/schema. Account/user/context defaults come from SNOWFLAKE_* environment variables, followed by ~/.omni-dev/settings.json.
9. Local request log: every invocation and its HTTP requests are recorded to a local append-only log, searchable and traceable; enabled by default, best-effort, and never writes any secrets (auth headers are redacted, request bodies require explicit opt-in). Can be disabled with OMNI_DEV_LOG_DISABLE=1, or use OMNI_DEV_LOG_BODIES=1 / OMNI_DEV_LOG_HEADERS=1 to opt into capturing request bodies/headers.
10. Worktrees view: view repositories and git worktrees open in all VS Code windows in one live view; because extension hosts are sandboxed per window, a companion small first-party extension is needed to register each window with the daemon, which then aggregates them into a single registry. This registry exists only in memory, and windows that crash without unregistering are automatically aged out.
11. Agent session tracking: tracks Claude Code, Codex, and pi.dev sessions across terminals and VS Code windows, showing coarse real-time status (working, idle, waiting for user input). Via optional hooks, claude-wrap / codex-wThe rap wrapper, pi.dev extension, and transcript monitor feed data to the daemon.
12. Jev judgment: omni-dev ai jev is a Jev API client for TypeSafe AI that returns typed probabilistic judgments rather than generated text; in addition to the choice / score / noul / ask primitives, it can route and judge which model tier each GitHub issue requires for design, implementation, and review, and verify each claim in a decision comment against its cited source via verify-decision.
13. Claude Code slash commands: can generate ready-to-use slash command templates into a project's .claude/commands/ directory, each template being a self-contained workflow that drives multi-step omni-dev operations within a Claude Code session, such as /commit-twiddle, /pr-create, /pr-update.
14. Claude conversation history export: exports Claude Code chat history into a directory of .jsonl files, with repeated runs being an idempotent sync. The exported content is positioned as a behavioral transcript rather than a faithful archive; the top-level session jsonl captures all prompts, responses, thinking blocks, tool calls, and tool result metadata; sub-agent internal turns, large tool output attachment files, PDF page rasters, and Claude automatic memory are intentionally excluded. --output-format markdown additionally generates .md files with YAML frontmatter.
15. Transcript fetching: pulls subtitles and transcript text from external media platforms, with YouTube as the first supported source; the CLI namespace and library design allow later addition of sources such as Vimeo, podcast RSS, and generic VTT/SRT URLs. --format accepts srt, vtt, txt, or json.
16. Shell completion: omni-dev completions <shell> can output completion scripts for bash, zsh, fish, powershell, and elvish.

III. Usage Precompiled binaries are provided and attached to each release. The Linux versions (omni-dev-linux.tar.gz, omni-dev-linux-arm64.tar.gz) are dynamically linked and requireglibc 2.35 or newer (Ubuntu 22.04 and Debian 12 satisfy this); on older hosts such as RHEL 9 or Amazon Linux 2023 (glibc 2.34), it will fail at the loader stage with GLIBC_2.xx not found, in which case cargo install omni-dev can be used to build from source. The material provides an approximately 10-minute introductory walkthrough called Getting Started, covering everything from authentication to the first AI improvement commit; if you only need an API key reference, see the Authentication documentation.

IV. Applicable scenarios Suitable for individual or team developers who need to organize scattered commits into a standardized history, and also suitable for development and operations workflows that perform command-line and MCP integration between SSO-protected intranet dashboards, Snowflake data warehouses, Jira/Confluence, and Datadog.

V. Limitations and notes Some services (daemon, Snowflake service, worktrees registry, Agent sessions) only support Unix systems because their control plane is based on Unix domain sockets. The Gmail and Drive command trees (including Docs, Sheets, Slides), their 23 MCP tools, and the omni_dev::{gmail,drive} library modules have been migrated to the separate project gwi; within one version, omni-dev gmail ... and omni-dev drive ... are still retained as hidden stubs that accept arbitrary arguments and exit with a non-zero status, with a prompt pointing to gwi, and will be removed in the next minor version. Details such as the measured status of Jev quotes and the last verification time of each competitor comparison table (2026-06-23) are as recorded in the material. Content not provided in the documentation has not been supplemented in this article.