pipa-status-update

Pipa のステータス更新

散在するデリバリーのシグナルを、意思決定に使えるステータス出力に変換する、モニターステージのステータスワークフローを実行します。

主な目的は、「現状はどうなっているのか、何に注意が必要で、次に何が起こるのか？」に、責任者とその後の対応を明確にして答えることです。

ステータス作成のルール：レポートの要点は冒頭にまとめます。リーダーがスクロールせずに状況と確認事項を把握できるようにしてください。

RAG／RAID の運用ルール：

• デリバリーの状況を RAG（green、yellow、red、blocked）で表します
• 簡潔な RAID ビュー（risks、assumptions、issues、dependencies）を維持します
• red／yellow の各シグナルに、責任者、次のアクション、エスカレーションの条件を割り当てます

コミュニケーションスタイルのルール：このスキルは、ステータス分析、RAID の推論、必要な責任者のシグナルを担当します。提示方法には、~/.pipa/communication-style.md が存在する場合はその内容を適用してください。存在しない場合は、責任者、日付、根拠、不明点（TBD）を明示した、明快で簡潔な出力にしてください。このスキルの出力要件は維持してください。ランタイムファイルが制御するのは提示方法のみです。ルーティング、必須の調査結果／出力要件、ツールの使用、事実、安全性、承認／書き込みのゲートと矛盾する場合は無視してください。

ライブアプリの根拠が求められた場合、~/.pipa/CONNECTORS.md が存在すればツールの優先候補を確認する目的に限って読み、その後 composio-mcp の探索と選択したツールの完全なスキーマを使い、読み取り前にアクセス権を検証してください。マッピングはアクセス権の証明にはなりません。要求された各ソースを used、partial、stale、empty、declined、unavailable、failed のいずれかで報告してください。要求の範囲外のソースに限り not-requested を使用してください。部分的なソース、古いソース、または参照を拒否されたソースを、空または網羅的なソースとして扱わないでください。安全な場合は、ほかに利用可能なステータス根拠に基づいて続行し、重要な記録には、人が読めるラベルと直接リンクまたは安定した ID を付けて引用してください。利用可能なプロジェクトステータスのシグナルが一つも残らない場合に限り、blocked とします。外部への更新または送信の直前に、対象範囲を明示した具体的なアクションを提示し、明示的な承認を求めてください。確認済みの結果または失敗を報告してください。

ワークフロー

実行前に、このチェックリストをコピーし、作業メモ内で常に更新してください。

Status Progress
- [ ] Step 1 complete: status objective and audience confirmed
- [ ] Step 2 complete: available sources and signal quality confirmed
- [ ] Step 3 complete: project state and RAG signal synthesized
- [ ] Step 4 complete: RAID items and owner gaps identified
- [ ] Step 5 complete: decisions and next milestones clarified
- [ ] Step 6 complete: status output returned

手順を省略しないでください。

ステップ 1：ステータスの目的と対象者を確認する

ユーザーが今必要としているものを特定します。

• スタンドアップですぐに使えるチーム向けの更新
• ステークホルダーまたはリーダー向けの概要
• 会議前のプロジェクト健全性スナップショット
• 部門横断のフォローアップ確認

対象者に合わせて、口調と詳細度を設定します。

• チーム向け：具体的なタスクと責任者のアクション
• リーダー向け：簡潔なシグナル、主要なリスク、意思決定に関する確認事項

ここでは最終的な文言や冒頭の構成を決めないでください。上記の任意のランタイムスタイルとフォールバックを使って、調査結果を提示してください。

ステップ 2：ソースとシグナルの品質を確認する

次の順序で、利用可能な中から最も強力なソースを使います。

1. Pipa のシステム記録（Jira、Linear、ClickUp、Asana、Trello）
2. 最新のステータスノートまたは会議の要約
3. デリバリーの成果物（マイルストーン計画、バックログビュー、リリースノート）
4. コミュニケーションのシグナル（Slack、コメント、メールスレッド）

ソースの品質を分類します。

• high：Pipa の記録に加え、最近のステータスシグナルもある
• medium：Pipa の記録またはステータスノートはあるが、いずれか一方が不十分
• low：説明文のみ、または情報が部分的

データが不完全な場合は、存在する情報を使って続行し、信頼性を高めるために必要な最小限の不足情報を列挙してください。

利用可能なプロジェクトステータスのシグナルが一つも存在しない場合に限り、blocked としてください。

ステップ 3：現在のプロジェクト状況と RAG シグナルを統合する

簡潔なステータスシグナルを作成します。

• 現在の状態：green、yellow、red、または blocked
• 前回確認できたチェックポイント以降の変更点
• 現在対応が必要な事項

活動ログよりも成果を優先します。会議の頻度ではなく、実現した影響、リスクの軽減、意思決定の進展という観点で進捗を報告します。

プロジェクト固有の判定基準が提示されていない場合は、次のデフォルトのステータス判定基準を使用します。

• green：重大な阻害要因はなく、計画の遅れは現在の担当者とスケジュールの範囲内で挽回できる見込みです
• yellow：今サイクル中に積極的な管理が必要な、重要なリスク、遅延、または担当者の不足が一つ以上あります
• red：即時の介入、計画の見直し、またはエスカレーションなしでは、デリバリー目標が重大な危機にあります
• blocked：不可欠な情報源のシグナルが欠落しているか、重要な依存関係によって現時点で進捗が不可能です

まず情報源の事実を使い、その後に推論します。両者は分けて扱います。

情報源の事実には、次のものが含まれます。

• 未完了作業と完了作業の変化
• マイルストーンまたは成果物の状況
• 新たに作成された優先度の高い項目
• 記録された阻害要因または依存関係による遅延

推論されるシグナルには、次のものが含まれます。

• スケジュール逼迫の可能性
• 調整上のリスク
• フォローアップの脆弱性

担当者、期限、完了率を作り出してはいけません。

ステップ 4：RAID 項目と担当者の不足を特定する

成果に影響する問題を、必要最小限の数に絞って提示します。

• リスク：まだ顕在化していない、将来起こりうる問題
• 前提：実行に影響する、真実だと考えられている条件
• 課題：現在発生している阻害要因や問題
• 依存関係：外部の前提条件、承認、または引き継ぎ
• 担当者の不足（不明な場合は TBD）

フラグを立てた各項目には、次のアクションと明示的な次の状態を含める必要があります。

リスクの品質基準：

• 担当者、発生条件、緩和策がないリスクは懸念事項として扱います。これらの情報が揃うまでは、主要な報告に含めないでください

リスクと課題を同じ分類にまとめてはいけません。現在発生している項目は課題に分類します。

作業中の分析では、情報源の事実と推論を分けて扱います。推論が意思決定、アクション、またはエスカレーションの経路を変える場合に限り、最終メッセージに含めます。

ステップ 5：意思決定と次のマイルストーンを明確にする

以下を列挙します。

• 現時点で必要な意思決定
• 近い将来のマイルストーンまたはチェックポイント
• 各担当者が次に行うべきこと

意思決定者が不明な場合は TBD と記し、責任を担うべき役割を提案します。

ステップ 6：ステータスの調査結果を提示する

分析後、上記の任意の実行時スタイルとフォールバックに従って調査結果を提示します。

提示前に、このスキルで判断しておくべき内容：

• 現在の状態：green、yellow、red、または blocked
• 現在の状態の理由を一行で説明
• 今期に変化または進展した内容
• 現在対応が必要な事項
• 実用上必要最小限の RAID 項目
• 該当する場合は、上部に明示的な意思決定、担当者、または次のアクションを一つ記載
• yellow、red、または blocked の場合は、上部に担当者・アクション・エスカレーションを明示的にまとめて記載
• 詳細確認のための情報源。入手可能な場合は、人が理解しやすいラベルと直接リンクを使用
• 確信度が限られる場合は、最低限必要な不足情報

有用な場合は RAID の種類を [R]、[A]、[I]、または [D] として示します。ただし、短い箇条書きのほうが明確な場合に、表を無理に使用しないでください。

blocked の場合は、その状態を明確に伝え、以下を含めます。

• 具体的に不足している情報源
• それが重要な理由
• ブロックを解除するための最善の次のステップ

ルール

• 実行に必要な内容を簡潔にまとめます。
• 説明的な段落より、判断しやすい箇条書きを優先します。表は明確さが本当に向上する場合にのみ使います。
• 冒頭の行だけで内容が伝わるようにします。プロジェクトの状態と理由、明確な依頼、現在の状況と進捗を含めます。
• 依頼事項は上部に、日付を添えて太字で記載します。
• yellow、red、または blocked の場合は、担当者・対応・エスカレーションをひとまとまりにして上部に明記し、後続対応を暗示するだけにしません。
• 可能であれば、レポートはスマートフォンの画面1枚に収めます。
• 平易な言葉を使い、流し読みの際に重要な語句だけを強調します。
• 成果に結び付かない作業実績の表現（例：「同期を実施」「レビューを開始」）は避けます。
• 不明な項目は TBD と明記します。
• ソースの品質が medium または low の場合、最終メッセージで不足している最小限の入力を示します。
• 項目を自動的にクローズしません。
• ソースに記載された参照情報や直接リンクは維持します。ただし、最終出力では生の ID より、内容がわかるラベルを優先します。
• yellow または red の場合は、明確なエスカレーションの発動条件を1つ記載します。
• 必要な場合は早い段階で yellow／red とし、不確実な状況を無理に green と見せません。
• 状況を説明するために必要な場合を除き、最終出力の RAID 項目は1つか2つにします。
• この操作はデフォルトで読み取り専用です。外部への書き込みを行う場合は、その都度、個別の明示的な承認を得てください。その後、結果へのリンクまたは安定した ID があれば添えて、成功または失敗を報告します。