diff-intake
Reads a PR or branch diff and produces a structured YAML change brief for downstream analytics instrumentation skills. Use this as the first step whenever a user shares a PR link, branch comparison, or raw diff and wants to understand what changed, what needs tracking, or how to instrument a feature. Trigger on phrases like "review this PR", "what changed in this branch", "help me instrument this diff", "check analytics coverage for this change", or any request to start the analytics review workflow.
- Installs
- 43.9K
- Last 24h
- +1.1K
- Trending rank
- #323
- Security
- Warn
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/amplitude/mcp-marketplace --skill diff-intake- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads diff-intake automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
diff-intake
Follow this skill step by step. You are step 1 of the analytics instrumentation workflow. Produce a compact YAML change brief that downstream skills (discover-event-surfaces, instrument-events) will consume. Keep the output machine-readable and precise — no prose around the YAML block.
Step 1: Gather changed files and categorize
Fetch the list of changed files from the source, then categorize each one.
Fetching changes
- PR URL
gh pr view <number-or-url>gh pr view <pr-number> --json files --jq '.files[] | "\(.path)\t+\(.additions) -\(.deletions)\t"' - Branch comparison
git log <main|master>..<branch>git diff --stat <main|master>..<branch> - Ambiguous mention (PR number, branch name): infer the right form and fetch without asking unless auth fails.
Categorize files
Assign each file to a category based on its path:
- Core Logic: application source (e.g. src/auth/login.py, database/models.ts)
- Generated: anything with
generatedin its path - Testing: test files
- Config / Dependencies: package.json, docker-compose.yml, etc.
- Documentation: READMEs, docs/
- Noise: lock-files, .svg, auto-generated migrations
For each file, record: path, category, change type (Added / Modified / Deleted), and analytics likelihood (1–5).
Step 2: Build the file summary map
Read every single Core Logic file and create the file summary map. Only process and include Core Logic files.
Fetching detailed diffs
- PR
gh pr view <number-or-url> --json baseRefOid,headRefOidUsing the response, get a detailed diffgit diff <baseRefOid>...<headRefOid> -- <file1> <file2> <file_n> - Branch comparison
git diff main..feature/foo -- <file1> <file2> <file_n>
For each file, record
summary— 2-line summary of what changedstack— frontend, backend, or shared
Also derive user-facing changes and touched surfaces
While reading the diff and the changed files, also produce the higher-level signals that downstream event discovery needs:
user_facing_changes— a flat list of concrete behavior changes that matter to a user, PM, or analyst. Each item should describe what a user can now do, see, or experience differently. Omit purely internal refactors.surfaces.components— the UI components, routes, pages, handlers, or other interaction surfaces directly involved in those user-facing changes. Prefer likely instrumentation points over low-level helpers.
For each surface, record:
name— component, route, page, hook, or surface namefile— repo-relative pathchange—added,modified, ordeleted
If the change is backend-only or has no clear interactive surface, omit
surfaces.components rather than inventing one.
Step 3: Classify the overall change
Infer the change type and analytics scope:
| Type | Analytics implication |
|---|---|
| feat | High — new surfaces likely need tracking |
| fix | Low–Medium — may affect existing event conditions |
| refactor | Low — tracking paths may move, regression risk |
| perf | Low — usually no tracking impact |
| revert | Medium — need to check what tracking was lost |
| style / docs / test / build / ci / chore | None — skip analytics analysis |
analytics_scope = highest implication present:
none— only no-impact typeslow— only perf/refactormedium— fixhigh— any feature or capability addition
If analytics_scope is none, emit the brief and note that downstream skills are not needed.
Step 4: Emit the YAML brief
Output only the YAML block — no prose before or after. Follow the format exactly. List each file individually in file_summary_map (no globs).
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
FAQ
What does the diff-intake skill do?
Reads a PR or branch diff and produces a structured YAML change brief for downstream analytics instrumentation skills. Use this as the first step whenever a user shares a PR link, branch comparison, or raw diff and wants to understand what changed, what needs tracking, or how to instrument a feature. Trigger on phrases like "review this PR", "what changed in this branch", "help me instrument this diff", "check analytics coverage for this change", or any request to start the analytics review workflow.
How do I install diff-intake?
Run npx skills add https://github.com/amplitude/mcp-marketplace --skill diff-intake in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/diff-intake/ (personal) or .claude/skills/diff-intake/ (project).
Which AI agents can use diff-intake?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is diff-intake safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk flagged items to review. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains diff-intake?
It is published by amplitude in amplitude/mcp-marketplace. It has 43,917 recorded installs.
More from amplitude/mcp-marketplace
discover-analytics-patterns
amplitude/mcp-marketplace
Discovers how analytics tracking calls are actually written in this codebase — the concrete SDK calls, function signatures, and import patterns used to send events. Use this skill whenever you need to understand the existing analytics instrumentation patterns before adding new tracking, when someone asks "how do we track events here?", "show me the analytics setup", "what's the analytics pattern in this codebase?", or any time the instrument-events or discover-event-surfaces skills are about to run and you need to know the correct coding style to follow. Outputs a deduplicated list of patterns with generalized examples and the file paths where each pattern appears, plus the dominant event and property naming conventions inferred from those call sites. Always use this skill before writing any analytics instrumentation code.
add-analytics-instrumentation
amplitude/mcp-marketplace
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.
discover-event-surfaces
amplitude/mcp-marketplace
Given a changebrief YAML (output from diff-intake), generates an exhaustive list of candidate analytics events to instrument. Takes the perspective of an engineer with a PM mindset — surfaces everything worth considering so a PM can decide what actually matters. Use this as step 2 of the analytics instrumentation workflow, immediately after diff-intake produces a changebrief. Trigger whenever a user has a changebrief YAML and wants to know what analytics events to add, or asks "what should I track for this PR", "what events should I instrument", "generate event candidates", or any request to surface analytics coverage gaps for a code change.
instrument-events
amplitude/mcp-marketplace
Given eventcandidates YAML (output from discover-event-surfaces), generates a concrete instrumentation plan for priority-3 (critical) events. Acts as a Software Architect: discovers existing analytics patterns in the codebase, reads the hinted files to determine what variables are in scope, designs minimal chart-useful properties, and identifies the exact insertion point for each tracking call. Outputs a structured JSON trackingPlan. Use this as step 3 of the analytics instrumentation workflow, after discover-event-surfaces. Trigger whenever a user has eventcandidates and wants to generate tracking code, asks "instrument these events", "generate tracking plan", "add analytics for these events", "where should I put the tracking calls", or any request to turn event candidates into concrete implementation guidance.
taxonomy
amplitude/mcp-marketplace
Source of truth for event taxonomy generation, data auditing, and governance best practices in Amplitude. Use when an agent needs to create, validate, audit, score, or recommend improvements to event tracking plans, naming conventions, property standards, data quality, or deprecation workflows, including checking a plan against the customer's own standard (Data → Settings naming conventions and AI Context). Covers naming rules, property standards, scoring frameworks, safe metadata operations, deprecation procedures, and AI readiness guidance.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.