القائمة
將當前 Claude Code session 的工作內容整理成 Jira ticket 的進度更新 comment。 當使用者說「整理成 jira 進度」、「寫 jira comment」、「更新 jira」、「整理進度」、 「幫我寫 comment」、「記錄到 ticket」等類似意圖時觸發此 skill。 也適用於使用者完成一段工作後想記錄進度的場景，即使沒有明確提到 Jira。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
For git operations on files tracked by Leon's dotfiles bare repo — paths under `$HOME` such as `~/.config/`, `~/.claude/`, `~/.local/bin/`, `~/install.sh`, `~/README.md` — use `git dotfiles <subcommand>` instead of plain `git <subcommand>`. The repo is bare at `~/personal/.dotfiles` with `$HOME` as the work tree, so plain `git` cannot find a `.git/` and will either error out or walk up into an unrelated repo. Translate mechanically: same args, same flags. Does NOT apply to git operations in regular projects (any directory with its own `.git/`, e.g. `~/work/*`, `~/personal/projects/*`, cloned repos) — those use plain `git` as normal. The trigger condition is the file path being under a tracked dotfiles location, not the mere mention of "commit" or "git".
深度 review 另一個 AI agent (Cursor, Copilot Agent, Gemini CLI, ChatGPT, 其他 Claude session 等) 或 AI-輔助同事完成的 code 變更，從 reviewer 角度驗證實作正確、能 work、品質達標。 觸發情境包含使用者說「同事用 AI 寫了 X，幫我 review」「另一個 AI 完成的，pull 下來看一下」 「幫我詳細 review 這個 branch / PR / commit」「我同事推了 code，幫我看」 「這是 Cursor / Copilot Agent 做的，幫我審查」「幫我 code review」、提到拉取一個分支或 PR 並要求審查、或附上與其他 AI 的對話紀錄、task spec 並要求驗證實作的場景。 重點是 AI agent 寫的 code 有特定失敗模式 (hallucinated APIs、silent fallback、表面合理但實際錯誤、 testing theater、spec drift、over-engineering)，這些跟人類寫的 code 不一樣，要用對應的方法檢查。 這個 skill 是 *reviewer 視角*——不是請別人 review 自己的 code (那是 requesting-code-review)， 也不是處理收到的 review (receiving-code-review)。 Leon 收到同事 push 上來的 AI-輔助 commit / PR 並請你 review 時，請主動使用此 skill，即使他沒 明確要求。
استنادا إلى تصنيف SOC المهني
| name | jira-progress |
| description | 將當前 Claude Code session 的工作內容整理成 Jira ticket 的進度更新 comment。 當使用者說「整理成 jira 進度」、「寫 jira comment」、「更新 jira」、「整理進度」、 「幫我寫 comment」、「記錄到 ticket」等類似意圖時觸發此 skill。 也適用於使用者完成一段工作後想記錄進度的場景，即使沒有明確提到 Jira。 |
你的任務是將這次 session 的工作內容，整理成一段可以直接貼到 Jira ticket comment 的進度更新。
這份進度報告的讀者不只是工程師，還包括 PM 和主管。寫的時候請站在「使用者要在會議上用這份內容報告進度」的角度思考：
簡單來說：讓讀者知道「做了什麼、為什麼要做、涉及哪些面向、目前狀態如何」，而非「每一步具體怎麼改的」。
每一項工作描述都應該讓讀者理解因果脈絡，而不只是列出結論。
--scanner fortify、.fpr）維持原樣，不要把裡面的半形標點轉成全形h3. [PDMS-123] 標題，直接寫 h3. 標題）不要只用純文字，適當使用 Jira wiki markup 的格式標記來提升可讀性：
{*}粗體{*}：用於強調重要的結論、關鍵發現、或需要注意的事項{{monospace}}：用於技術名詞、工具名稱、檔案名稱、設定值、程式碼片段等{color:red}文字{color}：用於標記警告或需要特別注意的風險容易搞錯的語法（Jira wiki markup 跟 markdown 不同）：
{*}...{*}，不是 markdown 的 **...** 或 *...*（後者在 bullet list 開頭會被當成 list marker）{{...}}，Jira wiki markup 沒有 backtick（`...`）語法，用了不會渲染成 monospace，只會原樣顯示反引號字元。檔名、設定值、程式碼片段、技術名詞都用 {{...}}適當的格式修飾可以讓讀者更快速地掃讀重點，避免整篇都是同樣樣式的文字。
使用者必須提供 Jira ticket 號碼，絕對不要自己猜測或推斷。如果使用者沒有提供，請直接詢問。
如果有 jira_get_issue 或 jira_add_comment 等 Jira MCP 工具可用：
h3. 標題顯示成 ###、{{...}} 顯示成反引號、||表格|| 顯示成 markdown 表格）。這是 MCP 抓取時的轉譯，不是使用者原本寫的格式。不要因此誤判使用者是用 markdown 寫 comment，產出時一律使用 Jira wiki markup。既有 comment 只拿來參考語氣、結構與詳略程度，不要模仿它被轉譯後的語法如果沒有 Jira MCP 工具，跳過這步，直接根據下方格式撰寫。
回顧這次 session 中做了哪些事情，包括：
根據內容的複雜度彈性決定結構：
簡單任務（單一問題修復、小調整）：
h3. 修復 XXX 問題
* 描述描述，{*}結論是 XXX{*}
* 確認 {{某個設定}} 已正確配置
較複雜的任務（多個面向、較長的工作過程）：
h3. 實現 XXX 功能
描述這次工作的整體概況（一兩句話）
h4. 子主題 A
* 描述描述描述
* {*}關鍵發現{*}：描述描述
h4. 子主題 B
* 描述描述描述
結構不是固定的，根據內容自然地組織即可。重點是讓讀者能快速掌握進度。
將最終的 Jira wiki markup 內容包在 markdown codeblock 中輸出，讓使用者可以直接複製：
```
h3. 標題
* 內容
* 內容
```
輸出 comment 內容後，簡短提示使用者可以直接複製貼到 Jira。如果有 Jira MCP 可用，也可以詢問使用者是否要直接透過 MCP 發佈 comment。