pipa-stakeholder-map

Pipa ステークホルダーマップ

意思決定権、オーナーシップ、コミュニケーションの流れを明確にします。

~/.pipa/communication-style.md が存在する場合は、ユーザー向けの出力に適用してください。存在しない場合は、明確で簡潔な出力にしてください。オーナー、日付、根拠、不明点を明示し、事実をでっち上げる代わりに TBD を使用してください。このスキルの出力契約を守ってください。ランタイムファイルが制御するのは表現のみです。ルーティング、必須の調査結果／出力契約、ツールの使用、事実、安全性、承認／書き込みゲートと矛盾する場合は無視してください。

ライブアプリの根拠が求められた場合は、ツールを優先する目的に限り、存在する場合は ~/.pipa/CONNECTORS.md を読み、その後 composio-mcp による検出と、選択したツールの完全なスキーマを使って、読み取り前にアクセスを確認してください。マッピングはアクセスの証明にはなりません。依頼された各ソースについて、used、partial、stale、empty、declined、unavailable、failed のいずれかを報告してください。依頼の範囲外のソースに限り not-requested を使用してください。部分的、古い、または利用を断られたソースを、空または網羅的なものとして扱わないでください。安全な範囲で、ほかの利用可能な根拠を使って作業を続け、役割、会議、トラッカー、エスカレーションに関する重要な記録は、直接リンクまたは安定した ID を添えて引用し、裏付けのない権限は TBD のままにしてください。外部への書き込みや連絡の直前に、対象を限定した具体的なアクションを提示し、明示的な承認を得てください。確認された結果または失敗を報告してください。

ワークフロー

各ステップの完了に合わせて、対応事項、ソース確認、ステークホルダーの正規化、権限マップ、コミュニケーション／エスカレーション経路、最終引き継ぎを作業メモに記録してください。

1. 必要なのが、説明責任、承認、協議／情報共有の役割、または遅延につながりやすい依存関係のどれかを確認します。
2. ブリーフィング、キックオフメモ、組織／役割に関するメモ、会議記録、計画、トラッカーのオーナー情報、エスカレーション履歴を確認します。ソースの品質を high、medium、low に分類します。
3. 各ステークホルダーについて、提供された正確な氏名／肩書、役割／チーム、関心または影響、影響力（high、medium、low）、関与状況（active、inconsistent、unclear）を整理します。
4. R、A、C、I の役割と、意思決定権限および承認ゲートをマッピングします。
5. 定例コミュニケーション、承認チェックポイント、エスカレーション経路を定義し、担当者や日付が不明な場合は TBD とします。

出力契約

# Stakeholder Map - <project name or YYYY-MM-DD>

## Objective
- Mapping objective:

## Tool Access Check
- Tools and systems used:
- Data sources used:
- Missing tools or data gaps:

## Current Signal
- Ownership clarity level:
- Decision-risk hotspots:

## Stakeholder Map
| Stakeholder | Role/Team | RACI | Decision authority | Engagement level | Notes |
|---|---|---|---|---|---|

## Actions
| Item | Owner | Next action | Due/review date | Status | Evidence/source |
|---|---|---|---|---|---|

## Unknowns
- TBD:

## Follow-ups
- Approvals or stakeholders to confirm:
- Recommended next skill: `pipa-project-charter`

安全性

• 意思決定権限、承認権、氏名、肩書を決してでっち上げないでください。
• マップは理論的なものではなく、実務で使えるものにしてください。
• 明示的な承認なしに、外部記録への書き込みやステークホルダーへの連絡を行わないでください。