mcpField
U
utility-pm-workflow-builder

utility-pm-workflow-builder

github.com/product-on-purposeエージェントワークフロー769489 回インストール4 日前に更新
リポジトリ

utility-pm-workflow-builder について

PM-skills の貢献者向けに、複数スキルのワークフローとレビュー資料を作成するスキルです。既存ワークフローとの重複やステップの妥当性を確認し、実行や公開はせずに成果物をステージングします。

主な機能

  1. 01ワークフローとコマンドの草案作成
  2. 02既存ワークフローとの重複分析
  3. 03ステップに使うスキルの検証
  4. 04ステップ間の引き継ぎ内容の定義
  5. 05公開チェックリストの作成

活用シーン

  1. 01反復する PM プロセスのワークフロー化
  2. 02実証済みスキルチェーンの再利用

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/product-on-purpose/pm-skills --skill utility-pm-workflow-builder

インストール後、Claude Code で/utility-pm-workflow-builderを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

HISTORY.md
evals/
trigger-fixtures.json
references/
EXAMPLE.md
TEMPLATE.md

詳細

PM ワークフロービルダー

このスキルは、pm-skills ライブラリ用の新しいマルチスキルワークフローを作成します。Workflow Implementation Packet を作成します。内容は、ステージング領域に用意する _workflows/<name>.md のドラフトファイル、commands/workflow-<name>.md コマンドのドラフト、および横断的な更新チェックリストです。これらは正式な場所へ移す前にレビューします。ビルダーは作成のみを行い、チェーンを実行することも、自身の出力を正式な場所へ移すこともありません。

使用する場面

  • 新しいマルチスキルワークフローのアイデアがある場合(「四半期ごとの事業レビュー用のワークフローが必要です」)
  • チェーン化したいスキルが決まっていて、それを永続的に記録したい場合(「competitive-analysis、experiment-results、pivot-decision をチェーン化する」)
  • /chain の実行(オーケストレーターの Mode B)で再利用可能だと確認され、完了時の出力でチェーンを永続的なワークフローに昇格するよう提案された場合。その提案にあるチェーン式をそのままこのスキルに渡してください。

使用しない場面

  • 作成を伴わず、一度だけ一連の処理を実行する場合 → /chain コマンドまたは utility-pm-workflow-orchestrator を直接使用します。
  • 単一のスキルを作成または変更する場合 → utility-pm-skill-builder、utility-pm-skill-validate、または utility-pm-skill-iterate を使用します。
  • 既存のワークフローをカスタマイズする場合 → 対象の _workflows/<name>.md を直接編集します。以下の重複分析で、カバー範囲の重複が大きい場合はそのワークフローが案内されます。

手順

ステップ 1:アイデアを把握する

以下の 3 つの入力形式のいずれでもアイデアを受け付けます。いずれも同じ後続フローに進みます。

  • 課題起点:「X のワークフローが必要です」。繰り返し発生する PM プロセス、その実施者、残すべき成果物の記録を特定します。
  • **スキル起点:**ユーザーがすでにチェーン化したいと考えているスキルのリスト。
  • **チェーン昇格:**チェーン式をそのまま指定します(例:measure-experiment-results -> discover-stakeholder-summary)。通常はオーケストレーターの完了時の提案から貼り付けます。あわせて、その実行で使用したコンテキストも指定します。

アイデアが曖昧な場合は、確認の質問を 1 つだけしてください(繰り返しのきっかけと最終成果物について)。質問を重ねないでください。

ステップ 2:重複分析と必要性の確認

実行時に _workflows/ ディレクトリをスキャンし、現在の一覧(README.md を除くすべての *.md)を取得します。記憶している件数やハードコードされた一覧に頼らないでください。アイデアを既存のすべてのワークフローと比較します。

  • 重複する各ワークフローの名前と、その対象範囲を挙げます。
  • カバー範囲の重複度を正直に見積もります。

中止ゲート(カバー範囲の重複が 70% 超): 次の順に提案します。(a)既存のワークフローをカスタマイズする。(b)そのワークフローにステップを追加する。(c)たまの実行なら /chain を使う。ここから先には進みません。

必要性の確認(意味のある重複がある場合): 既存のワークフローでは必要な成果を出せない、具体的なシナリオを 2~3 件尋ねます。その証拠、またはユーザーによる明示的なオーバーライドがない限り、この確認を通過させないでください(オーバーライドがある場合は、パケットの Decision セクションに記録します)。

ステップ 3:シーケンスの設計

ユーザーとともにステップを選択し、順序を決めます。作成時に、チェーン式の 契約の検証ルールを適用します (skills/utility-pm-workflow-orchestrator/references/PARSE-CONTRACT.md、 Mode B Chain Expression Contract)。

  • 各ステップは、skills/<name>/SKILL.md にあるインストール済みスキルに、名前を完全一致させて解決できなければなりません。近似や自動修正は決して行わず、一致しない場合はそのステップを拒否し、最も近い実在する名前を提示します(提示のみで、置き換えはしません)。
  • カテゴリー 1 のコンテンツスキルのみ。 次のものはステップとして拒否し、それぞれについて1行で説明します:Tier-3 メンテナンススキル(utility-pm-skill-*、utility-pm-release-conductor、utility-pm-changelog-curator、utility-update-pm-skills、foundation-prioritized-action-plan)、サブエージェントに処理を振り分けるディスパッチスキル(utility-pm-critic、utility-pm-workflow-orchestrator とその同種のスキル)、既存のワークフロー(ワークフローの中に別のワークフローをネストすることはできません)。このビルダー自体が Tier-3 であるため、構造上、自己参照は不可能です。
  • 各ステップについて、引き継ぎ内容を作成します。前のステップの出力から何を受け取り、次のステップに何を渡す必要があるかを明記します。この引き継ぎガイダンスがあることで、場当たり的なチェーンとは異なる、長期にわたって使えるワークフローになります。実質的な引き継ぎがなければ、パケットは完成していません。
ステップ 4:パケットの生成

完全な Workflow Implementation Packet を _staging/workflows/<name>/(gitignore 対象。スキルビルダーと同じレビュー方式)に書き込みます。正規の場所には決して書き込みません。

_staging/workflows/<name>/
├── workflow.md      <- draft _workflows/<name>.md
├── command.md       <- draft commands/workflow-<name>.md
└── PACKET.md        <- decision, overlap analysis, checklist, promotion steps

パケットの形式には references/TEMPLATE.md を使用します。ワークフローのドラフトには、現在の _workflows/*.md ファイルに共通するセクション一式(TEMPLATE に埋め込まれたひな形を参照)をすべて含める必要があります。コマンドのドラフトは、各ステップにつき skills/<name>/SKILL.md のパスを1つそのまま記載し、末尾に $ARGUMENTS を含めるなど、既存の commands/workflow-*.md の形式に準じます。最終的なシーケンスから、線形の Mermaid コンテキストフロー図を導き出します(ノードにはステップ名、エッジには実行順序を使用)。

ステップ 5:レビューと昇格の案内

パケットを提示して終了します。ビルダー自体が昇格を行うことはありません。承認後、ユーザー(または後続のセッション)がドラフトを正規のパスに移動し、ワークフローの追加によって影響を受けるすべての件数とドキュメントの対象箇所を記載した、パケットの Cross-Cutting Checklist に沿って作業します。これには、バリデーターでは検出されない .github/workflows/release.yml のリリースノートテンプレートも含まれます。ビルダーがこれらの横断的なファイルを編集することはありません。

出力形式

パケットは references/TEMPLATE.md に従います。

  1. Decision - 推奨事項と Why Gate の根拠(または記録された例外)
  2. Overlap Analysis - 重複するすべてのワークフロー、それぞれの対象範囲、ギャップ
  3. Workflow Draft - _workflows/<name>.md の完全な内容
  4. Command Draft - commands/workflow-<name>.md の完全な内容
  5. Cross-Cutting Checklist - 昇格時に更新するすべての対象箇所と、それを適用するバリデーター(存在しない場合は「validator-blind」)
  6. Promotion Steps - 移動、検証、バリデーションの手順

完全なパケットの作成例については、references/EXAMPLE.md を参照してください。

品質チェックリスト

パケットを提示する前に、次の項目を確認してください。

  • 重複分析では、ライブの _workflows/ ディレクトリをスキャンしています(記憶したリストやハードコードされた件数は使っていません)
  • Why Gate の根拠が具体的なシナリオで示されているか、明示的なオーバーライドが記録されています
  • すべてのステップが、完全一致する名前のインストール済みスキルに対応しています
  • Tier-3 のメンテナンススキル、ディスパッチスキル、ワークフローがステップに含まれていません
  • すべてのステップに、スキル名だけでなく、作成者が記述した引き継ぎ内容(消費するもの/生成するもの)があります
  • ワークフロードラフトに、TEMPLATE の骨格にあるすべてのセクション(メタデータ表、Do NOT use を含む When to Use、各ステップのブロック、コンテキストフロー図、ヒント、品質チェックリスト、関連項目)が含まれています
  • コマンドドラフトに各ステップの skills/<name>/SKILL.md パスが記載され、末尾に $ARGUMENTS フッターがあります
  • mermaid 図が最終的な順序と完全に一致しています
  • すべて _staging/workflows/<name>/ の下に作成されており、正規のパスには触れていません
  • .github/workflows/release.yml のリリースノートの行を含む、Cross-Cutting Checklist 全体が再掲されています

参考ファイル

コメント