Checkbox syntax reaches Jira as literal brackets on both update-jira-ticket paths

[williamthorsen]

Problem

update-jira-ticket is silent on task-list syntax on both paths, so checkbox-bearing content reaches Jira as literal brackets and agents rediscover the failure once per session by noticing the mangled description after the fact. On the Markdown path, Jira's Markdown-to-ADF converter does not map - [ ] / - [x] to ADF task items; it escapes the brackets, so each line persists as a bullet reading \[ \] .... On the HTML path, the conversion step gives no rule for task lists, so <li>[ ] ...</li> passes the pre-flight checker clean and lands the same defect without the backslashes.

Context

• The failure is systematic, not incidental. design-and-plan and create-ticket both template acceptance criteria as - [ ] checkboxes, so an agent that faithfully forwards its own ticket artefact hits this on every run. An instruction phrased as advice about hand-authored prose would not catch that path; it has to name artefact-sourced content as in scope.
• The Markdown path's existing step 2 reserves contentFormat: "adf" for "content whose fidelity Markdown cannot express," a description task lists fit. A rule that only forbids checkboxes would leave two steps pointing opposite ways.
• contentFormat is a call-level parameter governing the whole fields.description value, so there is no per-section ADF escape.
• Observed against COMPPLAN-1729 via Rovo editJiraIssue with contentFormat: "markdown". The tool's returned description rendered every criterion as * \[ \] ..., so the escaping happens server-side during conversion and is visible in the tool response without a separate read. The HTML-path variant is inferred from the allowlist rather than observed.

Proposed solution

Add a checklist rule to each path of packages/agents/content/skills/update-jira-ticket/SKILL.md, converting task-list syntax to plain bullets at the Jira boundary. Upstream templates keep - [ ], which renders correctly in local artefacts and on GitHub; only the Jira submission converts.

The Markdown path's rule also states that native checkboxes exist only as ADF taskList / taskItem nodes and that a checklist never justifies authoring the whole description as ADF, resolving the step-2 tension rather than sitting beside it.

No pre-flight checker rule. Every rules.ts entry maps to a documented INVALID_INPUT trigger, and a bracket-rendering defect fails nothing; enforcing it there would turn a validity pre-flight into a style linter and make "findings are not optional" untrue.

Acceptance criteria

Must have

• Each path instructs converting task-list syntax to plain bullets before submitting.
• The Markdown path's instruction names artefact-sourced content as in scope, so forwarding a checkbox-bearing ticket artefact verbatim is covered.
• The Markdown path's instruction states that a checklist does not warrant contentFormat: "adf".

Should have

• The Markdown path records why - [ ] cannot work there, so an implementer does not spend a round trip re-testing it.