Restaurant Management Planner
Structured discovery planner that turns a vague restaurant POS prompt into a scoped, evidence-cited CLAUDE.md or AGENTS.md build spec.
The problem this kills
"Build me a restaurant POS" is one of the most reliably broken prompts you can give a coding agent. The agent happily builds something — a sales form, an invoice screen, maybe a pretty dashboard — and calls it done. Then you discover there is no kitchen ticket flow, no shift close, no floor plan, no way to record a split bill, and no proof that the reports are derived from actual orders rather than seed constants. You spend two weeks debugging a system that was never scoped to be a restaurant system in the first place.
Restaurant management software is not one product. It is a cluster of subtypes — counter-service cafe, full-service dine-in, QSR, bar, pizza/takeaway, cloud kitchen, QR table ordering, multi-location chain — each with different mandatory modules, different branch boundaries, and different failure modes. A generic prompt collapses all of them into one hallucinated blob or, worse, picks the wrong one silently. The result is scope drift: integrated payments claimed but not implemented, hardware integration implied but untested, a KDS that is a static admin table rather than a real operator surface, a floor plan replaced by a text input for table number.
Why your agent cannot fake this
This planner encodes what 59 real restaurant systems actually do. The inventory tracks explicit frequency counts for every major feature family across those 59 sources — POS order entry in 41/59, menu categories and items in 44/59, receipts and KOT in 35/59, kitchen display system in 31/59, payments in 33/59, table and floor plan in 27/59, and so on down to branch-specific capabilities like QR ordering in 20/59, recipe and BOM in 17/59, or phone orders in 8/59.
Your agent cannot reproduce those counts without redoing the scrape. It can generate a restaurant app. It cannot tell you, grounded in evidence, that visual floor plan is a required dine-in branch (not a Basic default), that inventory deduction timing is a genuinely subtle design decision (payment-time deduction can be too late for a kitchen), or that shift close/cash drawer creates real operational disputes and requires a structured review modal with expected/count variance — not a browser confirm dialog. This planner encodes those distinctions as decision rules tied to specific frequency anchors, so the generated spec reflects what the market has already stress-tested.
What you actually get
A single agent-ready build spec — CLAUDE.md for Claude Code, AGENTS.md for Codex, or your tool's preferred file — produced after a structured discovery interview. The planner asks grouped decision blocks: First Delivery depth (Basic, Moderate, or Advanced), venue shape, service mode (counter, dine-in, takeaway, delivery, phone, QR, or a mix), roles, the core POS and order loop, which branch families belong in First Delivery, payment method, hardware intent, local policy fields, UI priority, visual direction, stack and hosting preference, and Build Execution Mode.
The generated spec includes locked decisions and explicit non-goals, a cited scope table, roles and permissions, a full data model, a screen map, UI requirements with visual direction, workflows, technical requirements, setup and seed data, reports, a step-by-step build sequence, acceptance tests, handover audit requirements, risks and open confirmations, an amendment roadmap, and a forbidden-family scan result so deferred modules cannot silently leak into active build sections.
Build Execution Mode is buyer-selected and locked: Guided Step Mode stops after each step and requires proof before continuing; Batch Mode stops after a buyer-selected batch with per-step proof; Autopilot Mode continues only while every gate passes and stops immediately on failure.
Coverage
The planner runs six structured discovery blocks before writing the spec:
- Phase 0 picks First Delivery depth and flags scope overruns early, before any code is written.
- Block 1 locks venue shape, service mode, and location count. Basic defaults to single-restaurant counter-service; multi-location is an explicit Advanced branch.
- Block 2 identifies roles and the one user who must love First Delivery most, which determines the primary UI surface.
- Block 3 covers the core POS and order loop: menu, modifiers, sold-out toggle, POS grid, payments, receipts and order tickets, shift open and close, dashboard, reports, audit log, and go-live checklist.
- Block 4 gates every branch family explicitly: dine-in floor plan, split bill, KDS and station routing, QR ordering, phone and delivery queues, reservations, inventory and recipe costing, integrated payments, hardware drivers, offline sync, multi-register, multi-location, and loyalty.
- Block 5 and Block 6 lock payment method, hardware intent, local policy fields, UI priority, visual direction, stack preference, and Build Execution Mode.
The planner then runs a forbidden-family scan across roles, data model, screens, workflows, technical requirements, reports, jobs and APIs, build sequence, and acceptance tests before writing the final spec. Deferred modules may appear only in non-goals, the defer ledger, risks and open confirmations, the amendment roadmap, or the scan result itself.