Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:40:34 +08:00
commit 7c88e7d08d
10 changed files with 3266 additions and 0 deletions

220
skills/quick-fix/SKILL.md Normal file
View File

@@ -0,0 +1,220 @@
---
name: quick-fix
description: 當使用 test 開頭的 command、skill、agent 時,在執行過程中使用者提出改善建議,立即調整 .claude 目錄中對應的 md 檔案
---
# Plugin 快速修正
當使用 test 開頭的 command、skill、agent 進行測試時,若使用者提出改善建議,立即定位並調整 `.claude` 目錄中對應的 md 檔案。
## 核心功能
- 快速識別當前測試的 plugin 和相關檔案
- 根據使用者回饋定位需要修改的 md 檔案
- 立即進行修正並驗證
- 提供修改前後的對比說明
## 執行步驟
### 1. 確認測試中的 Plugin
當使用者在測試過程中提出改善觀點時:
1. **識別目標 Plugin**
- 從對話脈絡中確認正在測試的 plugin 名稱
- 如果不明確,使用 AskUserQuestion 詢問:
- 正在測試哪個 plugin
- 是測試 agent、command 還是 skill
- 具體是哪個檔案?
2. **定位目標檔案**
- Agent: `plugins/{plugin-name}/agents/{agent-name}.md`
- Command: `plugins/{plugin-name}/commands/{command-name}.md`
- Skill: `plugins/{plugin-name}/skills/{skill-name}/SKILL.md`
### 2. 讀取並分析當前內容
1. **使用 Read tool 讀取目標檔案**
```
Read: plugins/{plugin-name}/{type}/{name}/檔案.md
```
2. **分析使用者的改善觀點**
- 理解使用者反映的問題點
- 確認需要修改的具體區塊
- 思考最佳的修改方式
3. **確認修改範圍**
- 如果使用者的意見很明確,直接進行修改
- 如果需要澄清,使用 AskUserQuestion 確認:
- 具體要修改哪個章節?
- 要新增內容還是修改現有內容?
- 修改的幅度如何?
### 3. 執行修改
1. **使用 Edit tool 進行修改**
- 精確定位需要修改的區塊
- 使用 old_string 和 new_string 進行替換
- 保持檔案格式的一致性YAML Front Matter、Markdown 格式)
2. **注意事項**
- 保持 YAML Front Matter 的完整性
- 維持原有的文件結構
- 確保修改後的內容符合 Markdown 格式
- 檔案結尾保留一個空行
3. **多處修改**
- 如果需要修改多處,一次性處理
- 保持修改的邏輯一致性
### 4. 驗證與確認
1. **重新讀取檔案**
- 使用 Read tool 確認修改結果
- 檢查是否有格式錯誤
2. **向使用者說明修改內容**
- 清楚說明修改了哪些部分
- 解釋修改的理由和預期效果
- 提供修改前後的對比(如果必要)
3. **詢問是否需要繼續測試**
- 確認使用者是否滿意修改
- 是否需要再次測試功能
- 是否還有其他需要調整的地方
## 使用場景
### 適用情境
1. **測試 Agent 時**
- Agent 的提示詞不夠明確
- Agent 的執行步驟需要調整
- Agent 的範例需要更新
2. **測試 Command 時**
- Command 的說明不清楚
- Command 的參數說明需要補充
- Command 的執行邏輯需要修正
3. **測試 Skill 時**
- Skill 的工作流程需要優化
- Skill 的注意事項需要補充
- Skill 的範例需要修正
### 典型工作流程
```
[使用者正在測試某個 skill]
User: 我發現這個 skill 的步驟 3 說明不夠清楚,
應該要先執行 git status 再決定要用哪個策略。
Agent: 我會立即修正這個 skill 的 SKILL.md 檔案。
[使用 Read tool 讀取當前的 SKILL.md]
[使用 Edit tool 修改步驟 3 的內容]
Agent: 已修改 plugins/git/skills/resolving-conflict/SKILL.md:42
- 在步驟 3 開頭新增「先執行 git status 確認狀態」的說明
- 補充不同狀態下的處理策略
修改內容:
原本:「對於每個衝突的檔案...」
修改後:「先執行 git status 確認衝突狀態,再對於每個衝突的檔案...」
你要繼續測試看看嗎?
User: 好的,再測試一次。
[繼續測試流程...]
```
## 特殊處理
### YAML Front Matter 修改
如果需要修改 YAML Front Mattername 或 description
```yaml
---
name: 原始名稱
description: 原始描述
---
```
修改時要特別注意:
- 保持 `---` 分隔線的完整性
- name 使用 PascalCase 或 kebab-case
- description 簡潔明瞭,說明核心功能
### 大幅度重構
如果使用者的改善意見需要大幅度重構:
1. **使用 AskUserQuestion 確認範圍**
- 列出需要調整的主要區塊
- 確認是否需要重新組織結構
- 是否影響其他相關檔案
2. **分步驟進行**
- 先調整結構性的內容
- 再補充細節說明
- 最後更新範例
3. **保持溝通**
- 每個大區塊修改後向使用者確認
- 確保修改方向符合使用者期望
### 同時修改多個檔案
如果改善意見涉及多個檔案(例如 SKILL.md 和 README.md
1. **使用 TodoWrite 規劃任務**
- 列出所有需要修改的檔案
- 標示修改的優先順序
2. **按順序執行**
- 先修改核心檔案agent 的 .md、command 的 .md、SKILL.md 等)
- 再更新文件檔案README.md
3. **整體確認**
- 所有修改完成後,整體說明變更
- 確保檔案間的一致性
## 注意事項
### 修改原則
- **快速響應**:立即處理使用者的改善意見,不要拖延
- **精確定位**:準確找到需要修改的區塊,避免影響其他內容
- **保持格式**:維持原有的檔案格式和結構
- **清楚溝通**:說明修改的內容和理由
### 常見錯誤
**避免:**
- 在不確定的情況下猜測使用者的意圖
- 修改過度,超出使用者的要求
- 破壞檔案的原有結構
- 修改後沒有向使用者確認
**推薦:**
- 不確定時使用 AskUserQuestion 確認
- 只修改使用者明確提出的部分
- 保持檔案結構的完整性
- 修改後清楚說明變更內容
### 品質檢查
修改完成後檢查:
- [ ] YAML Front Matter 格式正確
- [ ] Markdown 格式正確
- [ ] 檔案結尾有空行
- [ ] 內容邏輯清晰
- [ ] 符合使用者的改善意見
## 整合其他工具
- 如果修改涉及 README.md確保與 plugin 的實際功能一致