Hi all,
For a while I’ve been building atlcli, a tool for working with Jira and Confluence without living in the browser. It’s open source (Apache-2.0) and I’d love some outside eyes on it.
Repo: https://github.com/BjoernSchotte/atlcli · Docs: https://atlcli.sh
What it does
Scripting (new). Write Jira/Confluence automation in a few lines of TypeScript, with no imports and no boilerplate; atlcli.* is just there:
for await {const issue of atlcli.jira.search("project = TEAM AND updated < -180d")) {
await atlcli.jira.comment(issue.key, "Closing as stale");
await atlcli.jira.transition(issue.key, "Won't Do");
}
Scripts run in a QuickJS sandbox without file system or network access.
Every write is planned first: atlcli script run shows exactly what would change, and --plan-out plan.json saves the plan so it can be reviewed in a PR and applied later in CI.
On apply, atlcli checks that nothing changed in the meantime and writes nothing if it did. Re-running a script whose work is already done plans nothing.
Scripts can cover issues (create, update, transition, comment, link, assign, labels, attachments), sprints, pages (create, upsert, move, delete to trash, labels, comments, attachments) and PDF/DOCX exports.
Optional meta.permissionsrestricts a shared or AI-generated script to the projects and spaces it names.
PDF and Word export. Real, structured documents rather than a printed web page: a single page, a page tree or a whole space. Tables, panels, status badges, Jira macros, Draw.io/Gliffy and Mermaid diagrams keep their meaning. Output is tagged PDF (Typst engine) and native Word with your own templates. Anything that can’t render falls back visibly instead of disappearing silently.
DOCX and PDF import. Turn Word files and digital PDFs into native, editable Confluence pages. You always review first, and nothing is published without an explicit --confirm. PDF import is still experimental.
Bidirectional wiki sync. Pull a space into Markdown, edit it with your usual tools and Git, and push it back with conflict detection. Hierarchy, attachments and labels survive the round trip. Common macros become readable Markdown, third-party macros are preserved as raw XML, and round trips keep them intact.
Confluence as a virtual filesystem. Spaces are directories and pages are files, so ls, cat, grep and sed just work, in a shell or as a mounted volume. That also makes it handy for coding agents: no MCP server needed.
TUI. A fullscreen terminal UI for Jira and Confluence: boards, sprints, issues and pages, with a diff before every change.
Browser extension. Export the Confluence Cloud page you’re looking at to PDF or Word from a Chrome side panel, using the session you’re already signed in with. The PDF engine runs locally in the extension; content never goes to an external rendering service.
Cloud and Data Center
Both are supported. To be transparent: Confluence/Jira Cloud is my primary test path and gets live-tested for every feature. Data Center is covered by contract tests, but I’d especially appreciate reports from DC users.
Try it
brew install bjoernschotte/tap/atlcli # or: curl -fsSL https://atlcli.sh/install.sh | bash
atlcli auth init
atlcli tui
Prebuilt binaries for macOS, Linux and Windows (extensively tested it on MacOS and Linux as I'm mainly working on these platforms).
Feedback very welcome
I’d really love to hear what you think: here in the comments, as a GitHub issue (bugs, missing features, this was confusing), or as a PR. And if you find it useful, a ⭐ on the repo helps a lot with visibility.
What would you automate first in Jira or Confluence?