Jira QA Handoff

Convert recent git commits on the current branch into a Chinese product-behavior summary + test cases, then sync them to the PM's task-type Jira issue. Designed for product managers who have shipped code changes themselves.

The team's flow: the PR title carries the PM's task-type Jira key → after PR merge, Jira automatically generates a downstream test-type issue for QA → QA reads the PM's task description to get context. So the description written here is what QA will end up reading.

Hard rules

• Output language for Jira content: 中文 (Simplified Chinese) — title, description, test cases. Never include code snippets, file paths, function names, line numbers, or implementation details. QA reads this; QA does not read code.
• Skill instructions stay in English (this file).
• Preserve any pre-existing context in the Jira issue when updating — Slack URLs, linked Jira issues, attached screenshots, @mentions, prior product decisions, and the existing title/description. This is the silent default; never ask "should I preserve this?" and never list what you're "not changing" before posting. Append, don't replace.
• One confirmation gate, then execute. Preview the proposed appended content once in Step 3. After the user approves, call the edit endpoint immediately — do not show a before/after diff, do not re-summarize what you're keeping.
• Trust the diff, but ask for product intent. Code shows what changed; only the PM knows why. If the intent is ambiguous, ask one clarifying question before drafting.
• Convert any relative dates ("today", "this week") to absolute dates (YYYY-MM-DD) before writing them into Jira.

When to skip

• Pure refactor / chore / dependency bump with no user-visible change → tell the user "no QA-visible behavior to hand off" and stop.
• Code-only fixes that already have a QA-owned Jira test issue → confirm with the user before duplicating.