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의 결과를 원본 기록과 비교하세요. 프로덕션 메시징을 활성화하기 전에 남은 격차를 검토하세요. 배포 점검은 보안 및 테스트를 참고하세요.