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 及連接這些服務的計畫。先在預備環境進行，並告訴我還有哪些需要驗證。

服務連接目錄涵蓋客服系統、臨床平台、藥局、帳務與出貨。挑選一個具代表性的支援案件，以便在全面推行前檢查完整的工作流程。

憑證會透過 UI 或 CLI 存入 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 支援。

若要在既有對話、Cursor 中使用，或你的瀏覽器無法開啟應用程式，請使用 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 的發現與原始記錄進行比對。在啟用正式環境訊息傳送前，檢閱尚存的缺口。推行檢查請參閱安全性與測試。