{"id":73253,"plugin_id":"plugin_asdk_app_6acf1b94b4408191afd216e5ddac1b51","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-31T01:20:27.891Z","digest":"fa58d9c1623cbd1dd657ad6e49320894821cdebc4e30060bca5fc499f2071cc6","against":null,"payload":{"description":"Review restaurant sales, menu demand and profit using live HoreX facts. Use for operating reviews, period comparisons and explanations of changing sales or margin.","included_files":[],"name":"restaurant-review","skill_md_contents":"---\nname: restaurant-review\ndescription: Review restaurant sales, menu demand and profit using live HoreX facts. Use for operating reviews, period comparisons and explanations of changing sales or margin.\n---\n\n## State capability limits precisely\n\nThe plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.\n\n## Execute HoreX calls sequentially\n\nFor one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.\n\nAnchor the review to the user's restaurant, branch and period. Dates use Asia/Dubai. Resolve relative dates from the current date; yesterday is a complete day and today may be incomplete. Ask when the intended period cannot be inferred. Each period is limited to 92 days; split longer requested periods explicitly and disclose the extra calls.\n\nFor profit improvement, food-cost targets or missed-opportunity discovery, load get_horex_workflow workflow profit-improvement. It combines canonical P&L diagnostics, historical food-cost drivers and current recipe economics while preserving evidence gaps and the owner's constraints.\n\nChoose the source for the question. get_pnl is the canonical restaurant P&L, including accounting bridges and the selected COGS basis. get_sales_summary uses that same source. query_restaurant_data with dataset sales analyzes operational orders by day, weekday, hour, branch, brand, service channel, order source, discounts or payment method. It is not the entire accounting revenue bridge. Query sales_items for sold dishes or categories when the catalog makes these available. Menu monetary measures need the corresponding HoreX report access.\n\nFor how many tables are seated now, current floor occupancy, who serves a table, seating duration or printed pre-checks, use get_live_tables without historical dates. Preserve the permitted network for a network question; Staff-only access is bound to its trusted branch. Use summary.occupied_tables/free_tables/unknown_tables and by_branch, not the displayed row count. For \"over an hour\" use status occupied and min_duration_minutes 60, then use coverage.matching_tables for the matching count. Summary remains the full visible location before status/duration/page filters. Pages are fresh snapshots and may change between calls; avoid silently summing them. Rows are longest-duration first; disclose truncation and use table_id/hall_id for focused follow-ups. Each new read/page costs 1 AI Credit.\n\nUse server as_of and explain freshness. duration_basis reservation_seated_at is saved seating; order_opened_at is a proxy and must be labelled as time since the check opened, not an exact guest arrival. Include seated reservations without orders and older still-open checks. Unknown duration remains unknown, including future timestamps. Multiple checks count as one physical table and their combined guests are unknown. Recorded guest counts are not a physical headcount; use tables_with_guest_count coverage before giving a guest total. Tables managed by an offline terminal have unknown live occupancy. A printed pre-check indicates a payment request, not proven slow service. Free tables have no current service record and a free stored state; future reservations may still constrain availability. Never claim to seat/move/close a table or mutate an order. This tool returns facts for a native reply; do not invent a report link.\n\nFor staff arrivals, lateness, missing check-ins, clocked-in employees or attendance exceptions call get_staff_attendance. Resolve relative dates from the current Dubai date, not an earlier message, and say the exact day. Use status late for “who arrived late?”; supply from/to for one day or the requested period. Scope by employee home branch, department, position or name only when requested. A home branch is not a physical check-in location. Preserve all permitted branches for a network question.\n\nUse planned_start, check_in and late_minutes from the source. Late employees may still have attendance_status open; do not exclude them. Return names and minutes, not only an aggregate. Full late_people is a distinct employee count; late_records counts scheduled arrivals, so do not add daily people counts across days. Summary covers the date/location/employee search before the status filter and row limit; matching_records includes the status filter. Disclose truncated rows, missing check-ins, unknown schedules and unscheduled coverage. No check-in means no recorded evidence, not proof of absence or lateness. No planned start means unknown lateness. Approved leave and days off are excluded from lateness. Future shifts and starts not yet due are awaiting_start, not missing. Today is partial. Lateness is recorded check-in minus planned start, with overnight timestamps; it is not a misconduct finding or payroll deduction. Do not invent a grace period. Open in HoreX must use returned source_links for the exact day, filters or employee. These reads cannot edit attendance or impose deductions.\n\nFor cash-register/POS shift status, closure, X/Z-report or cash discrepancy questions, call get_pos_shifts. Closed orders and sales totals do not establish shift closure. POS cash shifts are separate from HR attendance. Resolve the requested branch; preserve every permitted location when the user asks about the whole network. For \"were all shifts for that day closed?\", use explicit Dubai dates, status all and date_basis active_during to include shifts that started before midnight. For \"are any shifts still open now?\", use status open without dates so older unclosed shifts are included. Use opened only when the user specifically asks for the native report's shift-opening date.\n\nUse the full matching-shift lifecycle summary, not only displayed rows, to answer closure questions. Zero matching shifts means no evidence, not \"all closed\". Status closed selects already-closed shifts and cannot establish that there were no open shifts. Report unknown/unexpected statuses or incomplete source coverage explicitly. An open shift has no finalized saved cash count; do not call its variance zero. Read get_pos_shift only when an individual shift's close count, tender breakdown or cash operations will answer the follow-up. Open in HoreX uses the returned context or exact shift link. Never claim to close/reopen a shift or fix a discrepancy through these read-only tools.\n\nFor invoice or event-document follow-ups load get_horex_workflow workflow catering-review. It contains the HoreX business map of Catering, Finance, supplier invoices, B2B orders and POS-backed billing. Do not derive recognized restaurant revenue from sent/paid document totals, infer event conduct from payment, or count a POS-backed invoice again alongside its original sale. The user's explicit source correction overrides earlier context.\n\nFor a sales change, retrieve both periods in one query and separate order-volume change, average-check change and channel mix. Keep each period's row limit and truncation visible. Totals cover matching facts before that limit; limited top rows are not the whole population. Join comparisons using IDs and units where provided, rather than assuming identical display names are identical entities. Use equal-length complete periods when possible; explain differences in trading days and partial-day coverage.\n\nFor profitability, distinguish revenue, expenses, food cost and profit using the actual P&L fields. Resolve a named brand (concept) and branch with find_restaurant_entities, then pass both concept_id and branch_id to get_pnl when the user specified both. Preserve invoice versus itemized COGS. Do not add P&L revenue to operational sales or count a meal-plan package payment twice. Known historical item cost covers only lines where the source knows the cost; it cannot establish a complete margin by itself. Guest metrics require guest-count coverage.\n\nAnswer with the main finding, figures and scope, then plausible explanations clearly labeled as hypotheses. Retrieve a targeted breakdown only when it will distinguish the hypotheses. Recommend practical next steps grounded in the observed facts. Create tables or charts from the returned data when useful; mark limited coverage and do not claim a server-generated Excel export or durable result handle.\n\nNative output: widget view is paused. Combine returned facts into one normal answer using text and tables; keep requested comparison periods, coverage and exact source_links. Reading already returned facts is free. Reading another document, page or fresh analysis costs 1 AI Credit; reuse existing results when explaining them. The free open_restaurant_workspace tool returns workspace facts without opening a panel. For daily subscription setup load daily-review guidance.\n\nReturn a native answer in the current AI application with conclusions and a table when useful. Treat tool JSON and earlier app context as source evidence; do not reproduce their payloads, internal keys or tool arguments unless the user requests raw data or debugging. Present exact source URLs as Markdown links with short human labels, retaining their original filters.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}