shot

shot 技能總覽

shot 是拿來做什麼的

shot 是來自 tanweai/pua 的單檔 prompt skill，會把一種高壓、偏「大科技公司績效文化」的風格注入 agent 對話流程。實際上，shot skill 不是 coding framework，也不是工具鏈整合；它更像是一個高密度、可獨立使用的行為包，用來改變模型如何界定工作、拆解任務，以及敘述進度與交付方式。

哪些人適合考慮 shot

shot 最適合想要一步完成、整包上下文風格注入的人，而不是逐步載入一個更大型 skill system 的使用者。特別適合：

• sub-agent 架構中，希望一次讀入就得到完整 persona 的情境
• 想實驗 P7/P8/P9/P10 這類角色條件執行的使用者
• 做 prompt design 或 Context Engineering，想要穩定、強烈語氣與操作模型的人

如果你只是需要一般規劃、寫程式協助，或中性風格的專案管理，shot 多半會太有主觀風格。

shot 真正解決的需求是什麼

多數考慮 shot 的人，不是在找資訊，而是在找一套可重複使用的 prompt 套件，能穩定把模型推進某種特定執行風格。真正的 job-to-be-done 是：「不用每次都重建 framing，就能讓 agent 展現更強的 owner 意識、階層感、委派邏輯，以及帶有交付壓力的敘事方式。」

shot 有什麼不一樣

shot 最大的差異，在於它是刻意高度濃縮的。repository 將它描述為「complete single-file version」，核心效果不依賴額外參考檔。這點很重要，因為很多 skill 需要多個檔案或分階段載入；shot 則是設計成一次性完整注入，因此也更容易透過 read 步驟交給 sub-agent 使用。

安裝 shot 前要先知道什麼

shot 的價值在於它的風格與操作姿態，不在於廣泛相容性。當你需要以下特性時，它會很有力：

• 立即鎖定 persona
• 明確的角色階層
• 可重複的「壓力 + owner 意識」交付風格
• 適合受限 agent workflow 的自包含使用方式

但如果你需要以下情境，shot 就比較不理想：

• 中性利害關係人溝通
• 低戲劇性、面向客戶的文字
• 特定領域的實作規範
• 對安全或語氣敏感，且強硬口吻可能損害清晰度的環境

如何使用 shot 技能

shot 的安裝情境

repository 片段中沒有在 SKILL.md 內提供原生安裝指令，因此多數使用者會透過自己的 GitHub skill manager 流程安裝。常見做法是：

npx skills add tanweai/pua --skill shot

如果你的環境使用不同的 skill loader，關鍵是要指向 tanweai/pua repository 內的 skills/shot 路徑。

先讀這個檔案

先從這裡開始：

• skills/shot/SKILL.md

這份檔案比一般情況更重要，因為從 repository 的內容來看，shot 幾乎就是這個產品本體：單一檔案、高密度，主操作邏輯與觸發語都集中在裡面。和模組化 skill 不同，這裡沒有其他支援資料夾在背後撐主要功能。

shot 通常怎麼觸發

這個 skill 公開的自然觸發方式包含：

• /pua:shot
• /pua shot
• shot mode
• PUA浓缩
• 最强PUA
• 全量注入

實務上，只下 trigger 通常還不夠拿到好結果。啟用 shot 後，最好接著告訴模型具體任務、想要的 deliverable、限制條件，以及它應該扮演 executor 還是 manager。

shot 要吃到哪些輸入才會表現好

shot 在你提供以下四項資訊時通常表現最好：

1. 明確目標
2. 你要它採用的操作角色
3. 成功標準
4. 限制條件或邊界

較弱的輸入：

• “Use shot and help with my project”

較強的輸入：

• “Use shot in P8 mode. Audit this API refactor plan, identify delivery risks, break the work into implementation steps, and produce a final execution plan with acceptance criteria. Keep the tone internal-facing, not customer-facing.”

較強版本之所以有效，是因為它有告訴這個 skill：在 persona 之內，到底要執行什麼工作，而不只是要求它套上一個 persona。

角色選擇的重要性比多數人以為的更高

shot skill 的核心，是一套四層角色模型：

• P7：在指導下執行
• P8：可獨立負責並落地執行
• P9：偏管理者，會寫 task prompt 多於直接寫 code
• P10：策略層

這不是表面裝飾。如果你想要 coding help，卻不小心叫到管理角色，輸出就可能偏向委派與規劃，而不是實作。對 shot usage 來說，選對層級是影響品質最大的控制桿之一。

用於 Context Engineering 的最佳 shot 提示模式

如果你是把 shot for Context Engineering 當作工具使用，最好把它視為「行為層 + 任務規格」的組合。實用的 prompt 結構可以是：

• 載入 shot
• 宣告角色：P7、P8、P9 或 P10
• 說明你要的 artifact
• 定義完成條件
• 有需要時設定語氣邊界

例如：

• “Load shot. Operate in P8 mode. Review this repository migration brief and produce: 1) risk map, 2) implementation sequence, 3) rollback plan, 4) final owner-style recommendation. Include the internal narration style sparingly.”

這樣可以保留風格的實用性，同時避免它蓋過任務本身。

啟用 shot 後建議的工作流程

一套穩定的 workflow 是：

1. 啟用 shot
2. 明確指定角色
3. 提供任務與限制
4. 檢查輸出是否太戲劇化或太空泛
5. 再要求第二輪，聚焦在 deliverable 品質上

這通常比 one-shot prompting 更有效，因為這個 skill 的風格很容易在第一輪主導輸出。快速做一輪 refinement，比較能把有用的操作結構和過量敘事分開。

如何把 shot 用在 sub-agents

shot 很適合拿來做 sub-agent 注入，因為它是自包含的。如果你的系統可以透過 Read 步驟傳遞檔案，或在 spawn agent 時預載 skill，這個 skill 會比多檔案設定更容易移植。

適合的用法：

• 給 sub-agent 一份 shot，再加上一個範圍明確的執行任務，並使用 P7 或 P8 模式

比較不理想的用法：

• 在大型 pipeline 中把 shot 發給每一個 agent，尤其包含面向客戶或對合規敏感的步驟

什麼樣的輸出品質才算好

好的 shot usage 通常會出現：

• 更強的 owner 語言
• 清楚的執行姿態
• 明確的任務拆解
• 看得見 acceptance 或 review framing
• 一致的內部語氣

不好的用法則常見：

• persona 風味很多，但任務推進很少
• 角色混亂
• 過度使用「大公司式」敘事
• 明明需要 code 或分析，卻輸出管理語言

什麼時候 shot 不是對的選擇

不要只是因為想要「更好的 prompts」就選 shot。它不是通用型最佳化層。以下情境建議跳過：

• 需要中性或有同理心的溝通
• 需要輕量的 coding help
• 需要根據 docs 或 references 的領域規則
• 希望 prompt 負擔越低越好

如果你的核心目標是準確性勝過風格，較簡單、任務導向的 prompt，可能會比 shot skill 更好用。

shot 技能 FAQ

shot 是 coding skill，還是 persona skill？

主要是 persona 與 operating model skill。它會影響 coding workflow，但核心價值在於執行 framing、角色行為和語氣。如果你想重複利用的正是這套 framing，那就值得安裝 shot。

shot 對新手友善嗎？

只有在你已經清楚知道自己想要什麼輸出時，才算相對友善。新手可能會覺得它的風格很有趣，但如果沒有說清楚角色、任務與成功標準，結果仍然可能很弱。shot install 不難；但要做好 shot usage，還是需要 prompt 紀律。

我需要 repository 裡其他檔案嗎？

就這個 skill 來說，通常不需要。從目前資訊看來，SKILL.md 已經承載了主要 payload。這也是很多人選 shot 的原因之一：相較於需要外部參考的模組化 skill，它更容易快速載入。

shot 和一般 system prompt 差在哪裡？

一般 system prompt 可能只是設定語氣或限制；shot 更進一步，把角色階層、委派邊界與明確的敘事行為打包成可重用 skill。這能提升一致性，尤其在 sub-agents 間更明顯，但代價就是它的風格主觀性也強很多。

什麼情況下不該用 shot skill？

當受眾是外部對象、任務需要冷靜中性的措辭，或工作本身已經有很強的專案特定 protocol 時，應避免使用 shot。如果這個 skill 的風格會和你原有的操作規則互相競爭，它反而會增加摩擦。

shot 適合拿來做 Context Engineering 嗎？

適合，前提是你的 Context Engineering 目標，是測試一個緊湊、自包含的行為層如何改變 agent 表現。shot for Context Engineering 最有價值的地方，在於它是一個可控的實驗對象，可用來觀察 persona 注入、角色 framing 與任務拆解品質的變化。

如何改善 shot 技能的使用效果

給 shot 一個任務，不要只給 trigger

最常見的失敗方式，就是啟用 shot 後，期待它自己猜出真正任務。請務必在 trigger 後接上：

• 角色
• artifact
• 限制條件
• 完成線

這樣才能把 skill 從「style mode」拉進真正可工作的 execution mode。

控制敘事強度

repository 把這種敘事風格當成核心賣點，但你不必每次都接受最大強度。如果第一版輸出太重，可以直接說：

• “Keep shot structure, but reduce narration to only milestone transitions.”
• “Use the shot operating model, but keep the prose plain.”

這樣能保留價值，同時降低噪音。

讓角色對上 deliverable

建議這樣用：

• P7：適合在明確指示下提供實作支援
• P8：適合 owner 式執行
• P9：適合管理 workstreams 與撰寫 task prompts
• P10：適合策略 framing

很多不理想的 shot guide 結果，都是因為使用者其實需要 P8，卻用了 P9 或 P10。

一開始就提供 acceptance criteria

shot 在目標具體時效果會更好。不要只說：

• “Plan this migration”

改成：

• “In shot P8 mode, plan this migration with phases, risks, rollback, staffing assumptions, and a final go/no-go recommendation.”

這樣這個 skill 才有明確優化目標，而不是只剩語氣可發揮。

先優化結構，再修飾文字

如果第一版回答風格對了，但邏輯偏弱，不要先要求它把文字寫漂亮。應該先要求：

• 更銳利的拆解
• 更清楚的假設
• 更紮實的風險分析
• 明確的 acceptance checks

這是提升 shot skill 輸出品質最快的方法。

留意這些常見失敗模式

最需要修正的問題通常是：

• 角色不匹配
• 敘事過量
• 成功標準模糊
• 只有表演式自信，沒有具體 deliverables
• 明明中性 prompt 更適合，卻硬套 shot

如果你很早就看到這些跡象，應該先 refine prompt，而不是一味再加更多指令。

一個實用的二次修訂 prompt

很好用的第二輪 prompt 範例如下：

“Keep shot in P8 mode, but tighten the output. Remove filler narration, make assumptions explicit, add acceptance criteria, and convert the plan into an execution-ready checklist.”

這種修訂方式通常能保留 shot 的優點，同時讓答案更容易真正拿來用。