Jira Ticket Writing

Overview

Write practical Jira tickets whose field structure matches the target Jira instance. Preserve user value and delivery outcomes while keeping implementation detail, acceptance evidence, and issue relationships in their proper fields.

Operating Boundary

• Draft by default. Requests to prepare, draft, rewrite, or clean a ticket do not authorize a Jira mutation.
• Create or update an issue only when the user explicitly requests the write and an approved Jira integration is available. Use a dry run when the integration provides one.
• Before a write, inspect the target project's field and issue-link metadata. For an edit, also read the current issue. Verify the exact project or issue, complete field payload, parent, and requested links immediately before mutation.
• If the target, field mapping, representation, or relationship direction cannot be verified, return the usable draft and identify the blocker. Do not silently publish a partial ticket; require explicit approval for any reduced write.

Field Representation

• For a human-readable draft, Markdown headings and labeled links are acceptable.
• For Jira API fields or a payload, return field-keyed data and serialize every rich-text value in the exact format accepted by the configured Jira instance. Use ADF nodes and marks when the field requires ADF; do not present Markdown as an API-ready ADF value.
• Discover instance-specific custom field IDs instead of inventing them. If field metadata is unavailable, use semantic field names in the draft and report that ID mapping is still required.