claude-engineering-plugin/plugins/compound-engineering/skills/jira-ticket-writer/SKILL.md

name, description

name	description
jira-ticket-writer	This skill should be used when the user wants to create a Jira ticket. It guides drafting, pressure-testing for tone and AI-isms, and getting user approval before creating the ticket via the Atlassian MCP. Triggers on "create a ticket", "write a Jira ticket", "file a ticket", "make a Jira issue", or any request to create work items in Jira.

Jira Ticket Writer

Write Jira tickets that sound like a human wrote them. Drafts go through tone review before the user sees them, and nothing gets created without explicit approval.

Workflow

Phase 1: Validate Scope

Before drafting anything, confirm two things:

1. What the ticket is about. Gather the ticket contents from the conversation or the user's description. If the scope is unclear or too broad for a single ticket, ask the user to clarify before proceeding.

2. Where it goes. Determine the Jira project key and optional parent (epic). If the user provides a Jira URL or issue key, extract the project from it. If not specified, ask.

To look up the Jira project and validate the epic exists, use the Atlassian MCP tools:

• mcp__atlassian__getAccessibleAtlassianResources to get the cloudId
• mcp__atlassian__getJiraIssue to verify the parent epic exists and get its project key

Do not proceed to drafting until both the content scope and destination are clear.

Phase 2: Draft

Write the ticket body in markdown. Follow these guidelines:

• Summary line: Under 80 characters. Imperative mood. No Jira-speak ("As a user, I want...").
• Body structure: Use whatever sections make sense for the ticket. Common patterns:
  • "What's happening" / "What we need" / "Context" / "Done when"
  • "Problem" / "Ask" / "Context"
  • Just a clear description with acceptance criteria at the end
• Code snippets: Include relevant config, commands, or file references when they help the reader understand the current state and desired state.
• Keep it specific: Include file paths, line numbers, env names, config values. Vague tickets get deprioritized.
• "Done when" over "Acceptance Criteria": Use casual language for completion criteria. 2-4 items max.

Phase 3: Pressure Test

Before showing the draft to the user, self-review against the tone guide.

Read references/tone-guide.md and apply every check to the draft. Specifically:

1. Patronizing scan: Read each sentence imagining you are the recipient, a specialist in their domain. Flag and rewrite anything that explains their own expertise back to them, tells them how to implement something in their own system, or preemptively argues against approaches they haven't proposed.

2. AI-ism removal: Hunt for em-dash overuse, bullet-point-everything formatting, rigid generated-feeling structure, spec-writing voice, and filler words (Additionally, Furthermore, Moreover, facilitates, leverages, streamlines, ensures).

3. Human voice pass: Read the whole thing as if reading it aloud. Does it sound like something a developer would type? Add moments of humility where appropriate ("you'd know better", "if we're missing something", "happy to chat").

4. Kindness pass: The reader is a human doing their job. Frame requests as requests. Acknowledge their expertise. Don't be demanding.

Revise the draft based on this review. Do not show the user the pre-review version.

Phase 4: User Approval

Present the final draft to the user in chat. Include:

• The proposed summary (ticket title)
• The proposed body (formatted as it will appear)
• The destination (project key, parent epic if any, issue type)

Ask for sign-off using AskUserQuestion with three options:

• Create it — proceed to Phase 5
• Changes needed — user provides feedback, return to Phase 2 with their notes and loop until approved
• Cancel — stop without creating anything

Phase 5: Create

Once approved, create the ticket:

1. Use mcp__atlassian__getAccessibleAtlassianResources to get the cloudId (if not already cached from Phase 1)
2. Use mcp__atlassian__createJiraIssue with:
   • cloudId: from step 1
   • projectKey: from Phase 1
   • issueTypeName: "Task" unless the user specified otherwise
   • summary: the approved title
   • description: the approved body
   • parent: the epic key if one was specified
3. Return the created ticket URL to the user: https://discoverorg.atlassian.net/browse/<KEY>