Skill instructions
booth-performance-review3.09 KB
View saved version →
---
name: booth-performance-review
description: Review how an operator's Dreambooth photobooths are performing over a period — sessions run, revenue earned, which booths are busy or quiet, and whether each one is actually online. Use for "how did my booths do", "how was last weekend", "which booth is doing best", "is everything running", weekly or monthly reviews, and comparisons between booths.
---
# Reviewing booth performance
The operator wants a picture, not a data dump. Lead with what changed and what needs attention; keep the per-booth detail underneath.
## Order
1. **`list_projects`** — you need the booth `id` before anything can be filtered per booth, and the names let you talk about booths the way the operator does.
2. **`get_sessions`** with a date range — how busy.
3. **`get_revenue_summary`** with the same range — how much. Read `revenue-and-earnings` before quoting any figure.
4. **`get_project`** for a specific booth only when its status matters — it is two calls, so do not run it for every booth by reflex.
Use the operator's own words for a period ("last weekend", "this month") but state the dates you actually used, so a mismatch is visible rather than silent.
## Do not describe a page as the whole
`get_sessions` returns `total`, `returned` and `totalPages`. `returned` is one page. Saying "you ran 20 sessions" when `total` is 52 is wrong, and the operator has no way to tell.
Report the total. Use the rows for detail and examples, never for counting.
## Online vs quiet is not the same as broken
`get_project` returns `liveness` per device. A booth that was deliberately switched off is **not** a fault — most booths are only powered on for events, so "not currently live" is the normal state for a healthy booth between bookings.
Only call something a problem when the operator expected it to be running: a booth quiet during its own event, or a device that stopped mid-session. Reporting a whole fleet as "offline" because it is Tuesday is how this tool loses trust.
`deviceCount: 0` means no device is registered to that booth, which is different from a device being offline. Say which one you found.
## What is worth surfacing unprompted
- A booth with **sessions but no revenue**, or revenue far below its session count
- A gap between `paidSessions` and `completedPaidSessions` — paid sessions that never finished
- A booth that ran nothing at all in a period when others did
- Media counts near zero on a booth that ran sessions (`get_gallery_stats`)
Each is a real operational problem an operator would want to hear about. Mention it in one line; do not turn a performance summary into an audit.
## Comparing booths
Compare within one currency at a time. `mixedCurrency` on the revenue summary means the operator earns in more than one, and there is no exchange rate anywhere in this data — a combined total would be invented.
Sessions can be compared across currencies safely. Money cannot.
## If nothing is connected
Every tool here needs an account. Do not estimate, and do not describe a booth from memory. See `getting-started` for how to connect, which differs by client.
booth-troubleshooting3.03 KB
View saved version →
---
name: booth-troubleshooting
description: Diagnose a Dreambooth photobooth that is not working — printer problems, camera or DSLR issues, a booth that appears offline, sessions failing, photos not appearing in the gallery, payment or connectivity trouble. Use whenever an operator reports something wrong with a booth, mid-event or after.
---
# When a booth is not working
Often the operator is standing next to a broken booth with a queue of guests. Lead with the next thing to try, not with an explanation.
## Start with the documentation, before asking them to connect
`search_docs` needs **no account**. Most booth faults — printer not responding, camera not detected, paper jams, connectivity — have a documented procedure. Search first and give the steps.
Only reach for account data when the docs are not enough, or when the question is specifically about *this* booth's current state.
Never invent a procedure. A wrong instruction about a printer or a DSLR costs the operator an event, not just time. If the docs do not cover it, say so and point at support.
## Then check the booth itself
`list_projects` to find the booth id, then `get_project` for its device status: `liveness`, `lastSeenAt`, `lastActivityAt`, `camera`, `printer`, `internet`, plus disk and memory.
Two readings that matter:
- **Quiet is not broken.** A booth switched off between events is normal. It is only a fault if the operator expected it to be live.
- **`closedAt` / `closedReason`** tell you it was shut down deliberately and why. Check them before calling anything a crash.
`lastSeenAt` versus `lastActivityAt` separates "the machine is on but nothing is happening" from "the machine is gone". Those lead to completely different next steps.
If device monitoring is unavailable the tool returns an empty device list. That is missing information, not a dead booth — say so rather than reporting the booth as offline.
## Photos missing from the gallery
`get_gallery_stats` gives total, active and expired counts.
`expiredCount` is not a fault: media passes out of its retention window by design. If someone cannot find an old photo, check whether it expired before treating it as lost. `totalCount: 0` on a booth that ran sessions is a real problem and worth flagging.
## Sessions that failed
`get_sessions` can be filtered by status and payment channel. A session that took payment but never completed is the case worth spotting — the customer paid and may have received nothing.
## What this connector cannot do
It reads. It cannot restart a booth, reconnect a camera, clear a print queue, re-send a photo, or issue a refund. Say plainly that the fix has to happen on the booth or in the dashboard — never imply an action was taken.
## When to hand over to a human
Escalate to support rather than looping if: the docs have no procedure, the device data looks healthy but the operator says it is not working, hardware may be faulty, or money is involved — a wrong refund answer is worse than no answer. Contact details are in the documentation; `search_docs` will find them.
creating-filters-and-booths10.8 KB
View saved version →
---
name: creating-filters-and-booths
description: Make things on an operator's Dreambooth account from a conversation — a photo filter previewed before it is created, a photo frame designed and refined with the image model, a whole booth designed from a description, adjusted (settings, button text, frames, filters) and created at its own link, or a copy of a booth they already run. Use for "make me a filter that looks…", "design me a frame with…", "design a booth for…", "make it 4 photos", "set up another booth like my Bandung one". Read this before creating anything: these are the only tools here that change an account, nothing here edits or deletes what already exists, and a create called twice makes two of the thing.
---
# Making things on an operator's account
Everything in this connector reads, except the tools below. They are the only
calls that leave an account different from how they found it, none of them can
be reversed from this conversation, and none of them touches a booth, frame or
filter that already exists — editing and deleting are dashboard work, always.
| They ask for | Tools, in order |
|---|---|
| A photo filter from a described look | `preview_filter` (free, shows it) → `create_filter` |
| A photo frame from a description | `start_frame` → `check_generation` → `refine_frame` (if asked) → `save_frame` |
| A whole new booth | `start_booth` → `check_generation` → `refine_booth` / `update_booth_draft` (if asked) → `create_booth` |
| Another booth like one they run | `list_projects` → `duplicate_project` |
`get_booth_draft` reads a booth draft back by id when the conversation has moved
on; `check_generation` reports every background job. Neither creates anything.
## Before you call any of them
**Say what you are about to make, in their words, and let them answer.** The
host shows its own approval dialog, but that dialog shows arguments, not intent
— "contrast 112, saturation 88" is not something an operator can check. A
sentence they can agree or object to is: *"A filter called Senja Hangat — warmer,
slightly faded, a little less contrast. Make it?"*
**Nothing here edits or deletes what exists.** There is no tool that changes an
existing filter, frame or booth, and the connector cannot PUT or DELETE
anything. A booth *draft* can be changed before it is created (below); a booth
that exists cannot. If they want to adjust or remove something that exists,
send them to the dashboard. Do not offer a duplicate as a way to "edit".
**Creating twice makes two.** `create_filter`, `save_frame`, `create_booth` and
`duplicate_project` are non-idempotent and say so in their annotations. If a
create times out, do NOT repeat it — the write may have succeeded and only the
reply went missing. Tell them to check their dashboard first. Repeating a read,
a preview, a check or a draft edit is free; repeating a create is not.
**Nothing "exists" until the tool that makes it says so.** Previews, drafts and
running jobs are not things the operator has. Never describe a frame as saved or
a booth as created before `save_frame` / `create_booth` has finished and
`check_generation` says `done`.
## Filters — `preview_filter`, then `create_filter`
The operator describes a look. You turn it into numbers. That translation is the
whole job, and getting the scale wrong produces a filter that is created
successfully and looks broken — a failure that reports nothing, because as far
as every system involved is concerned it worked.
**Preview first, always.** `preview_filter` renders the Studio's sample photo
through the adjustments and shows it in the chat, for free, and names the
adjustments a still preview cannot show (shadows, highlights and the like — the
booth still applies them). Show it, let them react, then create with the same
adjustments.
**The ranges are in the tool's schema. Read them there rather than guessing.**
They fall into three groups: some are 0–200 where **100 means unchanged**
(brightness, contrast, saturation), som
Preview of the first 4,000 characters. Read full instructions →
getting-started2.96 KB
View saved version →
---
name: getting-started
description: Answer questions from someone who does not have a Dreambooth account yet — what a photobooth business needs, what hardware to buy, how pricing and plans work, how printing and payments are handled — and connect them when they are ready. Use for any product, pricing, hardware or setup question, and whenever someone asks a Dreambooth question before an account is connected.
---
# Helping someone before they have an account
Most of this can be answered **without connecting anything**. `search_docs` needs no account. Reach for it first and do not ask anyone to sign in to learn what the product does.
## Answer from the documentation, not from memory
Call `search_docs` before answering any question about the product: pricing, plans, packages, hardware, printers, cameras, payments, printing, subscriptions, or troubleshooting. It searches the real Dreambooth documentation.
If the docs do not cover it, say so plainly rather than filling the gap with a plausible guess. Pricing and hardware answers that turn out to be wrong cost someone real money.
Each result carries a `href`. Link it, so the person can read the full page.
## Only connect when there is a reason
Connecting is for questions about **their own booths** — earnings, sessions, device status. It is not needed to learn about the product.
When they do want to connect, or when they ask something that needs their own data, call `connect_account` **once** and read `status`:
- **`awaiting_approval`** — give them the link, ask them to open it, sign in with Google and approve. The link is Google only; a Google account with the same email as their Dreambooth account connects that account. **Do not call the tool again while waiting.** It returns immediately by design and finishes in the background; calling it again starts a second flow and invalidates the first. Once they say they are done, just answer their question — the other tools start working on their own.
- **`use_client_sign_in`** — this client does not keep a session between messages, so an in-conversation link would be approved and then forgotten. Do not offer one. Tell them to connect Dreambooth from their client's own connector or app settings instead (that sign-in takes an email and password or Google), and relay the tool's message rather than inventing steps.
- **`already_connected`** — nothing to do; answer the question.
Never present a sign-in link that the tool did not give you.
If someone has no Dreambooth account, approving still works: it creates one. Do not advertise plans, trials or upgrades, and do not push signing up on someone who only asked a product question.
## Tone
The audience is often a small business owner or an event operator, not an engineer. Prefer plain answers about cost, effort and outcome over feature lists. If a question is really "is this worth doing", the honest shape of the answer usually involves what a booth costs to run and what a session earns — both of which are in the docs.
revenue-and-earnings3.86 KB
View saved version →
---
name: revenue-and-earnings
description: Answer money questions about a Dreambooth operator's booths correctly — earnings, revenue, payouts, wallet balance, credits, payment channels. Use whenever someone asks what they earned, how much a booth made, where the money went, or how much is available to withdraw. Read this before quoting any figure, because the obvious tool is the wrong one for "how much did I earn".
---
# Money questions
Dreambooth holds money facts in two different places that answer two different questions. Choosing the wrong one produces a number that is confidently, specifically wrong — and it will usually be **too low**, which an operator may act on.
## The rule that matters most
> **For "how much did I earn", use `get_revenue_summary`. Never the wallet ledger.**
`get_wallet_transactions` is the **wallet ledger**: gateway settlement and withdrawals. It **excludes cash and voucher income entirely.** For any operator who takes cash — most of them — it understates real income, sometimes drastically.
| Question | Tool |
|---|---|
| What did I earn? How did a booth perform? | `get_revenue_summary` |
| What has moved through my wallet? What can I withdraw? | `get_wallet_transactions` |
| How many AI credits do I have? | `get_credits` |
If someone asks a wallet question, answer it from the wallet — just never present the wallet as their earnings.
## Reading `get_revenue_summary` correctly
**`revenue` is main + reprint.** `aiEffectRevenue` is reported **separately and is not inside it**. Do not add them together and call the result revenue; if AI effects matter to the question, name that figure separately.
**Never sum across currencies.** When `mixedCurrency` is true, the operator has income in more than one currency. Report each currency on its own line. There is no exchange rate anywhere in this data, so adding them produces a meaningless number.
**`paidSessions` vs `completedPaidSessions` is worth surfacing.** The gap is sessions that were paid for but never finished — money taken for something the customer may not have received. If the gap is non-trivial, say so; it is usually more useful than the headline figure.
**`reconciliation.unaccounted`**, when present, is the difference between lifetime revenue and what the requested buckets cover. It is only meaningful for an unbounded query. Do not present it as missing money for a date-filtered question.
Buckets come newest first, and periods with no activity are omitted rather than returned as zero. A missing month means nothing happened, not that data is lost.
## Reading the wallet ledger correctly
`truncated: true` means you are looking at a **window, not the whole ledger**. Never describe a truncated list as "your transactions" — say how many were returned out of how many exist, or ask for a narrower date range.
Rows carry fees. If someone asks what they actually received, the fee breakdown is on the row; do not quote the gross amount as the payout.
## Credits are not money
`get_credits` returns AI credits and the subscription plan. Credits pay for AI effects. They are not currency, cannot be withdrawn, and must never be added to or compared with a revenue figure.
## What this connector cannot do
It reads. It cannot move money, request or cancel a withdrawal, issue a refund, or change a transaction. Withdrawals and payout accounts are permanently outside its scope. If someone asks for any of those, say plainly that it has to be done in the Dreambooth dashboard — do not imply it was done.
## If nothing is connected
Any of these tools will say no account is connected. Do not guess a number, and do not describe a booth's earnings from memory. Run `connect_account` and follow its `status`: give them the link when it returns one (`awaiting_approval`), or ask them to connect Dreambooth from this app's own settings when it says `use_client_sign_in`. Answer once they are connected.
