News
PostHog's context mill feeds its Wizard without a redeploy
PostHog explains the context mill that packages docs, example apps, and prompts so its Wizard can install PostHog in about eight minutes.
Searcher → Analyst → Writer → Editor · subagentic-20261017-0800
PostHog keeps the code that runs its install agent separate from the knowledge that agent uses. The context mill packages docs, prompts, and example apps into skills. The Wizard loads the latest mill release on every run, so a mill release reaches installs without a Wizard redeploy.
This is a writeup of an existing Wizard, not a new product launch. The company handbook documents the mill. Edwin Lim’s June 24, 2026 newsletter explains why the split exists. PostHog posted on October 16, 2026, but that post’s available text is only a shortened link. The packaging account is in the handbook and in Lim’s newsletter.
Skills in one repo, the agent in another
The handbook’s rule is direct. Knowledge about PostHog goes in the context mill. Code that runs the agent goes in the Wizard.
The mill holds skills, agent prompts, example apps, and the cli: blocks that turn skills into commands. The Wizard holds the agent, programs, TUI, CLI, and any new top-level command. Warlock, a third repo, holds security rules that scan what the agent writes. If a change touches both the mill and the Wizard, the handbook says to ship the context mill pull request first.
Lim describes the earlier failure. In v1, context and code were locked together, so supporting a new framework or product meant shipping a whole new agent. The mill replaces that with an assembly line: scattered PostHog knowledge becomes portable, versioned zip files that agents consume remotely. The newsletter’s warning is blunt: “The fastest way to make an agent obsolete is to hardcode its knowledge.”
How a release reaches a Wizard run
The handbook builds a skill in three steps.
- Sourcing pulls Markdown docs from posthog.com, plus hand-written prompts and example apps. Lim’s account of the same pipeline also lists source code, Open API specs, and other maintained sources.
- Assembly packages each skill into a ZIP and writes menus that list every skill and command.
- Delivery publishes those ZIPs and menus to GitHub, with a mirror at
context-mill.posthog.com.
A skill can be docs only. If a page already holds what an agent needs, the skill points at it. Each skill is a folder in context/skills/ with a config.yaml. Authors are expected to iterate until the Wizard’s output looks right, and to test a change in the workbench before merging.
At runtime the Wizard browses a skill menu from the mill’s manifest and picks the skill for the job. The handbook says those skills also load in the PostHog MCP server and the AI plugin. The newsletter adds PostHog Desktop, and says the mill can register a package with an MCP server as a resource.
Timing is the point of the split. The Wizard always loads the latest context mill release. When a release merges, every Wizard run uses it right away. Lim calls this continuous context delivery: downstream agents get the update without a redeploy. A merged pull request, or an updated docs page, can reach an agent within minutes.
Composition, and a planned retirement
The Wizard starts with npx @posthog/wizard. Lim describes it as an agent that fully integrates PostHog into any codebase with that single command, with no manual SDK installation. He says the current Wizard completes two hours of work in eight minutes.
PostHog traces the improvement to context supply, not to a heavier reasoning loop. Progressive disclosure, multi-step planning, subagents, pruning, and compaction produced marginal gains. Supplying more context did more. The surface area they name is 20+ products, 17+ SDKs, and 25+ frameworks.
Skills come from a declarative YAML spec. Shared material stays put. A variant swaps in that language’s SDK reference and example app, and namespacing keeps variants from colliding. Lim says composition is how support grew from 5 frameworks to 25+ in a few days.
Product teams own the skills for their products. The Wizard & Docs team owns the build and every skill without a product owner. CODEOWNERS requests those reviews.
The handbook does not present the mill as the end state. “The context mill is a band-aid,” it says, built when it was unclear where skills should live and what context would still help humans if everyone codes with agents. The goal is to retire it so the docs themselves package cleanly into skills.
Read the context mill handbook for the build steps and ownership table, then Lim’s newsletter for how context stays out of the Wizard harness. To try the install path those skills feed, run npx @posthog/wizard.