New to Claude Skills? Learn how to install them →

posthog on GitHub

Writing Streamlit Apps

Free

Create Streamlit apps for PostHog data visualization.

Get this skill

Free · Opens the source repo

What Writing Streamlit Apps does

The Writing Streamlit Apps skill is designed for developers and data analysts who need to create interactive data applications using Streamlit within the PostHog environment. This skill simplifies the process of writing source code for Streamlit applications that can efficiently query and visualize data from PostHog, leveraging the built-in posthog_apps.query() function. This function allows users to execute HogQL queries and retrieve data as pandas DataFrames, streamlining the integration of analytics into user-friendly applications.

When developing a Streamlit app, users must consider the unique constraints of the PostHog sandbox. The skill provides guidance on managing the Streamlit rerun model, emphasizing the importance of caching queries and utilizing st.session_state for maintaining state across interactions. This ensures that applications remain responsive and efficient, even as users interact with various widgets. The skill also covers best practices for layout and charting, helping users create visually appealing and informative dashboards.

This skill is particularly useful for those who are already familiar with Streamlit and want to build applications that visualize PostHog data. It provides a clear structure for developing apps in a single-file format, ensuring that all necessary code is contained within app.py. The skill also addresses common pitfalls, such as the need to avoid direct user input in queries, which helps maintain security and data integrity.

Overall, the Writing Streamlit Apps skill is an essential tool for developers looking to harness the power of Streamlit in conjunction with PostHog, enabling them to create dynamic and insightful data applications with ease.

When to use it

Use this skill when you need to build or debug Streamlit apps that visualize data from PostHog.

When not to use it

This skill is not suitable for general-purpose Streamlit app development outside of the PostHog environment or for applications requiring additional Python packages not included in the sandbox.

What you can build with it

Building a Data Dashboard

Create a Streamlit app that visualizes user events from PostHog, allowing stakeholders to interactively explore data.

Debugging Query Issues

Utilize the skill to quickly identify and resolve issues with HogQL queries in your Streamlit applications.

Creating Interactive Reports

Develop applications that generate reports based on PostHog data, enhancing data accessibility for non-technical users.

How to install Writing Streamlit Apps

View source

1. Install with the skills CLI

npx skills add posthog/posthog/writing-streamlit-apps --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by posthog

Writing Streamlit apps for the PostHog sandbox

The source you write becomes app.py at the root of a sandboxed Streamlit 1.31 runtime. Deployment mechanics (create/start/share) are the managing-streamlit-apps skill; this one is about the code.

Reading PostHog data: posthog_apps.query()

The one and only data door is the in-sandbox bridge:

import posthog_apps

df = posthog_apps.query("SELECT event, count() FROM events GROUP BY event LIMIT 10")
  • Takes a HogQL string, returns a pandas DataFrame.
  • Raises RuntimeError on failure. The message is deliberately generic ("Query execution failed") — the bridge does not return query internals to the sandbox, so you cannot diagnose a bad query from inside the app. Catch it and render with st.error(str(e)) so viewers get a message instead of a stack trace, and test queries in the SQL editor where real errors are visible.
  • import posthog does NOT exist in the sandbox — the module is posthog_apps, deliberately distinct from the posthog-python SDK's name.
  • The bridge is pre-authenticated to the app's project; user code never sees a token, and there is nothing to configure.
  • Queries run with server-side caps (30 s execution, 256 MB memory) that don't scale with sandbox sizing — so bound time ranges, LIMIT results, and aggregate in HogQL rather than pulling raw events into pandas.

Design for Streamlit's rerun model

Streamlit reruns the whole script top to bottom on every widget interaction. Two consequences:

  1. Cache every bridge call — uncached, one slider drag re-fires every query:

    @st.cache_data(ttl=300, show_spinner="Running query...")
    def run_query(hogql: str) -> pd.DataFrame:
        return posthog_apps.query(hogql)
    
  2. Use st.session_state for anything that must survive reruns — accumulated selections, pagination cursors, "last refreshed" stamps. Module-level variables reset on every interaction.

Widgets drive parameters naturally, but never interpolate a free-text widget value into HogQL. The bridge runs your query with the version author's data access, and anyone who can view the app drives those widgets — a raw st.text_input spliced into a query hands viewers the author's access to write their own. Constrain the input instead: pick from a fixed list you control (st.selectbox over known values), or coerce to a type that can't carry SQL (int(days), a date from st.date_input), and validate before it reaches the query.

Layout and charts

  • st.set_page_config(page_title=..., layout="wide") first — the default narrow layout wastes most of the screen for data apps.
  • Structure with st.columns for side-by-side metrics, st.tabs for alternate views, st.expander for detail sections; st.metric for headline numbers.
  • Charts: st.plotly_chart(fig, use_container_width=True) with plotly express is the reliable default; st.dataframe(df, use_container_width=True) for tables. matplotlib/seaborn also work via st.pyplot.

What's installed

The image ships Python 3.11 with: streamlit 1.31, pandas, numpy, polars, plotly, matplotlib, seaborn, scipy, scikit-learn, pyarrow, duckdb, requests, beautifulsoup4, lxml, sqlalchemy, aiohttp. There is no way to add dependencies: the sandbox never runs pip (a deliberate security posture — no arbitrary package code at boot), and a requirements.txt in an uploaded zip is tolerated but dropped. Only import what's listed above.

Structure and runtime constraints

  • One file. Via the MCP set-source flow your source IS app.py; there are no other modules, so keep everything in it.
  • The sandbox is ephemeral: anything written to disk disappears on stop/restart. Don't build state on files; recompute from queries (with caching) or hold it in st.session_state.
  • Your code runs as an unprivileged user; there's no posthog SDK, no way to pass your own environment variables or secrets to the app, and no expectation of general network egress. Don't read from os.environ — anything there belongs to the sandbox runtime, not your app. Design around posthog_apps.query() as the data source.

A minimal well-shaped app

import pandas as pd
import plotly.express as px
import posthog_apps
import streamlit as st

st.set_page_config(page_title="Events overview", layout="wide")
st.title("Events overview")


@st.cache_data(ttl=300, show_spinner="Running query...")
def run_query(hogql: str) -> pd.DataFrame:
    return posthog_apps.query(hogql)


# A slider is bounded and coerced to int, so it is safe to interpolate.
days = int(st.slider("Days to show", 1, 30, 7))
try:
    daily = run_query(
        f"""
        SELECT toDate(timestamp) AS day, count() AS events
        FROM events
        WHERE timestamp >= now() - INTERVAL {days} DAY
        GROUP BY day ORDER BY day
        """
    )
    st.plotly_chart(px.bar(daily, x="day", y="events"), use_container_width=True)
except RuntimeError as e:
    st.error(str(e))

Frequently asked questions about Writing Streamlit Apps

Similar skills