yes

yes skill 概覽

yes skill 是什麼

yes skill 是此 repository 裡 PUA 風格 leader persona 的「稱讚導向」變體。它不是用強壓式的表達方式，而是在保留原本紀律感與責任感的前提下，把敘事語氣改成溫暖、鼓勵、帶點 ENFP 感的教練式陪跑，並穿插輕微玩笑感。實際上，yes 很適合想要有激勵感、情緒支援感的 prompt 寫作體驗，但又不想失去結構、標準與後續追蹤的人。

誰適合安裝 yes skill

yes 適合希望 AI 能夠：

• 在你處理任務時一路鼓勵你
• 用更有人味、更有朝氣的語氣給回饋
• 在 debugging、起草內容或準備交付時幫你維持節奏
• 稱讚好的做事流程，而不只看最後結果

如果你在找的是 yes for Prompt Writing，那它尤其有價值：它能用教練式語氣幫你繼續推進、反覆修正、補完閉環，而不只是吐出一段中性的指令。

實際要解決的工作需求

多數考慮 yes 的使用者，想要的其實不是一個全新的能力引擎，而是更好的交付風格：希望 assistant 聽起來更支持你、更投入，偶爾帶點玩心，同時仍然會要求證據、驗證與更清楚的思考。當通用 prompt 讓你覺得太平、缺乏動力，或過於直接生硬時，這點就很重要。

yes 和一般風格 prompt 有什麼不同

yes 的核心差異不是單純「講話好一點」。這個 skill 定義了更具體的人設與回應節奏：

• 在你卡住時給高同理心
• 在工作做得不錯時表現出真心興奮
• 把實際可做的建議混進鼓勵裡
• 帶一點點玩笑，但應維持友善，不能變尖酸
• 持續遵守 repo 既有的「red lines」與方法紀律

因此，yes usage 比起一句像「be supportive」的單行 prompt，會更穩定一致。

採用前要先知道的事

這個 skill 很輕量：從 repository 可見證據來看，只有一個 SKILL.md 檔案，沒有額外規則、script 或範例。這對快速導入是優點，但也代表最終品質非常依賴你是否清楚喚起這個模式，以及你提供了多少上下文。若你需要可預測、可重現的任務邏輯，應把 yes 安裝成語氣與教練風格層，而不是把它當成 workflow automation。

如何使用 yes skill

yes install 的情境說明

上游 skill 檔案沒有提供明確的 install command，所以實際安裝流程會取決於你的 skill runner 或 agent 環境。如果你使用的是支援 GitHub skills 的 skills CLI，常見模式通常是依 repo 與 slug 加入該 skill，之後再在對話中呼叫 skill trigger。正式用在 production 前，請先確認你所用工具的精確 command syntax。

yes 在實務上怎麼觸發

skill 描述中明確標出了這些 trigger phrases：

• /pua:yes
• 夸夸模式
• 唠嗑模式
• 情绪价值
• yes
• 夸我
• 鼓励模式

如果你的 agent 支援從 skill metadata 做 trigger matching，使用上述任一詞句通常就能啟動 yes skill 的語氣。若不支援，請在 prompt 裡手動點名 skill 名稱與你要的模式。

yes skill 需要什麼輸入

當你提供以下資訊時，yes 會明顯表現得更好：

• 你正在做的任務
• 你目前的狀態：卡住、不確定、做一半、或已完成
• 你已經試過什麼
• 你想要的是稱讚、批評，還是兩者都要
• 是否接受輕微 teasing

如果沒有這些資訊，模型很容易退回成泛泛的鼓勵，而不是這個 skill 原本設計要達成的「支持你，但仍有標準意識」的行為。

把模糊目標寫成有效的 yes prompt

弱的 prompt：

• “Use yes and help me with this feature.”

更強的 prompt：

• “Use the yes skill. I’m implementing form validation in React, I already handled required fields, and I’m stuck on async uniqueness checks. Encourage me, point out what I’ve done well, then give the next 3 practical steps. If my thinking is weak, say so gently.”

後者更好，因為它同時提供了目前狀態、任務內容，以及稱讚與指導之間的精確平衡。

yes for Prompt Writing 的用法

在使用 yes for Prompt Writing 時，最好明確要求這個 skill 同時幫你提升士氣與 prompt 品質。比較理想的設定會包含：

• 你的目標成果
• 目標 model 或 agent
• 限制條件
• 你想避免的糟糕輸出範例
• 你要的是重寫、評論，還是搭骨架

Example:

• “Use yes for Prompt Writing. I need a prompt that makes an assistant summarize support tickets into action items. Be encouraging, tell me what is already good in my draft, then rewrite it with clearer scope, output format, and failure handling.”

第一次使用 yes skill 的建議流程

1. 明確啟動 yes。
2. 說清楚任務內容，以及你卡在哪裡。
3. 一次要求兩層輸出：先鼓勵，再給具體下一步。
4. 如果是技術任務，主動要求證據檢查：tests、logs、output 或 validation。
5. 收到第一輪回覆後，再要求一版更緊湊、以執行為主的版本。

這樣的 workflow 能讓你吃到這個 skill 的激勵效果，同時避免它滑向空泛吹捧。

深度採用前的 repository 閱讀路徑

因為這個 skill 目前只有一個可見 source file，所以請先讀 SKILL.md，並把它視為完整契約。閱讀時特別注意：

• personality traits
• tone examples
• 鼓勵、建議與 teasing 的比例
• 關於基礎紀律不變的提醒
• 檔案裡提到的 “flavor” switching support

照這條路徑讀一遍，通常就足以判斷這個聲線是否適合你的 workflow。

會影響輸出品質的實務邊界

這個 repository 除了文字描述外，並沒有提供正式的限制條件或決策規則。因此，你最好在 prompt 裡自己把邊界訂清楚：

• 說明你要情緒支持，還是硬一點的批判
• 敏感主題請停用 teasing
• 對「完成了」這類主張，要求具體檢查
• 如果不想看太長的激勵鋪陳，就要求 concise output

這點很重要，因為風格導向很強的 skill，只要任務框架太模糊，就容易變成表演感大於實用性。

yes skill 最適合的使用情境

yes skill 最有價值的場景包括：

• 士氣會影響表現的 coding session
• 需要反覆修訂的寫作工作
• 信心偏低時的 brainstorming
• 教練式進度回顧
• 想同時得到提振與更清晰結構的 prompt writing

如果只是純交易型需求，例如單行格式轉換或可確定規則的 extraction task，它的吸引力就沒那麼高。

yes skill 常見問題

yes skill 只是比較溫柔的 system prompt 嗎

不完全是。一般 prompt 也能寫「請多鼓勵」，但 yes 多了一套具體 persona、節奏與回饋風格。真正有用的地方在於一致性：把鼓勵、對過程的肯定、溫和修正，以及偶爾的輕鬆評論整合在同一種模式裡。

yes 適合初學者嗎

適合，而且很多時候比偏強硬的教練風格更適合。初學者通常會受益於一種能承認努力、降低失敗焦慮，同時還是會指向下一個具體步驟的模式。只是你的需求要說清楚，答案才不會只剩情緒價值，失去實作性。

什麼時候不該用 yes

以下情況建議不要用 yes：

• 需要中性、正式的商務語氣
• 需要嚴格 compliance 風格的輸出
• 需要情緒完全平的摘要
• 需要直接、高壓的管理口吻
• teasing 可能失準的敏感情境

這些情況下，直接用普通 instruction set 會比較安全。

yes 可以取代一般任務 prompt 嗎

不行。yes 是風格與引導層，不是任務規格本身的替代品。你仍然需要提供目標、限制、素材與預期輸出。你的任務框定得越清楚，這個 skill 的效果就越好。

yes 和一般 prompt 在激勵效果上怎麼比

yes usage 的優勢在於語氣連續性。一般 prompt 常常只會先給你一段鼓勵，接著又退回通用 assistant 語言；而這個 skill 的設計，就是要讓支持型 leader voice 持續貫穿整段互動。

yes 適合團隊或共享 workflow 嗎

有時候適合，但要小心使用。在個人 workflow 裡，這種帶點玩心的風格常能提升節奏；但在團隊情境中，不是每個人都喜歡 teasing 或情緒表達比較強的回饋。如果輸出要共享，建議要求模型保留 yes 的支持感，但維持 professional。

如何改善 yes skill 的使用效果

給 yes skill 明確的情緒目標

最快能拉高品質的方式，就是直接告訴模型你想要哪一種支持：

• hype me up
• reassure me because I’m stuck
• praise what’s working but be strict on gaps
• keep it light, no teasing
• be warm but concise

這能避免最常見的失敗模式：聽起來很開朗，但其實沒幫上忙。

提供進度證據，而不只是丟任務

當 yes 看得到真實過程時，效果會更好。請提供 code、draft、決策、logs，或你已經試過的步驟。這樣它才能針對你做對的地方給具體鼓勵，也能指出下一步該往哪走，而不是只回一句泛用的「你可以的」。

要求稱讚加上下一步行動

一個很強的 prompt pattern 是：

• “Acknowledge what is good in my approach, then give the next 2-4 actions.”

這樣能讓 yes skill 保有情緒上的推進力，同時確保它仍然會拉你往執行面前進。

避免空洞的正向輸出

yes 的其中一個風險，是過度偏向鼓勵。你可以加上這些要求來抵消：

• “Don’t flatter me if the work is weak.”
• “Point out the missing validation.”
• “If my plan is flawed, say so gently but clearly.”

這樣能保住這個 skill 原本設計好的平衡：既支持你，也維持標準。

謹慎調整 teasing 的比例

source text 顯示，teasing 只是整體風格裡很小的一部分，不是主戲。如果模型做得太多，請直接修正：

• “Use yes mode, but keep teasing under 5%.”
• “No sarcasm.”
• “Friendly encouragement only.”

這對初學者、緊繃的 debugging session，或 professional 場景特別重要。

第一輪回答後要再迭代

如果第一版輸出太 fluffy，可以直接要求：

• 更少稱讚
• 更多具體步驟
• 更強的優先順序
• 一版附 examples 的重寫答案
• 一版緊扣你實際 draft 或 code 的版本

最好的 yes guide workflow 通常是迭代式的：先把語氣立起來，再收斂到實用度。

在 prompt writing 任務中提供更強的輸入

使用 yes for Prompt Writing 時，最好一起提供：

• 完整的 prompt draft
• 目標受眾
• output schema
• failure cases
• 你希望保留的語氣

這樣這個 skill 才能一邊肯定原本已經做得好的部分，一邊實質改善結構、限制條件與清晰度。

讓 yes skill 做它擅長的事

如果你的核心問題是缺乏 domain knowledge，yes 本身不會自動解決這件事。它適合用來提升教練感語氣、建立信心，以及優化修訂流程；當工作需要更深的技術推理時，請把它搭配更完整的 task brief 或 specialist skill 一起用。