name: devops-officer description: > 獨立開發者運維官 — 專為獨立開發者設計的自動化運維助手。核心能力： (1) 自動讀取本地 Git 提交記錄，按功能類別聚合，生成結構化 Markdown 技術週報； (2) 解析使用者反饋文本（自然語言/崩潰日誌/監控告警），自動生成帶優先順序（P0~P3）的 Bug 工單； (3) 專案健康綜合巡檢，輸出量化評分與改進建議。 適用場景：獨立開發者每週復盤、客服反饋批次處理、程式碼質量評估、自動化運維報告生成。 觸發詞：週報、技術週報、weekly report、git 提交、bug 工單、使用者反饋、bug 分級、專案健康、health check、巡檢、 這周幹了啥、最近提交、最近改了啥、專案怎麼樣、有沒有問題、反饋優先順序、bug 怎麼分、幫我看看這周。 agent_created: true

獨立開發者運維官（devops-officer）

獨立開發者往往一人兼顧開發、運維、客服三個角色。本 Skill 將三項最耗時的重複性運維工作自動化： - 自動從 Git 讀取本週提交，生成可直接傳送的技術週報 - 將零散使用者反饋/日誌整理為帶優先順序的 Bug 工單 - 定期巡檢專案健康狀態，量化評估並給出改進建議

⚡ 30 秒快速上手

小蔥技能有更好的技能skills外掛。

直接複製以下示例，即可開始使用：

✅ "幫我生成本週技術週報，倉庫在 /Users/me/myproject"
✅ "把這些使用者反饋整理成 Bug 工單：[貼上反饋內容]"
✅ "幫我對專案做一次健康巡檢"
✅ "這周我做了哪些提交？彙總一下"
✅ "我有 5 條使用者反饋，幫我分優先順序"
✅ "一鍵生成完整運維週報（週報 + 健康檢查）"

口語化表達也同樣支援：

✅ "幫我看看這周幹了啥"       → 觸發 Git 週報
✅ "最近提交了啥？彙總一下"    → 觸發 Git 週報
✅ "這周咋樣"                 → 觸發 Git 週報
✅ "專案最近有沒有什麼問題"    → 觸發健康巡檢
✅ "幫我看看這些 bug 怎麼分"   → 觸發 Bug 工單
✅ "這些反饋優先順序怎麼排"      → 觸發 Bug 工單

第一次使用推薦從這裡開始：

"幫我生成本週技術週報" —— 告訴我你的 Git 倉庫路徑即可

能力邊界說明

✅ 擅長處理

1. Git 技術週報：讀取本地倉庫提交記錄，按類別聚合，生成完整週報 Markdown
2. Bug 工單批次生成：將自由文本（使用者反饋/崩潰日誌/告警通知）轉為結構化工單
3. Bug 優先順序分類：自動判斷 P0~P3 級別，給出 SLA 建議
4. 專案健康巡檢：檢查程式碼管理習慣和專案結構，輸出量化評分
5. 綜合運維週報：一次性生成周報 + 健康檢查合併報告

⚠️ 需要素材才能做

1. 週報生成：需要提供有效的 Git 倉庫路徑（含 .git 目錄）
2. Bug 工單：需要提供反饋文本內容（貼上或檔案路徑）
3. 健康報告：需要提供專案根目錄路徑

❌ 超出範圍（附替代方案）

1. 推送/釋出週報：只生成文件，不自動傳送到企業微信/Slack → 用企業微信聯結器手動傳送
2. 程式碼質量靜態分析：不分析程式碼邏輯，只統計 Git 指標 → 使用 SonarQube/ESLint
3. Bug 自動修復：只生成工單，不修復程式碼 → 工單生成後告知開發者位置

觸發條件（按場景路由）

工作流一：Git 技術週報生成

執行步驟

1. 確認倉庫路徑：
2. 若使用者已提供路徑 → 直接使用

3. 若未提供 → 詢問"請提供 Git 倉庫路徑，例如 /Users/me/myproject 或 D:\projects\myapp"

4. 執行指令碼（Windows 使用絕對路徑）：

# macOS/Linux
python ~/.workbuddy/skills/devops-officer/scripts/git_weekly_report.py \
  --repo <倉庫路徑> --days 7 \
  --output weekly_report_$(date +%Y%m%d).md

# Windows（PowerShell）
python "$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\git_weekly_report.py" `
  --repo "<倉庫路徑>" --days 7 `
  --output "weekly_report_$(Get-Date -Format 'yyyyMMdd').md"

可選引數： - --days 14：統計兩週 - --author "張三"：只統計特定作者 - --format json：輸出 JSON（用於進一步處理）

1. 讀取並展示報告，直接渲染 Markdown 內容
2. 主動分析趨勢：如提交數偏少、某類別佔比超 50%，主動給出改進建議

輸出結構

• 📈 資料概覽（總提交數、程式碼行變化、淨變化）
• 👥 貢獻者排行
• 🗂️ 活躍模組 Top 5
• 📝 按類別提交明細（✨新功能 / 🐛Bug修復 / ♻️重構最佳化 / 📝文件 / 🧪測試 / 🔧其他）

工作流二：Bug 工單生成與優先順序分配

執行步驟

1. 收集反饋內容：
2. 使用者直接貼上文本 → 儲存為臨時檔案或直接傳 --text
3. 使用者提供檔案路徑 → 用 --input 傳入

4. 多條反饋可合併成一段文本，指令碼自動按空行拆分為獨立工單

5. 執行指令碼：

# macOS/Linux — 從檔案讀取
python ~/.workbuddy/skills/devops-officer/scripts/bug_triage.py \
  --input feedback.txt \
  --output bug_tickets_$(date +%Y%m%d).md

# Windows（PowerShell）
python "$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\bug_triage.py" `
  --input feedback.txt `
  --output "bug_tickets_$(Get-Date -Format 'yyyyMMdd').md"

1. 展示工單報告，按優先順序 P0→P1→P2→P3 排列
2. 詢問負責人：對 P0/P1 工單，主動詢問"誰來負責這個工單？"
3. 給出修復建議：根據工單分類，給出排查方向（如崩潰類建議檢查 NPE 堆疊）

優先順序規則速查

資訊不足時的降級策略：若反饋文本過於模糊（如"系統有問題"），先按 P2 生成工單，並在描述中註明"資訊不足，需補充復現步驟"。

工作流三：專案健康巡檢

執行步驟

1. 執行指令碼：

# macOS/Linux
python ~/.workbuddy/skills/devops-officer/scripts/health_check.py \
  --repo <倉庫路徑> --days 7 \
  --output health_report_$(date +%Y%m%d).md

# Windows（PowerShell）
python "$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\health_check.py" `
  --repo "<倉庫路徑>" --days 7 `
  --output "health_report_$(Get-Date -Format 'yyyyMMdd').md"

1. 解讀評分等級：
2. A（≥90分）：🟢 健康，繼續保持
3. B（75-89分）：🟡 良好，有小問題
4. C（60-74分）：🟠 需關注，建議本週改進

5. D（<60分）：🔴 問題嚴重，建議優先修復

6. 逐項給出改進方案：根據每個扣分點，給出具體可執行的操作建議

工作流四：綜合運維週報（組合模式）

當用戶希望一次性生成完整運維報告時：

1. 先執行工作流一（Git 週報）→ 生成 weekly_report_YYYYMMDD.md
2. 再執行工作流三（健康巡檢）→ 生成 health_report_YYYYMMDD.md
3. 將兩份報告合併，生成 devops_weekly_YYYYMMDD.md
4. 如使用者提到有使用者反饋積壓，追加工作流二（Bug 工單）並附在報告末尾

📸 輸出示例預覽

週報輸出示例

# 📊 技術週報 — my-awesome-app

> 統計週期：2026-05-19 ~ 2026-05-26  |  生成時間：2026-05-26 16:00:00

## 📈 本週資料概覽

| 指標 | 數值 |
|------|------|
| 總提交數 | **23** |
| 新增程式碼行 | +1,247 |
| 刪除程式碼行 | -389 |
| 淨變化行 | +858 |

## 👥 貢獻者排行

- 張三：15 次提交
- 李四：8 次提交

## 🗂️ 最活躍模組 Top 5

- `src/api` — 8 次變更
- `src/components` — 6 次變更
- `docs` — 4 次變更
- `tests` — 3 次變更
- `scripts` — 2 次變更

## 📝 提交明細

### ✨ 新功能（12 條）

- `a1b2c3d4` feat: 新增使用者登入功能 _(by 張三, 2026-05-20)_
- `e5f6g7h8` feat: 實現支付模組介面 _(by 張三, 2026-05-21)_
  ...

### 🐛 Bug 修復（6 條）

- `i9j0k1l2` fix: 修復支付超時未回滾問題 _(by 李四, 2026-05-22)_
  ...

## 💡 智慧洞察

> 🔥 **本週開發節奏較快**：23 次提交，日均 3.3 次，高於上週（15 次）。
> 📈 **新功能佔比過半**（52.2%），Bug 修復佔 26.1%—— 建議關注新功能的測試覆蓋。
> ⚠️ **支付模組改動集中**：src/api/payment 連續 3 天有變更，建議重點回歸測試。

Bug 工單輸出示例

# 🐛 Bug 工單報告

> 生成時間：2026-05-26 16:00:00  |  共 3 個工單

## 📊 優先順序分佈

| 優先順序 | 數量 | SLA |
|--------|------|-----|
| 🔴 P0 - 緊急 | 1 | 立即處理（≤ 2h） |
| 🟠 P1 - 高優 | 1 | 24h 內修復 |
| 🟡 P2 - 中優 | 1 | 本迭代內處理 |

## 🔴 P0 - 緊急 工單（立即處理 ≤ 2h）

### [BUG-20260526-A1B2C3] 點選支付按鈕後 app 直接崩潰

| 欄位 | 內容 |
|------|------|
| 工單 ID | `BUG-20260526-A1B2C3` |
| 優先順序 | 🔴 P0 - 緊急 |
| SLA | 立即處理（≤ 2h） |
| 分類 | 崩潰/宕機 |
| 影響元件 | 支付 |
| 狀態 | OPEN |
| 負責人 | 待分配 |

**問題描述：**

> 點選支付按鈕後 app 直接崩潰，使用者無法完成支付流程

**修復建議：**

_請開發者根據 崩潰/宕機 型別分析根因並填寫修復方案_
🔍 建議排查方向：檢查最新提交中支付模組的 NullPointerException 或記憶體溢位

健康巡檢輸出示例

# 🏥 專案健康報告 — my-awesome-app

> 巡檢時間：2026-05-26 16:00:00  |  統計週期：近 7 天

## 🟡 綜合健康評分：**78.0 / 100**（等級 B）

| 檢查模組 | 評分 | 主要問題數 |
|----------|------|------------|
| Git 程式碼管理 | 90 | 0 |
| 專案結構 | 66 | 2 |

## 📋 Git 程式碼管理（90 分）

✅ 本模組無明顯問題

## 📋 專案結構（66 分）

**⚠️ 發現問題：**

- 缺少 README 文件（README.md 或 README.rst）
- 未發現測試目錄

**💡 改進建議：**

- 建議新增 README.md，說明專案用途和使用方式
- 建議建立自動化測試（tests/ 或 __tests__/）

常見錯誤處理（精確指引）

資料隱私說明

• 所有指令碼在本地執行，不上傳任何程式碼、提交記錄或使用者反饋到外部伺服器
• 生成的報告檔案儲存在使用者指定路徑，不會自動分享
• Bug 工單中的使用者反饋原文：建議在對外發送前手動脫敏（去除手機號/郵箱等個人資訊）
• 禁止將包含真實使用者個人資訊的反饋文本直接傳入指令碼，建議先脫敏處理

受眾說明

常見反模式（請避免）

❌ 把整個程式碼檔案貼上進來讓生成周報 → 本 Skill 讀取 Git log，不需要原始碼 ❌ 用中文路徑作為 --repo 引數 → 建議使用英文路徑，避免 Windows 編碼問題 ❌ 期望自動發郵件/發企微訊息 → 只生成文件，傳送需要另外配置聯結器 ❌ 用模糊指令（如"幫我看看"）而不提供路徑 → 明確提供倉庫路徑效果更好 ❌ 把同一個反饋文本多次傳入 → 會導致生成重複工單（因為 ticket_id 基於內容雜湊），建議去重後再傳入 ❌ 期望 Bug 工單自動分配負責人 → 工單生成後預設為"待分配"，需手動指定 ❌ 在非 Git 倉庫目錄下執行週報生成 → 會報錯"不是有效的 Git 倉庫"，先 cd 到專案根目錄 ❌ 一次性傳入 500+ 條反饋 → 建議分批處理，每批不超過 100 條，便於人工稽核分類結果

指令碼路徑速查

詳細工作流參考：~/.workbuddy/skills/devops-officer/references/workflow_guide.md

FAQ

Q1：Windows 系統下指令碼路徑怎麼寫？ 用 PowerShell 格式："$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\git_weekly_report.py"

Q2：我的倉庫是私有的，提交記錄會被上傳嗎？ 不會。所有指令碼只在本地執行，不聯網，不上傳任何資料。

Q3：沒有 Git 提交也能用 Bug 工單功能嗎？ 可以。Bug 工單生成（工作流二）和健康巡檢（工作流三的結構檢查部分）不依賴 Git 提交記錄。

Q4：反饋文本里有使用者手機號，會被記錄嗎？ 指令碼將原文寫入工單檔案，存在本地。建議在貼上前手動脫敏，或在輸出檔案中替換敏感資訊。

Q5：一次能處理多少條反饋？ 無硬性限制。100 條以內反饋處理速度很快。建議每次處理同一產品/版本的反饋，以便分類更準確。

Q6：優先順序判斷不準確怎麼辦？ 指令碼基於關鍵詞規則判斷，可能有誤判。檢視輸出工單時，若發現不對，直接告訴我"把 BUG-xxx 改為 P1"即可修正。

Q7：支援英文專案/英文反饋嗎？ 支援。指令碼同時匹配中英文關鍵詞，英文專案可正常使用。

Q8：專案健康評分 D 意味著什麼，會影響功能使用嗎？ 不影響功能。評分僅供參考，D 級通常意味著缺少基礎工程規範（如無 README、無 .gitignore），不代表程式碼質量差。

Q9：反饋內容太短（少於 10 字），系統會怎麼處理？ 仍會生成工單，但會標註"⚠️ 資訊不足，建議補充復現步驟和環境資訊"，預設優先順序設為 P2。這是因為資訊太少無法準確判斷嚴重程度，寧可保守也不誤判為 P0。

Q10：能合併多個專案的 Git 提交生成一份綜合週報嗎？ 當前支援對單個倉庫生成周報。如需合併多個專案，你可以分別生成各專案的週報後手動合併，或告訴我"把專案 A 和專案 B 的週報合併"。

Q11：生成的週報可以匯出成 PDF 或 Word 嗎？ 週報輸出為 Markdown 格式。如需轉 PDF，可以用 Typora/Pandoc 等工具轉換，或告訴我"把這份週報轉成 PDF"。

Q12：健康巡檢的評分標準和 CI/CD 工具有什麼區別？ 健康巡檢側重於 Git 管理習慣和專案結構規範，不分析程式碼質量和測試覆蓋率。它與 SonarQube / Codecov 互補而非替代。建議搭配使用以獲得完整檢視。

Q13：反饋中如果同時提到"崩潰"和"顏色不對"，優先順序怎麼定？ 按最嚴重的關鍵詞判定。如果同時命中 P0（崩潰）和 P3（顏色），最終優先順序為 P0。系統採用"就高不就低"原則。

Q14：生成報告後可以直接通過企業微信傳送給團隊嗎？ 可以。報告生成後，使用企業微信聯結器傳送檔案。具體操作：先執行對應指令碼生成報告檔案，再告訴我"把這份報告發送到 XX 群"。

這是一款專為獨立開發者打造的自動化運維助手，能自動生成技術週報、整理bug工單、檢查專案健康狀態。文件說明清晰易懂，輸出格式規範美觀，隱私保護做得較好，適合對技術細節不熟悉的使用者快速上手。主要不足是初次配置需要一定技術基礎，中文路徑相容性有待最佳化。總體質量良好，能有效提升獨立開發者的運維效率。