team-brief

COG チームインテリジェンスブリーフスキル

呼び出すタイミング

• ユーザーが「チームブリーフ」「チームの最新情報」「何をリリースした？」「スタンドアップの準備」と言った場合
• ユーザーが開発チームの作業内容を知りたい場合
• GitHub、Linear、Slack の情報を相互参照したインテリジェンスが必要な場合
• プロダクト／エンジニアリングリードの朝のルーティン

エージェントモードの確認

00-inbox/MY-PROFILE.md のフロントマターで agent_mode を確認します：

• agent_mode: team の場合 — 以下の完全な並列エージェント実行戦略（6 エージェント）を使用します
• agent_mode: solo の場合 — メインの会話内でデータ収集を順番に実行します。時間を短縮するため、フェーズ 3.5（Linear への同期）とフェーズ 3.7（HackMD への公開）は省略します。

目的

チームが取り組んでいること、注意が必要なこと、見落とされていることに焦点を当てた、簡潔な日次チームインテリジェンスブリーフを作成します。Linear の作業管理、Slack の議論、GitHub のアクティビティ、PostHog のプロダクト分析、ブレインダンプ、最近のミーティングを相互参照し、インサイトを明らかにして、食い違いを指摘し、チームの足並みをそろえます。

月曜日 = 週初めのブリーフ： 今日が月曜日の場合、ブリーフの対象期間は金曜日から日曜日（週末全体）です。日付範囲、クエリ、表現はすべて、「金曜日以降」「週末の間」とし、「昨日」ではなく週末を反映させます。これにより、金曜日の午後に発生したこと、週末のデプロイ、非同期の議論を漏らさず取り上げられます。

これは業界ニュースのレポートではありません。 ニュース／市場インテリジェンスは週次ブリーフに含めます。

コマンド：/team-brief

文体とトーン

あなたは単なる報告ツールではありません。すべての Slack スレッド、すべての PR、すべてのミーティングメモに目を通しているチームメイトです。チームの成功を心から願う人のように書いてください。

心がけること：

• 率直に、意見を明確に伝えます。何かおかしいと感じたら、はっきり言います。
• 成果を称えます。チームが素晴らしいものをリリースしたときは、それを認めます。
• 点と点をつなぎます。事実を並べるだけでなく、それらが組み合わさると何が重要なのかを説明します。
• 自然な言葉を使います。「新しいワークフローとキャッシュの修正、UX の磨き込みを含む v1.2.0 を、PR 11 件とともにリリースしました。充実した一日でした」ではなく、「報告期間中に 11 件の PR がマージされました」といった表現にします。
• 簡潔ながら温かみを保ちます。短い文、明確な考え、無駄のない表現を心がけます。
• リスクを正直に指摘します。「これは心配です」「引き続き注視したいところです」と伝え、企業的な曖昧表現は避けます。
• ビジネスの背景を理解していることを示します。関連する場合は、成長目標、顧客からのフィードバック、戦略に触れます。

避けること：

• プロジェクト管理ダッシュボードのような書き方をしません。「REPORT_GENERATED_AT」のような雰囲気は避けます。
• 過度に形式張りません。「チームとして検討することを推奨します」といった表現は使いません。
• 余計な文言を加えません。伝えることがなければ、無理に水増ししません。
• 受け身の表現にしません。「PR は未レビューのままです」ではなく、「まだ誰もレビューしていません。もう 3 日経っています」と伝えます。
• 不要なラベルやタグを使いません。文章そのものに語らせます。

トーンの例：

昨日はいい一日でした。新しいワークフロー、キャッシュの修正、さまざまな UX の磨き込みを含む v1.2.0 をリリースしました。4 人で 11 件の PR をマージしました。チームは着実にリリースを重ねています。

ただし、問題があります。連続した 2 回のディスカバリーコールで、見込み顧客がログインできないまま終わりました。オンボーディングのフローがうまく機能していません。入口を通れないユーザーのために機能を作っている状態です。

---

並列エージェントチームの実行戦略

日次ブリーフでは、速度と効率を最大化するため、必ず並列エージェントを使用します。

/daily-brief が呼び出されたら、オーケストレーター（メインエージェント）は次の手順を実行します。

フェーズ 1：セットアップ（オーケストレーター — 順次、迅速に）

1. 今日の日付と遡及開始日を決定します：
   • 今日が月曜日の場合： 遡及開始日は直近の金曜日（3 日前）です。LOOKBACK_DATE を金曜日の日付に設定します。これは週初めのブリーフです。
   • それ以外の曜日の場合： 遡及開始日は昨日です。LOOKBACK_DATE を昨日の日付に設定します。これは標準的な日次ブリーフです。
   • すべての日付は YYYY-MM-DD 形式にします。
2. ToolSearch（「slack」）、ToolSearch（「linear」）、ToolSearch（「posthog」）を使って、利用可能な連携機能を確認します
3. [CUSTOMIZE: path/to/meetings/] にある、LOOKBACK_DATE から今日までの日付に該当するミーティングメモを確認します
4. [CUSTOMIZE: path/to/braindumps/] にある、LOOKBACK_DATE から今日までの日付に該当する最近のブレインダンプを確認します

フェーズ 2：並列データ収集（6 つのエージェントを同時に起動）

Task ツールで run_in_background: true を指定し、これらすべてのエージェントを 1 つのメッセージで起動してください：

エージェント 1：「github-analyst」（subagent_type: general-purpose）

プロンプト：references/agent-prompts.md § github-analyst を参照してください。

エージェント 2：「slack-monitor」（subagent_type: general-purpose）

Slack MCP が利用可能な場合にのみ起動してください プロンプト：references/agent-prompts.md § slack-monitor を参照してください。

エージェント 3：「meeting-reviewer」（subagent_type: general-purpose）

プロンプト：references/agent-prompts.md § meeting-reviewer を参照してください。

エージェント 4：「linear-tracker」（subagent_type: general-purpose）

Linear MCP が利用可能な場合にのみ起動してください プロンプト：references/agent-prompts.md § linear-tracker を参照してください。

エージェント 5：「braindump-reviewer」（subagent_type: general-purpose）

プロンプト：references/agent-prompts.md § braindump-reviewer を参照してください。

エージェント 6：「posthog-analyst」（subagent_type: general-purpose）

PostHog MCP が利用可能な場合にのみ起動してください プロンプト：references/agent-prompts.md § posthog-analyst を参照してください。

フェーズ 3：統合と相互参照による統合分析（オーケストレーター — すべてのエージェントの完了後）

これは最も重要なフェーズです。オーケストレーターは次の作業を行う必要があります。

1. 結果を収集する：各エージェントの出力ファイルを Read で読み取ります

2. Linear ↔ GitHub を相互参照する（中核となる整合性チェック）：

   • Linear の課題を対応する PR／コミットと照合します（タイトル、説明、明示的な参照を基準にします）
   • 対応する PR またはコミットがない「In Progress」ステータスの Linear 課題にフラグを立てます（作業が着手済みとされているのに、コード上では開始されていません）
   • 対応する Linear の課題がない PR にフラグを立てます（追跡されていない作業です。問題ない場合もあるため、その旨を記録するだけにします）
   • PR がまだオープン、またはマージされていないのに「Done」ステータスになっている Linear の課題にフラグを立てます（ステータスの不一致です）
   • Linear の優先度と PR の緊急度が一致していない課題を記録します（例：Linear では Urgent なのに、PR が何日もレビューされていません）

3. Slack ↔ GitHub ↔ Linear を相互参照する：

   • Slack での議論のトピックを、関連する PR／コミットおよび Linear の課題と照合します
   • 関連する知見をまとめて、統合された項目にします（例：「クレジットシステム：[CUSTOMIZE: PROJ]-45 は進行中 ＋ Slack で 22 件の返信がある ＋ PR #930 は CHANGES_REQUESTED」）
   • 対応する PR、コミット、または Linear の課題がない作業について Slack での議論に言及があれば、フラグを立てます
   • Slack で議論されていない PR にフラグを立てます（議論されていない作業です。問題ない場合もあるため、その旨を記録するだけにします）

4. ミーティング ↔ GitHub ↔ Linear を相互参照する：

   • 昨日のミーティング／スタンドアップでのアクション項目に、対応する PR、コミット、または Linear の課題があるか確認します
   • GitHub または Linear 上での活動がない、議論された変更にフラグを立てます
   • 完了したアクション項目（議論済み、リリース済み、追跡済み）を記録します
   • ミーティングで割り当てられた優先度が Linear の優先度設定と一致しているか確認します

5. ブレインダンプ ↔ 現在の作業を相互参照する：

   • ブレインダンプから戦略的な考えを抽出し、進行中の Linear の課題や GitHub の PR と結び付けます
   • 現在追跡されている作業に反映されていないブレインダンプの懸念事項を明らかにします
   • 現在のスプリントの優先事項と矛盾する方針変更がブレインダンプで言及されていれば、フラグを立てます

6. Linear サイクル ↔ 全体の進捗を相互参照する：

   • サイクルの健全性を報告します（完了率、残り日数、進捗ペース）
   • スコープが拡大している場合（サイクルの途中で新しい課題が追加された場合）、フラグを立てます
   • サイクルの完了を妨げているブロック中の項目を強調します

7. イニシアチブ ↔ プロジェクト ↔ 課題を相互参照する：

   • 各イニシアチブについて、プロジェクトと課題のデータを集計し、実際の健全性を算出します：
     • リンクされているすべてのプロジェクトにおける、完了した課題数と全課題数を数えます
     • マイルストーンが予定どおりか、期限を過ぎているか確認します
     • 進捗を牽引しているプロジェクトと停滞しているプロジェクトを特定します
   • 算出した健全性と報告された健全性が異なるイニシアチブにフラグを立てます
   • 目標日が近づいているのに完了率が低いイニシアチブにフラグを立てます

8. PostHog ↔ GitHub ↔ Slack を相互参照する：

   • 機能リリース ↔ 指標：最近マージされた PR と PostHog の指標変化を関連付けます。機能をリリースして利用が増えましたか？それとも、リリース後に何も変化がありませんでしたか（利用定着の問題）？
   • エラー急増 ↔ デプロイ：PostHog のエラー急増を、最近マージされた PR と照合します。特定のマージ後にエラーが増加している場合、潜在的なリグレッションとしてフラグを立てます。
   • Slack での苦情 ↔ PostHog データ：Slack での議論にユーザーの問題が出てきた場合、PostHog のエラーデータやファネルの離脱で問題が確認できるか調べます。
   • 指標の異常 ↔ 既知の変更：訪問者数／登録数が大きく変化した場合、GitHub の活動や Slack と照合します。
   • 機能の利用定着 ↔ イニシアチブの目標：PostHog の機能利用データを Linear のイニシアチブ KPI に対応付け、ギャップにフラグを立てます。
   • アクティベーションファネル ↔ オンボーディング作業：ファネルで離脱が発生している場合、それに対応する PR や Linear の課題があるか確認します。何も取り組まれていなければ、そのギャップにフラグを立てます。

9. 以下のコンテンツ構成に従い、インサイトを最初に、詳細を最後に配置してブリーフを作成します。声とトーンのガイドラインに従い、ダッシュボードではなくチームメイトのような語り口で書きます。

10. 適切なメタデータを付けて [CUSTOMIZE: path/to/briefs/]daily-brief-YYYY-MM-DD.md に保存します

11. 簡潔な概要をユーザーに提示します

フェーズ 3.5：Linear への同期（オーケストレーター — 相互参照の後、Slack の前）

このフェーズでは、GitHub、Slack、ミーティングの実情を反映して最新の状態を保つため、Linear にデータを書き戻します。

ToolSearch を使って、必要な Linear 更新ツールを読み込みます：「+linear update issue」、「+linear update initiative」、「+linear update project」、「+linear create comment」、「+linear create attachment」、「+linear save status update」、「+linear update milestone」。

ステップ 1：PR ↔ Issue の関連付け

GitHub データで見つかった、マージ済みまたはオープン状態の PR ごとに、以下を行います。

1. PR のタイトル／本文／ブランチから Linear の Issue 参照を抽出します（パターン：[CUSTOMIZE: PROJ]-123）。
2. 該当する Linear Issue ごとに、以下を行います。
   • mcp__claude_ai_Linear__create_attachment を使って、PR の URL を Issue に添付します（まだ関連付けられていない場合）。次の形式を使います。
     • url：https://github.com/[CUSTOMIZE: your-org/your-repo]/pull/XXX
     • title：「PR #XXX: [PR title]」
   • Issue にこの PR がすでに添付されているか（get_issue の attachments 経由で）確認し、重複を避けるため、すでに関連付けられている場合はスキップします。

ステップ 2：GitHub からの Issue ステータス同期

フェーズ 3 の相互参照データに基づき、以下を行います。

1. PR がマージ済み → Issue がまだ「In Progress」：mcp__claude_ai_Linear__update_issue を使って、Issue を「Done」状態に遷移させます。コメントを追加します：「自動的に完了としてマークしました — PR #XXX は [date] にマージされました。」
2. PR がオープン → Issue がまだ「Todo」／「Backlog」：mcp__claude_ai_Linear__update_issue を使って、「In Progress」に遷移させます。コメントを追加します：「進行中としてマークしました — PR #XXX がオープンされました。」
3. PR に CHANGES_REQUESTED がある → Issue が「In Review」：Issue のステータスは維持しますが、レビューのフィードバックがまだコメントされていない場合は、その内容を記したコメントを追加します。

安全ルール：

• PR と Issue の関連付けが曖昧でない場合（Issue のプレフィックスが完全一致する場合）のみ、自動でステータスを遷移させます。
• Issue を前の状態に戻す遷移は行いません（例：「Done」を「In Progress」に戻さない）。
• 複数の PR が同じ Issue を参照している場合、関連する PR がすべてマージされた場合に限り、「Done」とマークします。
• 実施したステータス変更はすべて、簡潔なサマリー用に記録します。

ステップ 3：イニシアチブのステータス更新

アクティブなイニシアチブごとに、mcp__claude_ai_Linear__save_status_update を使ってステータス更新を作成し、投稿します。

1. 相互参照から以下を収集します。
   • 遡及期間以降にリリースされたもの（このイニシアチブのプロジェクトに関連付けられたマージ済み PR）
   • イニシアチブのプロジェクト全体における現在のブロッカー
   • イニシアチブの Issue のサイクル進捗
   • このイニシアチブに関連する Slack の主要な議論
2. 簡潔なステータス更新（箇条書き 3～5 項目）を作成します。

   **[DATE] Daily Update**
   • Shipped: [list key PRs/features merged]
   • In Progress: [key items being worked on]
   • Blocked: [any blockers, or "None"]
   • Health: [On Track / At Risk / Off Track] — [1-line reasoning]
   • Next: [what's expected to ship next]
   

3. mcp__claude_ai_Linear__save_status_update を使って、更新内容をイニシアチブに投稿します。
4. データに基づいてイニシアチブの健全性が明確に変化している場合は、mcp__claude_ai_Linear__update_initiative を使って健全性フィールドを更新します。

ステップ 4：マイルストーンの進捗確認

アクティブなプロジェクトのマイルストーンごとに、以下を行います。

1. マイルストーン内の完了済み Issue と全 Issue の数を数えます。
2. マイルストーンの目標日が近づいていて（7 日以内）、完了率が 70% 未満の場合は、フラグを立てます。
3. マイルストーンの期限が過ぎていて、未完了の Issue がある場合は、mcp__claude_ai_Linear__update_milestone を使って、注記を添えてステータス／説明を更新します。
4. マイルストーンの健全性をイニシアチブのステータス更新に含めます。

ステップ 5：プロジェクトのステータス同期

アクティブなプロジェクトごとに、以下を行います。

1. プロジェクト内の Issue がすべて「Done」で、プロジェクトのステータスがまだ「In Progress」の場合は、ステータス更新の対象としてフラグを立てます。
2. プロジェクト内のブロック中の Issue が 50% を超える場合は、その旨をイニシアチブのステータス更新に記載します。
3. プロジェクトの説明や概要を更新するのは、ステータスに大きな変化がある場合に限ります。

同期サマリー

すべての同期処理の後、更新内容のサマリーを作成します。

• ステータスを同期した Issue：[件数]（Issue ID と新しい状態の一覧）
• 関連付けた PR：[件数]（PR#→Issue の対応一覧）
• 投稿したイニシアチブの更新：[件数]
• フラグを立てたマイルストーン：[件数]
• 同期中に発生したエラー

このサマリーを、簡潔なレポートの「Linear 同期レポート」セクションに含めます。

フェーズ 3.7：HackMD への公開（Linear への同期後、Slack への投稿前）

このフェーズでは、チームとリンク経由で共有できるよう、日次ブリーフ全体を HackMD に公開します。

HackMD API トークンは .claude/settings/hackmd-token に保存されています（1 行で、空白はありません）。次のコマンドで読み取ります：cat .claude/settings/hackmd-token | tr -d '\n'。または、環境変数 HACKMD_API_TOKEN を確認してください。

API の詳細：

• ベース URL：https://api.hackmd.io/v1
• 認証ヘッダー：Authorization: Bearer <HACKMD_API_TOKEN>

手順：

1. POST https://api.hackmd.io/v1/notes を使用してノートを作成します：

   {
     "title": "Daily Brief — [DAY_NAME], [FULL_DATE]",
     "readPermission": "signed_in",
     "writePermission": "owner",
     "commentPermission": "disabled",
     "content": "placeholder"
   }
   

   • readPermission: "signed_in" は、リンクを知っている HackMD ユーザーなら誰でも閲覧できることを意味します
   • レスポンスから id と publishLink を抽出します

2. 全ブリーフの Markdown コンテンツを使用して、PATCH https://api.hackmd.io/v1/notes/<id> 経由でノートの内容を更新します：

   • [CUSTOMIZE: path/to/briefs/]daily-brief-YYYY-MM-DD.md から保存済みのブリーフを読み取ります
   • Python を使ってコンテンツを JSON エンコードし、一時ファイルに書き込みます
   • curl -X PATCH ... -d @/tmp/hackmd-payload.json で送信します

3. Slack メッセージとローカルのブリーフファイルで使うHackMD リンクを保存します：

   • 手順 1 の publishLink（形式：https://hackmd.io/@[CUSTOMIZE: your-hackmd-username]/<shortId>）
   • このリンクは Slack のハイライトメッセージに含めます
   • ローカルの .md ファイルのフロントマターに hackmd_url: <publishLink> を追加または更新して、リンクを書き戻します。created: フィールドの後に挿入してください。この操作には Edit ツールを使い、ファイル全体を書き換えないでください。

4. HackMD API が失敗した場合は、エラーを記録して処理を続行します。リンクなしでブリーフを Slack に投稿してください。Slack メッセージには「(HackMD link unavailable)」と記載します。

実装パターン（Bash）： references/publish-templates.md § HackMD implementation pattern (Bash) を参照してください。

フェーズ 4：Slack のハイライト（ブリーフ保存後 — 投稿前にプレビュー）

ブリーフの概要をユーザーに提示した後、必ず Slack のハイライトメッセージを作成し、プレビューとして表示してください。ユーザーが Slack で目にする正確なメッセージを表示してから、次のように尋ねてください：「#[CUSTOMIZE: your-team-channel] に投稿してよいですか？（または、先に編集しますか？）」

ユーザーが明示的に確認するまで投稿してはいけません。 編集の提案があれば、内容を調整して更新後のプレビューを表示してください。投稿するのは、ユーザーが「はい」「確認しました」「よさそうです」「送ってください」などと答えた後だけです。

1. Slack に適したハイライトメッセージを作成する — ブリーフ全体ではなく、チームに伝えるべき最も重要な内容だけをまとめます。実際に読んでもらえるよう、短くまとめてください。

2. ユーザーの確認後、ToolSearch を使って Slack の送信ツールを読み込み、mcp__claude_ai_Slack__slack_send_message を使って [CUSTOMIZE: your-team-channel] チャンネルに投稿します。

3. Slack メッセージの形式（実際の内容に合わせて調整してください — これはテンプレートであり、固定形式ではありません）：

月曜日（週の開始時のブリーフ）の場合： references/publish-templates.md の § Slack message format — Monday (Week Start Brief) にある完全なテンプレートを使います。

通常の日の場合： references/publish-templates.md の § Slack message format — regular days にある完全なテンプレートを使います。

4. Slack メッセージのルール：
   • 月曜日のブリーフは最大 30 行、通常の日は最大 20 行にします。以前より詳しい内容にしますが、ざっと読めるようにしてください。
   • 問題より先に、よかったこと（リリースされたもの）を伝えます。
   • 今日チームの対応が必要なアラートだけを含めます。
   • PR の表をそのまま載せないでください。ただし、リリースされた PR は、実際に何が変わったのか分かるよう、各 PR の説明を 1 行添えて列挙します。
   • Slack での重要な議論を要約します。チームはスレッドを見落としがちです。重要な会話を 2〜3 文で振り返ると、実用的な価値が加わります。
   • 担当者を明記してアクションアイテムを含め、誰が何をすべきか分かるようにします。
   • 平易な言葉を使い、プロジェクト管理用語は避けます。「#930 はまだ誰もレビューしていません」とし、「REVIEW_REQUIRED のステータスが継続しています」とは書きません。
   • 急ぎの対応がなければ、短くまとめます：「今日は順調で、X をリリースしました。特に問題はありません。」
   • 特定の人に言及するのは、前向きな内容（成果を祝う場合や、フォローアップの担当者が明確な場合）に限ります。期限に間に合わなかった人を公に非難しないでください。
   • PR に言及する場合は、必ず GitHub のリンクを埋め込んでください。 Slack のリンク形式を使います：<https://github.com/[CUSTOMIZE: your-org/your-repo]/pull/XXX|#XXX>。#930 のようにリンクのない表記は使わず、クリックできるようにしてください。
   • Slack メッセージの末尾には、必ず HackMD のリンクを含めてください。形式は :link: *Full brief:* [HACKMD_URL] です。チームはこのリンクから詳細なブリーフ全文を確認します。

フェーズの所要時間

• フェーズ 1：約 10 秒
• フェーズ 2：約 60〜90 秒（6 つのエージェントをすべて並行して実行）
• フェーズ 3：約 45 秒（PostHog と GitHub の相関分析を含む、6 方向の相互参照と組み立て）
• フェーズ 3.5：約 30〜45 秒（Linear への同期 — PR の関連付け、ステータスの同期、イニシアチブの更新）
• フェーズ 3.7：約 10 秒（HackMD への公開 — 非公開ノートを作成し、ブリーフ全文をアップロード）
• フェーズ 4：約 10 秒（ユーザーの確認後、HackMD のリンクとともに Slack に投稿）
• 合計：約 3〜4 分（＋希望があれば Slack への投稿）

---

コンテンツ構成（優先順位 — 重要な内容を先に、詳細は後に）

1. 冒頭（1〜2 文）

全体の雰囲気を手短に伝えます。成果の多い日だったか、静かな日だったか、議論は多かったもののマージはなかったか。平易な言葉で状況を伝えます。

月曜日（週の開始時のブリーフ）の場合： 冒頭では週末の状況を伝え、これから始まる週の方向性を示します。例：「月曜日です。チームは週末も忙しく、6 件の PR をマージしました。金曜日以降の出来事と、今週の予定をお伝えします。」

通常の日の例：

充実した一日でした — 11 件の PR をマージし、v1.2.0 をリリースしました。チームは機能開発を順調に進めています。一方、オンボーディングで問題が大きくなっており、これ以上見込み客を失う前に対応が必要です。

2. 要注意の項目（最優先アラート）

今日対応が必要な項目です。最大3～5件に絞ってください。システムアラートではなく、同僚がスタンドアップで共有するような書き方にしてください。

種類（優先度順）：

• イニシアチブの健全性の低下（イニシアチブのステータスが「順調」から「要注意」に変わった、またはマイルストーンの期限を超過した）
• ブロック中／緊急のLinear課題で進捗がないもの
• 長期間停滞しているPR（オープンから3日超でレビューなし、またはCHANGES_REQUESTEDから2日超）
• Linear ↔ GitHubのステータス不一致（例：Linearでは「完了」なのにPRはまだオープン）
• 完了率が低く、期限が近づいているマイルストーン（期限まで7日以内、完了率70%未満）
• 対応漏れ（会議／Slackで話題になったが、GitHub／Linearでの動きがない）
• レビューのボトルネック（レビュー待ちのPRが5件超）
• サイクルの健全性に関する警告（進捗の遅れ、スコープの拡大）
• 合意事項と実際の対応の不一致
• Slackで報告された未解決のブロッカー
• 重大なバグや課題
• Linear課題にリンクされていないPR（追跡されていない作業）
• 最近のデプロイと相関するPostHogのエラー急増（リグレッションの可能性）
• 重要な指標の低下（訪問者数、登録数が20%超減少）
• 対応するLinear課題がないファネルの離脱（追跡されていないプロダクト上の課題）

例：

オンボーディングが機能していません — ディスカバリーコールで、2人連続して登録時につまずきました。どちらの問題についても、修正PRはありません。

レビューの滞留が深刻です — オープン中のPRは22件あり、そのうち16件が長期間停滞しています。100日以上前のものもあります。不要になったPRを閉じるため、簡単にトリアージしましょう。

**APIドキュメント（#930）**は、実装（#933）をマージする前にレビュアーからのフィードバックを解決する必要があります。確証のない基盤の上に構築するのは避けましょう。

3. 重要なインサイト（統合・相互参照）

Slack、GitHub、会議から得た情報を統合します。関連する項目はまとめてください。ここでは相互参照が特に重要です。話し合われたことと、コードで実際に起きたことを結び付けてください。

4. リリースしたもの

成果を称えましょう。マージ済みPRを簡潔にまとめてください。単に列挙するのではなく、可能であればテーマごとにまとめてください。

5. 進行中の作業

レビュー状況と対応するLinear課題のステータスを含めて、オープン中のPRを記載してください。経過日数や、停滞しているように見えるものがあれば示してください。Linearのステータスと実際のPRの状態が一致しているかを示してください。

6. イニシアチブ健全性ダッシュボード

進行中の各イニシアチブについて、ひと目でわかるステータスを示してください。

形式：

イニシアチブ名 — 健全性：順調 | 完了率23% | 残り76日

• プロジェクト：プロジェクトA（進行中、40%）、プロジェクトB（進行中、15%）
• マイルストーン：マイルストーン1（期限3月15日 — 順調）、マイルストーン2（期限3月30日 — 要注意）
• 今日リリースしたもの：PR #945（機能X）、PR #948（機能Y）
• ブロッカー：なし

7. サイクルとスプリントの健全性

現在のLinearサイクルの進捗（完了率、残り日数、スコープの変更）を示してください。チームが予定どおりに進んでいるか、遅れているかを記載してください。

8. チームの概況

速度を把握するための簡潔な数値を示してください。網羅的である必要はありません。GitHubの指標（PR、コミット）とLinearの指標（完了した課題、サイクルの進捗）の両方を含めてください。

9. プロダクト指標（PostHogより）

実際のユーザーデータに基づく、プロダクトの実績の概要です。エンジニアリング活動をビジネスの実情に結び付けます。

形式：

訪問者数： 342（↑前日比12%） | サインアップ数： 8（↓25%） | コアイベント： 156（↑34%） | エラー： 新規3件

数値からわかること： ループ検出の修正（PR #942）をリリースした後、コアイベントが急増しました。ユーザーはエラーに遭遇することなく、ワークフローをさらに進められています。サインアップ数は減少しましたが、単に利用が少ない日だった可能性もあります。

機能の利用状況： new-feature はユニークユーザー23人が使用しており、初期の反応は良好です。onboarding-flow では、メール認証のステップで引き続き40%が離脱しています。

エラー監視： 昨日のデプロイ以降、/api/execute で新たな TypeError エラーが3件発生しています。PR #935 のマージと相関しています。

ルール：

• PostHog のデータが利用可能な場合に限り、このセクションを含めます
• 変化率とともに、必ず傾向の方向（↑ ↓ →）を示します
• 可能であれば、指標の変化とリリースした PR を関連付けます
• エラーの急増を明示し、最近のデプロイと関連付けます
• 最大4～6行にまとめます。詳細な分析は別途記載します

10. Linear 同期レポート

デイリーブリーフの同期処理で Linear に反映された内容の概要です。

• 同期したイシュー：ステータスを更新したイシュー数。イシュー ID と新しい状態を列挙します
• リンクした PR：Linear のイシューにリンクした PR 数。対応関係を列挙します
• 投稿したイニシアチブの更新：ステータス更新を受け取ったイニシアチブ数
• フラグを付けたマイルストーン：リスクあり、または期限超過のマイルストーン数
• エラー：同期に失敗した場合はその内容。問題がない場合は「すべて正常」と記載します

11. 戦略的コンテキスト（Braindumpsより）

最近のブレインダンプから得られた、現在の作業に関連する重要なインサイトです。「何が起きたか」だけでなく、プロダクトリード自身の考えに基づく「なぜ重要なのか」を加え、ブリーフに深みをもたらします。

12. 昨日の議論（参考）

Slack での議論の詳細な要約です。これは付録であり、詳しい内容を知りたい人が読めるようにします。

13. 会議のフォローアップトラッカー

最近の会議でのアクションアイテムを、実際の GitHub／Slack／Linear の活動と照らし合わせて追跡します。ステータスインジケーターを使って、進捗がひと目でわかるようにします。

---

メタデータテンプレート

保存するブリーフファイルの YAML フロントマターテンプレート全体：references/brief-frontmatter.md。

統合ルール

相互参照のロジック

1. Linear の課題＋対応する PR → Linear で相互にリンクします（フェーズ 3.5）。ステータスの不一致（例：Linear では「完了」なのに PR はまだオープン）にフラグを立てます
2. Linear の課題が「進行中」＋PR／コミットなし → 「対応中だが、まだコードなし」としてフラグを立てます（着手直後の可能性もありますが、1 日を超えている場合は注記する価値があります）
3. PR あり＋Linear の課題なし → 未追跡の作業として記録します。必ずしも問題ではありませんが、今後は Linear で管理する必要があります
4. Slack のトピックで PR 番号または Linear の課題に言及 → 主なインサイトで相互にリンクします
5. 機能に関する Slack の議論＋PR および／または Linear の課題あり → 3 つすべての情報を組み合わせた統合インサイトを作成します
6. ミーティングのアクションアイテム＋対応する PR／コミットなし、かつ Linear の課題なし → フォローアップ漏れとしてフラグを立てます（どこにも記録されていません）
7. ミーティングのアクションアイテム＋Linear の課題はあるが PR なし → 追跡されていますが未着手です。ステータスを記録します
8. Slack での合意＋GitHub／Linear のアクティビティがそれと矛盾 → 不一致としてフラグを立てます
9. 同じトピックに関する Slack スレッドが複数ある → 1 つのインサイトにまとめます
10. ブレインダンプで機能／方向性に言及＋Linear／GitHub に関連する作業あり → 戦略的な検討と実行を関連付けます
11. ブレインダンプで懸念が提起されている＋それに対処する Linear の課題や PR なし → 「戦略上のギャップ — 検討はあるが、追跡されている作業はない」としてフラグを立てます
12. Linear の緊急／高優先度の課題＋最近のアクティビティなし（2 日超） → 停滞している重要な作業としてフラグを立てます
13. PR がマージ済み＋Linear の課題がまだオープン → フェーズ 3.5 で自動的に「完了」へ移行し、同期レポートに記載します
14. PR がオープン＋Linear の課題が「未着手」 → フェーズ 3.5 で自動的に「進行中」へ移行します
15. イニシアチブの目標日が近づいている＋プロジェクトの完了率が低い → イニシアチブの健全性に「リスクあり」とフラグを立て、Linear で更新します
16. マイルストーンの期限超過＋未完了の課題あり → マイルストーンにフラグを立て、Linear で更新します
17. 完了した作業がイニシアチブのプロジェクトに対応している → Linear に投稿するイニシアチブのステータス更新に含めます
18. PR がマージ済み＋PostHog の指標に急上昇あり → 相関関係を確認します。機能が変化を引き起こした可能性があります。影響データとともに「リリース内容」に含めます
19. PR がマージ済み＋PostHog のエラーが急増 → ヘッズアップでリグレッションの可能性としてフラグを立てます。エラーの詳細と PR のリンクを含めます
20. PostHog でサインアップ／コアイベントが減少＋明らかな原因なし → プロダクト指標の異常としてフラグを立てます。週末／祝日のパターンか、実際の問題かを確認します
21. PostHog で機能の利用率が低い＋関連するイニシアチブで成長を目標にしている → 開発中の内容と、ユーザーが実際に利用しているものとのギャップにフラグを立てます
22. PostHog のファネルで離脱あり＋それに対処する Linear の課題なし → 未追跡のプロダクト課題としてフラグを立てます。ユーザーが利用に苦労しているのに、誰も対応していません
23. Slack でユーザーから苦情あり＋PostHog のエラーデータで確認済み → データで実際のユーザーへの影響が確認されたため、優先度を引き上げます

古い PR のルール

• REVIEW_REQUIRED の状態で 3 日超経過 → 古い PR としてフラグを立てます
• CHANGES_REQUESTED の状態で 2 日超経過し、新しいコミットなし → 古い PR としてフラグを立てます
• ステータスにかかわらず 5 日超経過 → 長期間滞留している PR としてフラグを立てます
• アラートにはリンクと担当者を含めます

イニシアチブの健全性ルール

• 順調：予想ペースの 60％以上（目標日までの経過時間に対する課題の完了数の割合）で、重大なブロッカーなし
• リスクあり：予想ペースの 40～60％、またはブロック中の課題が 2 件以上、またはマイルストーンの期限超過
• 遅延：予想ペースの 40％未満、または複数のプロジェクトにわたってブロック中の課題が 3 件以上、または複数のマイルストーンが期限超過
• 健全性の評価には、報告されたステータスだけでなく、実データ（課題数、マイルストーンの日付）を使用します

優先順位

複数のアラートがある場合は、次の順に並べます。

1. イニシアチブの健全性の悪化（イニシアチブが「At Risk」または「Off Track」に移行）
2. ブロッカー（Linear のブロックされたイシュー、または進行できないもの）
3. 最近のデプロイと相関する PostHog のエラー急増（リグレッションの可能性 — 今まさにユーザーに影響）
4. マイルストーンの期限超過またはリスク（時間的制約があり、イニシアチブの健全性に影響）
5. Linear ↔ GitHub の不一致（システム間のステータスのずれ）
6. 主要な指標の低下（訪問者数、サインアップ数が 20％超減少 — 実際の問題を示している可能性）
7. 長期間更新されていない PR（時間的制約があり、悪化中）
8. フォローアップの漏れ（約束が未達 — Linear のイシューも PR もない）
9. サイクルの健全性に関する警告（進捗の遅れ、スコープの拡大）
10. レビューのボトルネック（チームのベロシティを低下させている）
11. 戦略上のギャップ（ブレインダンプで挙がった懸念に、追跡対象の作業がない）
12. 追跡対象の作業がないファネルの離脱（プロダクトのギャップ）
13. 情報としての不一致（把握しておくとよい情報）

---

フォールバック動作

• Slack が利用できない場合：Slack のセクションをスキップし、GitHub + Linear + ミーティングのみを実行します。注記：slack: unavailable
• Linear が利用できない場合：Linear のセクションをスキップし、GitHub + Slack + ミーティングを実行します。注記：linear: unavailable。Linear は現在、主要な作業管理ツールであるため、その旨を明記します
• PostHog が利用できない場合：プロダクト指標のセクションをスキップし、ほかのエージェントを実行します。注記：posthog: unavailable。それでもブリーフは有用です
• ミーティングが見つからない場合：ミーティングのフォローアップのセクションをスキップし、ほかの情報源に進みます
• ブレインダンプが見つからない場合：戦略的コンテキストのセクションをスキップします。これは任意の補足情報であり、必須ではありません
• GitHub が利用できない場合（まれ）：エラーを記録し、開発アクティビティをスキップします
• データを決して捏造しないでください — クエリが失敗した場合は、その旨を明確に伝えます

エラー処理

• gh CLI コマンドが失敗した場合は、エラーを報告し、そのデータ項目をスキップします
• Linear MCP ツールが失敗した場合は、エラーを報告し、失敗したクエリを記載します。一括処理が失敗しても、個別のクエリを試します
• Slack MCP の応答が遅い場合は、妥当なタイムアウトを設定し、Slack なしで続行します
• 昨日のミーティングファイルが見つからない場合は、フォールバックとして一昨日を確認します
• ブレインダンプファイルが見つからない場合は、何も記録せずにスキップします。ブレインダンプは随時作成されるもので、毎日作成されるわけではありません
• Linear への同期でエラーが発生した場合：書き戻し操作が失敗したら、同期レポートにエラーを記録します。ただし、過度に再試行せず、残りの同期操作を続行します。一部の書き戻し手順が失敗しても、ブリーフは生成します
• 重複の防止：イシューに添付（PR リンク）を作成する前に、既存の添付を確認して重複を避けます。イニシアチブのステータス更新を投稿する前に、今日すでに投稿されていないか確認し、スパムを避けます
• ステータス遷移の安全性：情報が失われる可能性のある状態へ、イシューを自動で遷移させないでください。遷移に確信が持てない場合は実行せず、同期レポートに「推奨」として記録します