team-collaboration-issue
系統化解決 GitHub 問題
透過系統化調查、測試驅動開發和專業 Pull Request 工作流程，將模糊的錯誤報告和功能請求轉化為可投入生產的程式碼，遵循現代 CI/CD 實務。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「team-collaboration-issue」。 協助我調查 issue #456，使用者在最新部署後無法登入。
預期結果:
- 取得 issue #456 詳情：47 位使用者受影響，身份驗證出現 'invalid token' 錯誤
- 建立 hotfix 分支：hotfix/issue-456-auth-failure
- 執行 git bisect 以識別回歸 commit...
- 發現：Commit abc123d 於 2 天前引入 token 驗證錯誤
- 實作修復：新增適當的 token 過期檢查並包含測試涵蓋率
- 建立 PR #789 包含 hotfix 並部署至 staging
- 驗證：所有測試帳號的身份驗證現在正常運作
正在使用「team-collaboration-issue」。 實作 issue #789 中的使用者個人資料自訂功能。
預期結果:
- 建立包含 4 個階段的實作計劃：Schema、API、Frontend、Testing
- 已建立分支：feature/issue-789-profile-customization
- 階段 1 完成：新增 UserProfile 資料庫模型，包含 theme、language、timezone 欄位
- 階段 2 完成：實作具有身份驗證的 GET/PUT /api/profile 端點
- 階段 3 完成：新增前端個人資料設定元件
- 階段 4 完成：透過單元測試和整合測試達成 95% 測試涵蓋率
- 建立 PR #812 連結至 issue #789 並附上完整文件
- 所有 CI 檢查通過，準備接受審查
安全審計
安全All 77 static findings are false positives. The skill contains only documentation with code examples in markdown code blocks (git commands, GitHub CLI usage, testing patterns). No executable code, scripts, or runtime behavior present. The external commands, network patterns, and cryptographic references are purely illustrative examples for developers to follow during issue resolution workflows.
品質評分
你能建構什麼
關鍵生產環境錯誤修復
透過 git bisect 進行系統化根本原因分析，快速分流和解決影響使用者的 P0 生產環境問題，實作具有全面測試的緊急修復，並進行部署驗證。
從問題實作功能
透過結構化任務分解、測試驅動開發和遵循團隊標準的專業 Pull Request，將功能請求轉化為可投入生產的程式碼。
程式碼品質與流程改進
建立一致的問題解決團隊工作流程，包含適當的分支管理、全面測試和可擴展至開發團隊的文件。
試試這些提示
協助我解決 GitHub issue [ISSUE_NUMBER]。首先查看問題詳情和留言以了解問題。
Issue [ISSUE_NUMBER] 似乎是回歸問題。協助我使用 git bisect 識別哪個 commit 引入了錯誤，從 [BAD_COMMIT]（已損壞）和 [GOOD_COMMIT]（正常）開始。
實作 issue [ISSUE_NUMBER] 中描述的功能。建立功能分支，將實作分解為多個階段，首先使用 TDD 編寫測試，並建立具有完整文件的 Pull Request。
審查我針對 issue [ISSUE_NUMBER] 的修改，協助我建立專業的 Pull Request，包含全面描述（測試方法、效能影響和檢查清單）。
最佳實務
- 始終從 main 分支建立功能分支，使用描述性命名如 feature/issue-123-short-description
- 在實作修復前編寫失敗的測試（測試驅動開發），確保修復能解決實際問題
- 當錯誤是在過去的 commit 中引入時，使用 git bisect 進行系統化回歸追蹤
- 建立完整的 Pull Request，連結至 issue、描述變更內容並包含測試檢查清單
- 在結案問題前於生產環境驗證修復，並新增解決方案留言供未來參考
避免
- 跳過調查階段，在未了解根本原因的情況下直接進行程式碼變更
- 直接 commit 至 main 或 master 而非使用功能分支進行 issue 工作
- 編寫程式碼時未附上相應測試，這會使未來回歸更有可能發生
- 建立 Pull Request 時未連結至 issue 或未提供清晰的變更描述
- 合併 PR 後立即結案 issue，而未驗證修復是否真正解決了報告的問題