ajat
ajat stands for Atlassian Jira Automation Tool.
It is the Jira Automation governance and portability tool in the Climakers portfolio. Customers use it when automation has grown beyond one project screen into an organization-wide mesh of global rules, project-local rules, multi-project rules, manual rules, labels, actors, webhooks, and scheduled triggers that is difficult to review from Jira alone. ajat turns that mesh into customer-controlled files, self-contained reports, and repeatable operations.
Compatibility: ajat supports Atlassian Jira Cloud Automation only. It does not support Jira Server or Jira Data Center.
Platform availability: released builds are available for macOS and
Linux. macOS ships as a signed and notarized universal .pkg, and Linux
as a per-architecture .zip with checksums and Sigstore/Cosign bundles.
Positioning: ajat is not just a backup CLI. It is a customer tool for governance, ownership, portability, and safe operation of the Jira Automation estate — the same control model the Confluence-focused cousin tools acp2md and acs2md bring to enterprise knowledge.
Commercial plans: ajat is sold through the Climakers store in Solo, Team, CI/CD Automation, and Enterprise paid editions, plus a free Trial edition that unlocks the full feature set for a 14-day evaluation. Compare plans and start a trial at store.climakers.com/ajat.
What it does
- Export every Jira Automation rule in a tenant to a scope-aware tree of plain JSON files in one command.
- Generate five self-contained HTML reports — inventory, collision, consistency, risk, and workflow — that read the export locally without calling Jira.
- Compare two export snapshots for drift, additions, deletions, and changed rules with no Jira credentials or network access.
- Restore or promote rules through an explicit, plan-first import that shows create, update, skip, prune, and error counts before any API write.
- Operate rules in bulk — disable, enable, delete, or rescope selected rules — using a shared selector vocabulary over the local catalog.
- Discover and invoke manual rules from scripts or CI/CD with per-target results, dry-run previews, and explicit confirmation.
Why customers use it
Customers typically adopt ajat when the problem is not a single rule but an entire automation estate. The business need is usually governance, continuity, backup, migration, compliance evidence, or AI enablement rather than one-off convenience.
- Maintain a customer-controlled backup of every Automation rule outside Jira.
- Build a disaster-recovery archive and a safe path back when rules are edited, disabled, or deleted.
- Audit where automation sends data outside Jira — the webhooks, chat spaces, email recipients, and cloud services it reaches.
- Find silent-failing, unowned, stale-but-enabled, and high-frequency rules before they cause incidents.
- Promote rules from sandbox to production with new UUIDs and rewritten project scopes.
- Turn automation structure into a corpus for internal search, analytics, and RAG.
Installation and First-Time Setup
If this is your first time with the product, start with setup before choosing a command.
The recommended onboarding flow is:
- install the released binary for the target platform
- confirm the install and the available command surface
- review and activate the commercial or local license
- create the configuration file
- generate a Jira API token and configure credentials
- run
ajat doctor - run the first export and inventory report
Use Installation and First-Time Setup as the primary guide for new users. That page is written for customers who need to move from procurement and installation to a first successful, correctly scoped Automation export.
How to use this documentation
Read this overview first when you need to decide whether the requirement is a full export, a governance report, a drift comparison, a restore, or a safe bulk operation.
Then move into the operational guide that matches the job:
- Installation and First-Time Setup for the first successful export
- Configuration for connection, credentials, precedence, and proxy settings
- Export the estate for the scope-aware JSON export, state files, and incremental refresh
- HTML Reports for the five self-contained reports and secure sharing
- Compare Snapshots for local drift review and CI drift gates
- Search the Tenant for live, summary-level rule queries
- Bulk Rule Operations for disable, enable, delete, scope updates, and manual rule discovery
- Import and Restore for same-tenant recovery and cross-tenant promotion
- Invoke Manual Rules for target resolution, typed inputs, and per-target results
- Configuration Commands for
config create,get,list,set,validate, andwhere - Workflows & Recipes for repeatable governance, continuity, and migration scenarios
- Licensing for activation, variants, backup, and the CI/CD Automation edition
- Utilities for
doctor,tree,support, andcompletion
That split keeps this page focused on operating model and decision-making, not on duplicating every command flag.
The five reports
Every report reads the local export tree and produces one self-contained HTML file. None of them calls Jira, so they are safe to run on a review workstation, attach to a ticket, or store as evidence.
- Inventory — the full catalogue by scope, with per-rule flow diagrams, owners, labels, estate analytics, and the integration footprint: every external service the automation reaches. This answers the data-egress and vendor-dependency question Jira cannot.
- Collision — overlapping and behaviourally-duplicate rules, clustered by similarity across scopes to expose copy-paste sprawl and consolidation candidates.
- Consistency — label and naming hygiene, ownership, and overall governance posture.
- Risk — a scored A–F governance and operational-risk dashboard that surfaces silent failures, orphaned ownership, stale-but-enabled rules, high-frequency schedules, complexity, and external data egress, with per-project attribution.
- Workflow — every rule rendered as a print-friendly flow-diagram runbook with a step-by-step reading of what it does.
Use HTML Reports for report contents, navigation, theming, and secure sharing guidance.
Business outcomes
Backup and long-term retention
The exported JSON tree is customer-controlled and returned in the standard Automation API shape, not a private database format. Store it in Git, object storage, encrypted archives, backup vaults, regional storage, or offline evidence packages. That makes rule definitions easier to retain, diff, classify, approve, and recover than a Jira-only view.
Business continuity and disaster recovery
When a rule is accidentally edited, disabled, or deleted, teams need a recent copy and a safe path back. ajat import reads the export tree, computes a plan, and applies creates or updates only after confirmation. The default UUID strategy preserves identity for same-tenant recovery.
Compliance and governance
Plain JSON exports with predictable, scope-aware organization are useful for evidence collection, records management, internal controls, and audit support. Teams can apply retention labels, version control, access review, and immutable backup policies using the storage and governance tools they already trust, and the risk and integration reports provide review-ready governance artifacts.
RAG and LLM enablement
The export tree and reports make Jira Automation structure available to search, analytics, and internal AI workflows. Teams can index rule names, labels, conditions, actions, descriptions, scopes, and change history without scraping Jira screens.
Data ownership and tenant safety
ajat is designed around customer-controlled artifacts.
- Rule exports are written to local JSON files under a deterministic, scope-aware directory tree.
- HTML reports are self-contained files that can be opened offline, attached to tickets, stored as evidence, or shared inside approved channels.
- Snapshot comparisons run locally and do not require Jira credentials.
- License files are encrypted locally and bound to the machine.
- Support bundles mask sensitive configuration values before they are shared.
Read-only and plan-first by design: ajat separates commands that only observe from commands that can change tenant state.
- Read-only commands —
export,report,diff,search,doctor,config,license list,license validate,support,tree, andversion— never modify Jira Automation rules. - Mutation commands —
import,rule enable,rule disable,rule delete,rule scope set, andinvoke— print a plan first and support--dry-runand--yes, so the same workflow works interactively and in controlled automation. - Delete guard: rule deletion is allowed only for disabled rules, matching the upstream Automation API.
import --prunedeletes only disabled orphan rules; enabled orphans are retained and must be handled explicitly.
Exports and reports can contain sensitive automation content — webhook URLs, email recipients, smart values, message bodies, and integration configuration. Store them with the same controls you use for other confidential operational records.
Choosing the right command
| Question | Command |
|---|---|
| Is this workstation ready? | ajat doctor |
| Where is my config or license file? | ajat config where, ajat license where |
| What rules exist right now? | ajat search for a live summary, ajat export for a complete local catalog |
| What automation exists across the organization? | ajat report inventory |
| Where does our automation send data outside Jira? | ajat report inventory (integration footprint) |
| Which rules look duplicated or overlapping? | ajat report collision |
| Which labels, names, and capability families need cleanup? | ajat report consistency |
| What is broken, unowned, or risky? | ajat report risk |
| What does a given rule actually do? | ajat report workflow |
| What changed between two snapshots? | ajat diff |
| How do I pause or re-enable a selected group? | ajat rule disable, ajat rule enable |
| How do I delete disabled cleanup candidates? | ajat rule delete |
| How do I move rules between scopes? | ajat rule scope set |
| How do I restore or promote rules into a tenant? | ajat import |
| How do I discover and run manual rules? | ajat rule manual list, then ajat invoke |
| How do I prepare diagnostics for support? | ajat support |
Typical customer scenarios
| Scenario | How |
|---|---|
| Back up every Automation rule to customer-controlled files | ajat export --output-dir ./jira-automations-backup |
| Produce an org-wide governance review pack | ajat report inventory --input-dir ./jira-automations-backup --output-file inventory.html |
| Gate a CI pipeline on automation drift | ajat diff ./baseline ./current --check |
| Pause a project’s automation during an incident | ajat rule disable --input-dir ./snapshot --scope <ari> --dry-run |
| Restore rules after an accidental change | ajat import --input-dir ./last-known-good --dry-run |
| Promote a sandbox rule into production | ajat import --input-dir ./sandbox-export --uuid-strategy=new --scope-map OLD=NEW |
| Run a manual rule from a script | ajat invoke <rule-uuid> --target PROJ-123 --dry-run |
Companion tools
ajat governs Jira Cloud Automation. For the Confluence side of the Climakers Atlassian suite, see the Confluence tools: acp2md for exporting individual pages and acs2md for exporting full spaces.
The suite shares one theme: turning platform-bound Atlassian data into durable, portable, customer-governed artifacts. Use ajat for the Jira Automation estate and the acp2md / acs2md pair for Confluence knowledge.