Jira automation rules API and cloud-to-cloud migration: two new agent skills
Mihai Perdum
Author
7 min readOctober 3, 2026
Key takeaways
Jira Cloud Automation has a public REST API under /automation/public/, on api.atlassian.com or on your own site at /gateway/api/automation/public/, and not under /rest/api/3. On our test site one API token got three 404s on the paths people usually guess, then a 200 with all 24 rules from the public path.
automation-engineer gives an agent the three rules POST /rule needs (the full GET structure, a fresh v7 uuid, a valid authorAccountId on the target) and the ids that break when a rule moves to another site. Read, create and enable/disable are proven on a live migration of 15 rules. Update is documented, not proven.
atlassian-cloud-to-cloud-migration-skill is for when Atlassian's own cloud-to-cloud copy can't be used or isn't acceptable: nobody is org admin on both sides, the busy target must not change, or people must be anonymised. Atlassian's list of what that copy carries marks automation with a cross, which is why the two skills ship together.
Both are Apache 2.0, in a nine-skill pack with 66 commits so far. One git clone and one script installs them.
The Jira automation rules API at api.atlassian.com/automation/public lets a coding agent read, create, update and migrate Automation rules, and two new skills in LeanZero's open-source agent skills pack teach it how. The second skill copies Jira projects, JSM desks and Confluence spaces from one Cloud site to another over REST. They ship together for a reason. Atlassian's own cloud-to-cloud copy leaves your automation behind.
Most people never find it. The top search results are Community questions like "Solved: Do we have api to create automation rules". Its accepted answer, from October 2021, says you "cannot add/edit automation rules over the REST API", then "One day, maybe". That day came. Atlassian has announced the Automation Rule Management API as generally available. On 1 October I pointed one API token at our test site. Three 404s on the paths people usually guess, then a 200 and 24 rules from the public one. Same token.
Install the Claude Code skills for Jira and Confluence
The pack is nine skills. Each one is a folder with a SKILL.md in it, and the agent loads the body only when a task needs it. Claude Code, Cline, anything that reads SKILL.md folders.
On a clean machine it prints one line per skill (trimmed, paths shortened).
text
1[install-skills] --- Claude Code skills (~/.claude/skills) ---
2[install-skills] OK: linked atlassian-jira-forge-skill -> ~/.claude/skills/atlassian-jira-forge-skill
3...
4[install-skills] OK: linked atlassian-cloud-to-cloud-migration-skill -> ~/.claude/skills/atlassian-cloud-to-cloud-migration-skill
5[install-skills] OK: linked forge-security-review -> ~/.claude/skills/forge-security-review
6[install-skills] OK: linked automation-engineer -> ~/.claude/skills/automation-engineer
7[install-skills] Done. Restart your AI tool to pick up the new skills.
Drop --claude-only to link into ~/.cline/skills/ too. They're symlinks, so git pull updates them in place. The script won't overwrite a real folder with the same name. Good.
For one project, put the skill folder under its .claude/skills/. I checked that with Claude Code 2.1.280. A project holding only the cloud-to-cloud skill lists it with its description. The same question in an empty project gets a no. Cline I haven't tested. Apache 2.0, so commercial use is fine. Keep the NOTICE.
What automation-engineer is for, what to skip it for, and the endpoints it covers. Captured on leanzero.net/ai-skills, 1 October 2026.
Create Jira automation rules using the API
The trap is the path. The automation paths people guess on their own site (/rest/api/3/automation, /rest/cb-automation, the internal-api the UI uses) all answer 404, and a 404 reads like "no such thing". It isn't. The public API sits under /automation/public/, on api.atlassian.com or on your own site at /gateway/api/automation/public/. A plain API token works on both, and both answered 200 on 1 October.
Here's the read-only run against our test site, from the repo folder. Swap wolfaenpak for your own site; EMAIL and TOKEN are your Atlassian login and a classic API token.
bash
1$ CLOUDID=$(curl-s https://wolfaenpak.atlassian.net/_edge/tenant_info | python3 -c 'import sys,json;print(json.load(sys.stdin)["cloudId"])')2$ curl-s-o /dev/null -w'%{http_code}\n'-u$EMAIL:$TOKEN https://wolfaenpak.atlassian.net/rest/api/3/automation/rule
34044$ curl-s-o /dev/null -w'%{http_code}\n'-u$EMAIL:$TOKEN https://wolfaenpak.atlassian.net/rest/cb-automation/latest/project/GLOBAL/rule
54046$ curl-s-o /dev/null -w'%{http_code}\n'-u$EMAIL:$TOKEN https://wolfaenpak.atlassian.net/gateway/api/automation/internal-api/jira/$CLOUDID/pro/rest/GLOBAL/rules
74048$ curl-s-o /dev/null -w'%{http_code}\n'-u$EMAIL:$TOKEN"https://wolfaenpak.atlassian.net/gateway/api/automation/public/jira/$CLOUDID/rest/v1/rule/summary?limit=1"920010$ python3 automation-engineer/scripts/automation_client.py list --email$EMAIL--token$TOKEN--cloudid$CLOUDID1124 rule(s)12 01a08225-4805-72ca-821a-9a48ebda2801 ENABLED Classification changed in Assets - sync Confluence space
13 019a39ad-6978-71ae-9e3b-2929135707ed ENABLED Copy of Test-1231
14 019a39ad-374c-7a4d-ae54-b5adf94a662b ENABLED Test-123
15 01a0ebaa-54d7-7327-852a-51835d734381 ENABLED When a comment is added → update the status
16...
Now the part I'm not proud of. We published the public path on 19 August, in our tutorial on what JCMA and cloud-to-cloud do to automation rules. On 1 September the agent on one of my client engagements found the same API on its own. It read rules through it and created a test rule on that client's sandbox. On 18 September the same agent's notes said "Jira Automation has no API-token-accessible REST surface", for the second time, after trying only guessed paths like the three above. So the answer existed twice, in our tutorial and in the agent's own log, and the agent reads neither before it starts work. That one's on me. It does read its skills, so that's where it lives now.
Atlassian's intro page calls it "the primary way to get and modify data in Automation across products". The rule-management reference adds one limit on every endpoint: "Forge and OAuth2 apps cannot access this REST resource". So it's for a script or an agent with a token. Not your Forge app.
POST /rule answers most mistakes with the same 400.
json
1{"errors":[{"status":400,"code":"api.error.unknown","title":"The request body could not be parsed, please ensure the values provided are valid."}]}
On one earlier run, hand-built bodies got a 500 instead. Don't read the status code as the diagnosis either. The skill's gotchas file has the three rules that get you past it.
Keep the entire structure exactly as GET /rule/{uuid} returned it. Don't hand-build or strip it.
Set rule.uuid to a fresh, valid UUID v7. Not v4, not omitted.
Set rule.authorAccountId to a real accountId on the target site. Never omit it.
The v7 rule is in Atlassian's docs now ("it must be unique and V7"). On 22 September we'd found it only in the Postman collection. The skill now says both. The authorAccountId rule still isn't marked required in the schema. The skill's create_rule() always mints a fresh v7 uuid itself, and it refuses to send a rule with no authorAccountId, with a clear message instead of the 400. It can't tell whether the accountId is valid on the target. That one you still find out from the 400.
Read, create and enable/disable were proven on a live migration of 15 production rules onto a sandbox. The update, PUT /rule/{uuid}, comes from Atlassian's spec. I haven't proven it live. The skill says a granular-scoped token gets 401 "Unauthorized; scope does not match" on every call. I haven't re-tested that. Cloud only.
Jira automation rules migration between Cloud sites
Moving a rule is mostly about ids that belong to the old site. My own test rule shows one. This is get on that "When a comment is added" rule (trimmed).
That cloudId is the source site's. Post it unchanged and the trigger still filters on a project in the old site. The skill names the others: cf[NNNNN] field ids in JQL, which on the target can hit nothing or, worse, a different field with the same number (the same trap breaks saved filters after a migration). Assets object ARIs in JQL. A create-issue action naming the project by raw id, which fails late. Group UUIDs and accountIds need nothing. They're shared across sites in one organization.
The production run, quoted from the skill: 15 rules on one JSM project, from a client's production site to a sandbox. 13 were clean beyond the structural ids. 1 had a cf[] and an Assets ARI in the same JQL. 2 hit the raw id trap. All 15 went in disabled, read back with zero source-cloudId matches, then got production's states. Nothing was written to production.
Migrate a Jira project from cloud to cloud into a live site
The second skill is for moves where Atlassian's tool can't be used, or can but isn't acceptable. Atlassian's route comes first, and the skill says so: "Atlassian's own cloud-to-cloud migration is the first thing to evaluate". It needs one person who is org admin on both sides. Atlassian's page only offers "the Jira instances for which you are an organization admin".
The skill is for when that's off the table. Nobody is org admin in both orgs, or the source's IT won't support the tool. Or the target is busy in production and nothing on it may change. Atlassian's copy can land in a site with existing data, but it merges a same-named group in both directions (that one's written up here). Or only a KEEP list of people may appear on the target.
It's the runbook from a real production move of over a dozen Jira projects and about as many Confluence spaces (the skill rounds those, so do I). It covers silent loading: every channel that can send mail is closed with something you can read back. Ordered creates with fillers keep PROJ-1234 as PROJ-1234. KEEP-list anonymisation reaches into attachments with OCR. Why copy, not move? A move carries every name in the changelog. The price is history: created dates can't be set.
Automation stays behind either way. Atlassian's "What data is copied" page marks "Automation flows (including project-level automation flows)" with a cross for Jira, "Jira automation" for JSM and "Space Automation Flows" for Confluence. The cloud-to-cloud skill lists automation rules as a "Separate subsystem" and points to automation-engineer. That's the link between the two.
The skill on GitHub at fe4973f. The front matter now renders as a table; before the fix, the same page carried a red Error in user YAML banner. Captured 1 October 2026.
Proven: 44 offline tests and 14 leak-scan tests pass. I ran them on 3 October. The skill's changelog says its templates were exercised on a test site. I didn't run those writes myself. Not proven, and the skill says so: whether a reporter change notifies a JSM customer, whether a desk with no notification scheme is silent, and sites with customer-managed keys. The 1,700-2,100 items an hour per admin account is the engagement's number. I haven't reproduced it.
How the skills pack keeps improving
66 commits since the first one on 31 March. Since 22 September the pack went from seven skills to nine. The commits I care about are corrections a real job forced. Two from the last month:
24 September: the OpenAPI specs now refresh from Atlassian. The three we had had drifted since February: Jira 617 to 619 operations, Confluence v2 212 to 218, Assets 61 to 64.
2 September: Jira's attachment content endpoint answers 303, not 302. A follower that only handles 301 and 302 writes a zero-byte file, and Jira accepts it with a 200.
And one from 1 October. I shipped the cloud-to-cloud skill at 23:12 with an unquoted colon in its YAML front matter, and GitHub put a red banner on the page. Yes, a colon. Fixed 22 minutes later, with a scripts/check-frontmatter.py that parses every SKILL.md in the repo. Two more that night fixed the automation skill's wording on the path and the v7 rule.
The cloud-to-cloud release and the corrections that followed it the same night, above the 24 September spec refresh. Cropped from the commits page on github.com, 1 October 2026.
Credit to Atlassian's Automation team for shipping the Rule Management API with an OpenAPI spec. The skill's endpoint table is checked against it, not against prose.
Start read-only. Install the pack and ask your agent to list the automation rules on a test site. If it reaches for /rest/api/3, the skill probably isn't loaded. Found a gap? Open an issue. The full catalogue is on our AI skills page, and if skills are new to you, the working guide has six real examples.
JCMA "We couldn't export Custom Field Config Scheme": three causes, three fixes
JCMA stops with "We couldn't export Custom Field Config Scheme" and a java.lang.NullPointerException, and the same message has three unrelated causes, each documented in a different Atlassian source. Here is how to tell them apart from the log line, the fix for each, three problems in the knowledge base's own SQL, and what the Cloud-to-Cloud side looks like.
