BBQ weekly schedule builder - segmented evening shifts, grill-skill constraints, a closing crew: have a coding agent build a single-file scheduler
You are a coding agent. Build a single-file web scheduler for a BBQ restaurant's scheduling supervisor (HTML, CSS, and JS all inline; no external dependencies, no backend, no network requests), opened by double-click. The shift structure and constraints of BBQ scheduling are written below - build to this structure, not to a generic restaurant template.
Three input blocks:
1. Staff profiles
- Name, skill tags (multi-select: run meat grill / run vegetable grill / skewer / mark tickets / run food / cashier / cleaning - tags editable by me), weekly availability, weekly hour cap [ ], consecutive-workday cap [ ]
- Per person, flags like "no late night" or "late night only"
2. Band demand
- Bands are self-defined; the BBQ typical four: prep (opening to dinner), peak (dinner), late night (post-floor to close), closing crew - I set the boundaries
- Each band carries two demand types: a headcount floor; skill constraints (e.g., "peak requires at least 1 meat-grill-capable and 1 vegetable-grill-capable"; the closing crew's floor set separately)
- Demand may differ by day (Friday and Saturday extend the late band; midweek closes earlier)
3. Rules
- Minimum rest between shifts [ ] - the person who closes may not be scheduled the next morning; this is a hard constraint
- Minimum safe staffing for the late-night hours [ ]; below it, the whole band flags red
Generation and checking:
- One-click weekly generation: skill constraints first, hour balance second; after generation each band shows its coverage state - headcount met or not, grills covered or not, whatever is missing flagged by name
- I can drag people between shifts manually, and every manual edit instantly recomputes coverage - the scheduler's core value is "one edit, full re-check," not me re-auditing the sheet by eye afterward
- Per-person roll-up: weekly hours, consecutive workdays, count of late-night shifts - any breach flags the whole row red
Export:
- The schedule exports as plain text (grouped by day: date / band / names) - copy it straight into the staff group chat
- Profiles and demand persist in localStorage with JSON export / import
Hard requirements:
- Zero preset data: skill tags, bands, caps, gaps all left empty for me to fill
- Every check refreshes instantly after manual edits - no "re-check" button
- Deliver a single .html file with three lines of usage notes at the top
You must not:
- Build a smart "optimizing" scheduler - generate by rules, expose problems by checks; the decisions are mine
- Add accounts, cloud sync, or external libraries
- Preload sample staff or sample bands - an empty table is the correct state
Why it is written this way
The band structure is fixed as a self-defined prep - peak - late - closing four, rather than generic morning/evening blocks, because a BBQ labor curve cannot be approximated by two blocks: prep needs skewerers, peak needs grill and running food, late night needs self-sufficient all-rounders, and closing is its own small crew. A morning/evening template puts every real demand on a band boundary, generating endless special cases. Boundaries stay with the user; the shape is welded in - the tool understands BBQ's silhouette but not this shop's hours.
"Skill constraints outrank hour balance" and "no morning shift after closing" as a hard constraint are the two pivotal rules in generation. Adequate headcount with a skill gap is the leading cause of late-night incidents, so grill coverage checks take top priority; and "one edit, full re-check" upgrades the tool from generator to checker - real scheduling is generate, hand-adjust, adjust again, and any adjustment can silently move the only grill-capable person out of an hour. Instant recomputation means the supervisor always sees true coverage after every edit, which no spreadsheet will ever do.
"Count of late-night shifts" sits in the per-person roll-up because it is the dimension most easily missed outside raw-hours compliance: an employee can sit under the weekly total while running five consecutive late nights - and fall apart on day six. Scheduling's hidden costs live in distribution, not totals, and only a tool that displays distribution lets a supervisor see them.
Banning the "smart optimization" joins the zero-preset-data rule at the root: a schedule is a composite of personal favors, commutes, stamina, and preferences, and any algorithm claiming optimality is guessing across those unquantifiables. This tool's position is "generate by hard rules, flag violations instantly" - the decision stays with the supervisor. The day a scheduler oversteps and decides is the day employees start bringing their grievances about the algorithm to the schedule meeting.
Variables
| Variable | Notes |
|---|---|
| Hour and run caps | Weekly hours [ ] and consecutive days [ ] - set together with the payroll cycle |
| Rest gap | Minimum hours between close and next morning [ ] - set by commute distance, then enforce without exceptions |
| Late-night safety minimum | Same number as the early-warning tool - both tools speak from one figure, never two |