Summer

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

将 Summer AI 设置提示词交给你的编码代理，让它在你的网站中完成安装流程。它可以添加支持 Messenger、连接已登录用户、上传 Markdown 公司政策，并帮助配置支持案例背后的工具。该提示词还涵盖客户指南、截图、视频和文件上传，并包含独立的预览、发布和托管检查。

使用 Claude Code、Codex、Cursor 或其他能够编辑项目并运行终端命令的编码代理。该代理使用 Summer AI CLI，向你展示拟议的更改，并请你通过浏览器登录。

已经设置好 Summer AI？连接你的 MCP 客户端，即可从你的 AI 助手中读取案例、请求调查并管理公司知识。

从一个实用的工作流开始

告诉代理你的团队处理哪些事务以及你使用哪些工具。例如：

为此网站添加 Summer AI 支持。我们使用 Intercom 处理对话，使用 Stripe 处理账单。阅读 Summer AI 设置指南，检查我们的项目，并向我们展示安装 Messenger 和连接这些服务的计划。先使用暂存环境，并告诉我还有哪些需要验证。

服务连接目录涵盖帮助台、临床平台、药房、账单和配送。选择一个有代表性的支持案例，以便在全面推广前检查完整工作流。

凭据通过 Summer AI 内置的密钥管理器保存。MCP 客户端可以检查凭据并指导操作，密钥通过 UI 或本地 CLI 交接输入。无需 Doppler 账户。除非你选择现有的 Doppler，否则代理使用本地环境变量进行 CLI 上传。

复制提示词

打开 Company setup → Set up with your AI agent。选择 Open in ChatGPT Desktop 或 Open in Claude Code，以在已填入设置提示词的情况下打开应用。选择你的公司并审阅提示词后再发送。这些链接不会让你登录，也不会授予 Summer AI 访问权限。如果你的部署环境不支持此功能，请联系 Summer AI。

对于现有聊天，或者如果你的浏览器无法打开应用，请使用 Copy setup prompt。Company setup 版本包含你的公司 ID。启用设置后，通用提示词也以 Markdown 形式提供。

检查连接

在登录前运行 summer doctor --json，以检查 API 地址和登录服务是否可达。然后运行 summer login --scope setup --json 并在浏览器中批准连接。运行 summer whoami --json 以验证访问权限。你无需从 Summer AI 仪表板复制令牌或将其粘贴到任何地方。

# 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 set up Doppler or a vault unless I choose it.

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 customers in guides and staff in procedures. Follow ASD-STE100 about 80%: instructions under 20 words, descriptions under 25, active voice, one idea per sentence, consistent terms, no metaphors or 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 --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. Inspect \`summer integrations\` and \`summer credentials list\`. For missing providers, use \`integrations save custom-NAME --from-file integration.json --expected-version N\` with a name and fields (name, label, required), never values. Transfer secrets through the local CLI. Create guidance with \`knowledge create ID --from-file guide.md --path company/guide.md --reason TEXT\`, or edit its current revision. Verify Summer can discover and use each connection; saved configuration alone is insufficient.
10. Check each capability against its concrete test and authorized sample. Use original live records where needed. Local-only tools cannot pass Summer runtime access. Record Blocked with the missing path. \`capability-checks test ID --case CASE_ID --expected-version N\` requests an existing read-only investigator (needs setup and investigations.request; cases.read reads results). Obtain missing grants through consent. Inspect effect paths without executing them. Never replace case work or resume the 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.

## Check versions

If the last successful check is unknown or seven days old, or a tool/command is
missing, run \`summer version --check --json\` and \`summer client-status --json\`
(MCP: \`summer_client_status\`). Update from published npm releases. Refresh MCP
initialization and tools/list when its version changes. Keep existing scopes on
reconnect; updates never grant permissions.

## Support email

Read https://gosummer.ai/docs/support-email before configuring support email. Test reading, replies and DNS separately; Intercom's account check tests neither inbox nor replies. Gmail/Outlook connectors and email DNS commands are not released. Record evidence and gaps in capability checks. 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 native file, browser and media tools. Guides need CLI 0.2.0+ and its matching
deployment. Report release gaps; 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 roles use the same published articles. Humans edit them in Knowledge with history.

## Check Summer first

Ask before adding this rule to the end of AGENTS.md or CLAUDE.md:
"For a customer, ticket or order question, first run \`summer cases search TEXT --company YOUR_COMPANY_ID --json\` (name, email, phone, ID; \`--dob\`, \`--messages\`) or MCP \`summer_cases_search\`. Read the case before investigating locally. Results are leads."

## Report back

Use the shared operation catalog for workspace setup as well as installation.
Guest attachment and abuse limits live in installation settings; chat concurrency
and daily limits live in assistant settings. Use \`messenger.conversations.list\`
for the complete inbox, including visitors without Ops cases. Business hours,
saved replies/views, assignment, reports, quality scenarios and privacy-request
tracking have named API/MCP operations. Read current revisions before saving.
Members can grant \`workspace.write\` for personal views and quality assessments;
shared views and administrator settings keep their existing role checks.

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, revisions, returned URLs and gaps. Distinguish drafts, uploads and verified publication.

## 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 overwrite agent instructions or install unrelated tools.
- With actions.approve, approve exact prepared work I authorize using its review hash; no repeated UI approval. Never invent authorization. Secret reveal, access/role grants, spending increases, identity attestations and clinical directions stay restricted.
- 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.

代理会做什么

1. 读取你的项目以查找其框架、登录和服务器配置，且不会打印密钥。
2. 在你于浏览器中批准后，使用 summer login 进行连接。
3. 读取 Summer AI 的能力和当前设置，并遵守每一项不可用项。
4. 写入一个不含密钥的 summer.setup.json，规划更改并向你展示。
5. 应用该计划。CLI 将选定的凭据直接发送到 Summer AI，并将 Messenger 签名密钥写入你被忽略的服务器配置文件。
6. 使用你现有的登录方式添加 Messenger 小组件。参见安装 Messenger和连接已登录账户。
7. 使用合成账户测试访客使用、登录、登出和账户切换。
8. 按照 Summer AI 中显示的同一运营能力清单逐项处理。它可以上传公司指南、定义自定义集成、通过 CLI 保存选定的密钥，并测试可发现的 API、浏览器或知识路径。
9. 在清单中记录证据和剩余缺口，并明确标注为由设置代理报告。仅保存凭据或指南并不能通过某项能力。
10. 根据企业独特的产品、工作流和重复出现的支持请求添加重要能力，并附上具体测试和支持性发现说明。

哪些事项由你掌控

除非你要求，代理不会提交、推送或部署。通过委托的 actions.approve，它可以批准你授权的确切已准备案例工作。它不能凭空创建授权、泄露已保存的凭据、批准 Summer AI 访问权限或提高支出限额。生产环境消息传递需要单独授予的权限。你可以随时在 Your account → Security → Agent connections 中查看其连接。

设置完成后我应该拥有什么？

你应该在测试站点中拥有一个可用的 Messenger、经过检查的登录和登出行为，以及保存在 Summer AI 中的公司指南。代理应展示它测试了哪些服务连接、找到了哪些证据以及还有哪些缺失。

让它展示客户任务清单、准备好的 Markdown、截图、图片或视频，以及已检查的产品链接。当前范围参见准备客户指南。你的代理应展示已完成的上传回执和确切的指南预览。发布需要单独的 guides.publish 权限。本地文件或已保存的草稿不是已发布的指南；请验证返回的公开地址。自定义域名还需要经过验证的 DNS 和可用的 HTTPS。

尝试一个有代表性的支持请求，并将 Summer AI 的发现与原始记录进行比较。在启用生产环境消息传递之前，审查剩余缺口。推广检查参见安全与测试。