Jira Automation Rules API: Two New Agent Skills

LeanZero released two new skills in its open-source agent skills pack that teach coding agents to use Atlassian's Jira Automation Rules API, which is now generally available at api.atlassian.com/automation/public. One skill reads, creates, updates and migrates Automation rules, while the second copies Jira projects, JSM desks and Confluence spaces between Cloud sites over REST, filling a gap left by Atlassian's own cloud-to-cloud copy, which does not carry automation rules. The skills install as SKILL.md folders for Claude Code and Cline under Apache 2.0.

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 https://community.atlassian.com/forums/Jira-questions/Do-we-have-api-to-create-automation-rules/qaq-p/1841277 ". 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 https://community.atlassian.com/forums/Automation-articles/Automation-Rule-Management-API-is-now-Generally-Available/ba-p/3115881 . 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. 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. git clone https://github.com/leanzero-srl/leanzero-forge-skills cd leanzero-forge-skills ./scripts/install-skills.sh --claude-only On a clean machine it prints one line per skill trimmed, paths shortened . install-skills --- Claude Code skills ~/.claude/skills --- install-skills OK: linked atlassian-jira-forge-skill - ~/.claude/skills/atlassian-jira-forge-skill ... install-skills OK: linked atlassian-cloud-to-cloud-migration-skill - ~/.claude/skills/atlassian-cloud-to-cloud-migration-skill install-skills OK: linked forge-security-review - ~/.claude/skills/forge-security-review install-skills OK: linked automation-engineer - ~/.claude/skills/automation-engineer 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. 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 $ CLOUDID=$ curl -s https://wolfaenpak.atlassian.net/ edge/tenant info | python3 -c 'import sys,json;print json.load sys.stdin "cloudId" ' $ curl -s -o /dev/null -w '%{http code}\n' -u $EMAIL:$TOKEN https://wolfaenpak.atlassian.net/rest/api/3/automation/rule 404 $ curl -s -o /dev/null -w '%{http code}\n' -u $EMAIL:$TOKEN https://wolfaenpak.atlassian.net/rest/cb-automation/latest/project/GLOBAL/rule 404 $ 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 404 $ 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" 200 $ python3 automation-engineer/scripts/automation client.py list --email $EMAIL --token $TOKEN --cloudid $CLOUDID 24 rule s 01a08225-4805-72ca-821a-9a48ebda2801 ENABLED Classification changed in Assets - sync Confluence space 019a39ad-6978-71ae-9e3b-2929135707ed ENABLED Copy of Test-1231 019a39ad-374c-7a4d-ae54-b5adf94a662b ENABLED Test-123 01a0ebaa-54d7-7327-852a-51835d734381 ENABLED When a comment is added → update the status ... 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 https://leanzero.net/tutorials/jira-automation-rules-migration-actor-scope?utm source=devto&utm medium=referral&utm campaign=crosspost . 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 https://developer.atlassian.com/cloud/automation/rest/intro/ calls it "the primary way to get and modify data in Automation across products". The rule-management reference https://developer.atlassian.com/cloud/automation/rest/api-group-rule-management/ 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. {"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. GET /rule/{uuid} returned it. Don't hand-build or strip it. rule.uuid to a fresh, valid UUID v7. Not v4, not omitted. 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. 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 . "trigger": { "component": "TRIGGER", "schemaVersion": 1, "type": "jira.issue.event.trigger:commented", "value": { "eventTypes": "PRIMARY ACTION" , "eventFilters": "ari:cloud:jira:<cloudId :project/11884" }, 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 https://leanzero.net/blog/jira-filters-survived-the-migration?utm source=devto&utm medium=referral&utm campaign=crosspost . 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. 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 https://support.atlassian.com/organization-administration/docs/copy-jira-data/ 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 https://leanzero.net/blog/migrate-jira-users-groups-same-name-merge?utm source=devto&utm medium=referral&utm campaign=crosspost . 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 https://support.atlassian.com/organization-administration/docs/what-product-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. 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. 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: 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. 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 https://leanzero.net/ai-skills?utm source=devto&utm medium=referral&utm campaign=crosspost , and if skills are new to you, the working guide https://leanzero.net/tutorials/agent-skills-working-guide?utm source=devto&utm medium=referral&utm campaign=crosspost has six real examples. Originally published on leanzero.net https://leanzero.net/blog/jira-automation-rules-api-agent-skills?utm source=devto&utm medium=referral&utm campaign=crosspost . More Atlassian, Forge and local-AI write-ups at leanzero.net/blog https://leanzero.net/blog?utm source=devto&utm medium=referral&utm campaign=crosspost , and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services https://leanzero.net/services?utm source=devto&utm medium=referral&utm campaign=crosspost .