npm - quiver-cli - Versions diffs - 1.3.1 → 2.0.0 - Mend

quiver-cli 1.3.1 → 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (407) hide show

package/template/.agents/skills/integrations/posthog/references/integration-nextjs.md DELETED Viewed

@@ -1,385 +0,0 @@
-# Next.js - Docs
-PostHog makes it easy to get data about traffic and usage of your [Next.js](https://nextjs.org/) app. Integrating PostHog into your site enables analytics about user behavior, custom events capture, session recordings, feature flags, and more.
-This guide walks you through integrating PostHog into your Next.js app using the [React](/docs/libraries/react.md) and the [Node.js](/docs/libraries/node.md) SDKs.
-> You can see a working example of this integration in our [Next.js demo app](https://github.com/PostHog/posthog-js/tree/main/playground/nextjs).
-Next.js has both client and server-side rendering, as well as pages and app routers. We'll cover all of these options in this guide.
-> **Try `@posthog/next` (pre-release):** A simplified Next.js integration with synchronized client/server identity, server-side flag bootstrapping, and a built-in API proxy. [Read the setup guide →](/docs/libraries/next-js/posthog-next.md)
-## Prerequisites
-To follow this guide along, you need:
-1.  A PostHog instance (either [Cloud](https://app.posthog.com/signup) or [self-hosted](/docs/self-host.md))
-2.  A Next.js application
-## Beta: integration via LLM
-Install PostHog for Next.js in seconds with our wizard by running this prompt with [LLM coding agents](/blog/envoy-wizard-llm-agent.md) like Cursor and Bolt, or by running it in your terminal.
-`npx @posthog/wizard@latest`
-[Learn more](/wizard.md)
-Or, to integrate manually, continue with the rest of this guide.
-## Client-side setup
-Install `posthog-js` using your package manager:
-PostHog AI
-### npm
-```bash
-npm install --save posthog-js
-```
-### Yarn
-```bash
-yarn add posthog-js
-```
-### pnpm
-```bash
-pnpm add posthog-js
-```
-### Bun
-```bash
-bun add posthog-js
-```
-Add your environment variables to your `.env.local` file and to your hosting provider (e.g. Vercel, Netlify, AWS). You can find your project token in your [project settings](https://app.posthog.com/project/settings).
-.env.local
-PostHog AI
-```shell
-NEXT_PUBLIC_POSTHOG_TOKEN=<ph_project_token>
-NEXT_PUBLIC_POSTHOG_HOST=https://us.i.posthog.com
-```
-These values need to start with `NEXT_PUBLIC_` to be accessible on the client-side.
-## Integration
-Next.js provides the [`instrumentation-client.ts|js`](https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation-client) file for client-side setup. Add it to the root of your Next.js app (for both app and pages router) and initialize PostHog in it like this:
-PostHog AI
-### instrumentation-client.js
-```javascript
-import posthog from 'posthog-js'
-posthog.init(process.env.NEXT_PUBLIC_POSTHOG_TOKEN, {
-  api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
-  defaults: '2026-01-30'
-});
-```
-### instrumentation-client.ts
-```typescript
-import posthog from 'posthog-js'
-posthog.init(process.env.NEXT_PUBLIC_POSTHOG_TOKEN!, {
-  api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
-  defaults: '2026-01-30'
-});
-```
-Bootstrapping with `instrumentation-client`
-When using `instrumentation-client`, the values you pass to `posthog.init` remain fixed for the entire session. This means bootstrapping only works if you evaluate flags **before your app renders** (for example, on the server).
-If you need flag values after the app has rendered, you’ll want to:
--   Evaluate the flag on the server and pass the value into your app, or
--   Evaluate the flag in an earlier page/state, then store and re-use it when needed.
-Both approaches avoid flicker and give you the same outcome as bootstrapping, as long as you use the same `distinct_id` across client and server.
-See the [bootstrapping guide](/docs/feature-flags/bootstrapping.md) for more information.
-## Identifying users
-> **Identifying users is required.** Call `posthog.identify('your-user-id')` after login to link events to a known user. This is what connects frontend event captures, [session replays](/docs/session-replay.md), [LLM traces](/docs/ai-engineering.md), and [error tracking](/docs/error-tracking.md) to the same person — and lets backend events link back too.
->
-> See our guide on [identifying users](/docs/getting-started/identify-users.md) for how to set this up.
-Set up a reverse proxy (recommended)
-We recommend [setting up a reverse proxy](/docs/advanced/proxy.md), so that events are less likely to be intercepted by tracking blockers.
-We have our [own managed reverse proxy service](/docs/advanced/proxy/managed-reverse-proxy.md), which is free for all PostHog Cloud users, routes through our infrastructure, and makes setting up your proxy easy.
-If you don't want to use our managed service then there are several other options for creating a reverse proxy, including using [Cloudflare](/docs/advanced/proxy/cloudflare.md), [AWS Cloudfront](/docs/advanced/proxy/cloudfront.md), and [Vercel](/docs/advanced/proxy/vercel.md).
-Grouping products in one project (recommended)
-If you have multiple customer-facing products (e.g. a marketing website + mobile app + web app), it's best to install PostHog on them all and [group them in one project](/docs/settings/projects.md).
-This makes it possible to track users across their entire journey (e.g. from visiting your marketing website to signing up for your product), or how they use your product across multiple platforms.
-Add IPs to Firewall/WAF allowlists (recommended)
-For certain features like [heatmaps](/docs/toolbar/heatmaps.md), your Web Application Firewall (WAF) may be blocking PostHog’s requests to your site. Add these IP addresses to your WAF allowlist or rules to let PostHog access your site.
-**EU**: `3.75.65.221`, `18.197.246.42`, `3.120.223.253`
-**US**: `44.205.89.55`, `52.4.194.122`, `44.208.188.173`
-These are public, stable IPs used by PostHog services (e.g., Celery tasks for snapshots).
-## Accessing PostHog
-Once initialized in `instrumentation-client.js|ts`, import `posthog` from `posthog-js` anywhere and call the methods you need on the `posthog` object.
-JavaScript
-PostHog AI
-```javascript
-'use client'
-import posthog from 'posthog-js'
-export default function Home() {
-  return (
-    <div>
-      <button onClick={() => posthog.capture('test_event')}>
-        Click me for an event
-      </button>
-    </div>
-  );
-}
-```
-### Using React hooks
-The [React feature flag hooks](/docs/libraries/react.md#feature-flags) work automatically when PostHog is initialized via `instrumentation-client.ts`. The hooks use the initialized posthog-js singleton:
-JavaScript
-PostHog AI
-```javascript
-'use client'
-import { useFeatureFlagEnabled } from 'posthog-js/react'
-export default function FeatureComponent() {
-  const showNewFeature = useFeatureFlagEnabled('new-feature')
-  return showNewFeature ? <NewFeature /> : <OldFeature />
-}
-```
-### Usage
-See the [React SDK docs](/docs/libraries/react.md) for examples of how to use:
--   [`posthog-js` functions like custom event capture, user identification, and more.](/docs/libraries/react.md#using-posthog-js-functions)
--   [Feature flags including variants and payloads.](/docs/libraries/react.md#feature-flags)
-You can also read [the full `posthog-js` documentation](/docs/libraries/js/features.md) for all the usable functions.
-## Server-side analytics
-Next.js enables you to both server-side render pages and add server-side functionality. To integrate PostHog into your Next.js app on the server-side, you can use the [Node SDK](/docs/libraries/node.md).
-First, install the `posthog-node` library:
-PostHog AI
-### npm
-```bash
-npm install posthog-node --save
-```
-### Yarn
-```bash
-yarn add posthog-node
-```
-### pnpm
-```bash
-pnpm add posthog-node
-```
-### Bun
-```bash
-bun add posthog-node
-```
-### Router-specific instructions
-## App router
-For the app router, we can initialize the `posthog-node` SDK once with a `PostHogClient` function, and import it into files.
-This enables us to send events and fetch data from PostHog on the server – without making client-side requests.
-JavaScript
-PostHog AI
-```javascript
-// app/posthog.js
-import { PostHog } from 'posthog-node'
-export default function PostHogClient() {
-  const posthogClient = new PostHog(process.env.NEXT_PUBLIC_POSTHOG_TOKEN, {
-    host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
-    flushAt: 1,
-    flushInterval: 0
-  })
-  return posthogClient
-}
-```
-> **Note:** Because server-side functions in Next.js can be short-lived, we set `flushAt` to `1` and `flushInterval` to `0`.
->
-> -   `flushAt` sets how many capture calls we should flush the queue (in one batch).
-> -   `flushInterval` sets how many milliseconds we should wait before flushing the queue. Setting them to the lowest number ensures events are sent immediately and not batched. We also need to call `await posthog.shutdown()` once done.
-To use this client, we import it into our pages and call it with the `PostHogClient` function:
-JavaScript
-PostHog AI
-```javascript
-import Link from 'next/link'
-import PostHogClient from '../posthog'
-export default async function About() {
-  const posthog = PostHogClient()
-  const flags = await posthog.getAllFlags(
-    'user_distinct_id' // replace with a user's distinct ID
-  );
-  await posthog.shutdown()
-  return (
-    <main>
-      <h1>About</h1>
-      <Link href="/">Go home</Link>
-      { flags['main-cta'] &&
-        <Link href="http://posthog.com/">Go to PostHog</Link>
-      }
-    </main>
-  )
-}
-```
-## Pages router
-For the pages router, we can use the `getServerSideProps` function to access PostHog on the server-side, send events, evaluate feature flags, and more.
-This looks like this:
-JavaScript
-PostHog AI
-```javascript
-// pages/posts/[id].js
-import { useContext, useEffect, useState } from 'react'
-import { getServerSession } from "next-auth/next"
-import { PostHog } from 'posthog-node'
-export default function Post({ post, flags }) {
-  const [ctaState, setCtaState] = useState()
-  useEffect(() => {
-    if (flags) {
-      setCtaState(flags['blog-cta'])
-    }
-  })
-  return (
-    <div>
-      <h1>{post.title}</h1>
-      <p>By: {post.author}</p>
-      <p>{post.content}</p>
-      {ctaState &&
-        <p><a href="/">Go to PostHog</a></p>
-      }
-      <button onClick={likePost}>Like</button>
-    </div>
-  )
-}
-export async function getServerSideProps(ctx) {
-  const session = await getServerSession(ctx.req, ctx.res)
-  let flags = null
-  if (session) {
-    const client = new PostHog(
-      process.env.NEXT_PUBLIC_POSTHOG_TOKEN,
-      {
-        host: process.env.NEXT_PUBLIC_POSTHOG_HOST,
-      }
-    )
-    flags = await client.getAllFlags(session.user.email);
-    client.capture({
-      distinctId: session.user.email,
-      event: 'loaded blog article',
-      properties: {
-        $current_url: ctx.req.url,
-      },
-    });
-    await client.shutdown()
-  }
-  const { posts } = await import('../../blog.json')
-  const post = posts.find((post) => post.id.toString() === ctx.params.id)
-  return {
-    props: {
-      post,
-      flags
-    },
-  }
-}
-```
-> **Note**: Make sure to *always* call `await client.shutdown()` after sending events from the server-side. PostHog queues events into larger batches, and this call forces all batched events to be flushed immediately.
-### Server-side configuration
-Next.js overrides the default `fetch` behavior on the server to introduce their own cache. PostHog ignores that cache by default, as this is Next.js's default behavior for any fetch call.
-You can override that configuration when initializing PostHog, but make sure you understand the pros/cons of using Next.js's cache and that you might get cached results rather than the actual result our server would return. This is important for feature flags, for example.
-TSX
-PostHog AI
-```jsx
-posthog.init(process.env.NEXT_PUBLIC_POSTHOG_TOKEN, {
-  // ... your configuration
-  fetch_options: {
-    cache: 'force-cache', // Use Next.js cache
-    next_options: {       // Passed to the `next` option for `fetch`
-      revalidate: 60,     // Cache for 60 seconds
-      tags: ['posthog'],  // Can be used with Next.js `revalidateTag` function
-    },
-  }
-})
-```
-## Configuring a reverse proxy to PostHog
-To improve the reliability of client-side tracking and make requests less likely to be intercepted by tracking blockers, you can setup a reverse proxy in Next.js. Read more about deploying a reverse proxy using [Next.js rewrites](/docs/advanced/proxy/nextjs.md), [Next.js middleware](/docs/advanced/proxy/nextjs-middleware.md), and [Vercel rewrites](/docs/advanced/proxy/vercel.md).
-## Further reading
--   [How to set up Next.js analytics, feature flags, and more](/tutorials/nextjs-analytics.md)
--   [How to set up Next.js pages router analytics, feature flags, and more](/tutorials/nextjs-pages-analytics.md)
--   [How to set up Next.js A/B tests](/tutorials/nextjs-ab-tests.md)
-### Community questions
-Ask a question
-### Was this page useful?
-HelpfulCould be better

package/template/.agents/skills/integrations/posthog/references/integration-step-1-begin.md DELETED Viewed

@@ -1,43 +0,0 @@
----
-title: PostHog Setup - Begin
-description: Start the event tracking setup process by analyzing the project and creating an event tracking plan
----
-We're making an event tracking plan for this project.
-Before proceeding, find any existing `posthog.capture()` code. Make note of event name formatting.
-From the project's file list, select between 10 and 15 files that might have interesting business value for event tracking, especially conversion and churn events. Also look for additional files related to login that could be used for identifying users, along with error handling. Read the files. If a file is already well-covered by PostHog events, replace it with another option. Do not spawn subagents.
-Look for opportunities to track client-side events.
-**IMPORTANT: Server-side events are REQUIRED** if the project includes any instrumentable server-side code. If the project has API routes (e.g., `app/api/**/route.ts`) or Server Actions, you MUST include server-side events for critical business operations like:
-  - Payment/checkout completion
-  - Webhook handlers
-  - Authentication endpoints
-Do not skip server-side events - they capture actions that cannot be tracked client-side.
-Create a new file with a JSON array at the root of the project: .posthog-events.json. It should include one object for each event we want to add: event name, event description, and the file path we want to place the event in. If events already exist, don't duplicate them; supplement them.
-Track actions only, not pageviews. These can be captured automatically. Exceptions can be made for "viewed"-type events that correspond to the top of a conversion funnel.
-As you review files, make an internal note of opportunities to identify users and catch errors. We'll need them for the next step.
-## Status
-Before beginning a phase of the setup, you will send a status message with the exact prefix '[STATUS]', as in:
-[STATUS] Checking project structure.
-Status to report in this phase:
-- Checking project structure
-- Verifying PostHog dependencies
-- Generating events based on project
----
-**Upon completion, continue with:** [basic-integration-1.1-edit.md](basic-integration-1.1-edit.md)

package/template/.agents/skills/integrations/posthog/references/integration-step-2-edit.md DELETED Viewed

@@ -1,37 +0,0 @@
----
-title: PostHog Setup - Edit
-description: Implement PostHog event tracking in the identified files, following best practices and the example project
----
-For each of the files and events noted in .posthog-events.json, make edits to capture events using PostHog. Make sure to set up any helper files needed. Carefully examine the included example project code: your implementation should match it as closely as possible. Do not spawn subagents.
-Use environment variables for PostHog keys. Do not hardcode PostHog keys.
-If a file already has existing integration code for other tools or services, don't overwrite or remove that code. Place PostHog code below it.
-For each event, add useful properties, and use your access to the PostHog source code to ensure correctness. You also have access to documentation about creating new events with PostHog. Consider this documentation carefully and follow it closely before adding events. Your integration should be based on documented best practices. Carefully consider how the user project's framework version may impact the correct PostHog integration approach.
-Remember that you can find the source code for any dependency in the node_modules directory. This may be necessary to properly populate property names. There are also example project code files available via the PostHog MCP; use these for reference.
-Where possible, add calls for PostHog's identify() function on the client side upon events like logins and signups. Use the contents of login and signup forms to identify users on submit. If there is server-side code, pass the client-side session and distinct ID to the server-side code to identify the user. On the server side, make sure events have a matching distinct ID where relevant.
-It's essential to do this in both client code and server code, so that user behavior from both domains is easy to correlate.
-You should also add PostHog exception capture error tracking to these files where relevant.
-Remember: Do not alter the fundamental architecture of existing files. Make your additions minimal and targeted.
-Remember the documentation and example project resources you were provided at the beginning. Read them now.
-## Status
-Status to report in this phase:
-- Inserting PostHog capture code
-- A status message for each file whose edits you are planning, including a high level summary of changes
-- A status message for each file you have edited
----
-**Upon completion, continue with:** [basic-integration-1.2-revise.md](basic-integration-1.2-revise.md)

package/template/.agents/skills/integrations/posthog/references/integration-step-3-revise.md DELETED Viewed

@@ -1,22 +0,0 @@
----
-title: PostHog Setup - Revise
-description: Review and fix any errors in the PostHog integration implementation
----
-Check the project for errors. Read the package.json file for any type checking or build scripts that may provide input about what to fix. Remember that you can find the source code for any dependency in the node_modules directory. Do not spawn subagents.
-Ensure that any components created were actually used.
-Once all other tasks are complete, run any linter or prettier-like scripts found in the package.json, but ONLY on the files you have edited or created during this session. Do not run formatting or linting across the entire project's codebase.
-## Status
-Status to report in this phase:
-- Finding and correcting errors
-- Report details of any errors you fix
-- Linting, building and prettying
----
-**Upon completion, continue with:** [basic-integration-1.3-conclude.md](basic-integration-1.3-conclude.md)

package/template/.agents/skills/integrations/posthog/references/integration-step-4-conclude.md DELETED Viewed

@@ -1,38 +0,0 @@
----
-title: PostHog Setup - Conclusion
-description: Review and fix any errors in the PostHog integration implementation
----
-Use the PostHog MCP to create a new dashboard named "Analytics basics" based on the events created here. Make sure to use the exact same event names as implemented in the code. Populate it with up to five insights, with special emphasis on things like conversion funnels, churn events, and other business critical insights.
-Search for a file called `.posthog-events.json` and read it for available events. Do not spawn subagents.
-Create the file posthog-setup-report.md. It should include a summary of the integration edits, a table with the event names, event descriptions, and files where events were added, along with a list of links for the dashboard and insights created. Follow this format:
-<wizard-report>
-# PostHog post-wizard report
-The wizard has completed a deep integration of your project. [Detailed summary of changes]
-[table of events/descriptions/files]
-## Next steps
-We've built some insights and a dashboard for you to keep an eye on user behavior, based on the events we just instrumented:
-[links]
-### Agent skill
-We've left an agent skill folder in your project. You can use this context for further agent development when using Claude Code. This will help ensure the model provides the most up-to-date approaches for integrating PostHog.
-</wizard-report>
-Upon completion, remove .posthog-events.json.
-## Status
-Status to report in this phase:
-- Configured dashboard: [insert PostHog dashboard URL]
-- Created setup report: [insert full local file path]