메뉴
將當前 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。