---
name: setup-selldone-genesis-essentials
description: "Audit and configure the essential foundations of an existing Selldone shop through MCP: custom domain, email service, shop settings and copy, Privacy Policy and Terms of Use drafts, categories, and approval-gated product entry. Use for initial shop setup when the user does not need a complete custom storefront build."
---

# Set Up Selldone Genesis Essentials

Prepare an existing Selldone shop for operation without rebuilding its customer storefront. Work in reviewable phases, preserve existing configuration, and require explicit confirmation for every mutation.

Use `build-selldone-genesis-storefront` instead when the user wants a complete customer-facing storefront, custom journeys, basket and checkout implementation, browser testing, and Cloudflare deployment.

## Establish identity, shop, and safety boundaries

1. Call `selldone_current_connection` before doing anything else. Confirm the authenticated user, intended shop, granted scopes, and whether write operations are available.
2. Call `selldone_shop_get_my_info` and perform a read-only audit before proposing changes.
3. If MCP is not connected, ask the user to add `https://selldone.com/mcp/connector`, complete Selldone's browser authorization, choose the shop and minimal scopes, and retry.
4. Never ask for or expose a bearer token, API key, refresh token, SMTP password, provider secret, manual token, or `shop_id`. Let MCP resolve connection context and redact secret values.
5. Do not mutate a different shop, infer missing legal facts, overwrite existing objects without merging, delete resources, or enable unrelated features.
6. Show the exact proposed change, explain its effect, obtain the requesting user's explicit approval, and then call the write tool with `confirm=true`.
7. Treat silence, ambiguous replies, previous broad approval, and approval from a different person as no approval.

Use `selldone://developer/api/endpoint-registry`, `selldone-search-endpoints`, and `selldone-describe-endpoint` when a dedicated tool is unavailable or a contract needs clarification. Never invent an endpoint or payload.

## Collect the business brief

Gather only facts needed for the approved scope:

- Legal and public business name, contact details, address, business model, countries, language, currency, and timezone.
- Intended custom domain, DNS provider, current DNS access, and whether Cloudflare proxying is desired.
- Email provider (`smtp`, `postmark`, `mailgun`, or `ses`), sender identity, configuration availability, and safe test recipient.
- Shop title, short and long descriptions, About and Contact content, logo, icon, favicon, and brand assets.
- Business-specific facts needed for Privacy Policy and Terms of Use drafts, including jurisdiction, data practices, returns, fulfillment, and contact channel.
- Category hierarchy and product source data, including SKU, type, title, description, price, currency, inventory, variants, media, SEO, and delivery fields.

List missing or contradictory data. Do not fill gaps with plausible-looking facts. Present a phased checklist that distinguishes read-only checks, proposed writes, user decisions, and validation.

## Audit and configure the domain

1. Read current domains with `selldone_domain_list`.
2. Call `selldone_domain_setup_guide(domain, ssl_proxy=false, provider=cloudflare)` or use the user's actual provider. Present the returned A and TXT records exactly.
3. Stop while the user creates the DNS records. Do not claim DNS, ownership, routing, or SSL is complete before verification.
4. After the user says DNS is ready, verify the proposed domain again and call `selldone_domain_add(..., confirm=true)` only with approval.
5. Call `selldone_domain_check_dns(domain)`.
6. Add a domain client with `selldone_domain_add_client(domain_id, confirm=true)` only if the verified response says it is missing.
7. Call `selldone_domain_check_ssl(domain_id)`. Do not promise immediate certificate issuance.
8. Apply approved HTTPS, currency, or language domain settings through `selldone_domain_setting(..., confirm=true)`.
9. Change `enable`, `indexed`, or `primary` only through `selldone_domain_update_param(..., confirm=true)` and only after showing the exact effect.

Never use `selldone_domain_verification_set` for domain ownership TXT records; that tool is for the Stripe Apple Pay association file.

## Configure the shop email service

1. Read the current provider with `selldone_shop_mail_service_get`.
2. Explain which fields the selected provider requires and ask the user to enter secrets only through the secure MCP or Selldone flow—not in chat, code, screenshots, or logs.
3. Show all non-secret changes, sender identity, and whether the service will be enabled.
4. Call `selldone_shop_mail_service_set(..., confirm=true)` only after approval. Supported providers are `smtp`, `postmark`, `mailgun`, and `ses`; the tool redacts credentials, and enabling the service sends a test.
5. If another test is needed, describe the delivery impact and call `selldone_shop_mail_service_test(confirm=true)` after approval.
6. Report the provider and test result without echoing credentials. Do not send a campaign or customer mailing as a setup test.

## Configure shop identity, settings, and public copy

Read current values first. Preserve fields the user did not ask to change.

- Use `selldone_shop_edit(..., confirm=true)` for approved core changes. Because `name`, `title`, and `language` are required, re-send verified current values for any that remain unchanged.
- Use `selldone_shop_info_edit(info, confirm=true)` only after merging changes into the current info object; it is a replacement operation.
- Use `selldone_shop_countries_set`, `selldone_shop_currencies_set`, and `selldone_shop_business_model_set` only for specifically approved changes.
- Use `selldone_shop_icon_upload`, `selldone_shop_logo_upload`, and `selldone_shop_fav_upload` for user-provided approved assets.

Present final text and settings before saving. Re-read the shop after writes and report exact saved values plus unresolved items.

## Draft and publish legal and informational pages

Read each existing page with `selldone_shop_profile_get(type)`. Supported types are `privacy`, `terms`, `about-us`, and `contact-us`.

Draft Privacy Policy and Terms of Use only from user-provided, shop-verified facts. Clearly label them as drafts that require the user's legal review; do not claim legal sufficiency or invent an entity, jurisdiction, retention period, return right, or data processor.

Show the complete draft and a summary of what it changes. Save safe article HTML with `selldone_shop_profile_set(type, body, confirm=true)` only after the requesting user explicitly approves that exact draft. Re-read the backoffice value, then verify the customer-facing result with `selldone_storefront_profile_call(endpoint_id='xapi.profiles.get', path_params={type: '<approved-type>'})`. Apply the same review discipline to About and Contact pages.

## Propose and create categories

1. Read current categories with `selldone_category_list`, inspect relevant nodes with `selldone_category_get`, and verify the tree with `selldone_category_hierarchy`.
2. Propose a simple hierarchy, identifiers, parent-child relationships, and product mapping. Surface duplicates and naming conflicts.
3. Obtain explicit approval for the category plan.
4. Create parents before children with `selldone_category_create(..., confirm=true)`; use `selldone_category_update(..., confirm=true)` only for exact approved corrections.
5. Upload category media with `selldone_category_image_upload` only from an approved source.
6. Re-read the created tree and report IDs, titles, parents, and skipped conflicts.

## Enforce the mandatory sample-product gate

The sample batch is a hard stop, not a suggestion. Never add the whole catalog in the first product write phase.

1. Validate and normalize the supplied catalog without writing. Resolve duplicate SKUs, missing prices or currencies, product types, inventory meaning, variants, category mappings, media ownership, SEO fields, and delivery requirements.
2. Select **two or three representative products** that exercise the important patterns, such as different categories, variants, inventory behavior, or product types. Explain why the sample is representative.
3. Show the exact proposed fields for every sample product. Default each sample to `Unlisted` so it cannot be purchased publicly during review. Obtain explicit approval to create only those samples; require separate approval if the user wants samples created as publicly available products.
4. Create samples individually with `selldone_product_create(..., confirm=true)`. Do not use a bulk import for this phase.
5. Add approved main images with `selldone_product_image_upload_main`, specifications with `selldone_product_spec_save`, and rich product copy through `selldone_article_call` only after describing `api.articles.product.upsert` with `selldone-describe-endpoint`.
6. Re-read every sample with `selldone_product_get` and, when available, show the read-only `selldone_product_gallery_widget` resource. Present the requesting user with IDs and reviewable values for title, description, category, type, SKU, status, price, currency, variants, inventory, media, SEO, and delivery behavior.
7. Ask that **same requesting user** to inspect the created products in Selldone and explicitly confirm that the sample is correct.
8. **Stop. Do not create or import any remaining product in the same turn or from the original approval.** A separate post-creation approval is mandatory.
9. If the user reports any mismatch, update only the samples with `selldone_product_update(..., confirm=true)`, re-read them, and repeat the review gate.

Only proceed when the same requesting user unambiguously confirms the created samples are correct and authorizes the remaining catalog. Treat authorization to create the remainder and authorization to publish products as separate decisions unless that user explicitly combines both. If actor identity cannot be established, stop and request confirmation in the authenticated conversation.

## Add the remaining catalog after approval

After the sample gate is unlocked:

1. Re-read the approved samples and current categories so the remaining mapping uses the verified pattern.
2. Present the exact remaining product count, duplicate policy, batch size, and fields to be written. Resolve changes made since the sample review.
3. Obtain explicit approval for that exact remainder plan. A statement that the samples look correct does not authorize an unspecified import.
4. Create products in reviewable batches with `selldone_product_create(..., confirm=true)`, or use `selldone_shop_import_call` with `api.imports.products.create` only when bulk import is appropriate and the user explicitly approves the high-risk import.
5. Use `api.imports.categories.create` only if additional categories were explicitly approved. Monitor imports with `api.imports.status.get`, `api.imports.products.list`, and `api.imports.images.list` through `selldone_shop_import_call`.
6. Never silently overwrite a matching SKU, create duplicates to bypass a conflict, delete existing products, or assume failed rows succeeded.
7. After each batch, report created, updated, skipped, failed, and unresolved rows. Pause if error patterns indicate a mapping problem.
8. Keep remaining products `Unlisted` until the same user approves publication, unless the exact remainder plan explicitly authorized a public status.
9. Re-read representative results and reconcile the final counts against the approved source catalog.

## Finish with a verifiable handoff

Report:

- The verified shop and authenticated requester.
- Domain DNS, routing, client, SSL, and primary/index status separately.
- Email provider and test status, with secrets redacted.
- Changed settings, assets, and public copy.
- Legal drafts approved and saved, plus any legal-review reminder.
- Category IDs and hierarchy.
- Sample products, the identity and wording of their approval, remaining-batch authorization, and final product counts.
- Skipped items, failures, unresolved facts, and safe next actions.

Never mark an item complete based only on a requested write. Verify the resulting state with a read call whenever the MCP contract provides one.