{"slug": "jira-automation-rules-api-two-new-agent-skills", "title": "Jira Automation Rules API: Two New Agent Skills", "summary": "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.", "body_md": "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.\n\nMost 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.\n\nThe 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.\n\n```\ngit clone https://github.com/leanzero-srl/leanzero-forge-skills\ncd leanzero-forge-skills\n./scripts/install-skills.sh --claude-only\n```\n\nOn a clean machine it prints one line per skill (trimmed, paths shortened).\n\n```\n[install-skills] --- Claude Code skills (~/.claude/skills) ---\n[install-skills] OK:   linked atlassian-jira-forge-skill -> ~/.claude/skills/atlassian-jira-forge-skill\n...\n[install-skills] OK:   linked atlassian-cloud-to-cloud-migration-skill -> ~/.claude/skills/atlassian-cloud-to-cloud-migration-skill\n[install-skills] OK:   linked forge-security-review -> ~/.claude/skills/forge-security-review\n[install-skills] OK:   linked automation-engineer -> ~/.claude/skills/automation-engineer\n[install-skills] Done. Restart your AI tool to pick up the new skills.\n```\n\nDrop `--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.\n\nFor 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.\n\nThe 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.\n\nHere'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.\n\n``` bash\n$ CLOUDID=$(curl -s https://wolfaenpak.atlassian.net/_edge/tenant_info | python3 -c 'import sys,json;print(json.load(sys.stdin)[\"cloudId\"])')\n$ curl -s -o /dev/null -w '%{http_code}\\n' -u $EMAIL:$TOKEN https://wolfaenpak.atlassian.net/rest/api/3/automation/rule\n404\n$ curl -s -o /dev/null -w '%{http_code}\\n' -u $EMAIL:$TOKEN https://wolfaenpak.atlassian.net/rest/cb-automation/latest/project/GLOBAL/rule\n404\n$ 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\n404\n$ 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\"\n200\n$ python3 automation-engineer/scripts/automation_client.py list --email $EMAIL --token $TOKEN --cloudid $CLOUDID\n24 rule(s)\n  01a08225-4805-72ca-821a-9a48ebda2801  ENABLED   Classification changed in Assets - sync Confluence space\n  019a39ad-6978-71ae-9e3b-2929135707ed  ENABLED   Copy of Test-1231\n  019a39ad-374c-7a4d-ae54-b5adf94a662b  ENABLED   Test-123\n  01a0ebaa-54d7-7327-852a-51835d734381  ENABLED   When a comment is added → update the status\n  ...\n```\n\nNow 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.\n\nAtlassian'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.\n\n`POST /rule` answers most mistakes with the same 400.\n\n```\n{\"errors\":[{\"status\":400,\"code\":\"api.error.unknown\",\"title\":\"The request body could not be parsed, please ensure the values provided are valid.\"}]}\n```\n\nOn 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.\n\n`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.\nThe 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.\n\nRead, 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.\n\nMoving 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).\n\n```\n\"trigger\": {\n  \"component\": \"TRIGGER\",\n  \"schemaVersion\": 1,\n  \"type\": \"jira.issue.event.trigger:commented\",\n  \"value\": {\n    \"eventTypes\": [\"PRIMARY_ACTION\"],\n    \"eventFilters\": [\"ari:cloud:jira:<cloudId>:project/11884\"]\n  },\n```\n\nThat 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.\n\nThe 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.\n\nThe 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\".\n\nThe 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.\n\nIt'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.\n\nAutomation 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.\n\nProven: 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.\n\n66 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:\n\nAnd 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.\n\nCredit 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.\n\nStart 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.\n\nOriginally 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).", "url": "https://wpnews.pro/news/jira-automation-rules-api-two-new-agent-skills", "canonical_source": "https://dev.to/mihai_leanzero/jira-automation-rules-api-two-new-agent-skills-58b", "published_at": "2026-10-03 05:05:32+00:00", "updated_at": "2026-10-03 05:07:41.733827+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["LeanZero", "Atlassian", "Jira", "Confluence", "Claude Code", "Cline", "Jira Automation Rules API", "Jira Service Management"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/jira-automation-rules-api-two-new-agent-skills", "markdown": "https://wpnews.pro/news/jira-automation-rules-api-two-new-agent-skills.md", "text": "https://wpnews.pro/news/jira-automation-rules-api-two-new-agent-skills.txt", "jsonld": "https://wpnews.pro/news/jira-automation-rules-api-two-new-agent-skills.jsonld"}}