Manage in-app surveys with your coding agent

Start with the current documentation

Give your agent the prompt below. The documentation index links to the supported installation, SDK reference and management commands. Check the installed package version before reusing code from an older project.

Set up UserReason in this project. Read https://docs.userreason.com/llms.txt first, then follow https://docs.userreason.com/get-started/quickstart/index.md. Use the docs for the installed SDK version, not what you remember.

The installation wizard can add the SDK, the project-local CLI and the UserReason agent skill. It also guides you through connecting the application to a site.

npx -y @userreason/wizard@latest --agent-skill

• Follow the quickstart →

  Install, initialize and verify the current public SDK.

Begin with a product question

Describe what you need to learn, who should be asked and when it is appropriate to interrupt them. For example, ask people who skipped an onboarding step what made it difficult. A reported reason is useful evidence; it does not by itself prove the cause of a drop-off.

• Choose a specific decision the answers will inform.
• Define an audience and an appropriate moment using your application context and events.
• Draft a short, neutral question with an optional follow-up.
• Review how often someone can see the survey.

• Try the onboarding feedback recipe →

  A neutral question and conditional follow-up for an explicit pause in setup.

• Implement it in Next.js →

  A tested App Router example from setup to a saved response.

• Try the cancellation feedback recipe →

  Optional feedback after cancellation is scheduled, with careful interpretation.

• Implement it in React →

  A Vite example with a confirmed product action and nonblocking feedback.

• Choose a feedback implementation →

  Compare an owned form, managed feedback and the maintenance work.

• Compare PostHog Surveys →

  Use the same scenario to evaluate an existing analytics workflow.

• Writing useful surveys →

  Question design, timing and interpretation for people and agents.

Review the draft before publishing

An agent can create and change survey drafts, inspect the current configuration and run validation. Saving a draft does not change live delivery. Review the questions, audience, frequency and validation results before publishing.

CLI and MCP operations use access that you approve for the relevant workspace and permissions. Public documentation is readable without a grant. Reading customer responses and changing surveys require appropriate access; the installation grant alone does not authorize publication.

• Create your first survey →

  A complete draft, validation and publication walkthrough.

• CLI commands and access →

  Commands, project targeting, scopes and grants.

Connect through MCP or use the project CLI

Add the server below to a compatible MCP client. Your client opens a browser for sign-in and access approval. Inspect the available tools and their current schemas before asking the agent to operate on a site.

https://api.userreason.com/mcp

For a project with the CLI installed by the wizard, the agent can discover commands and search the documentation from the terminal.

npx --no-install userreason cli search "create a feedback survey"
npx --no-install userreason docs search "publish survey"

• Agent documentation →

  MCP connection, the project skill and machine-readable documentation.

Use responses to decide what to investigate next

With the right access, an agent can retrieve results and responses for the relevant site. Ask it to show the survey, period, counts and supporting answers alongside its interpretation. A small sample can suggest a follow-up question without establishing how every user feels.

When asking for a change, request a draft and review its returned dashboard link. Keep the distinction between a saved draft and a published survey explicit throughout the workflow.

• Read results and responses →

  Available results commands and filters.