← Nitrosend - AI Email MarketingCONTENT HISTORY

Update to Nitrosend - AI Email Marketing

Snapshot Oct 28, 2026 · 12:12 UTC · version 2.1.5

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Nitrosend - AI Email Marketing and check future changes in Following.

Up to 10 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "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.",
  "included_files": [],
  "name": "onboarding",
  "skill_md_contents": "---\nname: onboarding\ndescription: 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.\n---\n\n# Nitrosend onboarding\n\nHelp the user complete one first-email objective or inspect their email\nperformance. Start from the connected account's actual state and skip setup\nthat is already complete. This workflow is adapted from Nitrosend's canonical\nonboarding guide at https://nitrosend.com/SKILL.md.\n\n## Connect and confirm context\n\nConnect Nitrosend from the Plugin Directory and sign in or create an account\nin the OAuth flow. Do not request a password or provider credentials in chat.\nAfter connecting, call `nitro_get_status`. Confirm the account and brand\nbefore drafting or changing anything. If several accounts are available and\nnone is selected, ask which one to use, then call `nitro_select_account`.\nUse `nitro_select_brand` for an authorized brand change. Never infer a write\ntarget from the account that happened to open in the web dashboard.\n\nIf authentication has just finished but the tools are unavailable, start a\nnew conversation after connecting. Repeatedly reconnecting does not repair a\ntool definition held by the directory.\n\nThe status response supplies account, brand, onboarding, sender,\n`brand_subdomain`, `delivery`, issues and recommendations. Report setup gaps\nand pauses as returned. Do not invent a health score, verified customer domain,\ncapacity, send success or completed onboarding.\n\n## Complete only the missing setup\n\n- Use `nitro_set_brand_kit` to set the real company name and brand color or\n  inspect a website the user provides. Follow the returned missing-field\n  guidance. Ask for the user's real mailing address if campaign readiness\n  requires one; never copy an example address into the Brand Kit.\n- If no ready sender is selected, call `nitro_prepare_brand_sender` with\n  no arguments. This synchronously derives the\n  address from the complete Brand Kit. On `brand_identity_required`, set the\n  missing Brand Kit fields and retry. Follow the schema exposed by this\n  conversation, including when the server suggests a newer optional field.\n- A Nitrosend address is a protected brand subdomain under the platform's\n  verified shared root. It does not establish that the customer owns or has\n  verified an independent domain. A customer-owned sending domain needs its\n  own DNS verification. Preserve an existing sender selection.\n- Inspect `delivery.reason_code`, `issues` and `retry_at` for capacity or\n  pacing constraints. Never derive a private sending allowance from a plan\n  name. Billing and provider credential changes are managed in the Nitrosend\n  app; do not request keys, display offers, or initiate checkout in chat.\n- Import only contacts the user is authorized to use. Use\n  `nitro_search_contacts` or `nitro_query` to resolve existing lists rather\n  than inventing IDs. For up to 100 records use\n  `nitro_import_contact_records`. Larger CSVs use `nitro_reserve_csv_upload`,\n  PUT the bytes to the returned URL, then `nitro_start_csv_import` with the\n  returned signed_id. Follow the returned progress/read-back guidance.\n\n## Draft, review and test\n\nFor a newsletter or one-time broadcast, use `nitro_compose_campaign`.\nFor an event-triggered series, use `nitro_compose_flow`. Begin with\n`composition_mode: \"intent\"` and the user's objective. The returned authoring\ncontract supplies the exact brand, memory, design schema, bindings and\ncontinuation; follow its `next_call`. Do not reconstruct this packet from\nstatus or preload general reference documents before every composition.\n\nEmails are structured sections, not arbitrary HTML. Preserve the brand theme\nand required footer. Use `nitro://guide` for unfamiliar vocabulary and\n`nitro://brand-kit` or `nitro://schema` for literal manual edits when needed.\n\nAfter persistence:\n\n1. Keep the returned campaign/flow ID. For a flow, also retain its exact\n   `draft_revision_id`.\n2. Call `nitro_review_delivery` on that saved target and, for a flow, that\n   exact revision. Show the preview/editor link and actual blockers.\n3. If the user requests a test, use `nitro_send_test_message` with the saved\n   test recipient. A test sends real email. Report the actual recipient and\n   delivery outcome; a dry run or a pending result is not a delivered test.\n4. Obtain explicit approval for live delivery to the identified audience.\n   Only then use `nitro_control_delivery` to approve and launch or schedule.\n   For flows, use the revision returned by review. An all-contacts launch\n   additionally requires `confirm_send_to_all: true`.\n\nA saved draft is not a send; approval is not activation or a capacity\nreservation. After launch, report the actual status and monitoring link.\nTransactional email is for application-triggered receipts, resets and\nverification, not a substitute for a marketing campaign. Use the REST API or SDK\nfor application-triggered transactional email.\n\n## Analytics and recovery\n\nFor a performance-first request, use `nitro_get_insights` with the requested\nscope and period. Base advice on returned metrics, trends and data quality.\nExplain zero or insufficient data instead of fabricating performance.\n\nRead errors, `how_to_fix`, `suggested_tool_call` and response sidecars before\nretrying. Fix the named cause first. Preserve idempotency keys for exact\nretries; do not repeat an uncertain delivery with a new key. `nitro_append_memory`\nneeds a stable idempotency key. Never bypass a sending pause, ownership check\nor content-review decision. Contact support through `nitro_request_support`\nwhen the user asks or available recovery steps are exhausted.\n"
}

SHA-256 of public snapshot: 3b9ef961c6e73692ecc3cf21f20bbfa678ec63bda98fdb6de580a8b56a8ab3bf