Code Dev
📖 技能介紹
name: code-dev displayName: 🔧 程式碼開發 description: | 規範的 Git 開發流程：分支管理 → 開發 → PR → Review → 合併。 支援新 feature 開發和 bug 修復，強制禁止直接推送到 main。
觸發條件（需同時滿足）： 1. 使用者要求"開發"、"實現"、"新功能"、"修復"、"提交 PR" 2. 預估工作量 > 30 分鐘 或 涉及 > 3 個檔案
簡單修改不觸發： - 單檔案小改動（如修復 typo、正規表示式） - 配置檔案更新 - 文件修改 author: LuciusCao license: MIT version: 1.2 tags: - git - workflow - development - pr - code-review repository: https://github.com/LuciusCao/openclaw-skills/tree/main/code-dev compatibility: | Required tools: git, gh (GitHub CLI) Optional env: GITHUB_TOKEN (for GitHub authentication) Permissions: read/write current working directory, execute git and gh commands metadata: openclaw: emoji: "🔀" category: development
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}
流程結束
提交 PR 後流程結束。
後續由使用者決定： - 手動 Review PR - 讓其他 Agent Review PR - 合併 PR
分支命名規範
| 型別 | 格式 | 示例 |
|---|---|---|
| Feature | feature/{name} |
feature/identity-persistence |
| Fix | fix/{name} |
fix/cors-validation |
| Docs | docs/{name} |
docs/api-reference |
| Refactor | refactor/{name} |
refactor/message-queue |
命名規則： - 使用 kebab-case（小寫 + 連字元） - 簡短但描述性強
Commit Message 規範
{type}({scope}): {description} [optional body] [optional footer]7w4.net小蔥技能。
型別：
| Type | 用途 |
|------|------|
| feat | 新功能 |
| fix | Bug 修復 |
| docs | 文件更新 |
| refactor | 重構 |
| test | 測試相關 |
| chore | 構建/工具/依賴 |
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
- Subagent 執行 - 所有開發任務通過 subagent 完成，使用系統預設模型
- Feature 先理解 - 避免重複實現、影響現有功能
- Fix 先找根因 - 禁止只修復表面症狀
- develop 分支 - 所有 PR 都合併到 develop
- Code Review - 實現完成後必須審查
- PR 結束流程 - 提交 PR 後等待人工或其他 Agent Review
🤖 AI 評測
這個 Skill 質量不錯，它定義了一套安全可靠的程式碼開發流程，能有效防止常見錯誤如直接推 main、跳過 Review 等。觸發條件設計合理，小改動不會被複雜流程拖累。流程步驟清晰，分支命名和提交規範都有明確指引。主要不足是內容全靠一份長文件，學習成本稍高；另外如果 code-review 技能缺失時沒有備用方案。總體適合團隊協作場景，能提升程式碼質量。
