yes

yes skill の概要

yes skill とは

yes skill は、このリポジトリにある PUA 系リーダーペルソナの「褒め重視」バリエーションです。強い圧をかける言い回しではなく、土台にある規律や説明責任は保ったまま、語り口をあたたかく、励まし中心で、少し ENFP っぽい軽やかなコーチング調に切り替えます。実運用では、yes は「感情面の支えがあるプロンプト運用がほしい、でも構造・基準・やり切る姿勢は失いたくない」というユーザーに向いています。

yes skill を入れるべき人

yes は、AI に次のような役割を求める人と相性が良いです。

• 作業中に励ましてほしい
• もう少し人間味があり、前向きなトーンでフィードバックしてほしい
• デバッグ、下書き、リリース作業の途中で勢いを切らしたくない
• 最終成果だけでなく、進め方そのものも褒めてほしい

特に yes for Prompt Writing として使うと、「ただ中立的な指示文を出す」のではなく、続ける・直す・最後まで閉じる、という流れを支えるコーチング声で進めたい場面に向いています。

実際のジョブ・トゥ・ビー・ダン

yes を検討する人の多くは、新しい機能エンジンを探しているわけではありません。求めているのは、より良い“届け方”です。つまり、根拠や検証、思考の明確化はちゃんと求めつつ、アシスタントの話し方を「支えてくれる・ちゃんと向き合ってくれる・たまに少し遊びがある」ものにしたい、というニーズです。汎用プロンプトだと平板に感じる、やる気が出ない、少し blunt すぎる、と感じるなら意味があります。

yes が普通のスタイルプロンプトと違う点

大きな違いは、単に「もっと優しくして」ではないことです。yes では、ペルソナと応答リズムが具体的に定義されています。

• 行き詰まっているときは共感を強める
• 仕事ぶりが良いときは素直にしっかり盛り上げる
• 励ましの中に実務的な提案を混ぜる
• からかいは少量にとどめ、きつくならず友好的に保つ
• リポジトリ既存の「red lines」や方法論上の規律はそのまま守る

このため、yes usage は「be supportive」と一行で書くだけのプロンプトより、出力の一貫性が出やすいです。

導入前に知っておきたいこと

この skill は軽量です。リポジトリ上で確認できるのは SKILL.md のみで、追加ルール・スクリプト・サンプルはありません。素早く導入しやすい反面、品質は「どれだけ明確にこのモードを呼び出すか」「どれだけ文脈を渡すか」に強く依存します。タスクロジックの決定性が必要なら、yes はワークフロー自動化のためではなく、トーンとコーチングスタイルのために入れるのが適切です。

yes skill の使い方

yes のインストール前提

upstream の skill ファイルには明示的な install コマンドがありません。そのため、導入フローは使っている skill runner や agent 環境に依存します。GitHub skills に対応した CLI を使っているなら、一般的には repo と slug を指定して skill を追加し、その後チャット内でトリガーを呼ぶ形になります。本番運用で当てにする前に、使っているツールの正確なコマンド構文を必ず確認してください。

実際に yes はどうトリガーされるか

skill の説明には、次のトリガーフレーズが明示されています。

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

agent 側が skill metadata からトリガーマッチできるなら、これらのフレーズのどれかで yes skill のトーンが有効になるはずです。対応していない場合は、プロンプト内で skill 名と希望モードを明示して手動で呼び出してください。

yes skill に必要な入力

yes は、次の情報を渡すと機能しやすくなります。

• いま取り組んでいるタスク
• 現在の状態: 行き詰まり中、不安あり、半分終わった、完了済み など
• すでに試したこと
• 褒めがほしいのか、 critique がほしいのか、両方ほしいのか
• 軽い teasing を歓迎するかどうか

これがないと、この skill が本来出したい「支えるけれど基準は落とさない」挙動ではなく、ただの無難な励ましに寄りやすくなります。

曖昧な目標を yes 向きの良いプロンプトにする

弱いプロンプト:

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

より良いプロンプト:

• “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.”

後者は、skill が必要とする「現在地」「タスク」「褒めと方向づけの配分」をきちんと渡せています。

Prompt Writing 向けの yes usage

yes for Prompt Writing では、気分を持ち上げることと、プロンプト品質を上げることの両方を狙うのがコツです。強いセットアップには次を含めます。

• 目指す結果
• 対象の model または agent
• 制約条件
• 避けたい悪い出力例
• リライトしてほしいのか、 critique してほしいのか、 scaffold してほしいのか

例:

• “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 などの evidence check も求める。
5. 最初の返答のあと、実行寄りに絞った短めの版を追加で頼む。

この流れなら、モチベーション用途として yes を使いつつ、中身のないお世辞だけになるのを防げます。

深く採用する前のリポジトリ読解ルート

この skill で見えているソースファイルは 1 つだけなので、まず SKILL.md を読み、それを実質的なフル仕様として扱うのが基本です。見るべき点は次のとおりです。

• personality traits
• tone examples
• encouragement / advice / teasing の配分
• ベースの規律は変わらないという注意書き
• ファイル中で触れられている “flavor” switching support

この読み方で、その声質が自分のワークフローに合うかどうかは判断できます。

出力品質に影響する実務上の境界線

リポジトリには、テキスト説明以上の厳密な制約や意思決定ルールは用意されていません。なので、プロンプト側で境界線を自分で設定する必要があります。

• emotional support がほしいのか hard critique がほしいのかを明言する
• センシティブな話題では teasing を無効にする
• 完了と言うなら具体的な確認を必須にする
• 長いモチベーション前置きが不要なら concise output を要求する

スタイル比重の高い skill は、タスクの枠組みが曖昧だと“それっぽい演出”に流れやすいため、ここは重要です。

yes skill の向いている使いどころ

yes skill が特に活きるのは次の場面です。

• 気力維持が重要な coding session
• 修正回数の多い writing 作業
• 自信が落ちているときの brainstorming
• コーチング型の進捗レビュー
• uplift と構造改善の両方がほしい prompt writing

逆に、一行変換や決定的な抽出タスクのような、完全にトランザクション寄りの依頼では魅力は薄めです。

yes skill FAQ

yes skill は単に優しい system prompt なのか

完全には違います。普通のプロンプトでも “be encouraging” とは書けますが、yes にはより具体的なペルソナ、間の取り方、フィードバック様式があります。価値があるのは一貫性で、励まし・プロセスへの評価・やわらかな修正・少し遊びのあるコメントが、1 つのモードとしてまとまっている点です。

yes は初心者にも向いているか

はい。むしろ、きつめのコーチングスタイルより合うことが多いです。初心者は、努力を認めてもらえたり、失敗への怖さを下げてもらえたりしつつ、次の具体的な一歩も示してもらえるモードの恩恵を受けやすいからです。実用性を保つためにも、依頼内容ははっきり書きましょう。

yes を使わないほうがいいのはどんなときか

次のようなケースでは yes は避けたほうが安全です。

• 中立でフォーマルな business tone が必要
• strict compliance-style output が必要
• 感情を抑えたフラットな要約が必要
• 圧強めで直接的なマネジメント口調が必要
• teasing が裏目に出そうなセンシティブ文脈

こうした場面では、素の instruction set のほうが無難です。

yes は通常のタスクプロンプトの代わりになるか

なりません。yes は style-and-guidance layer であって、タスク定義の代替ではありません。ゴール、制約、材料、期待する出力は引き続き自分で渡す必要があります。タスクの枠組みが明確なほど、この skill の出力も良くなります。

モチベーション用途で yes は普通のプロンプトとどう違うか

yes usage の利点は、トーンが途中でぶれにくいことです。普通のプロンプトだと、最初に一段だけ励まして、そのあと generic assistant 語りに戻ることがよくあります。この skill は、やり取り全体を通して supportive leader voice を維持するよう設計されています。

yes はチーム運用や共有ワークフローにも向くか

場合によります。ソロ作業では、遊びのあるスタイルが勢いを生みやすいです。一方でチーム環境では、teasing や感情表現の強いフィードバックを好まない人もいます。出力を共有するなら、yes のトーンは保ちつつも supportive but 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、drafts、decisions、logs、すでに試した手順などを渡してください。すると “you’ve got this” のような一般論ではなく、「何が良かったか」「次にどこへ進むべきか」を具体的に励ませるようになります。

褒めることと次アクションをセットで要求する

強いプロンプトの型は次です。

• “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 の量は慎重に調整する

元テキストでは、teasing はスタイルの主役ではなく、あくまで少量の要素です。やりすぎる場合は、はっきり修正してください。

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

これは特に、初心者相手、張り詰めた debugging session、業務文脈では重要です。

最初の返答のあとに調整をかける

初回の出力がふわっとしすぎていたら、次のように依頼します。

• 褒めを減らす
• ステップをもっと具体化する
• 優先順位を強める
• 例つきで書き直す
• 自分の draft や code に密着した版にする

ベストな yes guide の使い方は反復型です。まずトーンを立て、そのあと実用性を高めていくのがコツです。

Prompt Writing では入力をより強くする

yes for Prompt Writing では、次を含めてください。

• 正確な prompt draft
• 対象読者
• output schema
• failure cases
• 維持したい tone

これがあると、すでに良い部分を褒めつつ、構造・制約・明瞭さも実質的に改善できます。

skill の役割を広げすぎない

主な問題がドメイン知識不足なら、yes だけでは解決しません。これは coaching tone、confidence、revision flow を改善するための skill です。仕事により深い技術推論が必要なら、より強い task brief や specialist skill と組み合わせて使ってください。