pua

pua skill の概要

pua skill が実際にすること

pua skill は、エージェント作業にかぶせるトーンと行動のオーバーレイです。セッション内でフラストレーション、失敗の反復、受け身な進行、あるいは質の低い完了が見られたときに、モデルを高圧・高主体性の実行スタイルへ切り替えます。実際のところ、pua は新しいツールを増やすものというより、作業中の計画、検証、エスカレーション、話し方をどう変えるかに重心がある skill です。

pua skill を使うべき人

pua は、コーディング、デバッグ、デプロイ、リサーチのワークフローで、より強いやり切り力を求める人に向いています。加えて、攻めの強いマネジメント調の語り口を受け入れられることが前提です。自分の環境をすでに把握していて、エージェントに曖昧なごまかしをやめさせたい、もっと深く調べさせたい、検証を増やしたい、未回収の論点まで能動的に閉じさせたい、という運用者に特に合います。

pua skill が解決する本質的なニーズ

pua を検討する多くの人は、娯楽目的ではありません。早々に諦めないエージェント、もっともらしい最初の答えで止まらないエージェント、証拠なしに完了を宣言しないエージェントを求めています。つまり pua skill は、「もっと粘れ、もっと検証しろ、結果に責任を持て」という場面のために設計されています。

通常のプロンプトと pua skill の違い

普通のプロンプトでも、一度だけ厳密さを要求することはできます。ですが pua は、それを再利用可能な運用パターンとして持ち込みます。具体的には、失敗時のエスカレーション、フレーバーに基づくリーダーシップ調の声色、タスク種別ごとの手法ルーティング、表示ルール、さらに ~/.pua/evolution.md を使った任意の長期ベースライン記憶まで備えています。単発の「もっと proactive に動いて」より、ずっと構造化されているのが違いです。

導入前に知っておきたい主なトレードオフ

pua for Workflow Automation の最大の利点は、完了と検証に対する圧力が明確に強まることです。一方で最大のコストはトーンです。この pua skill は意図的に厳しく、ロール色が強く、文化的な演出も濃い作りになっています。落ち着いたペアプログラミング、初心者向けの丁寧な伴走、あるいは中立的なエンタープライズ言語を求めるなら、相性はかなり悪いはずです。

pua skill の使い方

pua skill をワークフローのどこで使うか

pua は、エージェントが詰まっている、期待より弱い、あるいは受け身すぎるときのセッション修飾子として使うのが基本です。特に有効なのは、失敗が続いた後、品質への不満が出た後、あるいは「これじゃ足りない」といった曖昧でも不満の強いフィードバックが出た場面です。実際、リポジトリでもそうしたトリガーが明示的に中心に置かれています。

pua skill 採用前に最初に読むべきもの

まずは skills/pua/SKILL.md を読んで、トリガーロジック、フレーバー切り替え、タスクルーティングの全体像をつかみましょう。次に、出力フォーマットは skills/pua/references/display-protocol.md、タスクと手法の対応は skills/pua/references/methodology-router.md、ワークフロー圧よりもトーン調整を重視するなら skills/pua/references/flavors.md を確認するのが効率的です。

導入判断で重要なサポートファイル

pua skill を本気で使うつもりなら、特に判断材料になりやすいファイルは次のとおりです。

• skills/pua/references/agent-team.md：マルチエージェント委任のルール
• skills/pua/references/evolution-protocol.md：永続的なベースライン挙動
• skills/pua/references/p7-protocol.md、skills/pua/references/p9-protocol.md、skills/pua/references/p10-protocol.md：エスカレーション経路
• skills/pua/references/methodology-alibaba.md や skills/pua/references/methodology-huawei.md などの methodology 系ファイル：実行スタイル上の制約

実運用で pua skill はどう発火するか

リポジトリ上の記述を見る限り、pua は失敗の反復、「stop spinning」「you broke it」「why does this still not work」「/pua」といった、苛立ちや停滞を示すシグナルで有効化される設計です。つまり pua skill は、単に「すべてのタスクで常時オンにする」ものではありません。会話の流れ自体が失速や責任感の弱さを示しているときに、最も効きます。

pua skill がうまく機能するために必要な入力

pua は、次の情報があると明らかに働きやすくなります。

• 正確なタスク内容と definition of done
• 何がすでに失敗したか、何回失敗したか
• repo、branch、runtime、権限などの現在の制約
• build、test、curl、スクリーンショット、diff など、何を証拠とみなすか
• 単独実行を望むのか、マルチエージェント分解を望むのか

この文脈がないと、skill が強まるのは圧力や冗長さだけで、成果の改善につながらないことがあります。

pua skill 向けにより良いプロンプトを書く方法

弱いプロンプトの例はこうです。「Use pua and fix this.」
より強い pua guide 風のプロンプトなら、たとえば次のようになります。「Use pua on this failing API route. We already tried two fixes and both broke auth. Root-cause it, verify with the project test command, check similar routes for the same defect class, and do not mark done without evidence.」

このプロンプトが機能しやすいのは、失敗履歴、対象範囲、期待動作、検証要件をきちんと渡しているからです。どれも、この skill が強制力を持って扱うよう設計されている要素です。

曖昧な目標を実効性のある pua skill 利用に変える方法

もし目標が「デプロイを通したい」のように粗いなら、次の形に分解してください。

1. 対象環境と失敗症状
2. すでに試したこと
3. 変更できない境界条件
4. 成功の証拠
5. 周辺リスクまで見るべきかどうか

ここが重要なのは、pua が単に最初に見えた問題を直すだけでなく、類似モジュールの確認や下流への影響チェックといった、より広いクローズまで明示的に評価するからです。

pua skill はタスク種別ごとにどうルーティングするか

この skill は、手法選択にかなり強い癖があります。デバッグでは root-cause 分析や敵対的な観点の分析に寄りやすく、機能実装では簡素化と出荷圧を重視し、レビューではセンスや削減の方向へシフトします。ここはリポジトリの中でも見落とされがちですが、かなり有用な部分です。単なる汎用の「厳しくやれ」系 system prompt を流用せず、あえて pua を入れる理由になります。

チームモデルが pua skill の使い方をどう変えるか

pua for Workflow Automation がより魅力的になるのは、マルチエージェント構成で使う場合です。リポジトリには P10 から P7 までの4層チームモデルがあり、P8 が自分で処理すべき場面と、P7 スタイルの sub-agent を立てるべき場面が明確に整理されています。チャット欄で単一のアシスタントしか使わないなら、この部分の重要度は下がります。

完了前に pua skill が求める品質シグナル

この skill は、観測可能なクローズを強く優先します。たとえば build/test の通過、health check、直接検証、影響範囲のスキャンです。もし実行環境でコマンドが走らない、あるいは証拠を出せないなら、pua の価値は弱まりやすいと考えてください。というのも、この skill の規律の大部分は、クローズドループなしの「done」を拒否する姿勢から生まれているためです。

pua skill の導入判断に関する実践的なセットアップ注意点

SKILL.md からは明確な install コマンドが前面には出てこないため、pua install を判断するときは、パッケージの導入手順そのものよりも、ホスト側が skill loading と ~/.pua/config.json、~/.pua/evolution.md のような任意のユーザーレベル状態を扱えるかを見るべきです。プラットフォームがセッション状態の注入やローカルファイルの永続化に対応していないなら、高度な pua skill の挙動の一部は実現されません。

pua skill FAQ

pua skill は初心者にも向いているか

基本的には向いていません。pua skill は、強い叱責調の言い回しに耐えられること、そして高圧な指示を自分で解釈できることを前提にしています。初心者に必要なのは、圧力よりも明快さや足場づくりであることが多いです。

pua skill はトーンだけのものか

いいえ。目に見えやすいのはトーンですが、本質的な価値は実行規律にあります。methodology routing、エスカレーション閾値、検証への圧力、明示的なチームプロトコルが核です。行動モデルを削って声色だけ残すと、実務上の価値の大半は失われます。

pua skill を使わないほうがいい場面

pua は、感情面で繊細な文脈、やわらかいコーチング、ユーザー向けサポート文面、中立的なコミュニケーションが必要なチームには使わないでください。また、タスクが小さく、範囲も十分に切れている場合も不向きです。フレームワークのほうが仕事そのものより重くなることがあります。

「もっと頑張れ」とモデルに言うのと pua skill は何が違うか

一般的な「try harder」は強度を上げるだけで、通常は手法をどうルーティングするか、いつエスカレーションするか、どんな証拠を集めるか、sub-agent をどう連携させるかまでは定義しません。pua usage はそこがより構造化されています。特に reference protocols まで読むと、その差ははっきりします。

pua skill はコーディング専用か

いいえ。リポジトリには、コード、設定、デバッグ、デプロイ、リサーチのユースケースが含まれています。それでも最も説得力があるのは、客観的なチェックが置けるタスクです。そこでこそ、この skill の「最後まで閉じる」志向が測定可能になるからです。

corporate-style の flavor pack なしでも pua skill は使えるか

一部は可能です。flavor 関連の素材を大半無視しても、ワークフロー上の考え方から得られるものはあります。ただし、この skill は flavor selection をかなり深く前提に組まれているため、その枠組み自体が合わない人は、pua skill を丸ごと採用するより、protocols だけ抜き出して使うほうが向いているかもしれません。

pua skill を改善する方法

pua skill にもっと厳密な definition of done を与える

pua の結果を最短で改善する方法は、完了条件を測定可能な形で指定することです。たとえば「tests pass」「endpoint returns 200」「migration is reversible」「同種の bug pattern がないか似た handler も確認する」といった指定です。これは、この skill にもともと組み込まれている検証志向と、広めのクローズ志向にきれいに合います。

現在の問題だけでなく失敗履歴も渡す

pua はトリガー認識型なので、何がすでに失敗したかを明示すると使い勝手が上がります。「これで3回目」「前回の patch で auth が壊れた」「staging でしか再現しない」といった情報があると、エスカレーションや仮説選定の精度が上がります。

用途に合った reference file を読む

毎回すべての references を読む必要はありません。デバッグなら methodology routing と検証関連の reference を優先してください。マルチエージェント作業なら skills/pua/references/agent-team.md を最優先で見れば十分です。トーン調整なら skills/pua/references/flavors.md、長期的な個人ワークフローなら skills/pua/references/evolution-protocol.md が役立ちます。

自信ではなく証拠の多い出力を要求する

よくある失敗は、圧の強い言い回しだけ増えて、推論の質が上がらないことです。これを防ぐには、実行したコマンド、棄却した仮説、確認したファイル、周辺リスクのスキャン結果を出すよう求めてください。そうすれば pua skill は、声量の大きい説明ではなく、目に見える作業を出すようになります。

小さなタスクでは pua skill の適用範囲を絞る

もう一つの失敗パターンは、単純な作業を過剰処理してしまうことです。1行修正やごく軽い編集なら、フルのバナー、ロールプレイ、チーム構成までは求めず、pua の規律だけを使うのが適切です。リポジトリ自体も、タスクの複雑さに応じて出力密度を変える前提なので、それに合わせるほうが芝居がかった挙動にならず実用的です。

最初の pua skill 出力のあとに調整をかける

最初の回答がパフォーマンス過剰に見えるなら、指示を締めてください。スローガンを減らし、root-cause analysis を増やし、検証を強め、代替案の明示比較を求めると改善しやすいです。逆に狭すぎるなら、類似モジュール、upstream/downstream への影響、抜けている edge case まで見るよう指示します。これは、この skill が促す「氷山の下のさらに氷山を見る」タイプの思考に沿っています。

pua skill を自分の環境に合わせて調整する

リポジトリでは、~/.pua/config.json によるローカル設定と、~/.pua/evolution.md による永続ベースライン状態が示唆されています。ホストが対応しているなら、好みの flavor を定義し、うまくいった検証パターンを保存しておくとよいでしょう。そうすることで pua for Workflow Automation は、毎回ゼロから立ち上げるのではなく、セッションをまたいで一貫して機能しやすくなります。

pua skill 導入で本当に問うべきこと

本当の導入判断は、「pua は賢いか」ではなく、「自分のワークフローでエージェントの説明責任を測定可能なレベルで高めるか」です。より強いオーナーシップ、より体系的な検証、よりよいエスカレーション規律が必要なら、pua には相応の構造があります。単に感じのよいコーディング相棒が欲しいだけなら、もっと軽いものを選ぶほうが適しています。