mcpField
M
modifying-taxonomic-filter

modifying-taxonomic-filter

github.com/posthog开发40.5k171 次安装今天更新
代码仓库

关于 modifying-taxonomic-filter

这是一项修改 PostHog TaxonomicFilter 的开发技能，该组件用于选择分析和配置对象。它以证据为依据，指导维护旧版与重建界面的一致性、遥测契约、测试及效果衡量。

主要功能

  1. 01基于证据的变更指引
  2. 02旧版与重建界面保持一致
  3. 03遥测契约保护
  4. 04按变更类型定位参考资料
  5. 05测试与衡量检查清单

适用场景

  1. 01添加或移除筛选分组或标签页
  2. 02调整搜索、最近项目或排序
  3. 03调查筛选器故障报告
  4. 04为变更规划测试与指标

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/posthog/posthog --skill modifying-taxonomic-filter

安装后在 Claude Code 中输入/modifying-taxonomic-filter确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
architecture.md
call-sites-and-blast-radius.md
common-pitfalls.md
contested-decisions.md
design-principles.md
evidence-sources.md
failure-modes.md
feature-inventory.md
measuring-changes.md
performance.md
product-reality.md
refreshing-product-reality.md
surfaces-and-mirroring.md
telemetry-contract.md
testing-patterns.md

详细介绍

修改 TaxonomicFilter

TaxonomicFilter 是用户用来选择“PostHog 了解的任何事物”的选择器：事件、属性、操作、群组、用户组。 它是进入几乎所有分析、标记和回放配置的入口。 代码位于 frontend/src/lib/components/TaxonomicFilter/。

本文档是索引。 请先完整阅读，然后只加载修改所需的参考资料。 参考资料中包含详细信息和证据。

四条准则

  1. 依据证据做决定，而非凭喜好。 每个参与过此选择器开发的人都有强烈的看法，其中一些是错的。 行动前，请对照 product-reality 和 evidence-sources 核实说法，包括问题、Slack 或本指南中的说法。
  2. 降低用户实际选择项的优先级属于回归，即使所有测试都通过也不例外。 调整排序、推荐项、位置 0 和默认标签页，都需要明确的人工批准。
  3. 两个界面，两套实现。 重建版重新实现了旧版数据层。 大多数行为变更都需要同时应用于两者，否则两条实现会出现分歧。 请参阅 surfaces-and-mirroring。
  4. 遥测是一项公开契约。 仪表板和回放扫描器会读取这些事件。 切勿悄然重命名或改变属性用途。 如果捕获调用与契约不一致，telemetryContract.test.ts 会失败，因此请在同一个 PR 中更新契约。 请参阅 telemetry-contract。

五行概览（更新于 2026-10-15）

  • 大多数活跃的旧版打开操作最终都会产生一次选择（约 85%），而且大多数用户从未切换分类标签页（约 96%）。
  • “建议”视图承载了约 70% 的旧版选择。 其中略多于一半来自最近使用记录。
  • 位置很重要：约 52% 的旧版选择位于第 0 行，约 85% 位于前三行。
  • 最常见的问题是先选择一个分类，然后搜索却找不到任何结果。 大多数无结果的搜索都是在错误的标签页中搜索了正确的词。
  • 与速度慢相比，客户更多地反馈界面损坏和条目缺失。

详情、时间窗口和注意事项：请参阅 product-reality。 这些数字是一个快照。 如需当前数值，请在 PostHog 数据目录中运行 taxonomic_filter_* 指标（参见 refreshing-product-reality）。

根据你要修改的内容查阅资料

你要修改的内容先阅读
排序、推广、Suggested、默认标签页product-reality、design-principles、contested-decisions
添加、移除或隐藏分组或标签页feature-inventory、surfaces-and-mirroring、call-sites
搜索、空状态、无结果后的恢复failure-modes、design-principles
最近使用、固定、已记住的状态contested-decisions、design-principles
加载、延迟、分页、错误performance、failure-modes
遥测或仪表板telemetry-contract、measuring-changes
任何重构architecture、common-pitfalls、testing-patterns
无法复现的错误报告surfaces-and-mirroring（先确认所在界面）
判断某项更改是否值得evidence-sources、measuring-changes

工作流程

  1. 说明用户遇到的问题。 涉及哪个界面、哪些用户、出了什么问题。 从证据中查找，而不只依据请求。 参见 evidence-sources。
  2. 评估影响范围。 使用遥测数据中的比例。 如果一项更改仅对 0.1% 的打开操作有帮助，却会给 Suggested 视图带来风险，那就不值得做。
  3. 检查适用的原则和有争议的决策。 如果你的更改会推翻已有文档记录的决策，请说明并提供证据。
  4. 在两个界面中都进行更改，或者明确说明原因。
  5. 在你修改过的调用点使用 React Testing Library 测试锁定行为。 Agent 认为这个组件容易混淆；RTL 测试是最快的防护手段。 参见 testing-patterns。
  6. 在合并前决定如何确认更改生效。 排序或默认值更改应通过带有指标和护栏的功能开关发布。 参见 measuring-changes。

变更前检查清单

  • 用户问题与证据（遥测数据、回放、工单）相关联
  • 变更已同步到旧版和重建版，或已说明差异
  • 如果更改了标签页或分组，已测试两种界面
  • 两个遥测发送端共享的负载仍保持一致
  • 排序、置顶、位置 0 或默认标签页：需人工签核
  • 搜索或加载：已验证计划边界，可选请求不会延迟结果
  • 已明确成功指标和护栏指标
  • 如果更改了事实，请更新 product-reality
hogli test frontend/src/lib/components/TaxonomicFilter/

保持此技能诚实：如果数据与之矛盾，请在同一个 PR 中修正此技能。 当数据超过约三个月时，使用 refreshing-product-reality 刷新数据。

评论

支持 Markdown