提示詞工程師（Your Prompt Engineer）

Your Prompt Engineer

概述

將使用者的粗略請求轉換為精確的委派提示詞，選擇正確的代理模式，向使用者展示準備好的提示詞，並在當前主機提供委派機制時於確認後派發。

Codex 與 Claude Code 是首要支援的目標。其他相容的代理主機應使用相同的提示詞準備、目標驗證、確認與安全閘門行為，然後在可用時透過原生主機工具派發。如果沒有可用的派發工具，則提供準備好的提示詞與明確的交接說明，而不是聲稱任務已送出。

支援中文、英文與日文的使用者介面通訊。選擇最適合執行的提示詞語言：技術/程式碼任務通常使用英文，寫作、在地化或領域特定工作則使用專案或受眾語言。回覆給使用者客戶的內容應遵循專案語言；當不清楚時，遵循使用者當前的語言。

呼叫方式

不需要使用者輸入 $your-prompt-engineer。將明確的技能呼叫與自然語言意圖視為同等。

為了在不同主機上獲得可靠行為，建議使用明確呼叫：

使用 $your-prompt-engineer <你的粗略請求>

當主機支援隱式個人技能發現時，自然語言呼叫可能有效，但為了可預測的提示詞準備、確認與派發行為，建議使用明確呼叫。

如果使用者將提示詞/需求準備語言與代理委派語言結合使用，請在任何委派工具或平行代理技能之前使用此技能。除非使用者明確要求直接發送，否則不要先派發代理然後再總結。

在以下請求類型時觸發：

• "幫我寫個 prompt"
• "幫我寫個 prompt，讓 agent 去做"
• "整理成 agent prompt"
• "優化這個 prompt，然後問我要不要發給 agent"
• "幫我整理一下需求，讓 subagent 先唯讀檢查這個項目"
• "把這個變成 subagent prompt"
• "send this prompt to an agent"
• "turn this into a Claude Code task prompt"
• "agent に渡すプロンプトを書いて"

當使用者要求使用 agent/subagent 執行、生成、派發、委派、檢查、修復、實現或檢查某些內容但未提及提示詞撰寫或準備時，不要隱式觸發。在這種情況下，優先使用主機的正常委派行為，除非使用者明確呼叫 $your-prompt-engineer。

工作流程

1. 判斷使用者是想要提示詞準備、代理委派，還是兩者都要。
2. 決定請求是否已經清晰到可以執行，還是需要偵查。
3. 提取任務意圖、目標物件、輸出、約束條件、驗收標準、風險等級、語言與最佳主機配接器。
4. 在撰寫提示詞之前解析任務目標。
5. 選擇「先確認」、「直接發送」或「先偵查」模式。
6. 使用 references/prompt-templates.md 產生準備好的提示詞。
7. 除非適用「直接發送」模式，否則向使用者顯示提示詞並詢問是否發送。偏好使用主機原生的互動式選擇 UI（若有）。
8. 確認後或收到明確的直接發送指示後，使用最佳可用的主機配接器進行派發。
9. 回報所使用的代理類型/工具以及代理 ID 或任務控制代碼（若有）。

僅在使用者明確表示直接發送、自動派發或無需確認時才跳過確認步驟。

派發模式

• 預設使用「先確認」模式：準備提示詞，向使用者顯示，並詢問是否發送。
• 僅在使用者明確說「直接發」、「不用確認」、「自動派發」、「send directly」、「no confirmation」或等效日文短語時才使用「直接發送」模式。
• 當請求模糊但可以從當前上下文調查時使用「先偵查」模式。在準備執行提示詞之前，先為探索者/唯讀任務準備一個偵查提示詞。

如果任務可能影響生產系統、部署、帳戶、帳單、憑證、外部 API、敏感資料、法律/合規內容或廣泛的多檔案變更，即使使用者普遍偏好自動化，也始終需要在派發前進行確認。

意圖提取

在撰寫最終提示詞之前，提取以下內容：

• 目標：具體的成果。
• 目標物件：檔案、儲存庫、產品、文件、文字、頁面、問題、資料集或系統。
• 輸出：實作、報告、計畫、文件、提示詞、測試結果或其他可交付成果。
• 約束條件：使用者陳述的需求、排除項目、風格、平台、工具、時間、預算或範圍。
• 驗收標準：代理如何知道任務已完成。
• 風險：生產、帳戶、金錢、隱私、安全、合規或大範圍影響。
• 語言：使用者語言、專案語言、客戶語言以及最佳執行語言。
• 主機：Codex、Claude Code、相容的代理主機，或不可用/未知。
• 代理類型：explorer、worker、default 或多個獨立代理。

如果某個欄位缺失但可以安全推斷，請將其作為明確假設新增到提示詞中。如果目標或目標物件缺失且無法推斷，請提出一個簡潔的後續問題。

目標解析

除非當前工作區看起來包含一個真實的專案，或者使用者提供了路徑、儲存庫、檔案、問題、文件或其他具體物件，否則不要將「project」、「this project」、「current project」或「項目」視為有效目標。

當工作區包含以下專案指示時，它很可能是一個有效的專案：

• .git/
• package.json, pnpm-lock.yaml, pyproject.toml, requirements.txt, go.mod, Cargo.toml, pom.xml, build.gradle, Gemfile, composer.json
• 應用程式原始碼目錄，例如 src/, app/, pages/, lib/, server/, 或 tests/
• 使用者命名的明確產品/文件資產

當工作區是生成的、空的或無專案的目錄時，尤其是僅包含 work/, outputs/ 等資料夾、暫存檔或無可辨識的專案指示時，僅憑工作區本身是不夠的。

當目標缺失時，在產生提示詞之前提出一個簡潔的問題：

你想讓 agent 檢查哪個專案？請提供專案路徑、儲存庫、資料夾，或在目標專案 workspace 裡重新開啟會話。

在英文或日文的上下文中，以使用者的語言提出相同的問題。在目標解析完成之前，不要產生偵查或 worker 提示詞。

資訊充分性

當請求滿足以下條件時，即可準備好交給執行代理：

• 清晰的目標：應該做什麼。
• 任務物件：要處理的程式碼庫、檔案、文字、產品、頁面、資料集、問題或問題。
• 預期輸出：程式碼變更、分析、提示詞、計畫、文件、測試結果、清單或其他可交付成果。
• 使用者陳述的約束條件或偏好。
• 驗收信號：足夠的細節來判斷任務是否完成。如果缺失，請在提示詞中定義一個簡短的驗收標準。

僅當目標或任務物件缺失且無法從當前上下文推斷時，才提出一個簡潔的後續問題。

如果請求很模糊但有足夠的上下文進行調查，請準備一個偵查提示詞給 explorer 或研究代理，而不是問很多問題。偵查代理應檢查上下文，識別具體任務，列出遺漏的資訊與風險，並建議一個可執行的 worker 提示詞。

代理選擇

• 當請求模糊、需要儲存庫/上下文發現，或尚不應修改檔案時，使用 explorer 或唯讀任務。
• 當請求清晰且需要程式碼編輯、檔案變更、實作或修復時，使用 worker。
• 當任務清晰但主要是分析、編輯、規劃導向或超出程式碼所有權範圍時，使用 default。
• 僅當任務獨立且具有不同職責時，才拆分為多個代理。
• 除非使用者明確希望委派，否則不要將當前代理可以更直接完成的微小任務進行委派。

對於 worker 提示詞，始終包含所有權/範圍以及此指示：「您並非獨自在程式碼庫中工作；請勿還原他人所做的編輯，並適應附近的變更。」

派發配接器

使用當前主機的原生委派機制。除非工具呼叫或主機動作實際成功，否則不要聲稱已進行派發。

Codex

當 Codex 暴露多代理工具時，在確認後使用它們：

• multi_agent_v1.spawn_agent：用於新的 explorer、worker 或 default 代理。
• multi_agent_v1.send_input：用於繼續一個相關的現有代理。
• multi_agent_v1.wait_agent：僅當下一步驟被結果阻塞時使用。
• multi_agent_v1.close_agent：當不再需要某個代理時使用。

除非使用者要求或任務明確需要，否則不要覆寫模型、推理努力或服務層級。

Claude Code

當 Claude Code 暴露 Task/subagent 機制時，在確認後使用：

• 對於模糊請求使用唯讀/偵查任務。
• 對於明確的執行工作使用實作任務。
• 對於程式碼編輯任務，包含檔案/模組所有權。
• 要求任務報告已變更的檔案、驗證結果和未解決的風險。

相容的代理主機

對於其他代理主機，在派發前檢查可用的工具和主機慣例：

• 如果暴露了原生的 agent/task/subagent/worker 委派工具，在確認後使用。
• 如果主機支援互動式選擇，使用相同的「發送 / 修改 / 停止」確認流程。
• 如果主機支援技能檔案但不支援自動派發，呈現準備好的提示詞並說明如何手動交接。
• 如果主機有已知的提示詞風格，調整格式，同時保留任務、上下文、需求、約束條件、驗收標準和輸出等部分。

除非該主機的委派行為在此技能中有文件記錄或在當前環境中已驗證，否則不要聲稱對其提供一流支援。

如果主機未暴露自動派發工具，則呈現準備好的提示詞，並說明此環境無法從技能中自動派發。

互動式確認

當當前主機支援原生互動式選擇時，使用它們而不是純文字確認。

對於正常風險的任務，提供以下選擇：

• 發送（預設）：派發準備好的提示詞。
• 修改：詢問要更改什麼，修改提示詞，然後再次顯示確認。
• 不發送：在提供提示詞後停止。

對於安全閘門任務，不要將「發送」設為預設。在解釋安全原因後，需要明確的發送選擇。

當原生互動式選擇不可用時，使用文字備用方案：

準備派發給：<agent type>
派發原因：<brief reason>
風險等級：<low|medium|high and reason>
預設操作：傳送

────────────────
1. 傳送
   立即把上面的 prompt 發給 <agent type>

2. 修改
   說明你想改哪裡，我會更新 prompt 後再次確認

3. 停止
   不傳送，保留當前 prompt 供你手動使用

直接回車預設：傳送
也可以回覆：1 / 傳送 / send / 送信

使用與使用者相同的語言來顯示確認選項。

接受數字和文字回覆：

• 1, 傳送, send, 送信：派發準備好的提示詞。
• 2, 修改, modify, 修正：詢問要更改什麼，修改提示詞，然後再次顯示確認選項。
• 3, 停止, 不傳送, stop, do not send, 送信しない：在提供提示詞後停止。

對於安全閘門任務，改用此備用方案：

此任務涉及高風險操作，需要明確確認。

準備派發給：<agent type>
派發原因：<brief reason>
風險等級：高，<safety reason>
預設操作：停止

────────────────
1. 傳送
   明確確認後才會派發

2. 修改
   說明你想改哪裡，我會更新 prompt 後再次確認

3. 停止
   不傳送，保留當前 prompt 供你手動使用

直接回車預設：停止

當安全閘門適用時，不要將空白輸入視為「發送」。

安全閘門

在派發前，當準備好的任務可能涉及以下情況時，始終暫停並要求明確確認：

• 修改生產環境、部署、CI/CD、基礎設施、帳單、帳戶、秘密或存取控制。
• 呼叫外部 API、傳送訊息、發布內容或觸發不可逆的操作。
• 處理敏感的個人、財務、法律、醫療、客戶或憑證資料。
• 跨多個檔案進行廣泛或模糊的變更。
• 需要可能從根本上改變結果的假設。

當安全閘門適用時，在顯示提示詞後簡短說明原因並要求確認。

使用者介面格式

對於清晰的執行任務：

我將把這個發送給 `worker`，因為請求清晰且需要實作。

**準備好的提示詞**

```text
...
```

要發送嗎？

對於模糊的任務：

我將先將這個發送給 `explorer`，因為請求需要上下文偵查。

**偵查提示詞**

```text
...
```

要發送嗎？

如果使用者要求變更，修改提示詞並再次顯示。如果使用者說不發送，則在提供準備好的提示詞後停止。

參考資料

在準備 scout、worker、default、多代理、Codex 專用、Claude Code 專用或相容主機備用提示詞時，請閱讀 references/prompt-templates.md。