docs: Add handbook page on contributing to docs for CS team#15320
docs: Add handbook page on contributing to docs for CS team#15320ceyniustranberg wants to merge 2 commits intomasterfrom
Conversation
Explains the context flywheel, wizard, and skills architecture so CS team members understand how their handbook contributions power AI-assisted customer onboarding. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Deploy preview
|
|
Vale prose linter → found 6 errors, 7 warnings, 0 suggestions in your markdown Full report → Copy the linter results into an LLM to batch-fix issues. Linter being weird? Update the rules!
|
| Line | Severity | Message | Rule |
|---|---|---|---|
| 7:73 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 9:120 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 13:72 | warning | Use 'InKeep' instead of 'Inkeep'. | Vale.Terms |
| 20:114 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 74:51 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 78:3 | warning | Capitalize 'Product Analytics' for PostHog's product. Use 'Product analytics' for the general industry concept. | PostHogBase.ProductNames |
| 80:3 | warning | Capitalize 'Session Replay' for PostHog's product. Use 'Session replay' for the general industry concept. | PostHogBase.ProductNames |
| 81:3 | warning | Capitalize 'Error Tracking' for PostHog's product. Use 'Error tracking' for the general industry concept. | PostHogBase.ProductNames |
| 83:14 | warning | Capitalize 'Feature Flags' for PostHog's product. Use 'feature flags' for the general industry concept. | PostHogBase.ProductNames |
| 83:29 | warning | Capitalize 'Experiments' for PostHog's product. Use 'experiments' for the general industry concept. | PostHogBase.ProductNames |
| 83:61 | warning | Capitalize 'Logs' for PostHog's product. Use 'logs' for the general industry concept. | PostHogBase.ProductNames |
| 97:63 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
| 106:70 | error | Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash. | PostHogBase.EnDash |
gewenyu99
left a comment
There was a problem hiding this comment.
Awesome!
Just a note that the Wizard is a proper noun to us 😆 🧙
| showTitle: true | ||
| --- | ||
|
|
||
| Our documentation is a critical piece of PostHog's **context flywheel** — a system that connects our codebase to our docs, which then feeds into our AI agents and the [wizard](/handbook/docs-and-wizard/developing-the-wizard). When documentation is outdated, the agents that help customers integrate PostHog become outdated too. |
There was a problem hiding this comment.
| Our documentation is a critical piece of PostHog's **context flywheel** — a system that connects our codebase to our docs, which then feeds into our AI agents and the [wizard](/handbook/docs-and-wizard/developing-the-wizard). When documentation is outdated, the agents that help customers integrate PostHog become outdated too. | |
| Our documentation is a critical piece of PostHog's **context flywheel** — a system that connects our codebase to our docs, which then feeds into our AI agents and the [Wizard](/handbook/docs-and-wizard/developing-the-wizard). When documentation is outdated, the agents that help customers integrate PostHog become outdated too. |
I know it's not out yet, but Twig (or what ever it's called later) is also a consumer
| - **Show examples**: Real code snippets and configurations help | ||
| - **Explain the "why"**: Context about when to use something helps the AI apply it correctly | ||
| - **Use clear structure**: Headers, bullet points, and numbered steps work better than walls of text | ||
|
|
There was a problem hiding this comment.
Good to attach an example, such as logs.
It's as simple as a root prompt:
https://github.com/PostHog/context-mill/blob/main/transformation-config/skills/logs/description.md
and some reference material:
https://github.com/PostHog/context-mill/blob/main/transformation-config/skills/logs/config.yaml
|
|
||
| When you write something down, ask: "Could an agent do this automatically?" | ||
|
|
||
| For example, if you write a playbook for gathering a customer dossier, that could become an automated web search agent task. If you document how to identify cross-sell opportunities, that becomes a skill the wizard can use. |
There was a problem hiding this comment.
YES. We can ship these so fast that sometimes it's easier to ship a skill and send that to your customer to run in the afternoon.
That's the vision at least ;)
| - Session replay | ||
| - Error tracking | ||
|
|
||
| Coming soon: feature flags, experiments, LLM analytics, and logs. |
There was a problem hiding this comment.
I think LLMA and Logs support is already out. @daniloc Is it a separate skill rn or does it happen in the main loop?
|
|
||
| ### Close the gap in customer conversations | ||
|
|
||
| The wizard and skills architecture lets you close the gap between customer-facing hypotheticals and technical diagnostics without needing engineering present. If a customer asks "how would I track X?", you can point them to the wizard or a specific skill. |
There was a problem hiding this comment.
| The wizard and skills architecture lets you close the gap between customer-facing hypotheticals and technical diagnostics without needing engineering present. If a customer asks "how would I track X?", you can point them to the wizard or a specific skill. | |
| The Wizard and skills architecture lets you close the gap between customer-facing hypotheticals and technical diagnostics without needing engineering present. If a customer asks "how would I track X?", you can point them to the wizard or a specific skill. |
;)
|
|
||
| If customers are hesitant to run an agent on their codebase, they can receive the open-source skills package directly. This gives them 80-95% of the wizard's functionality to run locally with their own tools. | ||
|
|
||
| ### Better onboarding |
There was a problem hiding this comment.
I propose something like:
- Run the Wizard first
- Review what ever it did together with the customer
- Come up with a plan + tweaks.
I think the best value here is to get past that blank page. It's much easier to iterate!
edwinyjlim
left a comment
There was a problem hiding this comment.
let's gooo
we'll need to update this handbook page again when #team-docs-and-wizard gives y'all proper tools to create and experiment with skills! coming soon!
|
|
||
| ## Why your contributions matter | ||
|
|
||
| The docs team has automated writing documentation from PR merges using Inkeep, which indexes our codebase and docs to create first-pass drafts. But there's knowledge that only comes from working directly with customers: |
There was a problem hiding this comment.
| The docs team has automated writing documentation from PR merges using Inkeep, which indexes our codebase and docs to create first-pass drafts. But there's knowledge that only comes from working directly with customers: | |
| The <SmallTeam slug="docs-wizard" /> team has automated writing documentation from PR merges using Inkeep, which indexes our codebase and docs to create first-pass drafts. But there's knowledge that only comes from working directly with customers: |
| @@ -0,0 +1,108 @@ | |||
| --- | |||
| title: Contributing to docs | |||
There was a problem hiding this comment.
I'd make the title skill oriented, kind of like actionable writing
| title: Contributing to docs | |
| title: Creating agents skills from docs |
| title: Contributing to docs | |
| title: Turning knowledge into agent skills |
| ## The wizard and how it helps customers | ||
|
|
||
| The [AI wizard](/handbook/docs-and-wizard/developing-the-wizard) is a one-line `npx` command that runs an agent to integrate PostHog: | ||
|
|
||
| ```bash | ||
| npx -y @posthog/wizard@latest | ||
| ``` | ||
|
|
||
| Here's what it does automatically: | ||
| - Installs the right SDKs for their stack | ||
| - Scans their codebase to understand their product | ||
| - Creates 10-15 custom events based on product flows it identifies | ||
| - Writes both client-side and server-side code for full-stack implementations | ||
| - Creates an insight and dashboard in PostHog | ||
|
|
||
| This dramatically reduces manual integration work — what might take 3-5 hours happens in minutes. And it produces customized code tailored to each customer's setup. |
There was a problem hiding this comment.
This transition is a bit abrupt. I think we need a brief sentence or two that explains how the wizard uses the skills we produce at PostHog! It's a great example of agentic software that runs on our docs. We can just write things down and the wizard can execute skill as software. It's like magic!
Explains the context flywheel, wizard, and skills architecture so CS team members understand how their handbook contributions power AI-assisted customer onboarding.
Changes
Please describe.
Add screenshots or screen recordings for visual / UI-focused changes.
Checklist
vercel.json