Inventory Clearance Card

---
name: "inventory-clearance-card"
description: "Turn already-written clearance rules into one clearance explanation card per SKU. This clearance sale card studio lays out the seller-supplied discount and dates as an inventory clearance graphic. Use it for a clearance poster, clearance price card, and stock clearance still that stay one SKU, one still."
---

# Clearance Explanation Cards

Make one clearance explanation still per SKU from rules the seller
already wrote. Deliver 4 to 8 stills. Keep each still as its own file.

## Scope and adjacent routes

Use this Skill when a seller wants short clearance listing stills from
written sale rules and named SKUs.

Route an allergen notice to `allergen-label-card`. Route a social
comment pin still to `comment-pin-card`. Route a full listing gallery
to `ecommerce-listing-image-set`. Do not look up public posts for a
missing discount.

## Collect confirmed facts

Hard inputs are:

- at least one named SKU;
- the clearance facts the seller already wrote (percent or price,
  start and end if they wrote them, what is on sale);
- how many stills the pack should contain, or permission to use the
  default of 4.

Reuse brand palette, destination, language, and must-keeps already in
the conversation. Ask only for a missing hard input. A count outside
4 to 8 is still doable: confirm that pack size and its live cost.

Do not invent a discount, end date, stock count, or face. A product
photo is a visual reference, not a source for missing sale facts.
File access is not consent.

Inspect every optional still. Record MIME type, width, height, aspect
ratio, byte size, and whether it has an alpha channel. For a local
file, upload only through the bundled client after inspection
(`scripts/mcp_client.py` / `beatra.assets.upload`). Keep the returned
artifact id. Never pass a local path to `beatra.images.generate` or
`beatra.images.edit`.

## Plan the free card list

Write a labeled clearance-card list before any paid image. Default
four SKUs unless the seller names another count in 4 to 8. Each item
records the SKU, the printed clearance lines from written rules,
language, layout, canvas, and any optional reference role.

That list is the free visible result. Planning is not approval.

Safe defaults:

- one `beatra.images.generate` call per SKU;
- `model: "auto"` and `count: 1`;
- canvas `{"type":"preset","tier":"2K","aspect":"1:1"}` unless the
  seller named another destination;
- `beatra.images.edit` only after the seller accepts a card and asks
  for a local correction, with that accepted image as `images[0]`.

## Confirm once, create by SKU

Planning is free. Before the first billable call, read
`beatra.models.list` for `text_to_image`:

```json
{"capability": "text_to_image"}
```

Show one current production card and wait:

1. Work — one clearance explanation still per named SKU
   (`beatra.images.generate`).
2. Credits — the live `text_to_image` price just read, times the
   SKU count. Do not reuse a remembered number.
3. Count — one paid call per SKU card. Do not batch several SKUs
   into one `count`.
4. Identity — one new opaque `client_request_id` per card.
5. If we stop here — the labeled card list remains usable.
6. If the balance is insufficient — relay the official message and
   its top-up URL exactly. Translate the prose; keep the URL. Do not
   retry until the seller says they have topped up.

Submit once through bundled `scripts/mcp_client.py`. Poll
`beatra.tasks.get`. Deliver actual bytes plus
`billing.net_charged_credits`. Do not promise the prepaid estimate is
the final charge.

After approval, submit each SKU once. Keep no more than two generation
tasks in flight on one connection.

A later local correction is new paid work. Read the live `image_edit`
card first. Show a separate six-field edit card. Use a new
`client_request_id`.

## Review, deliver, and recover

Review printed lines against the confirmed rule list. Report only the
text the host can actually see. Treat generated small type as a review
item, not as a certified sale notice.

Deliver the stills in SKU order, the card list, observed dimensions
and formats, task IDs, resolved models, and returned
`billing.net_charged_credits`.

After a returned `task_id`, poll that task. If the create response is
lost, search with `beatra.tasks.list` and verify with
`beatra.tasks.get` before replay. Reuse an ID only with
byte-identical arguments. A changed SKU, rule line, canvas, model, or
prompt is a new card and a new ID. Cancel only when the seller asks.

## Execution

Invoke every remote Beatra operation only through this package's bundled
`scripts/mcp_client.py`. Put the MCP tool name after `call` and send one
JSON object on standard input.

```bash
python3 scripts/mcp_client.py call beatra.models.list
```

```json
{"capability": "text_to_image"}
```

```text
printf '%s' '{"prompt":"Create the approved clearance explanation card for the named SKU. Print only the confirmed clearance lines.","model":"auto","count":1,"canvas":{"type":"preset","tier":"2K","aspect":"1:1"},"client_request_id":"opaque-clearance-sku-01"}' | python3 scripts/mcp_client.py call beatra.images.generate
```

Do not configure or call a host Beatra Connector, and do not use
REST/OpenAPI as a fallback.

## Account balance

When the user asks how many credits remain or whether a live estimate fits,
call `beatra.wallet.get`. When they ask what was charged, call
`beatra.wallet.ledger`. Both are read-only. Do not invent an account-balance or
top-up tool. Do not make `wallet.get` a required step before every paid submit.

When a model card comes back carrying a `top_up` block, relay its tiers as the
card lists them and in that order. Do not rank them, do not talk one down, and
do not pick one for the user. Which tier suits them is their call, made on
the wallet page with the whole list in front of them. Never quote a tier from
memory.

## References by task

- For fact lists, payloads, confirmation, polling, recovery, and review,
  read [Clearance-card workflow](references/workflow.md).
- For authorization and the non-billable registration step, read
  [installation and authentication](references/installation-and-auth.md)
  and [installation registration](references/installation-registration.md).
- For shared task, billing, and connection details, read [tasks and
  results](references/tasks-and-results.md), [billing, errors, and
  recovery](references/billing-errors-and-recovery.md), and [Bundled MCP
  Client diagnostics](references/mcp-connection.md).
- For update guarantees and controls, read [automatic updates and
  safety](references/automatic-updates-and-safety.md). For removal, read
  [uninstall and disconnect](references/uninstall-and-disconnect.md).

## Runtime and safe automatic updates

The bundled client silently checks for a newer release at most once
every 24 hours per installation. When a newer version is available, it
installs automatically without separate confirmation. It downloads only
from the fixed official Beatra discovery and immutable CDN paths for
this package, channel, and locale, verifies discovery data, archive,
manifest, and every packaged file, and replaces only package-owned
files.

Update checks, downloads, verification, replacement, rollback, and
recovery fail open: the current installation remains usable and the
original command continues. An update failure never authorizes retrying
a paid image request. The setting persists for this installation. See
[automatic updates and safety](references/automatic-updates-and-safety.md).

```text
python3 scripts/mcp_client.py update --auto off
python3 scripts/mcp_client.py update --auto on
python3 scripts/mcp_client.py update --check
```