p9

p9スキルの概要

p9は何に使うスキルか

p9は、Agent Orchestrationのためのテックリード型スキルです。自分で直接コードを書くのではなく、プロジェクトの目標を他のエージェント向けの実行プロンプトへ落とし込みます。特にP8チームを動かす前提で設計されています。p9の中核となる役割は委譲です。スコープを明確にし、作業を分割し、担当を割り当て、実装そのものではなくプロンプトを通じてデリバリーを前進させます。

p9が向いているユーザー

p9は、複数のエージェントを調整したいとき、大きめの機能開発を管理したいとき、あるいは実行前にタスクをきれいに分解しておきたいときに向いています。コーディングエージェントの上位にある計画・オーケストレーション層を求める人には適していますが、コード生成そのものを期待する人向けではありません。

p9が実際に解決する課題

p9の実用的な価値は、1つのプロンプトや1体のエージェントでは扱い切れない大きなタスクで起きがちな混乱を減らせる点にあります。依頼を並行トラックに分けたい、引き継ぎポイントを明確にしたい、成果物の形式や制約についてチームの足並みをそろえたい、といった場面では、普通の「このプロジェクトを計画して」というプロンプトよりも、p9のほうが強い初期構造を作れます。

p9が他と違うポイント

差別化の核は、役割の厳密さにあります。p9スキルは明確にマネージャーモードに徹し、自分で実装するのではなく、タスク用プロンプトを書いてP8エージェントを調整します。この境界が重要です。計画がぶれにくくなり、その後の委譲内容も監査しやすくなります。

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

このスキル自体はリポジトリ内では軽量です。公開されている SKILL.md には、references/p9-protocol.md や references/agent-team.md など追加のプロトコル文書への参照がありますが、提供されたツリースナップショットにはそれらのファイルが含まれていません。つまり、p9の役割は大枠では理解できますが、実行時の細かな挙動は、より広い tanweai/pua システムや中核の /pua スキルに依存している可能性があります。

p9スキルの使い方

p9のインストール前提

このリポジトリ系で使われる基本のインストールコマンドは次のとおりです。

npx skills add tanweai/pua --skill p9

p9は共有の /pua 規約に依存しているように見えるため、完全に独立したプロンプトファイルというより、より大きなスキルシステムの一部として扱うのが適切です。

最初に読むべきファイル

まずは次を確認します。

• skills/p9/SKILL.md

そのうえで、スキル内から参照されている共有挙動や不足しているプロトコル文書を、親リポジトリ側でも確認してください。

• core /pua skill instructions
• references/p9-protocol.md
• references/agent-team.md

インストール環境でこれらの補助ファイルが参照できない場合は、ワークフローの一部を自分で補って組み立てる必要があります。

p9に渡すべき入力

p9は、単なる機能要望よりも、オーケストレーション前提の入力を与えたときに真価を発揮します。たとえば次の情報が有効です。

• プロダクトやリポジトリの目標
• 現在のプロジェクト状況
• 利用可能なチーム構成やエージェントの役割
• 締切、技術スタック、リスク許容度、レビュー基準などの制約
• 並列化したい作業と順番に進めるべき作業
• 期待する成果物

こうした情報がなくてもp9は作業分解自体はできますが、出てくるタスクプロンプトはどうしても汎用的になります。

ラフな目標をp9向けの依頼に変える

弱い入力例:

Build user auth for my app.

p9を活かした、より良い依頼例:

Use p9 for Agent Orchestration. We need to add email/password auth to a Next.js app with Prisma and PostgreSQL. We have 3 implementation agents available. Split work into parallel tracks where safe, define dependencies, create task prompts for each agent, and include acceptance criteria, shared constraints, and integration checkpoints.

後者のように書くと、p9は単に機能要件を言い換えるのではなく、実際に作業を割り当てられるだけの構造を持った出力を返しやすくなります。

p9が出力すべき内容

良いp9の出力には、少なくとも次が含まれているべきです。

• スコープが明確な目的
• タスク分解
• 役割またはエージェントへの割り当て
• 各下流エージェントがそのまま使えるプロンプト
• 制約条件と品質基準
• 統合のためのチェックポイント

元の記述でも “Task Prompts” と “P8 team delivery” が明示されているため、評価基準は「p9自身が課題を解いたか」ではなく、「他者が実行できるプロンプトを作れたか」で見るべきです。

p9を使うベストな進め方

実務上は、次の流れが使いやすいです。

1. プロジェクト目標と運用上の制約をp9に渡す。
2. 作業ストリームと依存関係を洗い出させる。
3. エージェント別のタスクプロンプトを作らせる。
4. 受け入れ条件の抜け、責任の空白、統合リスクがないかレビューする。
5. そのプロンプトをP8系の実行エージェントなど、コーディング担当に渡す。
6. 結果をp9に戻し、整合調整・優先順位の見直し・次の計画立案をさせる。

ここが、一般的な計画プロンプトよりp9が強いポイントです。p9は実行エージェントの上に立つことを前提にしています。

コーディングスキルではなくp9を呼ぶべき場面

p9を使うべきなのは、次のようなケースです。

• 作業が複数ファイルや複数システムにまたがる
• 複数のエージェントを並行稼働させたい
• 引き継ぎ設計が重要
• プロジェクトに順序設計と監督が必要
• 主な課題が実装力ではなく、曖昧さ・調整・プロンプト設計にある

一方で、小さなパッチを1体のエージェントに素早く書かせたいだけなら、p9は向きません。

p9スキルで使いやすい実践プロンプト

安定して使いやすいテンプレートは次のとおりです。

Use p9 skill as tech lead. Do not write code. Break this goal into agent-executable task prompts for a P8 team. Include scope, owner, inputs, outputs, constraints, dependencies, and acceptance criteria. Goal: ... Context: ... Available agents: ... Constraints: ... Done means: ...

このプロンプトは、SKILL.md に書かれているp9の核となる振る舞い、つまりマネージャーモード・プロンプト作成・直接コーディングしないことを強く補強します。

導入判断に影響する制約

導入時の最大の注意点は、隠れたプロトコル依存です。SKILL.md は外部文書や core /pua の挙動モデルを参照しており、その中には “three red lines” や narration protocol も含まれますが、ここでは詳細が見えません。プラットフォーム側が単一のスキルファイルしか取り込まない場合は、委譲品質・エスカレーション・安全性について、自前の運用ルールを決める必要があります。

最初の実行後に確認したいこと

p9が計画を出したあと、次を確認してください。

• 各タスクに明確な担当があるか
• 依存関係が明示されているか
• 共通の制約が各サブプロンプトにも繰り返し入っているか
• 統合とテストが宙に浮いていないか
• どこかのタスクで誤ってp9自身にコーディングをさせていないか

これらの確認は出力品質を実際に大きく左右します。オーケストレーションの失敗は、高レベルの計画不足よりも、曖昧な引き継ぎで起きることが多いためです。

p9スキルのFAQ

p9はコーディングスキルですか？

いいえ。p9スキルは明確にマネージャー、またはテックリードモードとして位置づけられています。コードを実装するのではなく、プロンプトを書き、P8チームを管理する役割です。

p9は初心者にも向いていますか？

はい。課題がコーディング文法ではなく調整や段取りにあるなら有効です。ただし初心者は、p9が実装の近道ではないことを理解しておく必要があります。実際に手を動かす下流エージェント、または自分自身の実行フローは別途必要です。

普通の計画プロンプトよりp9が優れるのはどんなとき？

再利用できるタスクプロンプト、役割分離、複数エージェントの調整が必要なときです。通常のプロンプトでも計画は出せますが、p9は委譲可能な実行単位を作ることに重心があります。

p9を使わないほうがいいのはいつですか？

小さく自己完結した作業、急ぎの1ファイル修正、あるいは強いコーディングエージェント1体でマネージャー層を挟むより早く終わるケースでは、p9は省いたほうが効率的です。

p9はPUAの外でも使えますか？

部分的には使えます。高レベルのオーケストレーションという発想自体は移植可能です。ただし、このスキルはP8エージェントと /pua の中核ルールを前提にしているように見えるため、別のエージェント構成で使う場合は調整が必要です。

「p9 for Agent Orchestration」とは結局どういう意味ですか？

p9が最も力を発揮するのは、実行エージェントの上に立つ調整レイヤーとして使うとき、という意味です。価値の中心は単純な生成能力ではなく、より明確なプロンプト、よりきれいな役割分担、より制御しやすいマルチエージェントの進行を作れることにあります。

p9スキルを改善する方法

p9には意思決定できるレベルの文脈を渡す

p9の出力を最も手早く改善する方法は、テックリードが確認したがる管理情報を最初から渡すことです。たとえば、スコープ、リスク、アーキテクチャ、利用可能なエージェント、締切、譲れない制約などです。調整課題が具体的になるほど、p9の出力も強くなります。

明示的なタスクプロンプト項目を要求する

最初の出力がぼんやりしているなら、委譲タスクごとに固定スキーマを使うよう求めてください。たとえば次のような項目です。

• objective
• owner
• inputs
• required files
• implementation constraints
• deliverable
• acceptance criteria
• dependency notes

これにより、p9は単なる「計画係」ではなく、「プロンプトを梱包して渡す役」に変わります。

代表的な失敗パターンを防ぐ

最もよくある失敗は、分解が浅いことです。見た目は整理されていても、各タスクが実行可能になっていません。これを避けるには、追加説明なしで別のエージェントがそのまま着手できるレベルまで、各タスクを独立して行動可能にするようp9へ求めてください。

制約を増やしてp9の使い方を改善する

追加すると有効な制約には、次のようなものがあります。

• スタックやフレームワークのバージョン
• 対象となるファイルやディレクトリ
• コーディング標準
• テスト要件
• レビューの関門
• 変更してはいけないもの

こうした情報があると、下流エージェントごとの解釈差による手戻りを減らせます。

分解だけでなく統合面も反復する

p9がタスクプロンプトを作成したあと、次のような第二段階の問いを投げると効果的です。

Review this plan for integration risk, duplicated work, hidden dependencies, and missing validation steps.

実際のデリバリー品質は、分解をさらに細かくするよりも、この見直しで良くなることが少なくありません。

補助リファレンスがない場合はp9をローカル運用に合わせて補う

参照されているプロトコルファイルが利用できない場合は、p9を本格運用する前にローカルルールを定義しておくと扱いやすくなります。

• p9 never writes production code
• every delegated task must include acceptance criteria
• one task owns integration
• one task owns verification
• unresolved dependencies must be surfaced early

こうした補完をしておくことで、完全なリポジトリ文脈がなくても、p9スキルをより実用的に使えるようになります。