p7

p7 skill の概要

p7 skill は何のためのものか

p7 skill は、コード作業向けのシニアエンジニア実行モードです。スコープが明確な実装タスクを受け取り、まず解決方針を設計し、影響範囲を見立て、そのうえでコードを書き、最後に短い自己レビューで締める前提で設計されています。端的に言えば、p7 skill は、ただ「コードを書いて」で終わる生の Code Generation ではなく、より規律ある手順で進めたいときに向く skill です。

p7 skill はどんな人に向いているか

p7 は、すでにタスクオーナーやアーキテクチャの方向性、あるいは親エージェントが存在しており、定義済みのサブタスクを確実に実行してくれる担当が必要なユーザーに向いています。特に、マルチエージェントのワークフローで動いている場合や、編集前に明示的な計画を挟む Code Generation を求める場合に相性がいいです。

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

p7 を検討する多くのユーザーが減らしたいのは、実装時の当てずっぽうです。価値は単にコードを出力することだけではありません。p7 skill の役割は、境界が明確な依頼を実行案に落とし込み、想定される影響を考え、実装し、その結果を短い自己チェックで圧縮して点検することにあります。

p7 skill が通常のコーディングプロンプトと違う点

最大の違いはワークフローの形です。p7 は、広く自律的に設計を主導するアーキテクトとしては説明されていません。P8 の監督下で動く実行役であり、ソリューション主導の進め方と、完了時の決まった出力形式を持ちます。そのため、汎用的な「この機能を作って」プロンプトよりは構造化されている一方で、上位の計画エージェントよりは役割が絞られています。

リポジトリから実際に分かること

リポジトリ上の根拠は最小限ですが、内容は明確です。SKILL.md には役割、トリガーフレーズ、期待される出力、そして外部プロトコルファイルへの参照が定義されています。導入判断の観点では、p7 skill は短時間で把握しやすい一方、運用上の詳細はより広い /pua システムや参照先プロトコルに依存する部分があります。

p7 skill がハマるケース・ハマらないケース

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

• 実装と理由づけを、決まった順番で進めたい
• タスクをサブタスクとして委譲できる
• コード変更前に影響分析を重視したい

逆に p7 を見送るべきなのは、次のようなケースです。

• まずプロダクトの切り分けやアーキテクチャの主導が必要
• 広く探索するブレインストーミングが欲しい
• サブタスクを明確に定義できるだけの前提情報が足りない

p7 skill の使い方

p7 skill をインストールする

実用的なインストール手順は次のとおりです。

npx skills add tanweai/pua --skill p7

インストール後は、環境がリポジトリ構成を反映しているなら skills/p7/SKILL.md を開いて確認します。あるいは GitHub リポジトリ内の skills/p7/SKILL.md を直接見ても構いません。

最初に読むべきファイル

p7 skill では、次の順番で読むのが最も効率的です。

1. skills/p7/SKILL.md
2. 環境内で参照できるなら、リポジトリレベルの /pua コア skill
3. インストール後にローカルに存在する場合は references/p7-protocol.md

これが重要な理由は、SKILL.md 自体は短く、重要な挙動をプロトコルと /pua コアのルールに委ねているためです。先頭のファイルだけを流し見すると、実行上の制約を見落としやすくなります。

実運用で p7 skill がどう起動されるか

ソースでは、ユーザーが P7模式 や 方案驱动 のようなフレーズを使ったとき、あるいは P8 がサブタスク実行役として p7 を起動したときに利用されると明記されています。実際には、p7 skill を使う際はモード名を明示し、自由度の高い戦略相談ではなく、境界のある実装タスクを与えるのが基本です。

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

p7 は、依頼に次の情報が含まれていると最も力を発揮します。

• 対象のリポジトリ、またはコードの範囲
• 実装したい機能、修正、リファクタの正確な目標
• 言語、フレームワーク、スタイル、触れてはいけない領域などの制約
• 期待する出力の形
• 影響分析で確認してほしいリスク

これらが抜けていても p7 は応答できますが、「ソリューション主導」の工程は抽象的になり、実用性が落ちます。

曖昧な依頼を強い p7 skill プロンプトに変える

弱い入力:

• “Use p7 to improve auth.”

より強い入力:

• “Use p7 for Code Generation on the login flow. In a Next.js app, add refresh-token rotation for existing JWT auth. Do not change database schema unless necessary. First propose the implementation plan and impact analysis, then implement server and client changes, then finish with a 3-question self-review.”

後者のほうが p7 skill の使い方として優れているのは、対象範囲、技術スタック、制約、出力順序が明確だからです。

実践的な p7 skill ワークフロー

おすすめの進め方は次のとおりです。

1. サブタスクを狭く定義する
2. まず p7 に実装計画を出させる
3. 影響分析を見て、危険な前提がないか確認する
4. スコープを確定、または調整する
5. p7 にコード生成を進めさせる
6. 最後の自己レビューを見て、抜け漏れ、退行、不明点を確認する

いきなりコードを要求するよりも、この流れのほうが skill 本来の価値に沿っています。

期待される出力パターン

リポジトリの説明によると、p7 の出力は次の構成です。

• implementation plan
• code
• 3-question self-review
• [P7-COMPLETION] 経由での完了通知

ツール側が構造化されたエージェント引き継ぎに対応しているなら、この完了マーカーは維持してください。対応していない場合でも、同じ内容ブロックを要求しておくと、skill の本来のプロトコルからズレにくくなります。

Code Generation で p7 skill を使うべき場面

Code Generation において p7 skill が特に強いのは、設計判断が実装品質を左右するタスクです。たとえば、複数ファイルにまたがる編集、下流への影響を伴う挙動変更、隣接モジュールを壊しうるリファクタなどです。反対に、1 行だけの軽微な修正では、計画フェーズのオーバーヘッドに見合わないことがあります。

p7 skill 導入前に見ておきたい注意点

導入時のつまずきどころは主に 2 つあります。

• 一部のプロトコル詳細が SKILL.md に埋め込まれておらず、参照形式になっている
• p7 が /pua エコシステム全体の用語や、コアのガードレール、ナレーションプロトコルに依存している

そのため、完全に自己完結した skill を期待していると、親システムの文脈も読み込まない限り、p7 は情報不足に感じる可能性があります。

p7 skill の初回実行品質をどう見極めるか

初回実行では、p7 が次を満たしているか確認してください。

• 計画と実装を分けている
• 影響を受けるファイル、モジュール、インターフェースを特定している
• 指定した制約を守っている
• 儀式的なチェックリストではなく、意味のある自己レビューで終えている

これらが欠けている場合、呼び出し方か実行環境が、skill の想定どおりに読み込まれていない可能性が高いです。

p7 skill の FAQ

p7 skill は初心者向けか

中程度です。p7 skill 自体の考え方は理解しやすいものの、まったくの初心者に教える用途に最適化されているわけではありません。タスクを切り出し、実装計画をレビューし、影響分析が妥当かどうかを判断できることが前提になります。

P8 なしでも p7 skill は使えるか

使えますが、限界はあります。ソース上では p7 は P8 の監督下に置かれているため、理想的な使い方は委譲先の実行役です。それでも、明確に境界を切ったサブタスクと明示的な制約を与えることで、単体利用は可能です。ただし、上位のオーケストレーションまで期待するべきではありません。

通常のプロンプトより p7 skill が優れるのはいつか

定義済みのエンジニアリングタスクを、規律ある手順で進めたいときです。「まず計画、次に実装、最後にレビュー」という流れが有効な作業では、p7 skill は通常のプロンプトが飛ばしがちな構造を補ってくれます。

p7 skill を使わないほうがよいのはいつか

次のような用途には p7 を使わないほうがよいです。

• 曖昧なプロダクト企画の発想出し
• 要件が固まっていない状態での広いアーキテクチャ選定
• 読み込んでいない repo 固有プロトコル知識が大量に必要なタスク
• 構造化された計画が遅延だけ増やし、品質向上が小さい単純修正

p7 skill にはインストールスクリプトや追加リソースが含まれるか

確認できるリポジトリ情報の範囲では、skill ディレクトリ表示上に追加スクリプトや同梱サポートファイルは見当たりません。中心となるのは SKILL.md で、そこから references/p7-protocol.md が参照されています。インストール後の環境にそのファイルが存在するかは必ず確認してください。

p7 skill は出力形式にこだわりがあるか

あります。skill の説明では、定義済みの完了ラッパーと、特定の成果物の順序が示されています。これはエージェント出力を揃えたいチームには適していますが、自由形式の会話的コーディングを好む場合にはやや不向きです。

p7 skill を改善する方法

p7 skill にはっきりしたサブタスク境界を与える

p7 の結果を最も手早く改善する方法は、タスクを狭めることです。「payments をリファクタして」ではなく、対象の endpoint、component、module、あるいは障害モードまで指定してください。p7 skill は実行役なので、境界が明確なほど Code Generation の質が上がります。

p7 skill の影響分析で見るべき対象を明示する

単に「impact analysis をして」と頼むだけでは不十分です。何を確認すべきかを具体的に指定してください。

• API compatibility
• schema changes
• test impact
• performance risk
• migration needs
• rollback concerns

こうすることで、p7 skill の計画フェーズは実質的にもっと役立つものになります。

p7 skill にリポジトリの手がかりを最初から渡す

触る可能性が高いファイルが分かっているなら、先に伝えてください。例:

• src/auth/session.ts
• app/api/login/route.ts
• tests/auth.spec.ts

これにより無駄な探索が減り、どこを触るべきかが品質を左右する大きめのリポジトリでも、p7 skill の使い勝手が上がります。

文脈が薄いなら、コードの前に前提条件を出させる

よくある失敗は、情報が薄いまま実装に突入してしまうことです。ブリーフが不完全なら、p7 にこう伝えてください。“List assumptions and blockers before coding.” これで、低確度の出力を無理に出させず、skill のソリューション主導という性格を保てます。

p7 skill の自己レビューを改善サイクルに使う

3 問の自己レビューは飾りとして扱わないでください。次の観点で読みます。

• 隠れた前提
• エッジケース対応の不足
• 欠けているテストや検証手順

見つかったギャップは、2 回目の p7 実行に戻してください。skill 自体を変えずに p7 を改善する、最も簡単な方法のひとつです。

受け入れ条件を入れて p7 skill プロンプトを強くする

Code Generation 向けに p7 の精度を上げたいなら、成功条件を含めてください。たとえば次のような条件です。

• “existing tests must still pass”
• “no breaking API changes”
• “support both mobile and desktop UI”
• “keep public function signatures stable”

受け入れ条件を入れることで、p7 skill は「書けるコーダー」から、より信頼できる実行役に近づきます。

p7 skill で早めに検出したい典型的な失敗

次の兆候には注意してください。

• 実装を動かすには抽象的すぎる計画
• 明示した制約を無視するコード
• 現実のトレードオフに触れない自己レビュー
• 提供していない親システム文脈を前提にした解決策

こうした問題はたいてい、p7 skill が使えないというより、プロンプト品質やコンテキスト読み込みの問題です。

skill としての p7 skill はどう改善できるか

p7 skill は、リポジトリ側でプロトコルの内容をもう少しインラインに公開するか、skill フォルダ内の補助ファイルへより直接リンクしていれば、導入しやすさが上がります。呼び出し例、期待される完了構造、単体利用の例があれば、新規ユーザーのセットアップ負荷もさらに下がるはずです。