git:20260829.c48df0a to git:20260913.68d1943

39 added, 28 removed. Audit A to A.

---

name: nitrosend

description: "Operate a Nitrosend account through one governed Runx skill: inspect readiness, analytics, subscription plans, and purchase status; plan and apply campaign/flow/template/segment drafts; import consented contacts; and approve or deliver email operations with provider readback."

runx:

category: growth

---

# Nitrosend

Use this as the single public Runx surface for Nitrosend customer operations.

Local account runners bind the API key only to the local runtime. The hosted

`review-content` runner calls one bounded `provider.read` operation whose Cloud

adapter retains credential custody. No runner accepts an API key as skill input

or returns one in a receipt.

This skill is not for Nitrosend customer-support administration or team Slack

work. Those are product-operator concerns owned by the Nitrosend repository.

## Choose the runner

- `status` (default): live account, brand, sender, domain, provider, warmup, and

deliverability readiness.

- `billing-status`: read the current account subscription and eligible paid-plan

catalog together. It creates no checkout; prepaid balance and add-funds

readiness remain a distinct `funding` block in the status evidence.

- `plan-checkout`: re-read current billing and plans, approve one exact plan,

create the idempotent hosted checkout or confirmed in-place plan change, then

read billing again. A checkout URL is pending operator work, not proof of

payment or activation.

- `plan-checkout-status`: reconcile one returned plan-purchase ID without

creating another checkout. Use it after hosted approval, timeout, or an

ambiguous client response.

- `configure-sender`: read, approve, update, and independently read back one

explicitly selected brand's exact sender defaults. It configures no content,

audience, campaign, flow, or delivery.

- `analytics`: live account, campaign, flow, or message insights.

- `review-delivery`: read-only content and preflight review. Flow review requires

the exact immutable `revision_id`; campaigns and templates do not.

- `review-content`: read-only spam and accessibility review for bounded inline

email content. It accepts no account entity, audience, delivery, or mutation

input and is safe to compose behind a payment-as-access vendor endpoint.

- `plan-campaign`, `plan-flow`, `plan-transactional`, and `plan-import`:

bounded agent judgment that produces a reviewable request without provider

completion.

- - `compose-email`: read the live Nitrosend authoring contract, let one bounded

- agent author its exact next call, and return authoritative MCP validation.

- It never persists a draft or gains delivery authority.

+ - `compose-email`: make one approval-free intent or validation call for a

+ campaign, flow, or reusable template and return authoritative provider

+ evidence. It never persists a draft or gains delivery authority.

- `apply-draft`: apply exact reviewed arguments for a campaign, flow, template,

segment, or remote image ingest. Image ingest validates the remote bytes and

returns a durable Nitro-hosted brand-library URL. It never sends or activates.

- `approve-delivery`: approve a reviewed campaign or an exact flow revision

without delivering.

- `send-campaign`: send or schedule an already-approved campaign after a fresh

provider review and explicit approval.

- `activate-flow`: publish an exact already-approved flow revision after a

fresh review and explicit approval.

- `send-transactional`: dry-run or send one idempotent message to one recipient.

- `import-contacts`: dry-run or import at most 100 inline consented records.

- `import-contacts-csv`: validate or upload a local CSV through Nitrosend's

authorized direct-upload path. File bytes and signed URLs never enter the

agent packet or receipt.

- `import-status`: make one bounded status read for an asynchronous import.

- `segment-from-prose`: internal planning lane for the current supported filter

catalog; unsupported filters are rejected rather than approximated.

Use the current public `https://nitrosend.com/SKILL.md`, `nitro_get_status`, and

the live MCP schema as product truth. Do not copy onboarding or tool schemas

into another repo-local skill.

+ ## Email composition

+ `compose-email` is one two-turn, non-persisting boundary for all three creative

+ surfaces. Choose `target_type=campaign`, `flow`, or `template`.

+ 1. Call it with `composition_mode=intent` and the surface-specific goal and

+ context under `arguments`. Nitrosend returns a frozen contract and exact next

+ call without creating an account entity.

+ 2. The host writes the candidate from that contract. No internal agent runner

+ or fallback reconstructs omitted brand, memory, source, or schema context.

+ 3. Call `compose-email` again with `composition_mode=validate` and the candidate

+ arguments. The runner forces the provider's validation mode and removes

+ persistence-only retry fields from this read.

+ 4. When the provider accepts the candidate and the operator wants it saved,

+ pass the provider-issued draft call to `apply-draft`. That is the first

+ persistence boundary and keeps its existing human approval.

+ Every intent and validation outcome returns the same

+ `nitrosend.provider_evidence.v1` packet, including `needs_input`, refusal, and

+ provider errors. A stopped composition is therefore a usable result with exact

+ repair guidance, never a successful graph with no result producer. Validation

+ proves only that the candidate currently satisfies the provider contract; it

+ does not create, approve, test, schedule, activate, or send anything.

## Safe operating sequence

1. Run `status` and stop on sender, domain, suspension, warmup, or account

blockers.

2. Correct sender defaults only through `configure-sender`. Supply the public

brand SID even when the credential currently defaults to that brand, plus

the complete sender name, sender address, reply-to address, saved test

recipients, and a stable idempotency key. The runner reads the selected

brand before approval and independently reads it again after mutation.

A missing brand SID, different readback brand, or changed field stops the

operation; never fall back to an account default.

- 3. For email authoring, use `compose-email` so Nitrosend supplies current brand

- and memory context before the model writes. Treat its MCP validation as

- authoritative; repair in another bounded turn when requested. For other

- planning, use the matching planning runner.

- 4. Apply only validated arguments through `apply-draft`; that separate runner

+ 3. For email authoring, use `compose-email` with `composition_mode=intent`

+ so Nitrosend supplies current brand and memory context before the host

+ writes. Call the same runner with `composition_mode=validate` and the

+ contract-bound candidate. Treat its provider result as authoritative and

+ repair against the same contract when requested. For other planning, use

+ the matching planning runner.

+ 4. Apply only the provider-issued persistence arguments through `apply-draft`;

+ creative operations must carry `composition_mode=draft`, the exact

+ `contract_id`, and a stable `idempotency_key`. That separate runner

retains the approval gate and is the first persistence boundary. For a new

vendor-site or free-stock image, use `operation=ingest_image` with its exact

public URL and an honest description, then reissue the composition intent so

the returned Nitro-hosted URL becomes a frozen image binding.

5. Run `review-delivery` before approval. For flows, carry the exact current

`revision_id` unchanged through review, approval, and activation. Use

`approve-delivery` separately so retries never combine approval-state

mutation with recipient delivery.

6. Use `send-campaign` or `activate-flow` only after provider approval state is

established. A fresh review and Runx approval gate are mandatory.

7. Give every sender update, real transactional send, campaign delivery, and

import a stable

idempotency key. Reuse that key after a timeout; do not mint a new one.

8. Treat completion as real only when the sealed receipt contains Nitrosend

provider evidence. A plan receipt is not proof of send, schedule, activation,

or import.

## Plan billing

Nitrosend is the merchant for its account subscription. Runx governs the exact

account operation and receipt, but it does not settle the operator's Stripe or

Shopify payment and must not route this hosted checkout through `spend`.

Start with `billing-status`; select only a returned eligible `plan_id`. Call

`plan-checkout` with one stable idempotency key and approve the exact selected

plan once. The same approval derives Nitrosend's provider confirmation flag, so

there is no second confirmation prompt. Reuse the key only for an unchanged

request.

A returned checkout URL means the provider is awaiting the operator. Preserve

its `purchase_id` and `next_action`, complete or abandon checkout outside the

runner, and call `plan-checkout-status` later. Do not mint another checkout to

poll. Only provider readback that reports activation is completion.

Prepaid balance is a separate Nitrosend product path. These plan runners refuse

amount, currency, instrument, add-funds, and funding-purchase arguments rather

than forwarding them through the shared billing MCP tool.

## Contact import rules

Every import requires a stable `source_id` and a plain-language

`consent_basis`. Purchased, scraped, or data-broker lists are refused.

For CSV imports, pass an absolute `.csv` path. The adapter computes metadata and

checksum locally, reserves an authorized upload, streams the file directly to

the returned public HTTPS host, finalizes with the signed ID, and discards the

signed URL. The import is asynchronous; call `import-status` again as needed

rather than keeping a resident polling loop.

## Stop conditions

- Missing provider credential or brand context.

- Missing explicit brand SID or incomplete sender defaults for a sender update.

- Sender readback that resolves another brand or differs from the exact request.

- Unsupported operation, audience, segment filter, or lifecycle transition.

- Missing consent source, recipient, schedule time, or idempotency key.

- Failed provider review or preflight.

- Missing or denied approval.

- Missing plan or purchase identity, changed idempotent checkout input, prepaid

funding arguments on a plan runner, or a request to treat checkout creation as

payment completion.

- Any request to expose credentials, signed upload URLs, raw contact files, or

unbounded provider responses.

- Any claim of completion without provider readback evidence.

## Agent task contracts

The planning acts prepare exact downstream operations and never call the

- provider. `compose-email-from-contract` is different: the enclosing graph has

- already read authoritative MCP intent evidence, and the agent only authors a

- candidate for the graph's read-only MCP validation. No agent act persists or

- delivers.

+ provider. `compose-email` contains no agent act: the host writes from the

+ provider-issued contract between its explicit intent and validation calls. No

+ composition call persists or delivers.

The internal provider boundary emits `nitrosend.provider_evidence.v1` for both

successful and stopped operations. Consumers carry that packet unchanged;

they do not reconstruct a smaller result shape or infer completion from raw

transport output.

### `send-campaign`

Build one campaign plan from the objective, current account-status JSON, and

audience brief. Distinguish a campaign from a flow or transactional message.

Require an explicit bounded audience, compliant sender readiness, review before

approval, and a separate confirmation before send or schedule. Do not invent

list or segment ids and do not claim delivery from this planning runner.

### `build-flow-plan`

Build one event-triggered automation plan with a supported trigger and ordered

steps. Route one-off broadcasts to `send-campaign`; never disguise them as a

flow. Preview and creation may be planned before confirmation, but approval and

activation must remain a separate confirmed delivery-control operation.

### `send-transactional-plan`

Plan exactly one email or SMS to one named recipient. Require channel-specific

content, a stable idempotency key, dry-run validation, and confirmation before a

real send. Reject audience or list broadcasts and route those to

`send-campaign`.

- ### `compose-email-from-contract`

- Read the `composition_intent` provider evidence supplied as the declared input

- or current graph context. It must contain a successful Nitrosend result with a

- composition contract, contract id, and next call. Return `campaign_candidate`

- with `decision` (`ready`, `needs_input`, or `reject`), exact `arguments`,

- `rationale`, and `blockers`.

- For `ready`, begin from the contract's `next_call`, preserve its `contract_id`,

- set `composition_mode` to `validate`, and fill only the requested creative

- fields. Follow the supplied brand, memory, examples, hard constraints, design

- mode, and repair guidance. Never reconstruct omitted context, invent claims,

- add an audience or schedule, or request draft, approval, activation, testing,

- or sending. If the intent evidence or required contract fields are missing,

- return `needs_input` without fabricated arguments.

### `import-contacts-plan`

Plan only consented contacts with a stable source, consent basis, bounded record

count, channels, compliance checks, dry run, and confirmation before import.

Refuse purchased, scraped, or brokered lists. Choose inline import only for the

bounded inline path; use the CSV runner for larger local files, without copying

file contents or signed URLs into the plan.

### `segment-from-prose-plan`

Translate the brief only through filters and predicates present in

`filter_catalog_json`. Return a concrete `segment_request` when every condition

is representable. Reject unsupported event history, attribution, or compound

semantics rather than approximating them with superficially similar fields.