Jira Automation Rules API: Two New Agent Skills

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. 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. 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. $ 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. 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. {"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). "trigger": { "component": "TRIGGER", "schemaVersion": 1, "type": "jira.issue.event.trigger:commented", "value": { "eventTypes": ["PRIMARY_ACTION"], "eventFilters": ["ari☁️jira: :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). 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. 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 th