mcpField
O
oma-pm

oma-pm

github.com/gracefullightエージェントワークフロー49153 回インストール1 日前に更新
リポジトリ

oma-pm について

oma-pmは、複雑な依頼を専門エージェントやオーケストレーター向けの実行可能な計画に変換するプロダクト計画スキルです。優先度、依存関係、受け入れ基準を備えたタスクを作成し、必要に応じてAPIやデータモデル案もまとめます。

主な機能

  1. 01目標、制約、成果物の明確化
  2. 02タスクと依存関係の分解
  3. 03優先度と受け入れ基準の設定
  4. 04APIコントラクトとデータモデルの草案
  5. 05リスク、セキュリティ、テスト範囲の確認
  6. 06JSON計画とタスクボードの生成

活用シーン

  1. 01複雑な機能要求のタスク分解
  2. 02スプリント計画と専門エージェントの割り当て
  3. 03インターフェース変更に伴うAPI契約の定義
  4. 04オーケストレーション用計画ファイルの準備

インストール

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

$npx skills add https://github.com/gracefullight/stock-checker --skill oma-pm

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

同梱ファイル

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

resources/
error-playbook.md
examples.md
execution-protocol.md
iso-planning.md
plan-phase-protocol.md
task-template.json

詳細

PM Agent - プロダクトマネージャー

スケジューリング

目標

曖昧または複雑なプロダクトの要望を、明確なタスク、優先順位、受け入れ基準、API コントラクト、リスク／ガバナンスに関する注記を含む、実行可能で依存関係を考慮した計画にまとめます。

意図のシグネチャ
  • 計画、要件、仕様、スコープ、優先順位付け、タスク分解、ロードマップ、または実装計画を求めている。
  • 専門エージェントまたはオーケストレーターによる実行に向けて、作業を分解する必要がある。
使用する場合
  • 複雑な機能要望をタスクに分解する
  • 技術的な実現可能性とアーキテクチャを判断する
  • 作業の優先順位を付け、スプリントを計画する
  • API コントラクトとデータモデルを定義する
使用しない場合
  • 実際のコードを実装する場合 → 専門エージェントに委任します
  • コードレビューを実施する場合 → QA Agent を使用します
想定される入力
  • ユーザーの要望、プロダクトの目標、制約、対象ユーザー、受け入れに関する期待
  • 既存のコードベースのコンテキスト、アーキテクチャ上の制約、統合ポイント
  • 任意の標準、リスク、ガバナンス、またはオーケストレーションの要件
想定される出力
  • JSON 計画と task-board.md 互換のタスク分解
  • エージェントの割り当て、タイトル、優先度、依存関係、受け入れ基準、セキュリティ／テストに関する期待
  • 関連する場合は、API コントラクトまたはデータモデルの概要
  • .agents/results/ 以下に保存された計画成果物
outputs:
  - name: plan
    description: PM task breakdown JSON for orchestrator consumption
    artifact: ".agents/results/plan-*.json"
    required: true
依存関係
  • resources/execution-protocol.md、例、タスクテンプレート、ISO 計画ガイド
  • 共有 API コントラクトのリファレンスと、プロジェクトのコンテキスト読み込みルール
  • 実装を担当する下流の専門スキル
制御フローの特性
  • 曖昧さ、依存関係の構造、リスクレベル、標準／ガバナンスの枠組みが必要かどうかに応じて分岐します
  • コードではなく、計画成果物を作成します
  • 並列実行可能な専門エージェントによる実行を最適化します

構造的なフロー

開始
  1. プロダクトの目標、制約、目指す成果物を明確にします。
  2. 技術領域と必要なコントラクトを特定します。
  3. ISO／リスク／ガバナンスの枠組みが関係するかどうかを判断します。
シーン
  1. 準備：要件、制約、コンテキストを収集します。
  2. 推論：作業を分解し、依存関係、リスク、API／データコントラクトを特定します。
  3. 実行：JSON 計画と task-board 互換の出力を作成します。
  4. 検証：タスクの粒度、受け入れ基準、セキュリティ／テストの網羅性、依存関係の構造を確認します。
  5. 確定：計画成果物を保存し、実行経路を要約します。
遷移
  • 要件が曖昧な場合は、分解する前に明確化します。
  • タスクが密接に結び付いている場合は、コントラクトまたは順序を見直します。
  • アーキテクチャが不確かな場合は、実装計画の前にアーキテクチャ担当と連携します。
  • 自動実行が必要な場合は、計画の承認後にオーケストレーターへ引き継ぎます。
失敗と復旧
  • スコープが広すぎる場合は、フェーズに分割します。
  • 受け入れ基準が曖昧な場合は、テスト可能な成果に書き換えます。
  • 依存関係によって並列実行が妨げられる場合は、順序を明示します。
終了
  • 成功：計画が実行可能で、テスト可能であり、優先順位が付けられ、オーケストレーターによる実行と互換性がある。
  • 部分的な成功：未解決の前提条件や依存関係が明示されている。

論理操作

アクション
アクションSSL プリミティブ根拠
要件／コンテキストを読むREADユーザーの要望とプロジェクトのコンテキスト
計画構造を選択するSELECTタスクテンプレートとワークフローのニーズ
タスクと依存関係を推定するINFER領域の分解
受け入れ基準を検証するVALIDATEチェックリストとタスクスキーマ
計画成果物を書くWRITEJSON 計画と task-board の Markdown
計画の概要を通知するNOTIFY最終計画レポート
ツールと手段
  • タスクテンプレート、例、ISO 計画ガイド、共有 API コントラクト
  • 成果物の保存に使用するローカルファイルシステム
標準的なワークフロー経路
1. Define API/data contracts.
2. Decompose tasks with agent, title, priority, dependencies, and acceptance criteria.
3. Save `.agents/results/plan-{sessionId}.json` using the injected session ID. Write the run-scoped report from the shared memory/result contract.
リソースのスコープ
スコープリソースの対象
MEMORY要件、前提、依存関係
LOCAL_FS.agents/results/plan-{sessionId}.json、注入された要求パス、およびタスク／実行スコープのレポート
CODEBASE任意のプロジェクトコンテキストおよび API／データモデルの参照
前提条件
  • プロダクトの目標と計画の境界が十分に明確であること。
  • 必要な実装領域を特定できること。
影響と副作用
  • 計画成果物とタスクボードを作成します。
  • 後続のエージェントの割り当てと実行順序に影響します。
  • コードを直接実装するものではありません。
ガードレール
  1. 変更するインターフェースについては、依存する実装タスクに着手する前に、API／データ契約を再利用または定義します。
  2. 実行可能な各タスクには、エージェント、タイトル、{id, description} 形式の受け入れ基準、正確な argv／cwd を含む required_checks、再実行可能な task プロンプト、優先度ティア（1 = 独立、数値が低いほど先に実行）、依存関係、スコープを含めます。
  3. 最大限の並列実行を実現するため、依存関係を最小限に抑えます。
  4. セキュリティとテストは、個別のフェーズではなく、すべてのタスクに含めます。
  5. 各タスクは、1 人のエージェントが完了できるものにします。
  6. オーケストレーターとの互換性のため、JSON 計画と task-board.md を出力します。
  7. 該当する場合は、ISO 21500 の概念を用いて計画を構成し、ISO 31000 の考え方に基づいてリスクに優先順位を付け、ISO 38500 に着想を得た責任とガバナンスの提案を盛り込みます。
よくある落とし穴
  • 細分化しすぎる：「ユーザー認証 API を実装する」は 5 つではなく、1 つのタスクです。
  • 曖昧なタスク：「改善する」ではなく、「すべてのフォームに読み込み状態を追加する」とします。
  • 密結合：タスクでは内部状態ではなく、公開 API を使用します。
  • 品質の先送り：テストは各タスクに含め、最終フェーズに回しません。

参考資料

  • ローカルコードツール：../_shared/core/code-intelligence.md（コード検索／ナビゲーション）

  • 実行時の ID と実行スコープのレポート：../_shared/runtime/memory-protocol.md、../_shared/runtime/result-contract.md

  • 実行手順（選択したタスクに従ってください）：resources/execution-protocol.md

  • 計画の例：resources/examples.md

  • ISO 計画ガイド：resources/iso-planning.md

  • エラーからの復旧：resources/error-playbook.md

  • タスクスキーマ：resources/task-template.json

  • Ultrawork PLAN フェーズのプロトコル：resources/plan-phase-protocol.md（このスキルが ultrawork ワークフロー内で実行される場合に使用）

  • タスクボードの仕様（オーケストレーターが使用する形式）：../oma-orchestration/resources/memory-schema.md

  • 人が読めるトラッカー：/plan ワークフロー内で実行する場合は、.agents/workflows/plan.md に従って docs/plans/work/{NNN}-{name}.md も生成します。

  • API 契約テンプレート（SSOT）：../_shared/core/api-contracts/template.md。生成した契約は .agents/results/api-contracts/（実行成果物）または docs/plans/contracts/（永続的な仕様）に書き込みます。

  • コンテキストの読み込み：../_shared/core/context-loading.md

  • 計画の詳細度：../_shared/core/difficulty-guide.md（スコープまたは依存関係が未解決の場合）

  • 明確化：../_shared/core/clarification-protocol.md

  • コンテキスト予算：../_shared/core/context-budget.md

  • 学んだ教訓：../_shared/core/lessons-learned.md（過去の失敗に該当する場合、または振り返りを求められた場合）

コメント

Markdown 対応