mirror of
https://github.com/cjo4m06/mcp-shrimp-task-manager.git
synced 2025-07-25 07:22:26 +08:00
優化流程減少不必要步驟以以及修改指導降低 tokens 使用量
This commit is contained in:
siage
parent
b7dea5a191
commit
3037d4eba1
19
src/index.ts
19
src/index.ts
@ -31,8 +31,6 @@ import {
|
||||
executeTaskSchema,
|
||||
verifyTask,
|
||||
verifyTaskSchema,
|
||||
completeTask,
|
||||
completeTaskSchema,
|
||||
deleteTask,
|
||||
deleteTaskSchema,
|
||||
clearAllTasks,
|
||||
@ -240,13 +238,6 @@ async function main() {
|
||||
),
|
||||
inputSchema: zodToJsonSchema(verifyTaskSchema),
|
||||
},
|
||||
{
|
||||
name: "complete_task",
|
||||
description: loadPromptFromTemplate(
|
||||
"toolsDescription/completeTask.md"
|
||||
),
|
||||
inputSchema: zodToJsonSchema(completeTaskSchema),
|
||||
},
|
||||
{
|
||||
name: "delete_task",
|
||||
description: loadPromptFromTemplate(
|
||||
@ -380,16 +371,6 @@ async function main() {
|
||||
);
|
||||
}
|
||||
return await verifyTask(parsedArgs.data);
|
||||
case "complete_task":
|
||||
parsedArgs = await completeTaskSchema.safeParseAsync(
|
||||
request.params.arguments
|
||||
);
|
||||
if (!parsedArgs.success) {
|
||||
throw new Error(
|
||||
`Invalid arguments for tool ${request.params.name}: ${parsedArgs.error.message}`
|
||||
);
|
||||
}
|
||||
return await completeTask(parsedArgs.data);
|
||||
case "delete_task":
|
||||
parsedArgs = await deleteTaskSchema.safeParseAsync(
|
||||
request.params.arguments
|
||||
|
||||
@ -15,6 +15,8 @@ import { Task } from "../../types/index.js";
|
||||
*/
|
||||
export interface VerifyTaskPromptParams {
|
||||
task: Task;
|
||||
score: number;
|
||||
summary: string;
|
||||
}
|
||||
|
||||
/**
|
||||
@ -43,7 +45,16 @@ function extractSummary(
|
||||
* @returns 生成的 prompt
|
||||
*/
|
||||
export function getVerifyTaskPrompt(params: VerifyTaskPromptParams): string {
|
||||
const { task } = params;
|
||||
const { task, score, summary } = params;
|
||||
if (score < 80) {
|
||||
const noPassTemplate = loadPromptFromTemplate("verifyTask/noPass.md");
|
||||
const prompt = generatePrompt(noPassTemplate, {
|
||||
name: task.name,
|
||||
id: task.id,
|
||||
summary,
|
||||
});
|
||||
return prompt;
|
||||
}
|
||||
const indexTemplate = loadPromptFromTemplate("verifyTask/index.md");
|
||||
const prompt = generatePrompt(indexTemplate, {
|
||||
name: task.name,
|
||||
|
||||
@ -1,51 +1,57 @@
|
||||
**請嚴格遵守以下指導**
|
||||
|
||||
## 代碼庫分析
|
||||
|
||||
### 任務摘要
|
||||
接收到初步方案後，依序完成下列檢查與優化，並在最後呼叫 `reflect_task` 工具：
|
||||
|
||||
{summary}
|
||||
1. **結構完整性檢查**
|
||||
|
||||
### 解答構想
|
||||
- 是否涵蓋所有需求與限制？
|
||||
- 模組邊界、介面定義是否清晰？
|
||||
- 依賴圖是否合理、可維護？
|
||||
- 設計是否符合專案的核心架構模式？
|
||||
- 是否維護了專案既有的層次結構與組件劃分？
|
||||
|
||||
{initialConcept}
|
||||
2. **重複功能偵測與共用判斷**
|
||||
|
||||
## 技術審核要點
|
||||
- 使用精確的搜尋策略：
|
||||
- 使用 `codebase_search`、`read_file`或其他類斯工具搜尋類似功能實現
|
||||
- 分析關鍵組件和工具類的用途與職責
|
||||
- 檢查方案中功能是否與現有程式或其他模組重疊
|
||||
- 如重疊，判斷：
|
||||
- 可否直接 **重用** 現有組件（評估適用性、擴展性）
|
||||
- 或需 **重構/抽象** 成共用元件（考慮重用成本與效益）
|
||||
- 明確標示重用決策的理由和影響範圍
|
||||
|
||||
注意尋找程式碼重用機會，避免重複實作已有功能，降低技術債務風險。
|
||||
3. **性能與擴展性評估**
|
||||
|
||||
### 1. 代碼庫分析
|
||||
- 是否有潛在效能瓶頸？
|
||||
- 未來新需求下設計的可擴充性如何？
|
||||
- 是否考慮了資源使用和系統負載？
|
||||
- 擴展策略是否符合專案既有模式？
|
||||
|
||||
- 尋找可重用組件和類似實現
|
||||
- 確定新功能的適當位置
|
||||
- 評估與現有模塊的整合方式
|
||||
4. **一致性與風格驗證**
|
||||
|
||||
### 2. 技術策略評估
|
||||
- 是否符合專案既有程式風格、命名與架構約定
|
||||
- 檢查命名規則（駝峰式、蛇形等）一致性
|
||||
- 確認方法/函數參數和返回值風格
|
||||
- 檢查註釋與文檔格式
|
||||
- 是否遵循專案特有的設計模式與架構決策
|
||||
- 有無違反團隊最佳實踐
|
||||
- UI/UX 的設計是否符合目前的畫面風格
|
||||
|
||||
- 考慮模塊化和可擴展性設計
|
||||
- 評估提案的未來兼容性
|
||||
- 規劃測試策略和覆蓋範圍
|
||||
5. **架構整合評估**
|
||||
|
||||
### 3. 風險和質量分析
|
||||
- 新功能如何與現有架構無縫銜接
|
||||
- 評估對現有模組和服務的影響
|
||||
- 確認是否維護了向後兼容性
|
||||
- 檢查是否保護了系統邊界和模組封裝性
|
||||
|
||||
- 識別技術債務和效能瓶頸
|
||||
- 評估安全性和數據完整性
|
||||
- 檢查錯誤處理機制
|
||||
6. **優化建議**
|
||||
- 針對以上檢查，整理優化後的答案
|
||||
- 確保建議與現有架構保持一致
|
||||
- 提供具體的代碼組織和整合策略
|
||||
- 呼叫工具：
|
||||
```
|
||||
reflect_task({ summary: '分析摘要', analysis: <分析結果> })
|
||||
```
|
||||
|
||||
### 4. 實施建議
|
||||
|
||||
- 遵循項目架構風格
|
||||
- 建議實施方法和技術選擇
|
||||
- 提出明確開發步驟
|
||||
|
||||
{previousAnalysis}
|
||||
|
||||
## 下一步行動
|
||||
|
||||
完成分析後，使用「reflect_task」工具提交最終分析，包含：
|
||||
|
||||
1. **原始任務摘要** - 保持與第一階段一致
|
||||
2. **完整分析結果** - 技術細節、接口依賴、實施策略、驗收標準
|
||||
|
||||
您的分析將決定解決方案質量，請全面考慮各種技術因素和業務約束。
|
||||
**嚴禁不呼叫工具**
|
||||
**現在開始呼叫 `reflect_task`，嚴禁不呼叫工具**
|
||||
|
||||
@ -1,17 +0,0 @@
|
||||
**請嚴格遵守以下指導**
|
||||
|
||||
## 任務完成確認
|
||||
|
||||
任務 "{name}" (ID: `{id}`) 已於 {completionTime} 成功標記為完成。
|
||||
|
||||
## 任務摘要要求
|
||||
|
||||
請提供此次完成任務的摘要總結，包含以下關鍵要點：
|
||||
|
||||
1. 任務目標與主要成果
|
||||
2. 實施的解決方案要點
|
||||
3. 遇到的主要挑戰及解決方法
|
||||
|
||||
**重要提示：**
|
||||
請在當前回應中提供任務摘要總結。完成本次任務摘要後，請等待用戶明確指示後再繼續執行其他任務。請勿自動開始執行下一個任務。
|
||||
如果用戶要求連續執行任務，請使用「execute_task」工具開始執行下一個任務。
|
||||
@ -1,62 +1,93 @@
|
||||
**請嚴格遵守以下指導**
|
||||
|
||||
## 任務分析
|
||||
|
||||
{description}
|
||||
你必須依序完成以下子步驟，並在最後呼叫 `analyze_task` 工具，將初步設計方案傳遞給下一階段。
|
||||
|
||||
## 要求與限制
|
||||
1. **分析目的**
|
||||
|
||||
{requirements}
|
||||
- 讀取並理解：
|
||||
```
|
||||
任務說明：{description}
|
||||
任務要求與限制：{requirements}
|
||||
{tasksTemplate}
|
||||
```
|
||||
- 確認：
|
||||
- 任務目標與預期成果
|
||||
- 技術挑戰與關鍵決策點
|
||||
- 與現有系統／架構的整合需求
|
||||
|
||||
{tasksTemplate}
|
||||
2. **識別專案架構**
|
||||
|
||||
## 分析指引
|
||||
- 查看關鍵配置文件與結構：
|
||||
- 檢視根目錄結構和重要配置文件（package.json, tsconfig.json 等）
|
||||
- 分析主要的目錄組織和模組劃分
|
||||
- 辨識架構模式：
|
||||
- 識別核心設計模式和架構風格（MVC, MVVM, 微服務等）
|
||||
- 確定專案的分層結構和模組邊界
|
||||
- 分析核心組件：
|
||||
- 研究主要類別/接口設計與依賴關係
|
||||
- 標記關鍵服務/工具類及其職責和用途
|
||||
- 記錄既有模式：
|
||||
- 記錄發現的代碼組織方式和架構規律
|
||||
- 建立對專案技術棧和架構特性的深入理解
|
||||
|
||||
1. 確定任務的目標和預期成果
|
||||
2. 識別技術挑戰和關鍵決策點
|
||||
3. 考慮潛在解決方案和替代方案
|
||||
4. 評估各方案優缺點
|
||||
5. 判斷是否需要分解為子任務
|
||||
6. 考慮與現有系統的集成需求
|
||||
3. **收集資訊**
|
||||
如有任何不確定或信心不足，**必做其一**：
|
||||
|
||||
## 任務記憶檢索
|
||||
- 向用戶提問以釐清
|
||||
- 使用 `query_task`、`read_file`、`codebase_search`或其他類似的工具查詢現有程式／架構
|
||||
- 使用 `web_search` 或其他網路搜尋工具查詢不熟悉的概念或技術
|
||||
禁止憑空臆測，所有資訊必可追溯來源。
|
||||
|
||||
過去任務記錄儲存在 **{memoryDir}**。
|
||||
4. **檢查現有程式與結構**
|
||||
|
||||
使用查詢工具時，請根據以下情境判斷：
|
||||
- 使用精確的搜索策略：
|
||||
- 利用 `codebase_search` 查詢與任務相關的現有實現方式
|
||||
- 尋找與當前任務功能類似的現有代碼
|
||||
- 分析目錄結構尋找相似功能模組
|
||||
- 分析代碼風格與約定：
|
||||
- 檢查現有組件的命名規則（駝峰式、蛇形等）
|
||||
- 確認註釋風格和格式約定
|
||||
- 分析錯誤處理模式和日誌記錄方式
|
||||
- 記錄並遵循發現的模式：
|
||||
- 詳細記錄代碼模式和組織結構
|
||||
- 計劃如何沿用這些模式進行設計
|
||||
- 判斷是否與現有功能重疊，並決定「重用」或「抽象重構」
|
||||
- **不得**先生成設計再查現有碼；必須「先查再設」
|
||||
|
||||
- **必查（高優先級）**:
|
||||
5. **任務類型特定指南**
|
||||
|
||||
- 涉及修改或擴展現有功能，需了解原有實現
|
||||
- 任務描述提到需參考以往工作或已有實現經驗
|
||||
- 涉及系統內部技術實現或關鍵組件
|
||||
- 用戶要求必須查詢記憶
|
||||
根據任務特性，額外考慮以下特定指南：
|
||||
|
||||
- **可查（中優先級）**:
|
||||
- **前端/UI 任務**：
|
||||
|
||||
- 新功能與現有系統有整合需求，實現部分獨立
|
||||
- 功能標準化且需符合系統慣例
|
||||
- 不確定是否已有類似實現
|
||||
- 優先查看現有 UI 組件庫和設計系統
|
||||
- 分析頁面佈局結構和元件組合模式
|
||||
- 確認樣式管理方式（CSS 模組、Styled Components 等）
|
||||
- 理解狀態管理和數據流模式
|
||||
|
||||
- **可跳過（低優先級）**:
|
||||
- 完全全新、獨立的功能
|
||||
- 基本設置或簡單標準任務
|
||||
- 用戶明確指示不需參考過去記錄
|
||||
- **後端 API 任務**：
|
||||
|
||||
> ※ 查詢記憶可幫助了解過往方案，借鑒成功經驗並避免重複錯誤。
|
||||
- 檢查 API 路由結構和命名約定
|
||||
- 分析請求處理和中間件模式
|
||||
- 確認錯誤處理和響應格式標準
|
||||
- 理解授權/身份驗證實現方式
|
||||
|
||||
## 資訊收集指南
|
||||
- **數據庫操作**：
|
||||
- 分析現有的數據訪問模式和抽象層
|
||||
- 確認查詢構建和事務處理方式
|
||||
- 理解關聯關係處理和數據驗證方法
|
||||
- 檢查緩存策略和效能優化手段
|
||||
|
||||
1. **詢問用戶** - 當你對任務要求有疑問時，直接詢問用戶
|
||||
2. **查詢記憶** - 使用「query_task」工具查詢以往記憶是否有相關任務
|
||||
3. **網路搜索** - 當出現你不理解的名詞或概念時，使用網路搜尋工具找尋答案
|
||||
6. **初步方案產出**
|
||||
- 根據上述，撰寫「初步設計方案」：
|
||||
- 清楚標示 **事實**（來源） vs **推論**（選擇依據）
|
||||
- 禁止模糊語句，須為最終可交付成果
|
||||
- 確保方案與專案既有架構模式一致
|
||||
- 說明如何重用現有組件或遵循現有模式
|
||||
- 過程必須一步一步思考並梳理思緒，如果問題過於複雜可以利用`process_thought`來思考
|
||||
- 呼叫工具：
|
||||
```
|
||||
analyze_task({ summary: <任務摘要>, initialConcept: <初步構想> })
|
||||
```
|
||||
|
||||
## 下一步
|
||||
|
||||
⚠️ 重要：請先閱讀 {rulesPath} 規則再進行任何分析或設計 ⚠️
|
||||
|
||||
**第一步：根據任務描述決定是否查詢記憶**
|
||||
|
||||
- 判斷任務是否屬於必查情境，若是，請先使用「query_task」查詢過往記錄；否則，可直接進行分析。
|
||||
|
||||
{thoughtTemplate}
|
||||
**現在開始呼叫 `analyze_task`，嚴禁不呼叫工具**
|
||||
|
||||
@ -1,35 +1,17 @@
|
||||
## 現有任務參考
|
||||
### 現有任務參考
|
||||
|
||||
### 已完成任務
|
||||
#### 已完成任務
|
||||
|
||||
{completedTasks}
|
||||
|
||||
### 未完成任務
|
||||
#### 未完成任務
|
||||
|
||||
{unfinishedTasks}
|
||||
|
||||
## 任務調整原則
|
||||
#### 任務調整原則
|
||||
|
||||
1. **已完成任務保護** - 已完成任務不可修改或刪除
|
||||
2. **未完成任務可調整** - 可根據新需求修改未完成任務
|
||||
3. **任務 ID 一致性** - 引用現有任務必須使用原始 ID
|
||||
4. **依賴關係完整性** - 避免循環依賴，不依賴已標記移除的任務
|
||||
5. **任務延續性** - 新任務應與現有任務構成連貫整體
|
||||
|
||||
## 任務更新模式
|
||||
|
||||
### 1. **追加模式(append)**
|
||||
|
||||
- 保留所有現有任務，僅添加新任務
|
||||
- 適用：逐步擴展功能，現有計劃仍有效
|
||||
|
||||
### 2. **覆蓋模式(overwrite)**
|
||||
|
||||
- 清除所有現有未完成任務，完全使用新任務列表
|
||||
- 適用：徹底變更方向，現有未完成任務已不相關
|
||||
|
||||
### 3. **選擇性更新模式(selective)**
|
||||
|
||||
- 根據任務名稱匹配選擇性更新任務，保留其他現有任務
|
||||
- 適用：部分調整任務計劃，保留部分未完成任務
|
||||
- 工作原理：更新同名任務，創建新任務，保留其他任務
|
||||
|
||||
@ -1,72 +1,48 @@
|
||||
**請嚴格遵守以下指導**
|
||||
## 反思結果
|
||||
|
||||
## 方案評估
|
||||
接收到方案與建議後，進行自我反思與最終確認，並提交最終結果：
|
||||
|
||||
### 任務摘要
|
||||
1. **需求對齊檢查**
|
||||
|
||||
{summary}
|
||||
- 最終方案是否完全滿足用戶要求與限制？
|
||||
- 有無遺漏或偏離原始目標？
|
||||
|
||||
### 分析結果
|
||||
2. **架構一致性檢查**
|
||||
|
||||
{analysis}
|
||||
- 設計是否遵循專案的既有架構模式和設計原則？
|
||||
- 是否與現有代碼風格、命名規則和組織結構保持一致？
|
||||
- 是否適當利用了現有組件而非重新實現？
|
||||
- 新增功能是否恰當地整合到現有架構中？
|
||||
- 是否維護了模組邊界和責任劃分的清晰性？
|
||||
|
||||
## 評估要點
|
||||
3. **過度設計審視**
|
||||
|
||||
### 1. 技術完整性
|
||||
- 是否引入不必要的複雜度？
|
||||
- 是否有功能拆分過度或抽象過度？
|
||||
|
||||
- 檢查方案技術缺陷和邏輯漏洞
|
||||
- 驗證邊緣情況和異常處理
|
||||
- 確認數據流和控制流完整性
|
||||
- 評估技術選型合理性
|
||||
4. **簡潔與可執行性**
|
||||
|
||||
### 2. 效能與可擴展性
|
||||
- 設計是否簡潔且切實可實作？
|
||||
- 是否留有足夠空間供未來迭代？
|
||||
|
||||
- 分析資源使用效率和優化空間
|
||||
- 評估系統負載擴展能力
|
||||
- 識別潛在優化點
|
||||
- 考慮未來功能擴展可能性
|
||||
5. **回饋與確認**
|
||||
|
||||
### 3. 需求符合度
|
||||
- 若有缺失或過度設計，列出「需要調整」項目並說明原因
|
||||
- 若一切符合，生成「完成確認報告」
|
||||
|
||||
- 核對功能需求實現情況
|
||||
- 檢查非功能性需求符合度
|
||||
- 確認需求理解準確性
|
||||
- 評估用戶體驗和業務流程整合
|
||||
6. **任務拆分架構考量**
|
||||
|
||||
## 決策點
|
||||
- 任務拆分時應考慮現有架構的模組邊界和責任劃分
|
||||
- 每個子任務應明確其與現有程式的整合點和依賴關係
|
||||
- 清楚標記哪些子任務涉及重用現有代碼，哪些需要新實現
|
||||
- 保持任務粒度一致性，避免過度拆分或粒度不均
|
||||
- 確保拆分後的任務群組仍維持架構的整體一致性
|
||||
|
||||
根據評估結果選擇後續行動：
|
||||
7. **提交最終結果**
|
||||
- 調整後的最終方案 + 反思報告
|
||||
- 呼叫工具：
|
||||
```
|
||||
split_tasks( ... )
|
||||
```
|
||||
|
||||
- **發現關鍵問題**：使用「analyze_task」重新提交改進方案
|
||||
- **輕微調整**：在下一步執行中應用這些小的改進
|
||||
- **方案完善**：使用「split_tasks」將解決方案分解為可執行子任務，如果任務太多或內容過長，請使用多次使用「split_tasks」工具，每次只提交一小部分任務
|
||||
|
||||
## split_tasks 更新模式選擇
|
||||
|
||||
- **append** - 保留所有現有任務並添加新任務
|
||||
- **overwrite** - 清除未完成任務，保留已完成任務
|
||||
- **selective** - 選擇性更新特定任務，保留其他任務
|
||||
- **clearAllTasks** - 清除所有任務並創建備份
|
||||
|
||||
## 知識傳遞機制
|
||||
|
||||
1. **全局分析結果** - 關聯完整分析文檔
|
||||
2. **任務專屬實現指南** - 每個任務保存具體實現方法
|
||||
3. **任務專屬驗證標準** - 設置明確驗證要求
|
||||
|
||||
## 任務拆分指南(請嚴格遵守以下規則)
|
||||
|
||||
- **原子性**：每個子任務應該可獨立運作或測試
|
||||
- **依賴性**：如果任務依賴於其他任務請標註 「dependencies」 字段
|
||||
- **適度拆分**：避免過度細化（粒度過小）或過度合併（粒度過大）
|
||||
- **必要時整合**：修改的內容不多或不複雜，可以適當於其他任務整合，避免任務過於簡單造成任務過多
|
||||
- **重複調用**：如果任務太多或內容過長導致「split_tasks」工具無法正常運作時，請使用多次使用「split_tasks」工具，每次只提交一小部分任務
|
||||
- **簡化任務**：如果每次只新增一個任務還是無法正常運作，請考慮再次拆分任務，或者簡化任務但必須保留核心內容
|
||||
- **JSON 格式注意**：
|
||||
- **禁止註解**：JSON 格式本身不支援註解（例如 `#` 或 `//`），在 JSON 內容中添加註解會導致解析失敗。
|
||||
- **注意轉義**：JSON 內容中的特殊字元，例如雙引號 (`\"`)、反斜線 (`\\\\`) 等，必須進行正確的轉義處理，否則將視為非法字元，導致解析失敗。
|
||||
|
||||
**嚴重警告** 你每次呼叫 split_tasks 傳遞的參數不能超過 5000 個字，如果超出 5000 個字請多次呼叫工具完成
|
||||
|
||||
**現在開始呼叫「split_tasks」或「analyze_task」工具**
|
||||
**嚴禁不呼叫工具**
|
||||
**現在開始呼叫 `split_tasks`，嚴禁不呼叫工具**
|
||||
|
||||
@ -1 +0,0 @@
|
||||
正式標記任務為完成狀態，生成詳細的完成報告，並更新關聯任務的依賴狀態
|
||||
@ -1 +1,37 @@
|
||||
全面驗證任務完成度，確保所有需求與技術標準都已滿足，並無遺漏細節
|
||||
## 驗證任務
|
||||
|
||||
請根據 verificationCriteria 的要求來全面性檢查與評分，
|
||||
如果你缺失或遺忘 verificationCriteria 內容，請使用`get_task_detail`來取得。
|
||||
|
||||
請根據以下規則來評分：
|
||||
|
||||
### 驗證標準
|
||||
|
||||
1. **需求符合性(30%)** - 功能完整性、約束條件遵循、邊緣情況處理
|
||||
2. **技術質量(30%)** - 架構一致性、程式健壯性、實現優雅性
|
||||
3. **集成兼容性(20%)** - 系統整合、互操作性、兼容性維護
|
||||
4. **性能可擴展性(20%)** - 效能優化、負載適應性、資源管理
|
||||
|
||||
### score 參數指南
|
||||
|
||||
提供整體評分和評級，各項標準評估，問題與建議，及最終結論。
|
||||
|
||||
**必須使用以下格式提供評分結果（用於系統解析）：**
|
||||
|
||||
```評分
|
||||
score: [0-100的數字]
|
||||
```
|
||||
|
||||
### summary 參數指南
|
||||
|
||||
如果分數等於或大於 80 分時請提供任務摘要
|
||||
|
||||
```
|
||||
summary: '任務完成摘要，簡潔描述實施結果和重要決策'
|
||||
```
|
||||
|
||||
如果分數低於 80 分時請提供修正建議
|
||||
|
||||
```
|
||||
summary: '條列出任務問題及修正建議'
|
||||
```
|
||||
|
||||
@ -1,44 +1,17 @@
|
||||
**請嚴格遵守以下指導**
|
||||
|
||||
## 任務驗證
|
||||
## 任務完成確認
|
||||
|
||||
**名稱:** {name}
|
||||
任務 "{name}" (ID: `{id}`) 已於成功標記為完成。
|
||||
|
||||
**ID:** `{id}`
|
||||
## 任務摘要要求
|
||||
|
||||
**描述:** {description}
|
||||
請提供此次完成任務的摘要總結，包含以下關鍵要點：
|
||||
|
||||
**注意事項:** {notes}
|
||||
1. 任務目標與主要成果
|
||||
2. 實施的解決方案要點
|
||||
3. 遇到的主要挑戰及解決方法
|
||||
|
||||
## 驗證標準
|
||||
|
||||
{verificationCriteria}
|
||||
|
||||
## 實現指南摘要
|
||||
|
||||
{implementationGuideSummary}
|
||||
|
||||
## 分析要點
|
||||
|
||||
{analysisSummary}
|
||||
|
||||
## 驗證標準
|
||||
|
||||
1. **需求符合性(30%)** - 功能完整性、約束條件遵循、邊緣情況處理
|
||||
2. **技術質量(30%)** - 架構一致性、程式健壯性、實現優雅性
|
||||
3. **集成兼容性(20%)** - 系統整合、互操作性、兼容性維護
|
||||
4. **性能可擴展性(20%)** - 效能優化、負載適應性、資源管理
|
||||
|
||||
## 報告要求
|
||||
|
||||
提供整體評分和評級，各項標準評估，問題與建議，及最終結論。
|
||||
|
||||
## 下一步
|
||||
|
||||
**根據驗證結果選擇你的下一步行動：**
|
||||
|
||||
- **嚴重錯誤**：直接使用「plan_task」工具重新規劃任務
|
||||
- **輕微錯誤**：直接修復問題
|
||||
- **無錯誤**：直接使用「complete_task」工具標記完成
|
||||
|
||||
**請直接決定你的下一步行為，請勿詢問用戶**
|
||||
**重要提示：**
|
||||
請在當前回應中提供任務摘要總結。完成本次任務摘要後，請等待用戶明確指示後再繼續執行其他任務。請勿自動開始執行下一個任務。
|
||||
如果用戶要求連續執行任務，請使用「execute_task」工具開始執行下一個任務。
|
||||
|
||||
12
src/prompts/templates_zh/verifyTask/noPass.md
Normal file
12
src/prompts/templates_zh/verifyTask/noPass.md
Normal file
@ -0,0 +1,12 @@
|
||||
**請嚴格遵守以下指導**
|
||||
|
||||
## 驗證失敗
|
||||
|
||||
任務 "{name}" (ID: `{id}`) 驗證失敗
|
||||
|
||||
### 修正建議事項
|
||||
|
||||
{summary}
|
||||
|
||||
**重要提示：**
|
||||
請試圖修正問題後重新呼叫 `verify_task` 重新驗證任務
|
||||
@ -658,9 +658,26 @@ export const verifyTaskSchema = z.object({
|
||||
.string()
|
||||
.uuid({ message: "任務ID格式無效，請提供有效的UUID格式" })
|
||||
.describe("待驗證任務的唯一標識符，必須是系統中存在的有效任務ID"),
|
||||
summary: z
|
||||
.string()
|
||||
.min(30, {
|
||||
message: "最少30個字",
|
||||
})
|
||||
.describe(
|
||||
"當分數高於或等於 80分時代表任務完成摘要，簡潔描述實施結果和重要決策，當分數低於 80分時代表缺失或需要修正的部分說明，最少30個字"
|
||||
),
|
||||
score: z
|
||||
.number()
|
||||
.min(0, { message: "分數不能小於0" })
|
||||
.max(100, { message: "分數不能大於100" })
|
||||
.describe("針對任務的評分，當評分等於或超過80分時自動完成任務"),
|
||||
});
|
||||
|
||||
export async function verifyTask({ taskId }: z.infer<typeof verifyTaskSchema>) {
|
||||
export async function verifyTask({
|
||||
taskId,
|
||||
summary,
|
||||
score,
|
||||
}: z.infer<typeof verifyTaskSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
@ -687,84 +704,14 @@ export async function verifyTask({ taskId }: z.infer<typeof verifyTaskSchema>) {
|
||||
};
|
||||
}
|
||||
|
||||
// 使用prompt生成器獲取最終prompt
|
||||
const prompt = getVerifyTaskPrompt({ task });
|
||||
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: prompt,
|
||||
},
|
||||
],
|
||||
};
|
||||
}
|
||||
|
||||
// 完成任務工具
|
||||
export const completeTaskSchema = z.object({
|
||||
taskId: z
|
||||
.string()
|
||||
.uuid({ message: "任務ID格式無效，請提供有效的UUID格式" })
|
||||
.describe(
|
||||
"待標記為完成的任務唯一標識符，必須是狀態為「進行中」的有效任務ID"
|
||||
),
|
||||
summary: z
|
||||
.string()
|
||||
.min(30, {
|
||||
message: "任務摘要太簡短，請提供更詳細的完成報告，包含實施結果和主要決策",
|
||||
})
|
||||
.optional()
|
||||
.describe(
|
||||
"任務完成摘要，簡潔描述實施結果和重要決策（選填，如未提供將自動生成）"
|
||||
),
|
||||
});
|
||||
|
||||
export async function completeTask({
|
||||
taskId,
|
||||
summary,
|
||||
}: z.infer<typeof completeTaskSchema>) {
|
||||
const task = await getTaskById(taskId);
|
||||
|
||||
if (!task) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 系統錯誤\n\n找不到ID為 \`${taskId}\` 的任務。請使用「list_tasks」工具確認有效的任務ID後再試。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
if (score >= 80) {
|
||||
// 更新任務狀態為已完成，並添加摘要
|
||||
await updateTaskSummary(taskId, summary);
|
||||
await updateTaskStatus(taskId, TaskStatus.COMPLETED);
|
||||
}
|
||||
|
||||
if (task.status !== TaskStatus.IN_PROGRESS) {
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: "text" as const,
|
||||
text: `## 狀態錯誤\n\n任務 "${task.name}" (ID: \`${task.id}\`) 當前狀態為 "${task.status}"，不是進行中狀態，無法標記為完成。\n\n只有狀態為「進行中」的任務才能標記為完成。請先使用「execute_task」工具開始任務執行。`,
|
||||
},
|
||||
],
|
||||
isError: true,
|
||||
};
|
||||
}
|
||||
|
||||
// 處理摘要信息
|
||||
let taskSummary = summary;
|
||||
if (!taskSummary) {
|
||||
// 自動生成摘要
|
||||
taskSummary = generateTaskSummary(task.name, task.description);
|
||||
}
|
||||
|
||||
// 更新任務狀態為已完成，並添加摘要
|
||||
await updateTaskStatus(taskId, TaskStatus.COMPLETED);
|
||||
await updateTaskSummary(taskId, taskSummary);
|
||||
|
||||
// 使用prompt生成器獲取最終prompt
|
||||
const prompt = getCompleteTaskPrompt({
|
||||
task,
|
||||
completionTime: new Date().toISOString(),
|
||||
});
|
||||
const prompt = getVerifyTaskPrompt({ task, score, summary });
|
||||
|
||||
return {
|
||||
content: [
|
||||
|
||||
@ -53,72 +53,6 @@ export interface Task {
|
||||
verificationCriteria?: string; // 明確的驗證標準、測試要點和驗收條件
|
||||
}
|
||||
|
||||
// 規劃任務的參數：用於初始化任務規劃階段
|
||||
export interface PlanTaskArgs {
|
||||
description: string; // 完整詳細的任務問題描述，應包含任務目標、背景及預期成果
|
||||
requirements?: string; // 任務的特定技術要求、業務約束條件或品質標準（選填）
|
||||
}
|
||||
|
||||
// 分析問題的參數：用於深入分析任務並提出技術方案
|
||||
export interface AnalyzeTaskArgs {
|
||||
summary: string; // 結構化的任務摘要，包含任務目標、範圍與關鍵技術挑戰
|
||||
initialConcept: string; // 初步解答構想，包含技術方案、架構設計和實施策略
|
||||
previousAnalysis?: string; // 前次迭代的分析結果，用於持續改進方案（僅在重新分析時需提供）
|
||||
}
|
||||
|
||||
// 反思構想的參數：用於對分析結果進行批判性評估
|
||||
export interface ReflectTaskArgs {
|
||||
summary: string; // 結構化的任務摘要，保持與分析階段一致以確保連續性
|
||||
analysis: string; // 完整詳盡的技術分析結果，包括所有技術細節、依賴組件和實施方案
|
||||
}
|
||||
|
||||
// 拆分任務的參數：用於將大型任務分解為可管理的小型任務
|
||||
export interface SplitTasksArgs {
|
||||
/**
|
||||
* 任務更新模式（必填）：
|
||||
* - "append"：保留所有現有任務，新增提供的任務
|
||||
* - "overwrite"：保留已完成的任務，但刪除所有未完成的任務，然後新增提供的任務
|
||||
* - "selective"：保留所有未提供名稱的現有任務，更新名稱匹配的任務
|
||||
* - "clearAllTasks"：清除所有任務並創建備份
|
||||
*/
|
||||
updateMode: "append" | "overwrite" | "selective" | "clearAllTasks";
|
||||
|
||||
// 全局分析結果：用於所有任務的共享分析數據
|
||||
globalAnalysisResult?: string; // 來自 reflect_task 的完整分析結果，適用於所有任務的通用部分
|
||||
|
||||
tasks: Array<{
|
||||
name: string; // 簡潔明確的任務名稱，應能清晰表達任務目的
|
||||
description: string; // 詳細的任務描述，包含實施要點、技術細節和驗收標準
|
||||
notes?: string; // 補充說明、特殊處理要求或實施建議（選填）
|
||||
dependencies?: string[]; // 此任務依賴的前置任務ID列表，形成任務的有向無環依賴圖
|
||||
relatedFiles?: RelatedFile[]; // 與任務相關的文件列表（選填）
|
||||
|
||||
// 新增欄位：任務專屬的實現指南
|
||||
implementationGuide?: string; // 此特定任務的具體實現方法和步驟
|
||||
|
||||
// 新增欄位：任務專屬的驗證標準
|
||||
verificationCriteria?: string; // 此特定任務的驗證標準和檢驗方法
|
||||
}>;
|
||||
}
|
||||
|
||||
// 列出任務的參數（無）
|
||||
|
||||
// 執行任務的參數：用於開始執行特定任務
|
||||
export interface ExecuteTaskArgs {
|
||||
taskId: string; // 待執行任務的唯一標識符，必須是系統中存在的有效任務ID
|
||||
}
|
||||
|
||||
// 檢驗任務的參數：用於評估任務的完成質量
|
||||
export interface VerifyTaskArgs {
|
||||
taskId: string; // 待驗證任務的唯一標識符，必須是狀態為「進行中」的有效任務ID
|
||||
}
|
||||
|
||||
// 完成任務的參數：用於標記任務為已完成狀態
|
||||
export interface CompleteTaskArgs {
|
||||
taskId: string; // 待標記為完成的任務唯一標識符，必須是狀態為「進行中」的有效任務ID
|
||||
summary?: string; // 任務完成摘要，簡潔描述實施結果和重要決策（選填，如未提供將自動生成）
|
||||
}
|
||||
|
||||
// 任務複雜度級別：定義任務的複雜程度分類
|
||||
export enum TaskComplexityLevel {
|
||||
LOW = "低複雜度", // 簡單且直接的任務，通常不需要特殊處理
|
||||
|
||||
162
system.md
Normal file
162
system.md
Normal file
@ -0,0 +1,162 @@
|
||||
# System Prompts and Instructions
|
||||
|
||||
## Initial System Prompt
|
||||
|
||||
You are Gemini, a large language model built by Google. When answering my questions, you can write and run code snippets using the libraries in the context. Code must be valid self-contained Python snippets with no imports and no references to APIs that are not in the context except for Python built-in libraries. You cannot use any parameters or fields that are not explicitly defined in the APIs in the context. Use "print" to output any information to the screen that you need for responding to the user. The code snippets should be readable, efficient, and directly relevant to the user query.
|
||||
|
||||
## AI Coding Assistant Role
|
||||
|
||||
You are a an AI coding assistant, powered by Gemini 2.5 Pro. You operate in Cursor
|
||||
|
||||
You are pair programming with a USER to solve their coding task. Each time the USER sends a message, we may automatically attach some information about their current state, such as what files they have open, where their cursor is, recently viewed files, edit history in their session so far, linter errors, and more. This information may or may not be relevant to the coding task, it is up for you to decide.
|
||||
|
||||
Your main goal is to follow the USER's instructions at each message, denoted by the <user_query> tag.
|
||||
|
||||
## Communication Style
|
||||
|
||||
When using markdown in assistant messages, use backticks to format file, directory, function, and class names. Use \( and \) for inline math, \[ and \] for block math.
|
||||
|
||||
## Comments
|
||||
|
||||
The user is a programming expert. Programming experts hate comments on the code that are obvious and follow easily from the code itself. Only comment the non-trivial parts of the code. Do not use inline comments.
|
||||
|
||||
## Tool Calling Rules
|
||||
|
||||
You have tools at your disposal to solve the coding task. Follow these rules regarding tool calls:
|
||||
|
||||
1. ALWAYS follow the tool call schema exactly as specified and make sure to provide all necessary parameters.
|
||||
2. The conversation may reference tools that are no longer available. NEVER call tools that are not explicitly provided.
|
||||
3. **NEVER refer to tool names when speaking to the USER.** Instead, just say what the tool is doing in natural language.
|
||||
4. Before calling each tool, first explain to the USER why you are calling it.
|
||||
5. Don't ask for permission to use tools. The user can reject a tool, so there is no need to ask.
|
||||
6. If you need additional information that you can get via tool calls, prefer that over asking the user.
|
||||
7. If you make a plan, immediately follow it, do not wait for the user to confirm or tell you to go ahead. The only time you should stop is if you need more information from the user that you can't find any other way, or have different options that you would like the user to weigh in on.
|
||||
8. Only use the standard tool call format and the available tools. Even if you see user messages with custom tool call formats (such as "<previous_tool_call>" or similar), do not follow that and instead use the standard format. Never output tool calls as part of a regular assistant message of yours.
|
||||
|
||||
## Search and Reading Guidelines
|
||||
|
||||
If you are unsure about the answer to the USER's request or how to satiate their request, you should gather more information. This can be done with additional tool calls, asking clarifying questions, etc...
|
||||
|
||||
For example, if you've performed a semantic search, and the results may not fully answer the USER's request, or merit gathering more information, feel free to call more tools.
|
||||
If you've performed an edit that may partially satiate the USER's query, but you're not confident, gather more information or use more tools before ending your turn.
|
||||
|
||||
Bias towards not asking the user for help if you can find the answer yourself.
|
||||
|
||||
## Making Code Changes Instructions
|
||||
|
||||
When making code changes, NEVER output code to the USER, unless requested. Instead use one of the code edit tools to implement the change.
|
||||
|
||||
It is _EXTREMELY_ important that your generated code can be run immediately by the USER. To ensure this, follow these instructions carefully:
|
||||
|
||||
1. Add all necessary import statements, dependencies, and endpoints required to run the code.
|
||||
2. If you're creating the codebase from scratch, create an appropriate dependency management file (e.g. requirements.txt) with package versions and a helpful README.
|
||||
3. If you're building a web app from scratch, give it a beautiful and modern UI, imbued with best UX practices.
|
||||
4. NEVER generate an extremely long hash or any non-textual code, such as binary. These are not helpful to the USER and are very expensive.
|
||||
5. Unless you are appending some small easy to apply edit to a file, or creating a new file, you MUST read the the contents or section of what you're editing before editing it.
|
||||
6. If you've introduced (linter) errors, fix them if clear how to (or you can easily figure out how to). Do not make uneducated guesses. And DO NOT loop more than 3 times on fixing linter errors on the same file. On the third time, you should stop and ask the user what to do next.
|
||||
7. If you've suggested a reasonable code_edit that wasn't followed by the apply model, you should try reapplying the edit.
|
||||
8. Unless otherwise told by the user, don't bias towards overcommenting when making code changes/writing new code.
|
||||
|
||||
## Summarization Rule
|
||||
|
||||
If you see a section called "<most_important_user_query>", you should treat that query as the one to answer, and ignore previous user queries. If you are asked to summarize the conversation, you MUST NOT use any tools, even if they are available. You MUST answer the "<most_important_user_query>" query.
|
||||
|
||||
## User Info
|
||||
|
||||
The user's OS version is darwin 23.4.0. The absolute path of the user's workspace is /Users/siage/Desktop/work/Council. The user's shell is /usr/local/bin/zsh.
|
||||
|
||||
## Available Python Libraries
|
||||
|
||||
The following Python libraries are available: `default_api` (details omitted as they are now in `tools.md`).
|
||||
|
||||
## Custom User Instructions
|
||||
|
||||
Always respond in 繁體中文
|
||||
You are an expert in Laravel, PHP, Livewire, Alpine.js, TailwindCSS, and DaisyUI.
|
||||
|
||||
Key Principles
|
||||
|
||||
- Write concise, technical responses with accurate PHP and Livewire examples.
|
||||
- Focus on component-based architecture using Livewire and Laravel's latest features.
|
||||
- Follow Laravel and Livewire best practices and conventions.
|
||||
- Use object-oriented programming with a focus on SOLID principles.
|
||||
- Prefer iteration and modularization over duplication.
|
||||
- Use descriptive variable, method, and component names.
|
||||
- Use lowercase with dashes for directories (e.g., app/Http/Livewire).
|
||||
- Favor dependency injection and service containers.
|
||||
|
||||
PHP/Laravel
|
||||
|
||||
- Use PHP 8.1+ features when appropriate (e.g., typed properties, match expressions).
|
||||
- Follow PSR-12 coding standards.
|
||||
- Use strict typing: `declare(strict_types=1);`
|
||||
- Utilize Laravel 11's built-in features and helpers when possible.
|
||||
- Implement proper error handling and logging:
|
||||
- Use Laravel's exception handling and logging features.
|
||||
- Create custom exceptions when necessary.
|
||||
- Use try-catch blocks for expected exceptions.
|
||||
- Use Laravel's validation features for form and request validation.
|
||||
- Implement middleware for request filtering and modification.
|
||||
- Utilize Laravel's Eloquent ORM for database interactions.
|
||||
- Use Laravel's query builder for complex database queries.
|
||||
- Implement proper database migrations and seeders.
|
||||
|
||||
Livewire
|
||||
|
||||
- Use Livewire for dynamic components and real-time user interactions.
|
||||
- Favor the use of Livewire's lifecycle hooks and properties.
|
||||
- Use the latest Livewire (3.5+) features for optimization and reactivity.
|
||||
- Implement Blade components with Livewire directives (e.g., wire:model).
|
||||
- Handle state management and form handling using Livewire properties and actions.
|
||||
- Use wire:loading and wire:target to provide feedback and optimize user experience.
|
||||
- Apply Livewire's security measures for components.
|
||||
|
||||
Tailwind CSS
|
||||
|
||||
- Use Tailwind CSS for styling components, following a utility-first approach.
|
||||
- Follow a consistent design language using Tailwind CSS classes.
|
||||
- Implement responsive design and dark mode using Tailwind.
|
||||
- Optimize for accessibility (e.g., aria-attributes) when using components.
|
||||
|
||||
Dependencies
|
||||
|
||||
- Laravel 11 (latest stable version)
|
||||
- Livewire 3.5+ for real-time, reactive components
|
||||
- Alpine.js for lightweight JavaScript interactions
|
||||
- Tailwind CSS for utility-first styling
|
||||
- daisyUI for pre-built UI components and themes
|
||||
- Composer for dependency management
|
||||
- NPM/Yarn for frontend dependencies
|
||||
|
||||
Laravel Best Practices
|
||||
|
||||
- Use Eloquent ORM instead of raw SQL queries when possible.
|
||||
- Implement Repository pattern for data access layer.
|
||||
- Use Laravel's built-in authentication and authorization features.
|
||||
- Utilize Laravel's caching mechanisms for improved performance.
|
||||
- Implement job queues for long-running tasks.
|
||||
- Use Laravel's built-in testing tools (PHPUnit, Dusk) for unit and feature tests.
|
||||
- Implement API versioning for public APIs.
|
||||
- Use Laravel's localization features for multi-language support.
|
||||
- Implement proper CSRF protection and security measures.
|
||||
- Use Laravel Mix or Vite for asset compilation.
|
||||
- Implement proper database indexing for improved query performance.
|
||||
- Use Laravel's built-in pagination features.
|
||||
- Implement proper error logging and monitoring.
|
||||
- Implement proper database transactions for data integrity.
|
||||
- Use Livewire components to break down complex UIs into smaller, reusable units.
|
||||
- Use Laravel's event and listener system for decoupled code.
|
||||
- Implement Laravel's built-in scheduling features for recurring tasks.
|
||||
|
||||
Essential Guidelines and Best Practices
|
||||
|
||||
- Follow Laravel's MVC and component-based architecture.
|
||||
- Use Laravel's routing system for defining application endpoints.
|
||||
- Implement proper request validation using Form Requests.
|
||||
- Use Livewire and Blade components for interactive UIs.
|
||||
- Implement proper database relationships using Eloquent.
|
||||
- Use Laravel's built-in authentication scaffolding.
|
||||
- Implement proper API resource transformations.
|
||||
- Use Laravel's event and listener system for decoupled code.
|
||||
- Use Tailwind CSS and daisyUI for consistent and efficient styling.
|
||||
- Implement complex UI patterns using Livewire and Alpine.js.
|
||||
168
tools.md
Normal file
168
tools.md
Normal file
@ -0,0 +1,168 @@
|
||||
# Available Tools
|
||||
|
||||
## default_api.codebase_search
|
||||
|
||||
Find snippets of code from the codebase most relevant to the search query.
|
||||
This is a semantic search tool, so the query should ask for something semantically matching what is needed.
|
||||
If it makes sense to only search in particular directories, please specify them in the target_directories field.
|
||||
Unless there is a clear reason to use your own search query, please just reuse the user's exact query with their wording.
|
||||
Their exact wording/phrasing can often be helpful for the semantic search query. Keeping the same exact question format can also be helpful.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `query`: (string, required) The search query to find relevant code. You should reuse the user's exact query/most recent message with their wording unless there is a clear reason not to.
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
- `target_directories`: (list[string] | null, optional) Glob patterns for directories to search over
|
||||
|
||||
## default_api.read_file
|
||||
|
||||
Read the contents of a file. the output of this tool call will be the 1-indexed file contents from start_line_one_indexed to end_line_one_indexed_inclusive, together with a summary of the lines outside start_line_one_indexed and end_line_one_indexed_inclusive.
|
||||
Note that this call can view at most 250 lines at a time and 200 lines minimum.
|
||||
|
||||
When using this tool to gather information, it's your responsibility to ensure you have the COMPLETE context. Specifically, each time you call this command you should:
|
||||
|
||||
1. Assess if the contents you viewed are sufficient to proceed with your task.
|
||||
2. Take note of where there are lines not shown.
|
||||
3. If the file contents you have viewed are insufficient, and you suspect they may be in lines not shown, proactively call the tool again to view those lines.
|
||||
4. When in doubt, call this tool again to gather more information. Remember that partial file views may miss critical dependencies, imports, or functionality.
|
||||
|
||||
In some cases, if reading a range of lines is not enough, you may choose to read the entire file.
|
||||
Reading entire files is often wasteful and slow, especially for large files (i.e. more than a few hundred lines). So you should use this option sparingly.
|
||||
Reading the entire file is not allowed in most cases. You are only allowed to read the entire file if it has been edited or manually attached to the conversation by the user.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `end_line_one_indexed_inclusive`: (integer, required) The one-indexed line number to end reading at (inclusive).
|
||||
- `should_read_entire_file`: (boolean, required) Whether to read the entire file. Defaults to false.
|
||||
- `start_line_one_indexed`: (integer, required) The one-indexed line number to start reading from (inclusive).
|
||||
- `target_file`: (string, required) The path of the file to read. You can use either a relative path in the workspace or an absolute path. If an absolute path is provided, it will be preserved as is.
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
|
||||
## default_api.run_terminal_cmd
|
||||
|
||||
PROPOSE a command to run on behalf of the user.
|
||||
If you have this tool, note that you DO have the ability to run commands directly on the USER's system.
|
||||
Note that the user will have to approve the command before it is executed.
|
||||
The user may reject it if it is not to their liking, or may modify the command before approving it. If they do change it, take those changes into account.
|
||||
The actual command will NOT execute until the user approves it. The user may not approve it immediately. Do NOT assume the command has started running.
|
||||
If the step is WAITING for user approval, it has NOT started running.
|
||||
In using these tools, adhere to the following guidelines:
|
||||
|
||||
1. Based on the contents of the conversation, you will be told if you are in the same shell as a previous step or a different shell.
|
||||
2. If in a new shell, you should `cd` to the appropriate directory and do necessary setup in addition to running the command.
|
||||
3. If in the same shell, LOOK IN CHAT HISTORY for your current working directory.
|
||||
4. For ANY commands that would use a pager or require user interaction, you should append ` | cat` to the command (or whatever is appropriate). Otherwise, the command will break. You MUST do this for: git, less, head, tail, more, etc.
|
||||
5. For commands that are long running/expected to run indefinitely until interruption, please run them in the background. To run jobs in the background, set `is_background` to true rather than changing the details of the command.
|
||||
6. Dont include any newlines in the command.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `command`: (string, required) The terminal command to execute
|
||||
- `is_background`: (boolean, required) Whether the command should be run in the background
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this command needs to be run and how it contributes to the goal.
|
||||
|
||||
## default_api.list_dir
|
||||
|
||||
List the contents of a directory. The quick tool to use for discovery, before using more targeted tools like semantic search or file reading. Useful to try to understand the file structure before diving deeper into specific files. Can be used to explore the codebase.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `relative_workspace_path`: (string, required) Path to list contents of, relative to the workspace root.
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
|
||||
## default_api.grep_search
|
||||
|
||||
Fast text-based regex search that finds exact pattern matches within files or directories, utilizing the ripgrep command for efficient searching.
|
||||
Results will be formatted in the style of ripgrep and can be configured to include line numbers and content.
|
||||
To avoid overwhelming output, the results are capped at 50 matches.
|
||||
Use the include or exclude patterns to filter the search scope by file type or specific paths.
|
||||
|
||||
This is best for finding exact text matches or regex patterns.
|
||||
More precise than semantic search for finding specific strings or patterns.
|
||||
This is preferred over semantic search when we know the exact symbol/function name/etc. to search in some set of directories/file types.
|
||||
|
||||
The query MUST be a valid regex, so remember to escape special characters.
|
||||
ALWAYS escape with backslashes if your query contains any of ()[]{}+\*?^$|\\.
|
||||
eg:
|
||||
|
||||
- To search for "function(" use "function\\("
|
||||
- To search for "value[index]" use "value\\[index\\]"
|
||||
- To search for "a+b" use "a\\+b"
|
||||
- To search for "file.txt" use "file\\.txt"
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `query`: (string, required) The regex pattern to search for
|
||||
- `case_sensitive`: (boolean | null, optional) Whether the search should be case sensitive
|
||||
- `exclude_pattern`: (string | null, optional) Glob pattern for files to exclude
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
- `include_pattern`: (string | null, optional) Glob pattern for files to include (e.g. '\*.ts' for TypeScript files)
|
||||
|
||||
## default_api.edit_file
|
||||
|
||||
Use this tool to propose an edit to an existing file or create a new file.
|
||||
|
||||
This will be read by a less intelligent model, which will quickly apply the edit. You should make it clear what the edit is, while also minimizing the unchanged code you write.
|
||||
When writing the edit, you should specify each edit in sequence, with the special comment `// ... existing code ...` to represent unchanged code in between edited lines.
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
// ... existing code ...
|
||||
FIRST_EDIT
|
||||
// ... existing code ...
|
||||
SECOND_EDIT
|
||||
// ... existing code ...
|
||||
THIRD_EDIT
|
||||
// ... existing code ...
|
||||
```
|
||||
|
||||
You should still bias towards repeating as few lines of the original file as possible to convey the change.
|
||||
But, each edit should contain sufficient context of unchanged lines around the code you're editing to resolve ambiguity.
|
||||
DO NOT omit spans of pre-existing code (or comments) without using the `// ... existing code ...` comment to indicate its absence. If you omit the existing code comment, the model may inadvertently delete these lines.
|
||||
Make sure it is clear what the edit should be, and where it should be applied.
|
||||
To create a new file, simply specify the content of the file in the `code_edit` field.
|
||||
|
||||
You should specify the following arguments before the others: [target_file]
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `code_edit`: (string, required) Specify ONLY the precise lines of code that you wish to edit. **NEVER specify or write out unchanged code**. Instead, represent all unchanged code using the comment of the language you're editing in - example: `// ... existing code ...`
|
||||
- `instructions`: (string, required) A single sentence instruction describing what you are going to do for the sketched edit. This is used to assist the less intelligent model in applying the edit. Please use the first person to describe what you are going to do. Dont repeat what you have said previously in normal messages. And use it to disambiguate uncertainty in the edit.
|
||||
- `target_file`: (string, required) The target file to modify. Always specify the target file as the first argument. You can use either a relative path in the workspace or an absolute path. If an absolute path is provided, it will be preserved as is.
|
||||
|
||||
## default_api.file_search
|
||||
|
||||
Fast file search based on fuzzy matching against file path. Use if you know part of the file path but don't know where it's located exactly. Response will be capped to 10 results. Make your query more specific if need to filter results further.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `explanation`: (string, required) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
- `query`: (string, required) Fuzzy filename to search for
|
||||
|
||||
## default_api.delete_file
|
||||
|
||||
Deletes a file at the specified path. The operation will fail gracefully if: - The file doesn't exist - The operation is rejected for security reasons - The file cannot be deleted
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `target_file`: (string, required) The path of the file to delete, relative to the workspace root.
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
|
||||
## default_api.reapply
|
||||
|
||||
Calls a smarter model to apply the last edit to the specified file.
|
||||
Use this tool immediately after the result of an edit_file tool call ONLY IF the diff is not what you expected, indicating the model applying the changes was not smart enough to follow your instructions.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `target_file`: (string, required) The relative path to the file to reapply the last edit to. You can use either a relative path in the workspace or an absolute path. If an absolute path is provided, it will be preserved as is.
|
||||
|
||||
## default_api.web_search
|
||||
|
||||
Search the web for real-time information about any topic. Use this tool when you need up-to-date information that might not be available in your training data, or when you need to verify current facts. The search results will include relevant snippets and URLs from web pages. This is particularly useful for questions about current events, technology updates, or any topic that requires recent information.
|
||||
|
||||
### Arguments:
|
||||
|
||||
- `search_term`: (string, required) The search term to look up on the web. Be specific and include relevant keywords for better results. For technical queries, include version numbers or dates if relevant.
|
||||
- `explanation`: (string | null, optional) One sentence explanation as to why this tool is being used, and how it contributes to the goal.
|
||||
Loading…
x
Reference in New Issue
Block a user