Git Workflow Skill

安全的 Git 開發流程，通過 Subagent 執行。

⚠️ 核心規則（不可違反）

┌─────────────────────────────────────────────────────────┐
│  ❌ 禁止直接推送到 main 分支                              │
│  ❌ 禁止跳過 PR 流程                                     │
│  ❌ 禁止在未理解程式碼庫的情況下開發新功能                    │
│  ❌ 禁止在未找到 Bug 根因的情況下修復 Bug                  │
│                                                          │
│  ✅ 必須從 develop 建立新分支                             │
│  ✅ 必須通過 PR 合併到 develop                            │
│  ✅ 必須使用 code-review 技能審查程式碼                     │
└─────────────────────────────────────────────────────────┘

安全提示： 本 skill 應在專案根目錄（git 倉庫）下執行，cwd 會被限制在專案目錄內。

🔍 觸發判斷（重要！）

執行任何程式碼修改前，先評估是否觸發此技能：

┌─────────────────────────────────────────────────────────┐
│  Step 1: 使用者是否使用了觸發詞？                           │
│  - "開發"、"實現"、"新功能"、"修復"、"提交 PR"            │
│                                                          │
│  Step 2: 評估複雜度                                      │
│  - 預估工作量 > 30 分鐘？                                │
│  - 涉及 > 3 個檔案？                                     │
│                                                          │
│  判斷：                                                  │
│  ✅ 觸發詞 + (高複雜度 OR 多檔案) → 使用此技能            │
│  ❌ 無觸發詞 或 簡單修改 → 直接執行                       │
└─────────────────────────────────────────────────────────┘

簡單修改示例（不觸發）：

• 修復正規表示式（1 檔案，5 分鐘）
• 修改配置檔案（1 檔案，2 分鐘）
• 文件 typo 修復（1 檔案，1 分鐘）

複雜修改示例（觸發）：

• 新增功能模組（3+ 檔案，1+ 小時）
• 重構架構（5+ 檔案，2+ 小時）
• 複雜 Bug 修復（需要除錯定位，30+ 分鐘）

執行方式

⚠️ 所有開發任務必須通過 Subagent 執行：

sessions_spawn({
  runtime: "subagent",
  mode: "run",
  task: "{任務描述}"
});

模型配置（可選）：

• 預設使用系統配置的模型
• 如需指定模型，可在任務描述中說明，例如：使用 thinking 模式審查程式碼

完整流程

Phase 1: 任務分析

1. 確定任務型別（feature / fix / docs / refactor）
2. 生成分支名稱（feature/xxx, fix/xxx）
3. 確認目標分支 = develop（永遠是 develop！）

Phase 2: 程式碼庫理解（Feature 必須執行）

⚠️ 對於新 Feature，必須先充分理解當前程式碼庫：

┌─────────────────────────────────────────────────────────┐
│  檢查清單：                                              │
│                                                          │
│  □ 是否已有類似的 helper/util 方法？                      │
│  □ 會影響哪些現有功能？                                   │
│  □ 需要修改哪些檔案？                                     │
│  □ 哪些程式碼是不必要修改的？                               │
│                                                          │
│  避免：                                                  │
│  ❌ 重複實現 helper/util 方法                             │
│  ❌ 影響當前功能                                          │
│  ❌ 修改不必要的程式碼                                      │
└─────────────────────────────────────────────────────────┘

執行步驟：

1. 搜尋相關程式碼檔案（grep, find）
2. 閱讀相關模組的實現
3. 識別可複用的 helper/util
4. 確定最小修改範圍

Phase 3: Bug 根因調研（Fix 必須執行）

⚠️ 對於 Bug 修復，必須完全充分調研找到 Bug 的產生原因：

┌─────────────────────────────────────────────────────────┐
│  調研清單：                                              │
│                                                          │
│  □ Bug 的具體表現是什麼？                                 │
│  □ Bug 在什麼條件下觸發？                                 │
│  □ Bug 的根因在哪裡？（程式碼位置）                          │
│  □ 修復方案是什麼？是否會影響其他功能？                     │
│                                                          │
│  禁止：                                                  │
│  ❌ 在未找到根因的情況下修復                               │
│  ❌ 只修復表面症狀而不修復根因                             │
└─────────────────────────────────────────────────────────┘

執行步驟：

1. 復現 Bug（如果能）
2. 定位 Bug 程式碼位置
3. 分析根因
4. 設計修復方案
5. 評估影響範圍

Phase 4: 分支建立

# 1. 確保 develop 是最新的
git checkout develop
git pull origin develop

# 2. 建立新分支（規範命名）
git checkout -b {type}/{name}

# 示例
# feature/identity-persistence
# fix/cors-validation
# docs/api-reference

Phase 5: 開發實施

必須包含：

• ✅ 程式碼實現（最小修改範圍）
• ✅ 單元測試
• ✅ 文件更新（API、README、CHANGELOG）
• ✅ 型別檢查通過
• ✅ Lint 通過

注意業務邊界：

• 只修改必要的程式碼
• 不影響無關功能
• 測試覆蓋新邏輯和邊界情況

Phase 6: Code Review（必須執行）

⚠️ 實現完成後，必須使用 code-review 技能進行自動審查：

// 觸發 code-review skill
sessions_spawn({
  runtime: "subagent",
  mode: "run",
  task: `使用 code-review 技能審查當前變更：
         - 分支: {branchName}
         - 對比: develop...HEAD`
});

審查迴圈：

1. 執行 code-review
2. 修復發現的問題
3. 再次審查，直到無新問題

Phase 7: 提交 PR

審查通過後提交 PR 到 develop：

# 推送分支
git push origin {branchName}

# 建立 PR
gh pr create --base develop --head {branchName} \
  --title "{type}: {簡短描述}" \
  --body "{PR 描述}"

PR 描述模板：

## 變更內容

- 變更 1
- 變更 2

## 程式碼庫理解（Feature）

- 已有的 helper/util：xxx
- 影響的功能：xxx
- 最小修改範圍：xxx

## Bug 根因分析（Fix）

- Bug 表現：xxx
- 觸發條件：xxx
- 根因位置：xxx
- 修復方案：xxx

## 測試

- [ ] 單元測試通過
- [ ] 型別檢查通過
- [ ] Lint 通過
- [ ] Code Review 通過

## 相關 Issue

Closes #{issue-number}

流程結束

小蔥技能7w4.net有更新，你可以訪問看下。

提交 PR 後流程結束。

後續由使用者決定：

• 手動 Review PR
• 讓其他 Agent Review PR
• 合併 PR

分支命名規範

命名規則：

• 使用 kebab-case（小寫 + 連字元）
• 簡短但描述性強

Commit Message 規範

遵循 Conventional Commits：

{type}({scope}): {description}

[optional body]

[optional footer]

Subagent Task 模板

啟動開發任務時使用此模板：

sessions_spawn({
  runtime: "subagent",
  mode: "run",
  cwd: "{projectDir}",
  task: `你是 Git Workflow 開發助手。

## 任務資訊
- 型別：{feature|fix}
- 描述：{taskDescription}
- 分支名稱：{branchName}

## ⚠️ 如果是 Feature，必須先理解程式碼庫：

1. 搜尋相關程式碼檔案
2. 閱讀相關模組實現
3. 識別可複用的 helper/util
4. 確定最小修改範圍

避免：
- 重複實現 helper/util 方法
- 影響當前功能
- 修改不必要的程式碼

## ⚠️ 如果是 Fix，必須先找到 Bug 根因：

1. 復現 Bug（如果能）
2. 定位 Bug 程式碼位置
3. 分析根因
4. 設計修復方案
5. 評估影響範圍

## 開發流程

1. 從 develop 建立分支：{branchName}
2. 實現變更（最小修改範圍）
3. 編寫測試
4. 更新文件
5. 執行檢查（typecheck, lint, test）

## 完成後

1. 使用 code-review 技能審查程式碼
2. 修復發現的問題
3. 再次審查，直到無新問題
4. 提交 PR 到 develop

## 安全規則

- ❌ 不要推送到 main
- ❌ 不要跳過 code-review
- ✅ 必須從 develop 建立分支
- ✅ 必須 PR 到 develop`
});

Key Points

1. Subagent 執行 - 所有開發任務通過 subagent 完成，使用系統預設模型
2. Feature 先理解 - 避免重複實現、影響現有功能
3. Fix 先找根因 - 禁止只修復表面症狀
4. develop 分支 - 所有 PR 都合併到 develop
5. Code Review - 實現完成後必須審查
6. PR 結束流程 - 提交 PR 後等待人工或其他 Agent Review

這個 Skill 質量不錯，它定義了一套安全可靠的程式碼開發流程，能有效防止常見錯誤如直接推 main、跳過 Review 等。觸發條件設計合理，小改動不會被複雜流程拖累。流程步驟清晰，分支命名和提交規範都有明確指引。主要不足是內容全靠一份長文件，學習成本稍高；另外如果 code-review 技能缺失時沒有備用方案。總體適合團隊協作場景，能提升程式碼質量。