So many tools, so many MCPs — why a CLI?
I use many different software products and project planning tools on a daily basis: GitHub, GitLab, YouTrack, Jira, Linear, and more. Each tool basically solves the same core problem in its own way, but switching between all of them was creating friction for my development process. What I wanted was something I could learn once and use everywhere. So I figured I’d take a crack at abstracting “project management” and “wiki management”. I also wanted whatever I made to pair nicely with AI agents, so I could accelerate my workflows in a hands-off fashion.
Before I started on the project, my first thought was to investigate what MCP server options were available, and I found many. However, I also found that having four different MCP servers active at once unnecessarily polluted my context, and as I continued to use the tools I found that their capabilities varied between services. Usually they stopped being useful beyond quick adds/edits and small scoped actions like finding a couple of tickets.
I was looking for a way to operate in bulk, optimize my token usage, and standardize my workflow. So I got to work: track-cli
What it does
Generally speaking, track covers almost the entire API surface of the services it wraps. It’s a Rust CLI that turns issue trackers and knowledge bases into a scriptable execution surface. One command set works across YouTrack, Jira, GitHub, GitLab, and Linear — configure and interact with multiple backends at once from a single config.
You can search and update issues, run batch operations, auto-paginate, emit JSON for robots or plain text for humans, and publish Markdown into YouTrack Knowledge Base or Jira/Confluence without hand-building wiki storage markup. It is also built for agent workflows: context aggregation, workflow hints, query templates, dry-runnable bulk plans, and resumable applies so a long operation can continue from an explicit state file instead of replaying completed work.
How it works
You point track at a backend with track init (or a .track.toml / env vars), then the same command names work everywhere. Backend-native query syntax still applies though — YouTrack query language, JQL, GitHub search, and so on — but the CLI surface stays consistent.
The parts that made the tool stick for me are the automation contracts, which I now use daily for reporting, analytics, and auto-match tagging/cleanup. The --all flag fetches every matching page and makes it easy to delegate and script around. The track apply command takes a declarative plan for create/update/comment/link (and guarded delete) operations, and you can validate it before it mutates anything:
# Pull every unresolved issue into a repeatable audit
track -o json i s "project: PROJ #Unresolved" --all \
| jq 'group_by(.state.name)[] | "\(.[0].state.name) \(length)"'
# Preview a multi-step change plan before it mutates anything
track apply cleanup-plan.json --dry-run --validate
# Resume the same plan after an interrupted run
track -o json apply cleanup-plan.json \
--resume /tmp/track-apply-state.jsonDocumentation follows the same pattern. Agents (or humans) can draft Markdown in the repo, review it like any other file, then publish through article/wiki commands. On Jira that means Confluence pages converted from Markdown on publish; on YouTrack it is the built-in Knowledge Base.
For AI coding sessions, track context returns projects, fields, users, query templates, workflow hints, and recent issues in one call. track doctor audits what the configured backend can actually do without mutating remote data. track init --skills installs a skill reference for Claude Code, GitHub Copilot, Cursor, and Gemini CLI. The point of the CLI, relative to MCP-style interfaces, is the contract: repeatable commands, shell pipelines, dry-runs, resumable state, and auditable JSON that can move from an agent session into a script, PR, or CI job.
What’s next
Track is already usable today — the current release is v1.17.0, with Homebrew (brew install OrekGames/tap/track), native installers that verify release checksums, and docs at orekgames.github.io/track-cli. Five backends ship now, and the public docs call out that more backends are on the way.
Near-term work is less about inventing a new product shape and more about deepening the existing one: broader tracker coverage, richer capability parity across backends where the native models allow it, and tighter agent workflows on top of context, apply, inspect, and the installable skills. The agent harness in the repo is how I keep those workflows honest as the surface grows.
If you want to try it:
brew install OrekGames/tap/track
# or
curl -fsSL https://raw.githubusercontent.com/OrekGames/track-cli/main/scripts/install.sh | bashThen run track init, optionally track init --skills, and point it at whatever software you already live in. Issues and feedback are welcome on GitHub.