Summer

npx add-mcp 'https://api.gosummer.ai/mcp'

Give your coding agent the Summer setup prompt and let it work through the installation in your website project. It can add the support Messenger, connect your signed-in users, upload Markdown company policies and help configure the tools behind your support cases. The prompt also covers customer guides, screenshots, videos and file uploads, with separate preview, publication and hosting checks.

Use Claude Code, Codex, Cursor or another coding agent that can edit your project and run terminal commands. The agent uses the Summer CLI, shows you the proposed changes and asks you to sign in through your browser.

Already have Summer set up? Connect your MCP client to read cases, request investigations and manage company knowledge from your AI assistant.

Start with a useful workflow

Tell the agent what your team handles and which tools you use. For example:

Add Summer support to this website. We use Intercom for conversations and Stripe for billing. Read the Summer setup guide, inspect our project and show me a plan for installing Messenger and connecting those services. Use staging first and tell me what still needs verification.

The service connection directory covers help desks, clinical platforms, pharmacies, billing and shipping. Pick one representative support case so you can check the complete workflow before rollout.

Credentials go into Summer's built-in secrets manager through the UI or CLI. An MCP client can inspect credential metadata and guide setup, with secret entry through the UI or a local CLI handoff. A Doppler account is not required. The agent uses local environment variables for CLI uploads unless you choose an existing Doppler connection.

Copy the prompt

Open Company setup → Set up with your AI agent. Select Open in ChatGPT Desktop or Open in Claude Code to open the app with your setup prompt filled in. Choose your website project and review the prompt before sending it. These links do not sign you in or grant Summer access. If setup is unavailable for your deployment, contact Summer support.

Use Copy setup prompt for an existing chat, Cursor, or if your browser cannot open the app. The Company setup version includes your company ID. The generic prompt below is also available as Markdown when setup is enabled.

Check the connection

Run summer doctor --json before sign-in to check that the API address and sign-in service are reachable. Then run summer login --scope setup --json and approve the connection in your browser. Run summer whoami --json to verify access. You do not need to copy a token from the Summer dashboard or paste it into chat.

# Set up Summer in this project

Set up Summer for this business in this repository. Use authorized company knowledge and tools to understand workflows and test them. Configure Summer through its API, CLI or MCP. Keep service credentials separate; Summer tokens are only for Summer.

Test how Summer handles the business's support cases. A capability passes when Summer can find and use its API, browser, knowledge or connected-tool path. Tool names are hints. Complete available setup and record precise blockers.

Summer details:
- API: https://api.gosummer.ai
- Company ID: YOUR_COMPANY_ID
- Environment for this setup: staging
- Summer CLI: run \`npx --yes @gosummerai/cli@0.1.1 <command>\`. The steps below write this as \`summer <command>\`. Add \`--api https://api.gosummer.ai\` to each command if that is not \`https://api.gosummer.ai\`.
- Optional MCP server: https://api.gosummer.ai/mcp

If the Company ID is \`YOUR_COMPANY_ID\`, run \`summer companies --json\` after sign-in and use the selected company's ID in every command and setup file. If more than one company is available and the project does not identify one, ask me to choose.

Use Summer's built-in secrets manager for provider credentials. Customers can save values in Settings → Integrations with **Store in Summer**, or through the CLI using \`--from-env\`, \`--from-file\` or \`--from-stdin\`. If using MCP, list credential metadata there and use \`summer_credentials_set\` with \`source: local_value\` for a local CLI handoff. Never put secret values in MCP arguments or chat. Doppler is optional. Do not ask me to create a Doppler account or connect a vault unless I choose that option.

The original setup consent covers normal Messenger installation, embed changes and activation within the selected company/environment and current spending limit. Do not add a separate installation approval or escalate routine setup to another agent. A setup grant does not approve customer business actions, investigations, budget increases or clinical directions.

## Write for the reader

Address the reader: customers for customer guides, staff for internal procedures.
Follow ASD-STE100 Simplified Technical English about 80% for human-facing text.
Aim for instructions under 20 words and descriptions under 25 words. Use active
voice, one idea per sentence, simple present-tense verbs and consistent terms.
Avoid metaphors, idioms and technical slang. Keep necessary facts and uncertainty.

## Steps

1. Inspect this project and relevant company guidance first. Identify products, customer requests, care and fulfillment flows, billing, refunds, subscriptions, support channels, policies, promises and existing tools. Find where operational facts live and how an agent can discover them. Identify the framework, sign-in and server-side secret configuration too. Do not print or dump environment files or secret values. Use only relevant company material; keep patient records in their authorized case.
2. Run \`summer doctor --json\` to check the API address and sign-in service. If it reports a failed check, explain the returned reason before continuing. Check access with \`summer whoami --json\`. If you are not signed in, run \`summer login --scope setup --json\` and ask me to approve the connection in my browser. Wait for the browser consent or my explicit approval of that connection. Use an existing authorized connection without asking again. If the result says access is pending, stop and tell me.
3. Read \`summer capabilities --company YOUR_COMPANY_ID --environment staging --json\`, \`summer status --company YOUR_COMPANY_ID --environment staging --json\` and \`summer capability-checks list --company YOUR_COMPANY_ID --environment staging --json\`. \`operational_readiness\` is the same checklist shown in Company setup → What Summer can do. Read each expectation, concrete test, prior evidence and discovery hints. Treat unavailable permissions as real. A missing named provider tool can have an available browser or knowledge alternative; discover and test those within your authority.
4. Match each checklist gap to useful setup work. Write a non-secret \`summer.setup.json\` with the company settings, Messenger installation (when needed), selected credential environment-variable names and knowledge files to create or edit. Each knowledge entry has \`id\`, \`file\` and \`reason\`; a new document can also set \`path\` under \`company/\` and \`tags\`. Reuse current documents rather than duplicate policies. Upload current policies, workflow guides, escalation contacts and discovery instructions that Summer needs. Explain original sources and known gaps. Keep unrelated files and existing setup; set \`replace: true\` on credentials only if I ask.
5. Run \`summer setup plan --file summer.setup.json --out summer.plan.json --json\` and show me the plan summary. Company settings and knowledge are company-wide: an edit there affects every environment, including production. Tell me before applying such a step.
6. Apply with \`summer setup apply --plan summer.plan.json --file summer.setup.json --json\`. Credentials are read by the CLI from the environment variables you name and are sent straight to Summer; the Messenger signing key is written by the CLI to the server-side file you chose (for example \`.env.local\`, which must be ignored by Git). Never read, echo or copy these values yourself. If a step is \`stale\`, plan again. If a step is \`uncertain\`, read the current state and follow the returned next step instead of retrying blindly.
7. If this business needs Messenger, integrate the widget using the existing sign-in system of this project: load the Summer loader, boot it with the installation ID, and add a small server endpoint that signs the identity assertion for the signed-in user with the signing key from server configuration. Follow https://gosummer.ai/docs/install-messenger and https://gosummer.ai/docs/verified-identity. Do not replace this project's authentication.
8. For a Messenger installation, test locally with synthetic accounts: guest use, sign-in, sign-out and switching accounts, and the site's Content-Security-Policy. Run \`summer messenger check --url <local page> --installation <id> --json\`. Run \`summer verify --company YOUR_COMPANY_ID --environment staging --json\` for the configured connections. A check reported as \`unsupported\` has not passed.
9. Complete remaining operational setup. Use \`summer integrations\` and \`summer credentials list\` to inspect metadata. For a provider outside the catalog, define its field names with \`summer integrations save custom-NAME --from-file integration.json --expected-version N --company YOUR_COMPANY_ID --environment staging --json\`, then use the secret-safe CLI upload commands. The integration file has \`name\` and \`fields\` (each with \`name\`, \`label\`, \`required\`); it contains no values. Upload additional guidance with \`summer knowledge create ID --from-file guide.md --path company/guide.md --reason TEXT --company YOUR_COMPANY_ID --json\`, or edit the existing document at its current revision. Saving fields, keys or instructions alone does not establish that Summer can use a provider. Check runtime access and discoverability; report missing trusted connection work precisely.
10. Check each applicable capability using its concrete test and an authorized sample. Use current knowledge for factual tasks and original live reads where the answer depends on current records. Try available alternatives when a named tool is missing. A local script or privileged login only passes when Summer can discover and use the same path with its own authorized connection. Record Blocked when only your local tools can do it. If Summer's investigator is available, \`summer capability-checks test ID --case CASE_ID --expected-version N --company YOUR_COMPANY_ID --environment staging --json\` requests its read-only check. This needs the \`investigations.request\` grant as well as \`setup\`; read case results with \`cases.read\`. Obtain any additional grant through normal human consent, or continue independent setup and report the gap. Never replace unfinished case work or enable the investigation backlog.
11. Save findings with \`summer capability-checks report ID --from-file result.json --expected-version N --company YOUR_COMPANY_ID --environment staging --json\` at the latest version. The file has \`state\` (\`passed\`, \`failed\`, \`blocked\`, \`not_checked\`, \`not_applicable\`), \`notes\`, \`evidence\` and, for a pass, \`fulfillment: {kind: api|browser|knowledge|other|combined, discovery: "how Summer finds it", location: "guide, tool or portal reference"}\`. Keep evidence references and observation times, without secrets or patient details. Reports are agent-reported. An assumed integration, saved secret, untested guide or different path cannot pass. Inspect action paths and exact approval requirements without executing effects.
12. Add important business-specific capabilities from actual products, workflows and recurring support needs. Prefer customer/team outcomes over endpoints. Create a definition with \`id\` (starting \`custom_\`), \`title\`, \`group\`, \`mode\` (\`read\` or \`approval\`), \`expectation\`, \`test\` and \`examples\` (discovery hints or an empty string). Save with \`summer capability-checks save ID --from-file definition.json --expected-version 0 --reason TEXT --company YOUR_COMPANY_ID --environment staging --json\`. Record the original business source, concrete test and passing evidence. Add supporting knowledge/integrations and assess it like the starter checks. Improve existing definitions at their current version rather than duplicate them. Explain inapplicable starters.

## Support email

Read https://gosummer.ai/docs/support-email before configuring support email.
Test reading, replies and DNS separately. Intercom's account check does not test inbox access or replies.
Direct Gmail/Outlook connectors and email DNS commands are not released.
Record test evidence and gaps in capability checks. Follow the company's reply rules.
Help-center DNS does not configure email. Keep chat in the widget unless the visitor wants email follow-up.
Contact capture sends no email.

## Customer guides, Markdown and media

Read \`summer guides authoring --company YOUR_COMPANY_ID --json\` (MCP:
\`summer_guides_authoring\`) for instructions, schemas, media syntax and draft
context. Use your native agent's file, browser and media tools. Summer stores
and hosts the result; no separate generation job starts. Check CLI \`--help\`:
guide commands need 0.2.0+ and the matching deployment. Report missing release
steps; never invent uploads or hosted URLs.

Inventory the full product, conditional features and account controls. Reuse
existing guides. Write task-focused Markdown with direct product links, sources
and check dates. Capture real UI with synthetic or authorized data and label
examples. Keep private procedures, personal data and medication directions out
of public articles. Use \`--company YOUR_COMPANY_ID --json\` with this journey:

1. Read \`guides get\`, \`guides article get ID\` and \`assets list\`. Configure the
   guide with \`guides save\` at the current version.
2. Upload actual files with \`assets upload --from-file PATH --metadata-file
   media.json\`, including alt text, provenance and captions/transcripts. Confirm
   ready asset IDs; resume the same file with \`--resume ASSET_ID\`. The trusted
   local CLI transfers bytes; no binaries/base64 or credentials in MCP context.
3. Save Markdown with \`guides article save ID --from-file article.md
   --metadata-file article.json --revision N --reason TEXT\`. New articles use
   revision 0. Open \`guides preview\`; check media, downloads, search, section
   links, phone/desktop layout and product links through sign-in.
4. Show the exact preview. Publishing needs human authority and separate
   \`guides.publish\` consent. When requested, use \`summer login --scope
   setup,guides.publish --json\`, then \`guides publish --from-file release.json
   --expected-version N --reason TEXT\` with exact article revisions. Verify
   public/Markdown URLs. Saved drafts are not public.
5. If requested, use \`guides hosting get/save/verify\`, follow returned DNS
   instructions and verify ownership, provider setup and HTTPS separately.

All agent roles use the same published articles/customer URLs in the company
library. Humans edit the work in Knowledge with history. Guide instructions do
not establish what a customer completed.

## Report back

Refresh \`summer status\` and \`summer capability-checks list\`. Report actual setup/capability states, evidence, discovered paths, business-specific additions, blockers and next steps. Saved is not verified; an agent report is not independent execution verification. Keep dashboard records current for human review.

Report guide topics, prepared Markdown and media, saved knowledge revisions and
returned URLs. Separate preparation, uploads, publication and verified product
links. List missing media tools, upload support or hosting.

## Limits

- Do not commit, push or deploy unless I ask. Complete authorized Messenger setup, including production, without asking for the same permission again. Use a returned local CLI handoff yourself when available. Ask only for missing company access, environment access or authority.
- Do not install global tools or skills, and do not overwrite AGENTS.md or other agent instructions.
- You cannot approve business actions, reveal saved credentials, approve Summer access or raise spending limits. Ask me to do those in Summer.
- Do not perform customer effects during onboarding tests. Only clinicians provide medication directions; do not write, quote, paraphrase or calculate them in guides, test reports or replies. Route those questions to the authenticated clinical channel.

What the agent does

1. Reads your project to find its framework, sign-in and server configuration, without printing secrets.
2. Connects with summer login after you approve it in your browser.
3. Reads Summer's capabilities and current setup, and respects every unavailable item.
4. Writes a non-secret summer.setup.json, plans the changes and shows them to you.
5. Applies the plan. The CLI sends selected credentials directly to Summer and writes the Messenger signing key into your ignored server configuration file.
6. Adds the Messenger widget using your existing sign-in. See Install the messenger and Connect signed-in accounts.
7. Tests guest use, sign-in, sign-out and account switching with synthetic accounts.
8. Works through the same operational capability checklist shown in Summer. It can upload company guides, define custom integrations, save selected secrets through the CLI and test discoverable API, browser or knowledge paths.
9. Records evidence and remaining gaps in the checklist, visibly labeled as reported by the setup agent. A saved credential or guide alone does not pass a capability.
10. Adds important capabilities based on the business's unique products, workflows and recurring support requests, with concrete tests and supporting discovery instructions.

What stays with you

The agent does not commit, push or deploy unless you ask. It cannot approve business actions, reveal saved credentials, approve Summer access, raise spending limits or turn on production messaging without the permission you grant for that. Review its connection any time in Your account → Security → Agent connections.

What should I have when setup is finished?

You should have a working Messenger in your test site, checked sign-in and sign-out behavior, and company guides saved in Summer. The agent should show which service connections it tested, the evidence it found and anything still missing.

Ask it to show the customer task inventory, prepared Markdown, screenshots, images or videos, and checked product links. See Prepare customer guides for the current scope. Your agent should show completed upload receipts and the exact guide preview. Publication needs the separate guides.publish permission. A local file or saved draft is not a published guidebook; verify the returned public address. Custom domains also need verified DNS and working HTTPS.

Try a representative support request and compare Summer's findings with the original records. Review the remaining gaps before enabling production messaging. See Security and testing for the rollout checks.