ProductByte

View saved version →

---
name: create-campaign
description: Turn a product launch, seasonal promotion or sale into a ProductByte campaign with an agreed plan and reviewed social drafts. Use when posts belong together as a campaign; use manage-posts for existing posts and create-creatives for standalone images.
---

Use the ProductByte MCP tools from this plugin. Tool names below are the server names; use the corresponding names exposed by the host.

- Resolve the project with `workspace-get` when it has not been selected. Ask which project to use when several are available, and keep subsequent calls scoped to that choice.
- Read `playbook-list` before planning or composing. Apply auto-selected playbooks when their descriptions fit, and other playbooks when the customer names them. Read `channel-list` for connected channels and supported formats.
- Agree on the products, number of stills and carousels, channels, dates and any offer before creating a campaign. Reuse details and authorization already supplied; ask only for choices that are still missing.
- Use `product-field-list` before field-based `product-search`, or use `product-semantic-search` for discovery. Base product claims on returned catalogue data. Empty searches or unavailable fields require a revised plan, not invented products or specifications.
- Check `creative-list` for suitable ready assets. Create new assets when none fits the request or the agreed plan. Pass product IDs, the full customer brief, the applicable playbook's format direction as `instructions`, and its relevant picture keys to `creative-still-create` or `creative-carousel-create`. Write captions in the playbook's tone.
- Use an existing campaign ID when appropriate. For a campaign that only holds these posts, pass `campaign_name` to the first platform post tool and reuse its returned campaign ID. Use `campaign-create` when a separately configured campaign is needed. Standalone posts can omit the campaign; pass the campaign ID the first call returned to the other platforms' post tools for the same creative.
- Preserve the agreed asset counts. Each platform has its own post tool (`post-x-create`, `post-tiktok-create`, `post-facebook-create`, `post-instagram-create`, `post-threads-create`, `post-bluesky-create`, `post-pinterest-create`), which creates one post per named channel of that platform; distinguish unique creative drafts from their channel posts. Pinterest boards and TikTok options come from `channel-list`; ask the customer for those choices.
- Generation runs in the background. Use the returned `creative_id` to write drafts without waiting, as the generation tool instructs. Use generation events when supported, or `creative-generation-get` when the customer asks or a status check is needed. A running or failed generation is not a finished asset; do not restart generation automatically after an uncertain result.
- Verify the persisted posts with `post-list`, including pagination when needed. Check campaign, copy, channels, formats and requested counts, then call `post-review` with the returned post IDs or campaign ID. Let the review card present the drafts.
- Complete the requested draft campaign before offering distribution. A request to prepare drafts or approve their copy leaves them unscheduled and unpublished. When the customer has also authorized scheduling or publishing, carry out that instruction using the post-management workflow and verify its result.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: create-creatives
description: Generate ProductByte product images and carousel decks from catalogue products and brand playbooks. Use for standalone creative briefs or campaign assets; generating an asset does not itself create posts.
---

Use the ProductByte MCP tools from this plugin. Tool names below are the server names; use the corresponding names exposed by the host.

- Use the selected project, or read `workspace-get` and resolve it by name before generation. Read `playbook-list` for its creative direction and `channel-list` when the asset has a publishing destination.
- Resolve product references through `product-semantic-search`, or inspect `product-field-list` before field-based `product-search`. Use `product-get` for details needed by the brief. Choose products with the customer when their reference is ambiguous, and use verified catalogue facts for claims in the creative.
- Carry forward the customer's actual goal, products, offer, copy language, visual direction, format and asset count. Ask for missing choices that affect the result. A request for a carousel means a deck, not several unrelated stills; keep the requested slide count within the generation tool's limits.
- Apply playbooks with `auto_select` when their descriptions fit. Use other playbooks when named by the customer. Pass the applicable `brief.image` or `brief.carousel` as generation `instructions`, use relevant picture keys as `playbook_pictures`, and include the complete current brief in `prompt`: the composer cannot read the chat or fetch playbooks itself.
- When the customer asks to save how their brand looks or sounds, change a fitting playbook or create one with `playbook-put` after they confirm.
- Call `creative-still-create` once per requested still or `creative-carousel-create` once per requested deck. Pass returned product IDs and the required ratio. A request to find or reuse an existing asset goes through `creative-list` instead.
- Save the returned generation and creative IDs. Follow generation events when the host supports them; check with `creative-generation-get` when the event arrives or the customer asks for progress. A running generation is still composing, and a failed or uncertain response does not authorize another paid generation.
- When creating posts was also requested, attach the returned creative ID without waiting, as the generation tool instructs. For an image-only request, return the asset or its generation status without creating a campaign or post.
- Report each requested asset's actual state. A request to revise a result needs a new complete brief carrying the requested changes and the original constraints; use only revision or reference inputs supported by the available tool. Explain when a new generation is required rather than claiming to have edited the existing asset.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: manage-posts
description: Review, revise, schedule, queue, publish or cancel ProductByte social posts and prepare standalone posts from existing creatives. Use for draft copy, approvals and publishing schedules; use create-campaign for a new multi-post campaign.
---

Use the ProductByte MCP tools from this plugin. Tool names below are the server names; use the corresponding names exposed by the host.

- Resolve the selected project through `workspace-get` when needed. Find an existing campaign by name with `campaign-list`, then read `post-list` for the requested campaign or project. Follow pagination before acting on a request concerning all matching posts.
- For a standalone post, read `playbook-list` for caption tone, `channel-list` for destinations and `creative-list` for a suitable asset. Write drafts with each platform's post tool, such as `post-instagram-create`; name every channel of that platform in one call, and pass the returned campaign ID to the next platform's tool for the same creative. Create a new creative when no existing one fits.
- For copy changes, group posts by the returned `draft_id` and update each affected draft once with `post-draft-update`, using its campaign ID. Write the full replacement copy and preserve wording, headline and channels outside the requested change. Re-read affected posts to verify the persisted copy; an empty update result is not success.
- Show draft reviews with `post-review` using the affected post IDs or campaign ID, and again after a creative or copy changes. Let the card present them. Record an explicit chat verdict with `post-draft-update`; copy approval alone does not authorize scheduling or publishing.
- Read `needs` before distribution. Use `post-pinterest-update` with the customer's Pinterest board or `post-tiktok-update` with their TikTok choices, both offered by `channel-list`. Keep those choices with the customer.
- For scheduling, translate the agreed date and time in the customer's timezone and use `post-publish` with `scheduled_at`. Omit `scheduled_at` only when the customer asked to publish now. Publishing-window setup is available in the ProductByte app.
- Adding to `post-queue` authorizes automatic publishing at the queue's next slots. Call it without changes to read the current queue first; adding a dated post removes its date, while scheduling a queued post removes it from the queue. Explain expected times using the current queue result. Publishing frequency and windows are configured in the ProductByte app.
- Remove queued posts through `post-unqueue`; they stay as drafts. Cancelling a dated post without deleting it is available in the ProductByte app; open `productbyte` when the customer requests that workflow. Use `post-delete` only for requested deletion; for a published post, check whether its channel supports taking it down. Cancellation and deletion are different outcomes.
- Verify changed posts with `post-list` and re-read the queue when it changed. Report accepted, refused, failed or still pending states separately. Publishing that lost contact may already be live: use `confirmed_not_live` only after the customer checked the channel and confirmed absence, and do not blindly retry an uncertain publication.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: manage-product-feeds
description: Connect, change or delete ProductByte product sources, resolve source setup, change import schedules and inspect sources and destinations. Use for shop connections, feed URLs, Merchant Center sources and catalogue freshness; destination inspection does not create or repair a destination.
---

Use the ProductByte MCP tools from this plugin. Tool names below are the server names; use the corresponding names exposed by the host.

- Resolve the selected project with `workspace-get` when needed. Read `sync-source-list` for sources and `sync-destination-list` for destinations relevant to the request. Describe names, statuses, last completed runs and available counts.
- Connect Shopify, WooCommerce or bol through `sync-source-connect` only when the customer requests that connection. Hand over the returned ProductByte link and its hints; the customer installs or authorizes the connection themselves. Re-read sources after they finish.
- For a product feed URL supplied by the customer, use `sync-source-feed-create` with that address. For Google Merchant Center, read `sync-source-google-feed-list`, let the customer choose the feed, and pass its returned URL, language and target market unchanged to `sync-source-google-merchant-create`.
- A `waiting` source needs the customer's setup answer. Present the proposed locale and currency from `sync-source-list`; send both through `sync-source-update` after the customer accepts or supplies them. Providing both starts the waiting import, so do not do this during a read-only inspection.
- Change source names or reading frequency through `sync-source-update` only as requested, passing only changed fields and the agreed schedule. A manual schedule does not read automatically.
- When the customer asks to refresh a source, use `sync-source-import` once and read its state with `sync-source-list`. An import already running is left to finish. Respect a returned `retry_at` and report pending work without triggering repeated imports.
- Delete a source with `sync-source-delete` only when the customer asks. Its products leave the catalogue and it cannot be undone.
- A successful connection or started read is not proof that products have landed. Verify completion and catalogue availability separately with the returned last-import state and `product-search` when needed. Feed or destination counts do not establish that product search is ready; identify a discrepancy without fabricating products.
- For destinations, explain the actual delivery status, filter and last published count from `sync-destination-list`. Only a live destination is delivering. Report unavailable configuration or repair actions accurately instead of promising a destination change the tools cannot perform.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: review-performance
description: Explain ProductByte sales and social performance for a requested reporting period and suggest next actions. Use for ProductByte analytics and performance reviews.
---

Use the ProductByte MCP tools from this plugin. Tool names below are the server names; use the corresponding names exposed by the host.

- Resolve the project with `workspace-get` when it has not been selected. Ask which project to use when several are available. Read only the selected project's figures.
- Translate the requested period into calendar dates and pass the customer's IANA timezone when known. For a review without a period, use the tool's current-month defaults and state the returned range.
- Use `insights-get` for sales and social figures. Call `insights-show` when the customer asks to see the performance card, and let it present the figures.
- Base conclusions on the returned reporting range and collection status. Missing metrics, absent days or an absent shop result mean figures are unavailable, not zero sales or poor performance.
- Treat gauge values as snapshots, not values to sum across days. Use returned range totals for daily metrics and shop sales. Preserve currency and identify ranges with no single currency.
- Compare equivalent periods and compatible metrics when the customer requests a comparison. Distinguish observed changes from possible explanations; do not claim that posts caused sales without supporting data.
- Give a concise assessment and practical next actions tied to the observed figures. A performance review does not itself authorize campaign changes or publishing.

Referenced files: 1 — file references are metadata, not package contents.