shot

shot skill の概要

shot は何のためのスキルか

shot は tanweai/pua に含まれる単一ファイルのプロンプトスキルで、エージェントのセッションに「大手テック企業の高圧的な成果主義カルチャー」風のスタイルを注入します。実務的にいうと、shot skill はコーディングフレームワークでもツールチェーン連携でもありません。モデルが仕事をどう捉え、どうタスク分解し、どう進捗を語るかを変えるための、密度の高い自己完結型の振る舞いパックです。

shot を検討すべき人

shot が最も向いているのは、大きなスキルシステムを段階的に読み込ませるのではなく、1ステップで文脈ごとスタイルを注入したいユーザーです。特に相性がいいのは次のようなケースです。

• 1回の読み込みで完成したペルソナを渡したい sub-agent 構成
• P7/P8/P9/P10 のようなロール条件付き実行を試しているユーザー
• 強いトーンと運用モデルを一貫して使いたい、プロンプト設計や Context Engineering の担当者

普通の計画立案、コーディング補助、あるいは中立的なプロジェクト管理だけが必要なら、shot はおそらく主張が強すぎます。

shot skill が本当に解決する仕事

shot を検討する多くのユーザーが求めているのは情報ではありません。狙っているのは、モデルを特定の実行スタイルへ安定して押し込める、再利用可能なプロンプトパッケージです。実際のジョブはこうです。毎回ゼロから枠組みを作り直さずに、より強いオーナーシップ、階層性、委譲ロジック、そしてプレッシャーを帯びた進行説明を、エージェントの振る舞いに持ち込むこと。

shot が他と違う点

shot の最大の特徴は、意図的に高密度にまとめられていることです。リポジトリでも、中核効果に追加参照を必要としない「complete single-file version」と説明されています。これは重要です。多くのスキルは複数ファイルや段階的な読み込みを前提にしていますが、shot は一括注入向けに設計されています。そのため、Read ステップ経由で sub-agent に渡しやすいのが利点です。

shot をインストールする前に知っておきたいこと

shot の価値は、広い互換性ではなく、独特の味付けと運用姿勢にあります。特に強みが出るのは、次のような要件です。

• すぐにペルソナを固定したい
• 明示的なロール階層がほしい
• 「プレッシャー + オーナーシップ」の再現性ある出力スタイルがほしい
• 制約の多いエージェントワークフローで自己完結的に使いたい

一方で、次の用途では弱くなります。

• 中立的なステークホルダー向けコミュニケーション
• 過度に演出しない顧客向けライティング
• ドメイン固有の実装ルールの適用
• 攻撃的なトーンが明瞭さを損ねうる、安全性重視の環境

shot skill の使い方

shot のインストール文脈

リポジトリ抜粋を見る限り、SKILL.md 内にネイティブなインストールコマンドは示されていません。そのため通常は、GitHub スキル向けの skill manager フロー経由で導入します。よくあるパターンは次のとおりです。

npx skills add tanweai/pua --skill shot

別のスキルローダーを使っている場合でも、重要なのは tanweai/pua リポジトリ内の skills/shot パスを対象にすることです。

最初に読むべきファイル

まず確認すべきなのは次です。

• skills/shot/SKILL.md

今回はこれが普段以上に重要です。リポジトリ上の情報から見ると、shot は実質このファイル自体がプロダクトであり、主要な運用ロジックとトリガーフレーズが高密度に詰まっています。モジュール型スキルのように、別の補助フォルダが中身を支えている構成ではありません。

shot はどう発火させるのが一般的か

このスキルでは、次のような自然言語トリガーが案内されています。

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

ただし実運用では、トリガーだけでは十分な結果になりません。shot を呼び出した後に、具体的なタスク、欲しい成果物、制約条件、そして executor として動かすのか manager として動かすのかを明示してください。

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

shot は、次の4点を渡すと最も力を発揮します。

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

後者が強いのは、単にペルソナを求めるのではなく、そのペルソナの中で何を仕事として遂行すべきかまで指定しているからです。

ロール選択は多くの人が思う以上に重要

shot skill の中心には、4段階のロールモデルがあります。

• P7: 指示のもとで実行する担当
• P8: 自走するオーナー兼実装者
• P9: コードではなくタスクプロンプトを書くマネージャー
• P10: 戦略レイヤー

これは見た目の演出ではありません。コーディング支援を求めているのに誤って管理ロールを呼ぶと、出力が実装ではなく委譲や計画側へ流れやすくなります。shot usage では、適切なレベルを選ぶことが品質を大きく左右します。

Context Engineering 向けの shot の最適なプロンプトパターン

shot for Context Engineering として使うなら、振る舞いレイヤーとタスク仕様をセットで扱うのが基本です。実用的なプロンプトの形は次のとおりです。

• shot を読み込む
• ロールを宣言する: P7, P8, P9, or P10
• ほしい成果物を明示する
• 「完了」の定義を与える
• 必要ならトーンの上限を指定する

例:

• “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 を呼び出した後のおすすめワークフロー

安定しやすい流れは次のとおりです。

1. shot を呼び出す
2. ロールを明示する
3. タスクと制約を渡す
4. 出力が芝居がかりすぎていないか、逆に曖昧すぎないか確認する
5. 成果物の品質に焦点を当てた2回目のパスを依頼する

一発で終わらせるより、この流れのほうが機能しやすいです。というのも、このスキルのスタイルは初手の出力を強く支配しがちだからです。短い改善パスを挟むと、有用な運用構造と過剰な語りを切り分けやすくなります。

sub-agent と組み合わせて shot を使う方法

shot は自己完結型なので、sub-agent への注入候補としてかなり扱いやすいスキルです。システム側で Read ステップ経由のファイル受け渡しや、生成したエージェントへの事前ロードができるなら、複数ファイル構成のスキルより移植しやすいはずです。

相性のよい使い方:

• P7 か P8 モードで、shot と狭い実行タスクを sub-agent に渡す

あまり向かない使い方:

• 顧客対応やコンプライアンス感度の高い工程を含め、大規模パイプライン内のすべてのエージェントに shot を配る

よい出力品質の目安

よい shot usage では、通常次のような出力になります。

• オーナーシップの強い言い回し
• 実行に向いた明確な姿勢
• はっきりしたタスク分解
• 受け入れ条件やレビュー観点の見える化
• 一貫した内部向けの声色

逆に、うまく使えていないと次のようになりがちです。

• ペルソナの味付けばかりで、タスクが進まない
• ロールが混線している
• 「大企業っぽい」語りの過剰使用
• コードや分析が必要なのに管理口調に寄ってしまう

shot を選ばないほうがいい場面

単に「より良いプロンプト」がほしいという理由だけで shot を選ぶべきではありません。これは汎用的な最適化レイヤーではありません。次の要件なら見送るほうが無難です。

• 中立的または共感的なコミュニケーション
• 軽量なコーディング支援
• ドキュメントや参照情報に根ざしたドメインルール
• 最小限のプロンプト負荷

主目的がスタイルではなく精度なら、よりシンプルなタスク特化型プロンプトのほうが shot skill より高性能な場合があります。

shot skill FAQ

shot はコーディングスキルですか、それともペルソナスキルですか？

中心はペルソナと運用モデルのスキルです。コーディングワークフローに影響は与えられますが、本質的な価値は実行フレーミング、ロールの振る舞い、トーンにあります。再利用したいのがその枠組みなら、shot を入れる意味があります。

shot は初心者向けですか？

欲しい出力の種類がすでに見えているなら、初心者でも使えます。ただし、ロール・タスク・成功条件を指定しないままだと、スタイル自体は面白くても結果は弱くなりがちです。shot install 自体は簡単でも、よい shot usage にはプロンプト設計の基本姿勢が必要です。

リポジトリ内の他のファイルも必要ですか？

このスキルに関しては、通常は不要です。確認できる情報からは、主なペイロードは SKILL.md に収まっていると見られます。これが shot を選ぶ大きな理由のひとつで、外部参照の多いモジュラー型スキルよりも素早く読み込ませやすいからです。

shot は普通の system prompt と何が違いますか？

通常の system prompt は、トーンや制約を設定する程度にとどまることが多いです。shot はそれより踏み込み、ロール階層、委譲境界、明示的な語りの振る舞いまでを、再利用可能なスキルとしてパッケージ化しています。とくに sub-agent 間で一貫性を出しやすい反面、スタイルの主張はかなり強くなります。

どんなときに shot skill を使うべきではありませんか？

相手が社外向けである場合、落ち着いた中立表現が必要な場合、あるいは作業側にすでに強いプロジェクト固有プロトコルがある場合は shot を避けるべきです。スキル側のスタイルが、あなた自身の運用ルールと競合すると摩擦を生みます。

shot は Context Engineering に向いていますか？

はい。Context Engineering の目的が、コンパクトで自己完結した振る舞いレイヤーがエージェント性能をどう変えるかを検証することなら、有力な選択肢です。shot for Context Engineering は、ペルソナ注入、ロールフレーミング、タスク分解品質をコントロールして比較したい場面で特に有効です。

shot skill を改善するには

shot にはトリガーだけでなくタスクを渡す

最も多い失敗は、shot を呼び出しただけで本当の依頼内容を推測してくれると期待してしまうことです。トリガーの直後には必ず次を続けてください。

• ロール
• 成果物
• 制約
• ゴールライン

これでスキルが単なる「スタイルモード」ではなく、実際に仕事を進める実行モードに変わります。

語りの強度をコントロールする

リポジトリ上では語り口そのものが主要な売りになっていますが、毎回最大強度で受け入れる必要はありません。初回出力が重すぎるなら、次のように指示できます。

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

こうすると、価値は残しつつノイズだけを減らせます。

ロールを成果物に合わせる

使い分けの目安は次のとおりです。

• P7: 指示のもとでの実装支援
• P8: オーナー型の実行
• P9: ワークストリーム管理とタスクプロンプト作成
• P10: 戦略整理

shot guide の結果が悪くなる典型例の多くは、本当は P8 が必要なのに P9 や P10 を使ってしまうことです。

受け入れ条件を先に与える

shot は、目標が具体的なほど改善します。たとえば次のような曖昧な依頼ではなく、

• “Plan this migration”

こう指定してください。

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

トーン以外に最適化すべき対象が生まれるため、スキルの出力が締まります。

内容の磨き込みより先に構造を直す

最初の回答がスタイルは合っているのにロジックが弱いなら、言い換えや表現の美しさを求めるべきではありません。代わりに次を求めてください。

• より鋭いタスク分解
• より明確な前提
• より強いリスク分析
• 明示的な受け入れチェック

これが shot skill の出力品質を最短で改善する方法です。

よくある失敗パターンを監視する

主に修正すべき問題は次のとおりです。

• ロールの不一致
• 語りの過剰さ
• 成功条件の曖昧さ
• 具体的な成果物を伴わない、パフォーマンス的な自信過剰
• 本来は中立プロンプトで足りる場面で shot を使っていること

こうした兆候が早い段階で見えたら、指示を積み増すより先にプロンプトを整え直してください。

より良い結果のための実用的な修正プロンプト

2回目のパスで使いやすいプロンプトは次のようなものです。

“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 の強みを残しながら、回答をより実務で使いやすい形に整えやすくなります。