atlassian

What it is good at

• Looking before it creates an issue

  A create call fails when the project key, the issue type name or a required field is wrong, and issue type names are per-project: Task in one project may be Story or Work Item in another. The skill reads the projects, types and required fields first, which costs one call and saves a confusing 400.

• Showing a bulk create before sending it

  --dry-run prints the exact payload for every issue and sends nothing. A real batch pauses a second between creates, waits out a rate limit and retries once, and reports created and failed counts at the end. Anything not created goes to a remaining file, so a re-run of that file sends only those.

• Writing a body Atlassian will accept

  The REST API wants Atlassian Document Format rather than a string, which is the detail that turns a two-line script into an afternoon. You author in a small HTML dialect and the conversion happens locally, so panels, status lozenges and task lists survive instead of collapsing to plain paragraphs.

• Proving it can reproduce a page before it rewrites one

  An update replaces the whole body, so anything the tool failed to understand on the way in is gone on the way out. Before a whole-page update it converts the live page out and back and compares the result against what the server holds. If a single node differs it refuses and names the type. A read-only audit runs the same check over every page a CQL query finds and reports how many would pass, so you can measure your own site before you trust it.

• Carrying through what it does not recognise

  Atlassian's format is wider than any converter's vocabulary, and every macro on a page is a node this one has never heard of. Rather than dropping them or giving up, it carries each one through untouched, so an edit to one paragraph leaves the macros, colours, images and inline comments around it exactly as they were.

• Refusing a stale edit rather than overwriting one

  You pass the version your change was based on. Re-reading the page immediately before writing looks like a safeguard and is the opposite of one - it makes the version number current at the instant of the write, which is exactly what stops the clash being noticed. Passing the base version is what lets somebody else's edit be caught instead of buried.

• Publishing a markdown file to a Confluence page

  One file becomes one page, bound by its own frontmatter: the first run creates the page and writes its id back into the file, and every run after that updates the same page rather than making another. A run that would change nothing sends nothing, local images go up as attachments, and a page somebody edited in Confluence since the last publish is refused, naming who and when.

• Moving an issue only where its workflow allows

  transition reads the moves the issue's workflow offers from where it is now, and refuses a target that is not among them, one that matches two, or one whose screen needs a field such as a resolution, before anything is sent. It moves one issue per call and prints the command to move it back. comment adds plain text, or a formatted fragment held to Jira's node list.

• Keeping the token off the command line

  curl reads the site, the credentials and the method from a config file at mode 600, so the token never appears in ps output or in shell history. Setup verifies it against your site before writing anything, so a wrong token costs you nothing.