mcpField
D
diff-intake

diff-intake

github.com/amplitudeデータ・データベース4646.1k 回インストール5 日前に更新
リポジトリ

diff-intake について

PRやブランチの変更を調べ、分析計測ワークフローの後続工程が使う構造化YAMLの変更概要を出力するスキルです。ファイルを分類し、主要なロジック変更と計測への関連性を評価します。

主な機能

  1. 01変更ファイルの収集
  2. 02用途別のファイル分類
  3. 03主要ロジック差分の要約
  4. 04ユーザー向け変更の特定
  5. 05分析計測範囲の分類

活用シーン

  1. 01イベント発見に向けたPRの準備
  2. 02ブランチ変更の計測影響の確認

インストール

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

$npx skills add https://github.com/amplitude/mcp-marketplace --skill diff-intake

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

詳細

diff-intake

このスキルを順を追って実行してください。 あなたは分析計測ワークフローのステップ1を担当します。後続のスキル（discover-event-surfaces、 instrument-events）が利用する、簡潔な変更概要をYAML形式で作成してください。出力は機械可読かつ 正確なものにし、YAMLブロック以外の文章は含めないでください。

Step 1: 変更ファイルを収集して分類する

変更ファイルの一覧をソースから取得し、それぞれを分類します。

変更の取得
  • PR URL gh pr view <number-or-url> gh pr view <pr-number> --json files --jq '.files[] | "\(.path)\t+\(.additions) -\(.deletions)\t"'
  • ブランチ比較 git log <main|master>..<branch> git diff --stat <main|master>..<branch>
  • 曖昧な指定（PR 番号、ブランチ名）：認証に失敗しない限り、確認を求めず適切な形式を推測して取得します。
ファイルの分類

パスに基づいて各ファイルを分類します。

  • コアロジック：アプリケーションのソース（例：src/auth/login.py、database/models.ts）
  • 生成物：パスに generated を含むもの
  • テスト：テストファイル
  • 設定／依存関係：package.json、docker-compose.yml など
  • ドキュメント：README、docs/
  • ノイズ：ロックファイル、.svg、自動生成されたマイグレーション

各ファイルについて、パス、カテゴリ、変更タイプ（Added／Modified／Deleted）、分析可能性（1～5）を記録します。

Step 2: ファイル要約マップを作成する

すべてのコアロジックファイルを読み、ファイル要約マップを作成します。 コアロジックファイルのみを処理し、含めてください。

詳細な差分の取得
  • PR gh pr view <number-or-url> --json baseRefOid,headRefOid 応答を使って、詳細な差分を取得します。 git diff <baseRefOid>...<headRefOid> -- <file1> <file2> <file_n>
  • ブランチ比較 git diff main..feature/foo -- <file1> <file2> <file_n>
ファイルごとに記録する項目
  • summary — 変更内容の2行要約
  • stack — frontend、backend、または shared
ユーザー向けの変更と関連サーフェスも導き出す

差分と変更ファイルを確認しながら、後続のイベント検出に必要な、より上位のシグナルも作成します。

  • user_facing_changes — ユーザー、PM、アナリストに関係する具体的な動作変更のフラットなリスト。各項目には、ユーザーが新たに実行できること、見られること、または異なる形で体験できることを記述します。内部的なリファクタリングのみの変更は除外します。
  • surfaces.components — それらのユーザー向け変更に直接関わる UI コンポーネント、ルート、ページ、ハンドラー、その他の操作サーフェス。低レベルのヘルパーよりも、計測箇所として適切と思われるものを優先します。

各サーフェスについて、次の項目を記録します。

  • name — コンポーネント、ルート、ページ、フック、またはサーフェスの名前
  • file — リポジトリ相対パス
  • change — added、modified、または deleted

変更がバックエンドのみの場合、または明確な操作サーフェスがない場合は、作り上げずに surfaces.components を省略します。

Step 3: 変更全体を分類する

変更タイプと分析スコープを推測します。

TypeAnalytics implication
featHigh — new surfaces likely need tracking
fixLow–Medium — may affect existing event conditions
refactorLow — tracking paths may move, regression risk
perfLow — usually no tracking impact
revertMedium — need to check what tracking was lost
style / docs / test / build / ci / choreNone — skip analytics analysis

analytics_scope = 該当する最も高い影響度：

  • none — 影響のないタイプのみ
  • low — perf／refactor のみ
  • medium — fix
  • high — 機能または能力の追加を含む

analytics_scope が none の場合は、概要を出力し、後続のスキルが不要であることを記載します。

ステップ 4：YAML の概要を出力する

YAML ブロックのみを出力してください。前後に説明文を付けないでください。形式に正確に従ってください。 file_summary_map には、各ファイルを個別に記載してください（ワイルドカードは使用しないでください）。

change_brief:
  classification:
    primary: feat           # dominant conventional commit type
    types: [feat, fix]      # all types detected
    analytics_scope: high   # none | low | medium | high
    stack: frontend         # frontend | backend | fullstack
  summary: "One sentence describing the overall change"
  user_facing_changes:
    - "Users can now upload an avatar with drag-and-drop and preview it before saving."
  surfaces:
    components:
      - name: "AvatarUpload"
        file: "src/components/AvatarUpload.tsx"
        change: modified
  file_summary_map:         # each entry includes a layer field
    - file: "src/components/AvatarUpload.tsx"
      summary: "New component for avatar upload with drag-and-drop and preview"
      layer: frontend       # frontend | backend | shared
    - file: "src/api/upload.ts"
      summary: "Upload endpoint handler, validates file type and persists to S3"
      layer: backend

コメント

Markdown 対応