Nitrosend - AI Email Marketing

View saved version →

---
name: onboarding
description: Plan a first branded email send on Nitrosend through an activated brand-subdomain sender or a verified customer domain, using the canonical delivery-capacity outcome from nitro_get_status.
---

# Nitrosend onboarding

Help the user complete one first-email objective or inspect their email
performance. Start from the connected account's actual state and skip setup
that is already complete. This workflow is adapted from Nitrosend's canonical
onboarding guide at https://nitrosend.com/SKILL.md.

## Connect and confirm context

Connect Nitrosend from the Plugin Directory and sign in or create an account
in the OAuth flow. Do not request a password or provider credentials in chat.
After connecting, call `nitro_get_status`. Confirm the account and brand
before drafting or changing anything. If several accounts are available and
none is selected, ask which one to use, then call `nitro_select_account`.
Use `nitro_select_brand` for an authorized brand change. Never infer a write
target from the account that happened to open in the web dashboard.

If authentication has just finished but the tools are unavailable, start a
new conversation after connecting. Repeatedly reconnecting does not repair a
tool definition held by the directory.

The status response supplies account, brand, onboarding, sender,
`brand_subdomain`, `delivery`, issues and recommendations. Report setup gaps
and pauses as returned. Do not invent a health score, verified customer domain,
capacity, send success or completed onboarding.

## Complete only the missing setup

- Use `nitro_set_brand_kit` to set the real company name and brand color or
  inspect a website the user provides. Follow the returned missing-field
  guidance. Ask for the user's real mailing address if campaign readiness
  requires one; never copy an example address into the Brand Kit.
- If no ready sender is selected, call `nitro_prepare_brand_sender` with
  no arguments. This synchronously derives the
  address from the complete Brand Kit. On `brand_identity_required`, set the
  missing Brand Kit fields and retry. Follow the schema exposed by this
  conversation, including when the server suggests a newer optional field.
- A Nitrosend address is a protected brand subdomain under the platform's
  verified shared root. It does not establish that the customer owns or has
  verified an independent domain. A customer-owned sending domain needs its
  own DNS verification. Preserve an existing sender selection.
- Inspect `delivery.reason_code`, `issues` and `retry_at` for capacity or
  pacing constraints. Never derive a private sending allowance from a plan
  name. Billing and provider credential changes are managed in the Nitrosend
  app; do not request keys, display offers, or initiate checkout in chat.
- Import only contacts the user is authorized to use. Use
  `nitro_search_contacts` or `nitro_query` to resolve existing lists rather
  than inventing IDs. For up to 100 records use
  `nitro_import_contact_records`. Larger CSVs use `nitro_reserve_csv_upload`,
  PUT the bytes to the returned URL, then `nitro_start_csv_import` with the
  returned signed_id. Follow the returned progress/read-back guidance.

## Draft, review and test

For a newsletter or one-time broadcast, use `nitro_compose_campaign`.
For an event-triggered series, use `nitro_compose_flow`. Begin with
`composition_mode: "intent"` and the user's objective. The returned authoring
contract supplies the exact brand, memory, design schema, bindings and
continuation; follow its `next_call`. Do not reconstruct this packet from
status or preload general reference documents before every composition.

Emails are structured sections, not arbitrary HTML. Preserve the brand theme
and required footer. Use `nitro://guide` for unfamiliar vocabulary and
`nitro://brand-kit` or `nitro://schema` for literal manual edits when needed.

After persistence:

1. Keep the returned campaign/flow ID. For a flow, also retain its exact
   `draft_revision_id`.
2. Call `nitro_review_delivery` on that saved target and, for a flow, that
   exact revision. Show the preview/editor link and actual blockers.
3. If the user requests a test, use `nitro_send_test_message` with the saved
   test recipient. A test sends real email. Report the actual recipient and
   delivery outcome; a dry run or a pending result is not a delivered test.
4. Obtain explicit approval for live delivery to the identified audience.
   Only then use `nitro_control_delivery` to approve and launch or schedule.
   For flows, use the revision returned by review. An all-contacts launch
   additionally requires `confirm_send_to_all: true`.

A saved draft is not a send; approval is not activation or a capacity
reservation. After launch, report the actual status and monitoring link.
Transactional email is for application-triggered receipts, resets and
verification, not a substitute for a marketing campaign. Use the REST API or SDK
for application-triggered transactional email.

## Analytics and recovery

For a performance-first request, use `nitro_get_insights` with the requested
scope and period. Base advice on returned metrics, trends and data quality.
Explain zero or insufficient data instead of fabricating performance.

Read errors, `how_to_fix`, `suggested_tool_call` and response sidecars before
retrying. Fix the named cause first. Preserve idempotency keys for exact
retries; do not repeat an uncertain delivery with a new key. `nitro_append_memory`
needs a stable idempotency key. Never bypass a sending pause, ownership check
or content-review decision. Contact support through `nitro_request_support`
when the user asks or available recovery steps are exhausted.