comprehensive-analysis

COG 総合分析スキル

呼び出すタイミング

• ユーザーが週次レビューや振り返りの準備を希望している
• ユーザーが「週次分析」「総合レビュー」「取締役会の準備」「詳細分析」と言っている
• ユーザーがより長い期間（7 日以上）にわたる分析を必要としている
• ユーザーがチームやプロダクトの健全性を全体的に把握したい

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

00-inbox/MY-PROFILE.md のフロントマターにある agent_mode を確認してください：

• agent_mode: team の場合 — 以下の完全な並列エージェント実行戦略（5 エージェント）を使用します。このスキルはチームモードで大きな効果を発揮します。
• agent_mode: solo の場合 — 軽量版を実行します。GitHub と Linear のデータを順次収集し、PostHog の詳細分析は省略して、3 つのドキュメントではなく単一の統合レポートを作成します。

目的

週次レビュー、取締役会の準備、戦略計画、または全体像の把握が必要なときに、すべてのデータソースを対象とした詳細分析を生成します。スピードと日々の関連性を重視するチームブリーフとは異なり、このスキルでは意図的により多くのデータを取得し、統合に時間をかけます。

次の場合に使用します：

• 週次チームレビュー／振り返りの準備
• 取締役会や経営陣への報告の準備
• 戦略計画セッション
• すべてのデータソースを横断した特定の問題の調査
• 月次／四半期ごとの健全性チェック

毎日は使用しないでください — 8〜12 分かかり、大量のデータを取得します。日々の情報収集には /daily-brief を使用してください。

コマンド：/comprehensive-analysis

文体とトーン

デイリーブリーフと同様に、率直で、明確な意見を持ち、チームメイトのような雰囲気にします。ただし、より深く、細やかなニュアンスを加えます。単に情報を得るだけでなく、意思決定を行う必要があるプロダクトリーダーに向けて書きます。

---

実行戦略

フェーズ 1：詳細なデータ収集（約 3〜5 分）

Task ツールを使い、run_in_background: true を指定して、すべてのエージェントを並列で起動します。

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

Deep GitHub analysis for [CUSTOMIZE: your-org/your-repo].
Analysis period: last 7 days (from [7_DAYS_AGO] to [TODAY]).

Collect:
1. ALL PRs merged in the last 7 days:
   gh pr list --repo [CUSTOMIZE: your-org/your-repo] --state merged --search "merged:>=[7_DAYS_AGO]" --json number,title,author,mergedAt,labels,additions,deletions --limit 100

2. ALL open PRs with full detail:
   gh pr list --repo [CUSTOMIZE: your-org/your-repo] --state open --json number,title,author,createdAt,reviewDecision,labels,updatedAt,additions,deletions --limit 100

3. Contributor activity breakdown:
   For each contributor, count: PRs merged, PRs opened, commits, review comments given.
   gh api repos/[CUSTOMIZE: your-org/your-repo]/stats/contributors

4. Code frequency (additions/deletions per week):
   gh api repos/[CUSTOMIZE: your-org/your-repo]/stats/code_frequency

5. Commit activity by day:
   gh api repos/[CUSTOMIZE: your-org/your-repo]/stats/commit_activity

6. ALL PR review comments from the last 7 days:
   gh api repos/[CUSTOMIZE: your-org/your-repo]/pulls/comments --paginate --jq '[.[] | select(.created_at >= "[7_DAYS_AGO]")]'

DEEP ANALYSIS:
A) **Contributor Velocity Matrix**: For each contributor — PRs merged, lines changed, review comments given/received. Who's shipping? Who's reviewing? Who's doing both?
B) **Code Churn**: Are we rewriting the same files repeatedly? Flag files with >3 PRs touching them in one week.
C) **PR Lifecycle**: Average time from PR open → first review → merge. Where's the bottleneck?
D) **Review Quality**: Are reviews substantive (comments with suggestions) or rubber stamps (approved with no comments)?
E) **Week-over-Week Trends**: Compare this week's velocity to last week. Accelerating or decelerating?
F) **Technical Debt Signals**: Large PRs with no tests, PRs that touch >10 files, dependency-only PRs.

Return structured data AND insights.

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

Slack MCP が利用可能な場合のみ起動

Deep Slack analysis for last 7 days across key channels.
Analysis period: [7_DAYS_AGO] to [TODAY].

Instructions:
1. Use ToolSearch to load Slack tools
2. Read messages from [CUSTOMIZE: your-team-channel] for the full 7-day window
3. If you have access, also check: [CUSTOMIZE: additional-channels] (e.g., #general, #engineering, #product)

For EACH significant thread (>3 replies or involving decisions):
- Full topic summary
- Key participants
- Decision reached (or explicitly: "no decision reached")
- Action items with owners
- Sentiment (positive/negative/neutral/heated)
- Links to external resources shared

DEEP ANALYSIS:
A) **Communication Patterns**: Who's driving discussions? Who's mostly silent? Any asymmetry?
B) **Decision Velocity**: How many decisions were made vs. how many discussions ended without resolution?
C) **Topic Clustering**: Group discussions by theme (product, engineering, bugs, strategy, etc.)
D) **Unresolved Threads**: List all discussions that need follow-up — no decision, open question, blocked waiting for someone
E) **Sentiment Map**: Overall team mood. Are discussions constructive or frustrated?
F) **External Intel**: All links shared (articles, competitor news, tools) — categorize by relevance

Return structured data AND insights.

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

Linear MCP が利用可能な場合のみ起動

Deep Linear analysis for last 7 days.
Analysis period: [7_DAYS_AGO] to [TODAY].

Instructions:
1. Use ToolSearch to load ALL Linear tools
2. Collect comprehensive data:

   a) All issues updated in last 7 days (mcp__claude_ai_Linear__list_issues)
   b) All issues created in last 7 days
   c) All issues completed in last 7 days
   d) All blocked issues (any date)
   e) Full initiative list with projects (mcp__claude_ai_Linear__list_initiatives)
   f) Detailed status for each initiative (mcp__claude_ai_Linear__get_initiative)
   g) All active cycles (mcp__claude_ai_Linear__list_cycles)
   h) All milestones for active projects (mcp__claude_ai_Linear__list_milestones)
   i) All projects with progress (mcp__claude_ai_Linear__list_projects)
   j) Recent status updates (mcp__claude_ai_Linear__get_status_updates) for each initiative

DEEP ANALYSIS:
A) **Initiative Trajectory**: For each initiative, model whether current velocity will hit the target date. Use issues_completed_per_week vs. issues_remaining / weeks_remaining.
B) **Cycle History**: Compare current cycle progress to previous cycles. Are we improving?
C) **Scope Creep Quantified**: How many issues were added mid-cycle vs. planned at start?
D) **Priority Drift**: Issues that changed priority during the week. Why?
E) **Assignee Load Balance**: Distribution of issues across team members. Overloaded? Underutilized?
F) **Stale In-Progress**: Issues marked "In Progress" for >5 days with no status change.
G) **Dependency Map**: Issues that block other issues. What's the critical path?
H) **Label/Project Distribution**: Where is effort being spent? Does it align with initiative priorities?

Return structured data AND insights.

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

PostHog MCP が利用可能な場合のみ起動

警告：PostHog は非常に大きなデータを返すことがあります。 このエージェントは意図的に負荷が高く設定されています。このスキルがデイリーブリーフより長くかかる理由です。クエリの対象範囲は慎重に設定してください。

Deep PostHog analysis for last 7 days.
Project ID: [CUSTOMIZE: your-posthog-project-id].
Analysis period: [7_DAYS_AGO] to [TODAY].

Instructions:
1. Use ToolSearch to load PostHog tools (search "+posthog")
2. Run these analyses:

   === CORE METRICS (7-day window) ===

   a) Daily visitors, sign-ups, and core events — broken out by day:
      Use mcp__posthog__query-run with HogQL:
      SELECT toDate(timestamp) as day, count(DISTINCT person_id) as unique_users, count() as events
      FROM events WHERE event = '$pageview' AND timestamp >= '[7_DAYS_AGO]'
      GROUP BY day ORDER BY day

   b) Same for sign-ups and core value events (separate queries)

   c) Week-over-week comparison:
      Compare [7_DAYS_AGO to TODAY] vs [14_DAYS_AGO to 7_DAYS_AGO]

   === FUNNEL ANALYSIS ===

   d) Key funnel (sign-up → first core action → repeat):
      Use mcp__posthog__insight-query or HogQL to build a funnel:
      - Step 1: user_signed_up
      - Step 2: [CUSTOMIZE: your_core_event] (first time)
      - Step 3: [CUSTOMIZE: your_core_event] (second time, >24h later)
      Compare this week's funnel to last week's.

   === FEATURE ADOPTION ===

   e) Feature usage matrix:
      SELECT event, count() as uses, count(DISTINCT person_id) as unique_users
      FROM events WHERE timestamp >= '[7_DAYS_AGO]' AND event NOT LIKE '$%'
      GROUP BY event ORDER BY unique_users DESC LIMIT 25

   f) New vs returning user behavior:
      Compare event types for users whose first_seen is within last 7 days vs. older users.

   === ERROR ANALYSIS ===

   g) Error trends:
      Use mcp__posthog__list-errors for the period. Group by error type.

   h) Error-to-deploy correlation:
      For each error spike, check the timestamp against known deploy times (from GitHub merged PR data).

DEEP ANALYSIS:
A) **Growth Trajectory**: At current rate, where will key metrics be in 30/60/90 days?
B) **Funnel Health**: Where do users drop off? Has it improved or degraded vs last week?
C) **Feature Value Matrix**: Which features correlate with retention? (users who use feature X come back more)
D) **New User Experience**: First-session behavior patterns. What do new users do? Where do they get stuck?
E) **Error Impact**: Which errors affect the most users? Which are increasing fastest?
F) **Engagement Segments**: Power users vs casual vs churned. How big is each segment?

Return structured data AND insights with trends.

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

Review ALL meeting notes from the last 7 days.
Analysis period: [7_DAYS_AGO] to [TODAY].

Instructions:
1. Glob for ALL meeting files in [CUSTOMIZE: path/to/meetings/] from the last 7 days
2. Also check [CUSTOMIZE: path/to/checkins/] for daily checkins
3. Read all found files

For EACH meeting, extract the same items as the daily brief agent.

DEEP ANALYSIS:
A) **Action Item Completion Rate**: Of all action items assigned in meetings this week, how many have corresponding GitHub/Linear activity?
B) **Decision Log**: Comprehensive list of every decision made this week, with context and who made it.
C) **Priority Shifts**: Did priorities change during the week? Track what was said Monday vs. Friday.
D) **Commitment Tracking**: Did people do what they said they'd do? (Cross-reference with GitHub/Linear data)
E) **Meeting Effectiveness**: Are meetings producing decisions and action items, or just discussion?

Return structured data AND insights.

フェーズ 2：詳細な統合（約 2〜3 分）

すべてのエージェントが完了した後、オーケストレーターがデータを詳細に相互参照します。

1. デイリーブリーフにある 23 の相互参照パターンすべて（daily-brief.md を参照）

2. 追加の総合分析パターン：

   • 週ごとのベロシティ推移：チームの進捗は加速していますか、それとも減速していますか？その理由は何ですか？
   • イニシアチブの進捗予測：現在のペースで、各イニシアチブは目標を達成できますか？何を変える必要がありますか？
   • チームのキャパシティ評価：今週の実績に基づくと、来週はどの程度の成果が現実的ですか？
   • リスク一覧：すべてのデータソースからリスクを集め、深刻度／発生可能性／担当者を含む統合リスク一覧を作成します
   • 戦略との整合性チェック：チームが開発しているものは、会議で経営陣が話し合った内容と一致していますか？
   • プロダクト・マーケットシグナルの統合：PostHog のデータ、Slack のユーザーフィードバック、会議での顧客に関する議論を組み合わせ、一貫したプロダクトシグナルを導き出します

3. 次の 3 つのドキュメントを生成します：

出力 1：エグゼクティブサマリー（経営陣向け）

• 最大 1 ページ
• 推移を含む主要指標
• イニシアチブの健全性ダッシュボード
• 主要リスク 3 件
• 主な成果 3 件
• 来週注力すべき事項の推奨

出力 2：チームレポート（エンジニアリング向け）

• 今週リリースしたもの（成果を祝いましょう！）
• ベロシティと貢献者の統計
• レビューの健全性（ボトルネック、形式的な承認）
• 停滞している PR とブロックされた課題
• 技術的負債の兆候
• 会議で決まった来週の優先事項

出力 3: プロダクトレポート（ステークホルダー向け）

• トレンドを含むユーザーメトリクス
• ファネル分析
• 機能の採用状況
• 顧客フィードバックの統合（Slack から）
• 成長軌道
• プロダクトのリスクと機会

4. 3 つすべてを [CUSTOMIZE: path/to/briefs/] に保存します：
   • comprehensive-analysis-YYYY-MM-DD.md（完全なレポート）
   • executive-summary-YYYY-MM-DD.md（リーダーシップ向けバージョン）
   • product-report-YYYY-MM-DD.md（ステークホルダー向けバージョン）

フェーズ 3: 出力と配布（約 1〜2 分）

1. エグゼクティブサマリーをユーザーに提示します
2. HackMD への公開を提案します（デイリーブリーフのフェーズ 3.7 と同じパターン）
3. ハイライトを Slack に投稿することを提案します（デイリーブリーフのフェーズ 4 と同じパターン）

---

メタデータテンプレート

---
type: comprehensive-analysis
domain: shared
date: YYYY-MM-DD
analysis_period:
  start: YYYY-MM-DD
  end: YYYY-MM-DD
  days: 7
created: YYYY-MM-DD HH:MM
tags:
  - comprehensive-analysis
  - weekly-review
  - team-intelligence
data_sources:
  github: true
  slack: true/false
  linear: true/false
  posthog: true/false
  meetings: true/false
  braindumps: true/false
metrics:
  prs_merged: X
  prs_opened: X
  commits: X
  active_contributors: X
  issues_completed: X
  issues_created: X
  visitors: X
  visitors_wow_change_pct: X
  signups: X
  core_events: X
  new_errors: X
initiatives:
  - name: "[CUSTOMIZE: Initiative 1]"
    health: on_track / at_risk / off_track
    progress_pct: X
    trajectory: will_hit / at_risk / will_miss
    days_remaining: X
team_velocity:
  this_week: X  # PRs merged
  last_week: X
  trend: accelerating / stable / decelerating
risks:
  - severity: high/medium/low
    description: ""
    owner: ""
    source: ""
---

フォールバック動作

デイリーブリーフと同じです — 各データソースはオプションです。分析は段階的に機能を縮小します。

最小限の有用な構成は GitHub のみです — それでもベロシティ分析、PR ライフサイクルメトリクス、コントリビューター統計、コードチャーン検出を利用できます。

エラーハンドリング

デイリーブリーフと同じ安全ルールに、1 点を追加します：

• コンテキストオーバーフロー保護: いずれかのエージェントが大きすぎると思われるデータ（推定 50k トークン超）を返した場合、警告をログに記録し、エージェントにもっと積極的に要約するよう依頼します。これは PostHog（大規模なダッシュボードダンプ）や Jira（広範な JQL クエリ）で発生する可能性が最も高くなります。