skills/skills-store/SKILL.md
Discover and use shared team skills stored in PostHog. Use when the user asks to list, browse, load, or manage "shared skills", "team skills", or references the "skills store" / "skill store".
npx skillsauth add posthog/ai-plugin skills-storeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Skills are reusable agent workflows stored in PostHog following the Agent Skills specification — a body of instructions (SKILL.md) plus optional bundled files (scripts, references, assets), structured metadata, and an allowed_tools list.
PostHog is the primary store for team-shared skills — always use the PostHog MCP skill tools to manage them.
| Tool | Purpose |
| -------------------------------- | ---------------------------------------------------------- |
| posthog:llma-skill-list | List all available skills (Level 1 — names + descriptions) |
| posthog:llma-skill-get | Fetch a skill by name (Level 2 — body + file manifest) |
| posthog:llma-skill-file-get | Fetch a single bundled file by path (Level 3 — on demand) |
| posthog:llma-skill-create | Store a new skill (optionally with bundled files) |
| posthog:llma-skill-update | Publish a new version (body, edits, or file_edits) |
| posthog:llma-skill-file-create | Add one bundled file to a skill (publishes a new version) |
| posthog:llma-skill-file-delete | Remove one bundled file from a skill |
| posthog:llma-skill-file-rename | Rename one bundled file (move without rewriting content) |
| posthog:llma-skill-duplicate | Duplicate an existing skill under a new name |
| posthog:llma-skill-archive | Archive all versions of a skill by name (cannot be undone) |
Skills use progressive disclosure: discover by description, fetch the body only when relevant, and pull individual files on demand. Do not fetch every file eagerly.
List all available skills:
posthog:llma-skill-list
{}
Search by keyword (matches name and description):
posthog:llma-skill-list
{ "search": "fractal" }
llma-skill-list returns only name + description — never the body. Use descriptions to decide which skill to fetch. The whole point of descriptions is that you can pick the right skill without loading any bodies.
posthog:llma-skill-get
{ "skill_name": "make-fractals" }
The response contains:
body — the full SKILL.md instructions (read these like system instructions for the task)license, compatibility, allowed_tools, metadata — spec fieldsfiles[] — manifest of bundled files (path + content_type only, not content)Read body and follow it. Treat it as your system instructions for this task.
When the body references a script or reference doc, pull it on demand:
posthog:llma-skill-file-get
{ "skill_name": "make-fractals", "file_path": "scripts/mandelbrot.py" }
Only fetch files you actually need. If the body's decision tree points at one script, don't preload the others.
Follow the Agent Skills specification when creating skills:
name — kebab-case, max 64 chars, no leading/trailing/consecutive hyphensdescription — explain what it does AND when to use it. Include keywords agents will search for. This is the only thing visible at discovery time — make it count.body — keep under ~500 lines. Move detailed reference material, SQL, scripts, and long examples into bundled files so the body stays scannable.scripts/ for executable code, references/ for docs, assets/ for templates/data. Agents pull these on demand via llma-skill-file-get, so splitting keeps context lean.Bundled files are optional and can be included in a single create call:
posthog:llma-skill-create
{
"name": "make-fractals",
"description": "Generate fractal images as PNGs. Use when the user asks to make, render, or visualize fractals.",
"body": "# make-fractals\n\nWhen to use... Workflow... Output contract...",
"license": "MIT",
"compatibility": "Requires Python 3.10+ with Pillow and numpy",
"allowed_tools": ["Bash", "Write"],
"metadata": { "author": "posthog", "category": "visualization" },
"files": [
{ "path": "scripts/mandelbrot.py", "content": "...", "content_type": "text/x-python" },
{ "path": "references/primer.md", "content": "# Primer\n...", "content_type": "text/markdown" }
]
}
Each write publishes a new immutable version. Always fetch first to get the current version, then update with base_version for concurrency checks:
posthog:llma-skill-get
{ "skill_name": "make-fractals" }
Pick the most surgical primitive for what you're changing — the API offers several so you don't have to round-trip the whole skill to tweak one part. Anything you don't touch is carried forward from the current latest.
Full replacement (good for substantial rewrites):
posthog:llma-skill-update
{
"skill_name": "make-fractals",
"body": "# make-fractals\n\nUpdated instructions...",
"base_version": 2
}
Incremental find/replace (good for small tweaks — no round-tripping the whole body):
posthog:llma-skill-update
{
"skill_name": "make-fractals",
"edits": [
{ "old": "Use Pillow for rendering.", "new": "Use Pillow ≥10.0 for rendering." }
],
"base_version": 2
}
Each edits[].old must match exactly once. body and edits are mutually exclusive.
Use file_edits to patch a single file without resending any other file:
posthog:llma-skill-update
{
"skill_name": "make-fractals",
"file_edits": [
{
"path": "scripts/mandelbrot.py",
"edits": [
{ "old": "ITERATIONS = 100", "new": "ITERATIONS = 250" }
]
}
],
"base_version": 2
}
Non-targeted files carry forward unchanged. file_edits cannot add, remove, or rename files — use the per-file tools below for that.
The file-path parameter has two names depending on where it sits in the request, so don't guess:
file_path — llma-skill-file-get and llma-skill-file-delete (the path is part of the URL).path — llma-skill-file-create, plus the files=[{path, …}] array and file_edits=[{path, …}] (body fields on a file object).old_path / new_path — llma-skill-file-rename.Passing path to file-get produces a /files/undefined/ 404. When in doubt, check the tool's input schema.
Atomic per-file tools — each publishes a new version and returns the updated skill (read its version to chain further edits via base_version):
posthog:llma-skill-file-create
{ "skill_name": "make-fractals", "path": "scripts/julia.py", "content": "...", "base_version": 2 }
posthog:llma-skill-file-delete
{ "skill_name": "make-fractals", "file_path": "scripts/old.py", "base_version": 3 }
posthog:llma-skill-file-rename
{ "skill_name": "make-fractals", "old_path": "scripts/julia.py", "new_path": "scripts/julia_set.py", "base_version": 4 }
Passing files to llma-skill-update replaces ALL bundled files — anything not in the array is dropped. Only use this when you intentionally want to wipe and reseed the bundle. For everything else, prefer file_edits or the per-file CRUD tools above.
llma-skill-archive hides every active version of a skill by name. It cannot be undone — the skill disappears from llma-skill-list and llma-skill-get for the whole team. Use it to retire a skill entirely; to remove a single file use llma-skill-file-delete, and to roll back content publish a new version instead.
posthog:llma-skill-archive
{ "skill_name": "make-fractals" }
To move a skill from a local SKILL.md directory (e.g. a local skills folder with scripts/, references/, assets/ subdirs) into PostHog:
SKILL.md — use its frontmatter for name, description, license, compatibility, allowed_tools, metadata; the body after the frontmatter becomes bodyscripts/, references/, and assets/ subdirs and collect each file as { path, content, content_type }posthog:llma-skill-create with everything in one shot — the skill lands at v1 with its full bundleThe skill is then available to the whole team via posthog:llma-skill-get.
Most coding agents support local skills or slash commands. A local bridge skill gives you a shortcut (e.g. /phs my-github) that routes straight to the PostHog skills API — faster and more deterministic than asking the agent to "use the PostHog skills store to load my-github".
Create a local skill in your agent's skills directory with these instructions:
---
name: phs
description: >-
Access and run shared team skills stored in PostHog.
Use when the user asks to list, run, or manage PostHog skills,
or references /phs, "ph skills", or "posthog skills".
user-invocable: true
allowed-tools: mcp__posthog__llma-skill-list, mcp__posthog__llma-skill-get, mcp__posthog__llma-skill-create, mcp__posthog__llma-skill-update, mcp__posthog__llma-skill-file-get, mcp__posthog__llma-skill-file-create, mcp__posthog__llma-skill-file-delete, mcp__posthog__llma-skill-file-rename, mcp__posthog__llma-skill-duplicate
---
# PostHog Skills Store
Local bridge to the PostHog Skills Store.
## Load and run a skill
When the user says `/phs <skill-name>`:
1. `llma-skill-get(skill_name="<skill-name>")` to fetch body + file manifest
2. Read the `body` field — follow it as system instructions for this task
3. Use `llma-skill-file-get` to pull bundled scripts/references on demand
## List skills
llma-skill-list # all skills
llma-skill-list(search="llma") # filter by keyword
## Create / update
llma-skill-create(name="my-skill", description="...", body="# Instructions...")
llma-skill-get → note version → llma-skill-update(skill_name="...", base_version=N, body="...")
## Edit one part of an existing skill
llma-skill-get → note version → pick the smallest primitive:
- body tweak: llma-skill-update(skill_name="...", base_version=N, edits=[{old, new}])
- one bundled file: llma-skill-update(skill_name="...", base_version=N, file_edits=[{path, edits:[{old, new}]}])
- add/remove/rename a file: llma-skill-file-create / llma-skill-file-delete / llma-skill-file-rename
The bridge is intentionally minimal — it just routes to the MCP tools. The real instructions live in PostHog and update without touching local files.
Agent-specific setup: Where to save this depends on your agent. For Claude Code, save as
~/.claude/skills/phs/SKILL.md. For other agents, consult your agent's docs on local skill or slash command configuration.
llma-skill-get firstllma-skill-file-get only when needed — don't preloadtesting
Focused Signals scout for PostHog projects running surveys. Watches active surveys for score regressions (NPS / CSAT / rating drops), response-volume drops, abandonment spikes, and targeting drift, AND aggregates open-text responses into recurring themes the team should know about (clusters of complaints, praise, feature requests). Emits findings only when a theme or anomaly clears the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills. Picked uniformly at random by the coordinator alongside `signals-scout-general` and other specialists.
development
Focused Signals scout for PostHog projects using revenue analytics. Watches the derived revenue product for upstream failures (Stripe sync stalls, capture regressions), config drift (missing subscription property, currency mix surprises, broken Stripe↔person joins, deferred-revenue gaps), and goal-miss escalations. Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills. Picked uniformly at random by the coordinator alongside `signals-scout-general` and other specialists.
testing
Focused Signals scout for finding observability gaps in PostHog itself — significant event volumes the team isn't tracking, custom events with no insight or dashboard coverage, insights pointing at events that have stopped firing, dashboards missing related context, critical events with no alerts. Watches the event-stream-vs-saved- inventory delta as the team's product evolves and emits findings recommending new insights, dashboard additions, or alerts when gaps clear the confidence bar. Self-contained peer in the signals-scout-* fleet — picked uniformly at random by the coordinator alongside `signals-scout-general` and other specialists.
testing
Focused Signals scout for PostHog projects using logs. Watches for volume bursts, severity-distribution shifts, service silence, fresh message patterns, and trace-correlated bursts via the logs ingestion pipeline. Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills. Picked uniformly at random by the coordinator alongside `signals-scout-general` and other specialists.