ARQAWA/cursor-pi

定義目標

概述

將用戶的意圖塑造成具體的成果，具有明確的範圍和根據請求得出的完成依據。一般的驗證透過閱讀和邏輯評估，在主提示詞的規則下進行；僅在數字表達真實需求時才使用數字。

此技能僅涵蓋目標定義和目標工具的建立。請勿使用此技能建立中間規劃工件、持久化快照、分類帳、決策記錄或恢復檔案。

只有根 Main 技能管理原生 Goal。它的選擇不會增加測試、審查、委派、權限或其他工作流程。Gold Standard 技能會獨立評估有用的工作狀態，無論是否使用 Goal。Notebook 技能可能會根據其自身條件自動加入已選取的 Goal，無需額外手動請求；僅使用 Goal 本身並不要求 Notebook。請在該政策下保留有用的操作筆記，不在本定義流程中處理；原生目標和狀態仍然具有權威性。

僅定義本身並未授權執行所提議的任務。Goal 永遠不會取代必要的批准或執行確認：ToSpec 的準備工作不會啟動未來的執行 Goal，而明確選擇的準備 Goal 僅涉及所請求的準備結果。自動選擇不會覆蓋用戶暫停，也不會將阻塞、等待批准、回合結束或未捨棄的取消視為完成。請遵循實際的原生狀態規則；完成需要實際結果和所有已強制的動作。

工作流程

1. 評估 Goal 對實際當前指令是否有用。

   • 當獨立請求的成果需要跨階段連續、實質性研究或不確定性、或長時間執行時，自動選擇它，但須通過第 6 步的權限檢查。
   • 簡短提問、直接的簡短編輯以及對未來可能工作的討論不需要 Goal。請求的探索本身可以有具體成果；討論它並不授權執行。
   • 直接輸入 /goal、請求建立目標或要求目標定義時，無論複雜度如何，都會選擇此技能。對於受影響的任務，指示不使用 Goal 的指令優先於自動選擇。
   • 在任務發生實質性變化後重新評估，而非每次工具呼叫；不要對指令、分鐘數或檔案使用臨界值。

2. 以具體術語重新陳述可能的目標。 一個可用的目標應說明：

   • 將為真的具體結果
   • 相關的主要工件、系統、儲存庫、環境或用戶可見行為
   • 如何透過閱讀和邏輯評估，以及任何明確要求的證據，來確定實際結果
   • 範圍內的事項
   • 若不明確會造成混淆時，範圍外的事項
   • 停止向用戶提問而非繼續鑽研的條件

3. 使用代表所請求結果的標準。

   • 根據請求推導出結果、工件路徑、範圍、格式、值和二進制完成條件。
   • 不要為了形式上的可衡量性而發明指標、臨界值、驗證器或執行次數。
   • 測試、指令、CI、測量和證據計數僅作為明確請求的經驗證據或特定採用的程序或更高優先義務的選項。
   • 對於一般修復、分析或基於架構的效能工作，透過實際結果和邏輯評估來定義完成。

4. 在設定目標前修復弱目標。

   • 當請求和本地上下文使該詮釋安全時，將模糊的目標重寫為具體的結果標準。
   • 當缺少的細節會改變預期結果或驗證時，提出一個簡潔的澄清問題。
   • 拒絕純活動目標，例如「取得進展」、「繼續調查」、「改善事物」或「處理 X」，除非它們被明確為可驗證的結果。

5. 在建立目標前檢查活動目標狀態。

   • 從 scope_focus_native_context 讀取當前根原生 Goal 快照。驗證 conversationId、goalId、objective 和原生狀態（0 未指定、1 活動、2 暫停、3 完成、4 清除）。缺少有效的根狀態表示沒有目標；未知的身分/狀態是未知，而非缺失。子技能不管理根 Goal。僅使用實際提供的原生預算欄位；不要發明它們。
   • 使用可用的原生 create_goal/update_goal 工具及其當前結構。Cursor 的 create_goal 接受 objective；不要傳遞僅適用於 Codex 的 budget 欄位。缺少必要的原生能力會阻止其依賴的轉換；不要模擬 Goal 或聲稱完全就緒。
   • 如果沒有未完成的目標，且 objective 符合品質標準且第 6 步允許建立，則呼叫 create_goal。
   • 根據當前用戶指示和原生狀態重複使用匹配的未完成目標；重複選擇不會建立重複項或重複已完成的操作。
   • 保留衝突的未完成目標。不要僅為了騰出空間而重置、取代或將其標記為完成。僅透過允許的原生路徑或針對性的用戶問題來解決實質衝突；不需要新的執行緒。

6. 僅在目標通過品質標準後才建立。

   • 選擇此技能本身並不授權 create_goal。遵循實際的工具指示和更高優先規則。表達用戶採用條件式自動 Goal，或適用的系統/開發者指令，只有在這些規則接受的情況下才提供持續請求。技能可用性或普通任務本身不是該權限；如果宿主需要單獨的明確請求，則不要違反該要求推斷權限。
   • 如果原生 Goal 不可用或未被允許，請勿使用檔案或其他控制器模擬它。繼續相容的授權工作；僅在對結果或明確請求的 Goal 有實質影響時，才揭露具體的限制。
   • 使用簡潔的 objective 字串。
   • 包含足夠的完成依據：透過閱讀和邏輯評估的請求結果，加上任何明確強制的證據。每個增加的臨界值或方法都必須遵循請求；將其寫入 objective 並不會建立權限。
   • 當範圍限制工作時，包含範圍邊界。
   • 僅在明確請求且受實際原生結構支援時才提供預算。如果請求的預算無法由 Cursor 原生 Goal 表示，則停止該依賴轉換並揭露缺失的能力；不要靜默丟棄或模擬預算。
   • 制定一個清晰的允許目標，無需僅為了啟用模式或批准其技術用詞而再次提問。僅在缺失的選擇會實質改變請求的結果、權限或強制證據時才提問。僅定義的請求仍然僅是定義。

目標品質標準

在 create_goal 之前，objective 應回答：

• 完成後有什麼具體的事實會為真？
• 有哪些實際的材料和邏輯依據來確定它，以及用戶明確要求了哪些經驗證據？
• 哪些請求的結果或有意義的二進制/量化條件定義了成功？
• 哪些範圍邊界很重要？
• 什麼情況應導致代理停止並提問？

良好：

在指定設定中將 A 替換為 B。編輯存在且閱讀受影響的程式碼確認與請求一致時完成。

良好：

透過相關來源和邏輯解決指定的設計問題。結論有支援且實質矛盾得到解決時完成。

不佳：

讓結帳更快。

不佳：

繼續調查 PR 評論。

量化啟發法

• 對於錯誤，定義所需的修正並透過受影響的程式碼和邏輯解釋它。再現和失敗後通過的驗證器需要明確請求該證據。
• 對於明確請求的測試，命名有序場景及其通過條件；遵循指定的指令。
• 對於效能，從機制、工作和上下文進行推理。將計算的複雜度標記為計算；僅從實際測量中聲稱測量到的改進。不要發明指標、目標、方法或執行次數。
• 對於品質工作，使用請求的結果，通常透過閱讀和邏輯評估；不要自動添加 lint、型別檢查或測試。
• 對於研究，定義研究必須支援的決策、涉及的來源或系統範圍，以及證據標準。
• 對於操作，定義請求的最終狀態。不要發明監控視窗、臨界值或回滾工作。

澄清問題

僅在合理的改寫會冒著追求錯誤結果的風險時才提問。保持問題簡短，並圍繞缺失的驗證器或範圍邊界。

有用的問題形式：

• 「這裡哪個指標應定義成功：延遲、成本、準確性還是用戶可見行為？」
• 「我應該針對哪個環境進行驗證：本地、暫存還是正式環境？」
• 「您希望我在將此目標標記為完成前，最少需要哪些證據？」

當有意義的標準直接來自請求時，直接制定它而無需再次確認。僅在未解決的選擇會實質改變結果或強制證據時才提問。