Agent skill · posthog
checking-member-access
Explains what a member or a role can do in a PostHog project, using the access control MCP tools. Use when the user asks what someone can see or edit, who can edit dashboards or feature flags, why a member can or cannot open a dashboard, notebook or table, what a role grants, which properties are hidden from someone, or how the project's default access is set. Covers what each level means, how the stored rule, the enforced level and the inherited access relate, what the null values mean, which tool answers which question, and when the answer needs the role tools too.
What it needs
About 7k tokens when loaded.
What this skill does
Checking member access Use this skill to answer "what can this person do here?" from the access control tools. The tools return the enforced level and where it comes from. This skill is for reading them correctly. When to use this skill "What can this member do in this project?" / "Can this member edit feature flags?" "Who can edit dashboards?" / "Who has no access to experiments?" "Why can't this member open this dashboard?" / "Which tables is this role restricted from?" "Which properties are hidden from the support role?" "What does the analyst role grant?" / "What is the default access in this project?" Not for changing rules. The read tools cannot write, and the settings page is where rules are edited. Plan availability Free and pay-as-you-go plans have no access control, and the access control tools are not offered to them. If the tools are missing from the catalog, say that the plan does not include access control and suggest upgrading to the Boost plan. Link the plan comparison: https://posthog.com/platform-packages. Boost and Scale include the default levels and rules for single members on the project, on tools, on objects and on properties. Roles exist on every plan, but role rules are an Enterprise feature: they can be set and are enforced only there, and the three role access tools are offered only there. If the tools are missing, say that role-based access control needs the Enterprise plan, with the same link. On other plans a member's roles never change the enforced level. The tools do not say which plan the organization is on. A sourcesubject of role anywhere in a members-list result proves that role rules are enforced. Without that, ask the user whether the organization is on Enterprise before walking roles in step 4 of the workflow. How access resolves Scopes. The project itself, then each tool (dashboard, insight, featureflag, notebook, experiment, warehouseobjects, and so on), then single objects inside a tool, then person and event properties. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills posthog/checking-member-access