claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 22h ago
スキルOfficialmonitoring

📊add-analytics-instrumentation

プラグイン
amplitude
ソース
GitHub で見る ↗

説明

PR、ブランチ、ファイル、ディレクトリ、または機能に対するエンドツーエンドの アナリティクス計装ワークフロー。 コードを読み込み、トラッキングすべきイベントを検出し、 具体的な計装プランを一括で生成します。 次のような場合に使用: - ユーザーがPRへのアナリティクス追加を希望している - 「このPRを計装して」「このブランチにトラッキングを追加して」 「このファイルにどんなアナリティクスが必要か」 「チェックアウトフローを計装して」「計装ワークフロー全体を実行して」 といったリクエスト、またはコード変更からトラッキングプランの作成を 意図するあらゆるリクエストがあった場合 - ユーザーがPRリンク、ブランチ名、ファイルパス、または機能の説明を提示し、 アナリティクス・イベント・計装について言及した場合 このSkillはアナリティクスワークフローのメインエントリーポイントです。 個別ステップ（diff-intake、discover-event-surfaces、instrument-events）を それぞれ個別に呼び出すよりも、このSkillを優先して使用してください。

原文を表示

End-to-end analytics instrumentation workflow for a PR, branch, file, directory, or feature. Reads the code, discovers what events should be tracked, and produces a concrete instrumentation plan — all in one shot. Use this skill whenever a user wants to add analytics to a PR, asks "instrument this PR", "add tracking to this branch", "what analytics does this file need", "instrument the checkout flow", "run the full instrumentation workflow", or any request that implies going from code changes to a tracking plan. Also trigger when the user gives you a PR link, branch name, file path, or feature description and mentions analytics, events, or instrumentation. This is the main entry point for the analytics workflow — prefer it over calling the individual steps (diff-intake, discover-event-surfaces, instrument-events) separately.

ユースケース

  • ✓PRへのアナリティクス追加を希望している
  • ✓コード変更からトラッキングプランを作成する
  • ✓ブランチにトラッキングを追加する
  • ✓ファイルに必要なアナリティクスを検討する
  • ✓機能の計装ワークフロー全体を実行する

本文（日本語訳）

add-analytics-instrumentation

あなたはアナリティクス計装パイプラインのオーケストレーターです。 ユーザーが計装したい対象を特定し、関連コードを収集して、 パイプラインを実行しトラッキングプランを生成することがあなたの役割です。

パイプライン

ステップ 0: 意図の把握

何かを実行する前に、ユーザーが何を計装したいのかを明確にします。 入力タイプは4種類あります。会話の中でユーザーがすでに提供した情報から推測してください。 本当に曖昧な場合にのみ確認を求めます。

入力タイプ 見分け方 例
PR PR の URL、PR 番号、または「this PR」「my PR」などの表現 instrument PR #42、https://github.com/org/repo/pull/42
Branch ブランチ名、または「this branch」「my branch」「current branch」などの表現 instrument feature/checkout、add tracking to this branch
ファイル / ディレクトリ ファイルパス、ディレクトリパス、または glob パターン instrument src/components/Checkout.tsx、add analytics to src/payments/
機能 特定のコード参照ではなく、機能を自然言語で説明したもの instrument the onboarding flow、add tracking to the checkout experience

推測ルール:

  • ユーザーが URL または #番号 を提供した場合 → PR
  • ユーザーが入力したものがブランチ名らしい場合（/ を含む、拡張子なし、git ブランチと一致する）→ Branch
  • ユーザーが提供したパスがディスク上に存在する場合（ファイルまたはディレクトリ）→ ファイル / ディレクトリ
  • 上記のいずれにも該当せず、入力が説明的な場合 → 機能
  • 過去のメッセージに PR リンク・ブランチ名・ファイルパスがすでに含まれている場合は、改めて確認せずそれを使用する

曖昧な場合は、ユーザーに次のように尋ねます:

何を計装しますか？

  1. 特定のファイルまたはディレクトリ
  2. PR
  3. ブランチ
  4. 機能（説明してください。関連コードを探します）

入力タイプが判明したら、対応するステップに進みます:

  • PR または Branch → ステップ 1（diff-intake）へ
  • ファイル / ディレクトリ → ステップ 1a（直接ファイル読み込み）へ
  • 機能 → ステップ 1b（機能検索）へ

ステップ 1: diff-intake スキル（PR または Branch）

ユーザーの PR またはブランチ参照を指定して diff-intake スキルを呼び出します。

スキルは change_brief YAML ブロックを出力します。

YAML 出力をそのまま取得してください — ステップ 2 でそのまま使用します。 ステップ 2 へスキップします。

ステップ 1a: 直接ファイル読み込み（ファイル / ディレクトリ）

diff-intake は完全にスキップします — 解析すべき diff がありません。 代わりに、ファイルを直接読み込んで change_brief YAML を自分で構築します。

  1. 入力を解決する。 ディレクトリの場合はその中のソースファイルをすべて探します（テスト、設定ファイル、ロックファイル、自動生成コードは除外）。単一ファイルの場合はそのファイルだけを使用します。
  2. 各ファイルを読み込み、そのファイルが何をするか要約します。実装の詳細ではなく、ユーザー向けの動作に焦点を当てます。
  3. 既存の計装を探します。diff-intake と同様のパターンを使用します: track(、trackEvent(、logEvent(、amplitude.track(、ampli.、およびアナリティクス関連のインポート。
  4. change_brief YAML を構築します。analytics_scope: high を設定します（ユーザーが明示的にこれらのファイルの計装を要求しているため、トラッキングを望んでいると見なします）。 primary: feat および classification.types: [feat] を設定します。 各ファイルの要約・レイヤー・既存の計装情報を file_summary_map に記入します。

構築した YAML を使ってステップ 2 へ進みます。

ステップ 1b: 機能検索（機能）

ユーザーが自然言語で機能を説明しています。 関連コードを見つけて change_brief を構築することがあなたの役割です。

  1. git コミット履歴を検索して関連コミットを探します。git log --all --grep="<パターン>" を使用します。これにより関連コミットが見つかります。続いて git コミットの本文を読み、機能と関連ファイルを把握します。結果が十分なら change_brief YAML の生成に進みます。
  2. コードベースを検索して説明された機能に関連するファイルを探します。以下を組み合わせて使用します:
    • 機能説明のキーワード（コンポーネント名、ルートパス、関数名、ドメイン用語）を grep で検索
    • 想定されるファイルパスを glob で検索（例: **/checkout/**、**/onboarding/**）
    • ルート定義、ナビゲーション設定、またはインデックスファイルを読んでエントリーポイントを探す
  3. change_brief YAML を構築します。

構築した YAML を使ってステップ 2 へ進みます。

ステップ 2: discover-event-surfaces

ステップ 1 で得た change_brief YAML を渡して discover-event-surfaces スキルを呼び出します。

スキルは event_candidates YAML ブロックを出力します。 候補が0件の場合は処理を停止し、変更はユーザー向けの影響があるものの、 計装する価値のあるイベントは見つからなかったことをユーザーに伝えます。

event_candidates が空の場合はここで処理を停止し、計装するものがない旨をユーザーに伝えます。

YAML 出力をそのまま取得してください — ステップ 3 で使用します。

ステップ 3: instrument-events

ステップ 2 で得た event_candidates YAML を渡して instrument-events スキルを呼び出します。

スキルは trackingPlan JSON を出力します。 内容は、すべての重要（優先度 3）イベントに対する、正確なファイル位置・トラッキングコード・プロパティ定義です。

結果の提示

ステップ 3 が完了したら、トラッキングプランをユーザーに提示します。 各イベントについて以下を簡潔に説明します:

  • 何をトラッキングするか、そしてなぜ重要か
  • トラッキング呼び出しの場所（ファイル + 関数）
  • 送信するプロパティ

その後、調整が必要かどうか、または実装に進むかどうかをユーザーに確認します。

エラーハンドリング

いずれかのステップが失敗した場合（例: PR が存在しない、git コマンドのエラー、解析対象ファイルがないなど）、 エラーを明確に表示して処理を停止します。 不完全なデータで処理を続行しないでください。

原文（English）を表示

add-analytics-instrumentation

You are the orchestrator for the analytics instrumentation pipeline. Your job is to figure out what the user wants to instrument, gather the relevant code, and run the pipeline to produce a tracking plan.

Pipeline

Step 0: Capture intent

Before running anything, determine what the user wants to instrument. There are four input types — infer the type from what the user has already provided in the conversation. Only ask if it's genuinely ambiguous.

Input type How to recognize it Example
PR A PR URL, PR number, or phrases like "this PR", "my PR" instrument PR #42, https://github.com/org/repo/pull/42
Branch A branch name or "this branch", "my branch", "current branch" instrument feature/checkout, add tracking to this branch
File / Directory A file path, directory path, or glob pattern instrument src/components/Checkout.tsx, add analytics to src/payments/
Feature A natural-language description of functionality, not a specific code reference instrument the onboarding flow, add tracking to the checkout experience

Inference rules:

  • If the user provided a URL or #number → PR
  • If the user provided something that looks like a branch name (contains /, no file extension, matches a git branch) → Branch
  • If the user provided a path that exists on disk (file or directory) → File / Directory
  • If none of the above match and the input is descriptive → Feature
  • If the conversation already contains a PR link, branch name, or file path from earlier messages, use that instead of asking again

If ambiguous, ask the user:

What would you like to instrument?

  1. A specific file or directory
  2. A PR
  3. A branch
  4. A feature (describe it and I'll find the relevant code)

Once you know the input type, proceed to the appropriate step:

  • PR or Branch → go to Step 1 (diff-intake)
  • File / Directory → go to Step 1a (direct file read)
  • Feature → go to Step 1b (feature search)

Step 1: diff-intake skill (PR or Branch)

Invoke the diff-intake skill with the user's PR or branch reference.

It produces a change_brief YAML block.

Capture the full YAML output — step 2 consumes it verbatim. Skip to Step 2.

Step 1a: Direct file read (File / Directory)

Skip diff-intake entirely — there's no diff to analyze. Instead, build the change_brief YAML yourself by reading the files directly.

  1. Resolve the input. If a directory, find all source files in it (skip tests, config, lock files, generated code). If a single file, just use that.
  2. Read each file and summarize what it does — focus on user-facing behavior, not implementation details.
  3. Scan for existing instrumentation using the same patterns as diff-intake: track(, trackEvent(, logEvent(, amplitude.track(, ampli., and analytics-related imports.
  4. Build the change_brief YAML with analytics_scope: high (the user explicitly asked to instrument these files, so assume they want tracking). Set primary: feat and classification.types: [feat]. Populate file_summary_map with each file's summary, layer, and existing instrumentation.

Proceed to Step 2 with the YAML you built.

Step 1b: Feature search (Feature)

The user described a feature in natural language. Your job is to find the relevant code, then build a change_brief.

  1. Search git commit history to find related commits. Use git log --all --grep="<patterns>". This will find relevant commits. Then read the git commit body to understand the feature and relevant files. If the results are good, then proceed to generating the change_brief YAML
  2. Search the codebase for files related to the described feature. Use a combination of:
    • Grep for keywords from the feature description (component names, route paths, function names, domain terms)
    • Glob for likely file paths (e.g., **/checkout/**, **/onboarding/**)
    • Read route definitions, navigation configs, or index files to find entry points
  3. Build the change_brief YAML.

Proceed to Step 2 with the YAML you built.

Step 2: discover-event-surfaces

Invoke the discover-event-surfaces skill, passing the change_brief YAML from step 1.

It produces an event_candidates YAML block. If there are zero candidates, stop and tell the user the change has user-facing impact but no events worth instrumenting were identified.

If event_candidates is empty, stop here and tell the user there's nothing to instrument.

Capture the full YAML output — step 3 consumes it.

Step 3: instrument-events

Invoke the instrument-events skill, passing the event_candidates YAML from step 2.

It produces a trackingPlan JSON with exact file locations, tracking code, and property definitions for every critical (priority 3) event.

Presenting the result

After step 3 completes, present the tracking plan to the user. Walk through each event briefly:

  • What it tracks and why it matters
  • Where the tracking call goes (file + function)
  • What properties it sends

Then ask if they want to adjust anything or proceed to implementation.

Error handling

If any step fails (e.g., the PR doesn't exist, git commands error, no files to analyze), surface the error clearly and stop. Don't try to continue with incomplete data.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。