在添加埋点前先摸清代码库现有的分析事件写法与命名规范

当你需要了解代码库中分析埋点调用实际是怎么写的（SDK 调用、函数签名、导入方式、事件与属性命名约定）时使用。

适用场景

解决思路

1. 先检查仓库根目录或正在埋点的子目录下是否存在 `.amplitude/instrumentation-agent-context.md`，若存在则读取它及其引用的仓库相对路径文件；其中声明的命名约定、属性标准、SDK/封装模式属于客户指令，优先级高于后续一切推断，记录它们并跳过其覆盖范围的推断；若不存在则继续。
2. 若 Amplitude MCP 已连接：检查已连接的目录，用其当前的 taxonomy reader 拉取项目中的事件名样本，只遵循该 reader 声明的 schema；当它支持调用方归属时，用 YAML frontmatter 中的 `name` 标识本技能；从结果中挑选几个有代表性的非系统产品事件，再用其事件属性读取能力查看真实属性名，作为主要命名参考。
3. 不要从带方括号前缀的 Amplitude 系统名（如 `[Amplitude]`、`[Guides-Surveys]`、`[Assistant]`、`[Experiment]`）推断事件或属性的命名约定，检测模式时排除这些；若 MCP 样本被系统名主导或证据不足，则回退到代码库推断命名。
4. 用 Grep 在代码库中搜索采样到的非系统事件名，定位真实的埋点调用点。
5. 若 Amplitude MCP 不可用（回退方案）：用 Grep 搜索这些信号——`\.track\(`（通用 `.track()` 方法调用）、`ampli\.`（Ampli 类型化 SDK 调用）、`amplitude\.track\|amplitude\.logEvent`（直接调用 Amplitude SDK）、`sendEvent`（自定义封装方法名）、`from.*amplitude\|import.*amplitude\|require.*amplitude`（导入语句）、`https://api2\.amplitude\.com/2/httpapi`（HTTP API 调用）。
6. 主动查找自定义分析封装——代码库常把原始 SDK 包在 `trackEvent()`、`track()` 之类的工具函数或 `useAnalytics()`、`useTracking()` 之类的 React hook 中；通过查找内部调用 Amplitude 的函数来搜索它们。把每个封装当作独立于底层 SDK 调用的单独模式，即使它最终调用 `amplitude.track()`；工程师遇到封装时会用封装而非原始 SDK，所以封装是更重要的模式。
7. 查找封装的方法：搜索导入了 Amplitude SDK 的文件，再检查这些文件中是否导出了被代码库其他部分导入并用于埋点的函数或 hook。
8. 排除测试文件（`.test.`、`.spec.`、`__tests__`）和 mock 文件，除非某模式只在这些文件中出现。
9. 按模式分组：两个调用点若共享相同的库/SDK/被调函数、方法名、参数结构（即使事件名或属性不同），则属于同一模式；例如 `amplitude.track('Page Viewed', { page: '/home' })` 与 `amplitude.track('Button Clicked', { label: 'signup' })` 是同一模式。
10. 始终把直接 SDK 调用、Ampli 类型化方法、自定义封装分开为不同模式，例如 `amplitude.track(...)`、`ampli.pageViewed(...)`、`trackEvent(...)` 三者各不相同；记录封装模式时注明它包装了什么（如“包装 `amplitude.track()` 的自定义 hook”），让工程师理解分层。
11. 分别解析两个约定：`event_naming_convention`（埋点代码中事件名的大小写、分隔符、词序、前缀和时态，如 `Title Case`、`snake_case`、`[Prefix] Action`、对象优先还是动作优先）与 `property_naming_convention`（事件属性的大小写、分隔符及常见前后缀模式，如 `snake_case`、`camelCase`、`*_id`、`is_*`、扁平键还是嵌套对象）。
12. 按严格优先级解析命名约定：1) 仓库埋点上下文文件（`.amplitude/instrumentation-agent-context.md`）中明确声明的事件或属性命名约定直接胜出，记录并跳过其指定范围的推断，仅当文件缺失或未提及命名时才向下；2) Amplitude MCP——若 taxonomy reader 对几个有代表性的非系统事件返回的事件名和属性名显示出明显的主导约定则采用，不得用带方括号的 Amplitude 系统名作为命名证据；3) 代码库——若 MCP 证据不可用、稀疏或不一致，则从仓库中邻近的真实埋点调用点推断主导约定，若存在多种约定则指出主导者并说明有意义的局部例外；4) 最后回退到 `../taxonomy/SKILL.md` 的 `taxonomy` 技能。
13. 不要猜测；若检查完这些来源后一个或两个约定仍不清晰，明确说明。
14. 输出时先给出简短的约定部分，再列出每个唯一模式：以 YAML 输出 `event_naming_convention` 和 `property_naming_convention`（依次取自仓库上下文文件、MCP、代码库、taxonomy 技能，或写 `insufficient evidence`）。
15. 对每个唯一模式输出一个区块，格式为：`### Pattern: <简短描述性名称>`，包含 **Description**（该模式做什么、在此代码库中通常何时使用，如“用于 React 前端各处的用户行为埋点”）、**Example**（泛化示例，含所需 import 和带占位名的代表性埋点调用）、**Relevant paths**（相关文件路径列表）。
16. 按最常见（文件路径最多）到最不常见排列模式；若两个模式总是一起使用（如 import 加调用），在同一个示例中一起展示。
17. 若用任何搜索策略都找不到埋点调用，明确说明；建议用户检查项目中是否已设置 Amplitude（或其他分析库），并在相关时主动提出搜索其他分析库（Segment、Mixpanel、PostHog 等）。

适用边界 · 注意事项

• 代码库中根本没有任何分析埋点调用时（此时应报告未找到并建议检查是否已接入分析库）。
• 只需要知道存在哪些事件、而不需要了解埋点代码写法时（本技能关注的是“怎么写”，不是“有哪些事件”）。
• 尚未确定要遵循的命名约定、且仓库上下文文件与 MCP 证据都缺失或矛盾时，不应强行推断，应明确说明证据不足。