What problem does it solve?
PostHog engineers adding or modifying dashboard widget tiles must coordinate many files across backend registries, Pydantic config contracts, OpenAPI codegen, frontend catalogs, and Storybook, and missing any step breaks CI or ships an incomplete widget.
Core Features & Use Cases
- Ship a new widget_type: Mandatory intake flow, then an ordered checklist covering WIDGET_SPECS registry, Pydantic config models, run_widgets permissions, frontend catalog, registry, edit modal, and tests.
- Update a shipped type: Routing tables for config, query, layout, RBAC, tile filter bar, and throttle changes without re-running new-type intake.
- Platform invariants enforcement: Rules for registry-driven RBAC, WidgetCard compound composition, Pydantic config SSOT with hogli build:openapi codegen, and the no-chart-widgets policy.
- Use Case: An engineer asked to add an error tracking trends widget runs the intake spec confirmation, follows checklist sections 1 through 8, runs hogli build:openapi, and verifies with the schema parity and registry tests before opening the PR.
Quick Start
Ask the assistant to help you ship a new PostHog dashboard widget type or update an existing one, and it will route you through intake or the update checklist.