FLITTEN PROMPTS
Prompt like an engineer.
Without being one.
Just say what you want to build. Answer a few questions. Get a detailed, professional prompt that helps your AI coding tool build precisely.
- Clear requirements, architecture, workflows, and acceptance checks
- Automatic safety guidelines tailored to your project
- One complete prompt, or split it into ordered build steps
- Rewrite, add features, or trim scope with saved versions
PROJECT: GARDEN CLUB BOOKING PLATFORM
Build a production-ready garden plot booking application for registered club members and administrators. Members browse availability, reserve a plot, view their bookings, and join a waitlist when capacity is exhausted. Garden administrators approve bookings, manage plots and seasons, and review an audit trail. Deliver a responsive application with explicit access boundaries, transactional booking rules, automated tests, and repeatable deployment. Do not substitute static mock data for the persistence layer. Preserve the approved workflow: registered members only, with administrator approval before a reservation is confirmed.
ARCHITECTURE & TECHNOLOGY
Use TypeScript throughout, React for the interface, a server-rendered application framework, PostgreSQL for persistence, and an ORM with parameterized queries. Keep credentials, business rules, authorization, and database access on the server. Divide the application into authentication, membership, plot inventory, availability, bookings, waitlists, notifications, and administration modules. Browser components render data and submit validated commands; they cannot assign roles, approve reservations, calculate trusted prices, or bypass capacity checks. Centralize domain operations so the web interface and background jobs enforce identical rules.
DATA MODEL & MIGRATIONS
User: id UUID primary key, providerSubject unique, email normalized and unique, displayName, createdAt, updatedAt. Membership: userId foreign key, status ACTIVE|SUSPENDED, joinedAt. Plot: id, publicCode unique, name, description, capacity, active, createdAt. Season: id, name, startsAt, endsAt, bookingOpensAt, bookingClosesAt. Booking: id, memberId, plotId, seasonId, startAt, endAt, status PENDING|APPROVED|REJECTED|CANCELLED, requestKey, decisionBy, decisionAt. Add indexes for member history, plot/season availability, and pending approval queues. Migrations must include foreign keys, non-null constraints, valid-date checks, and a rollback strategy.
DATABASE CONSTRAINTS & CONCURRENCY
The database is the final authority for reservation consistency. Execute approval and capacity checks in one transaction. Lock the affected plot/season row before counting overlapping APPROVED reservations; use the same lock order for every booking mutation. A PENDING request does not silently become a confirmed reservation. Reject approval when capacity is unavailable, returning a stable conflict code. Add a unique request key per member to make repeated booking submissions idempotent. Test two members racing for the last available slot and two administrators approving competing requests concurrently. Exactly one permitted transition should commit when only one slot remains.
IDENTITY & AUTHENTICATION
Use a maintained authentication library with Google OAuth, state validation, PKCE where supported, and exact registered callback URLs. Create the application user from the verified provider identity, not an email supplied by the browser. Sign-in requires an active club membership. Use HttpOnly session cookies with SameSite=Lax and Secure on HTTPS; keep cookies host-only. Rotate or revoke sessions after sensitive account changes. Return a generic sign-in failure for inactive membership and give a support path without exposing whether another email is registered. No passwords, OAuth tokens, or session credentials may be embedded in browser bundles or logs.
ROLE & OWNERSHIP MATRIX
MEMBER: read active plots and seasons; read, request, and cancel their own permitted bookings; manage their own waitlist entries. GARDEN_ADMIN: edit inventory and schedules; inspect membership; approve or reject pending requests; view the administrative audit trail. A member cannot approve bookings, inspect another member's history, change capacity, or assign roles. Evaluate role and ownership on every server request. Hiding a button does not authorize an operation. Resolve memberId from the signed session and constrain database queries by both the requested record ID and authorized owner.
SCREEN MAP & NAVIGATION
Provide sign-in, availability, plot detail, request review, booking history, waitlist status, account settings, and an administration area. On phones, use a compact navigation layout and full-width forms with readable labels and touch targets. The availability screen shows season dates, open capacity, and pending-request guidance without exposing private member information. Plot detail explains the rules and offers an explicit reservation request. The review screen confirms plot, season, dates, and approval requirements before submission. Keep validation messages next to the affected fields and preserve unsent form values after a recoverable error.
BOOKING STATE MACHINE
Allowed transitions: PENDING→APPROVED, PENDING→REJECTED, PENDING→CANCELLED, APPROVED→CANCELLED subject to the cancellation deadline. Reject all other transitions, including approving an already rejected request or changing a cancelled request back to approved. An administrator decision records actor, timestamp, reason, previous state, and resulting state. Never trust a status field sent by a member. Display confirmation only after the server has committed the transition. Repeated approval requests must return the already recorded result without adding another reservation or sending duplicate notification messages.
AVAILABILITY & TIME RULES
Store timestamps as UTC and display them using the garden's configured IANA timezone. Validate startAt < endAt, dates inside the active season, and submission inside the booking window. Use half-open intervals [startAt, endAt) for overlap detection, with overlap defined by existing.startAt < requested.endAt AND existing.endAt > requested.startAt. Capacity calculation excludes REJECTED and CANCELLED bookings. Do not use the visitor's local clock as authority for submission or cancellation deadlines. Test daylight-saving transitions, boundary timestamps, adjacent non-overlapping slots, and edits to a season containing existing reservations.
WAITLIST WORKFLOW
WaitlistEntry: id, memberId, plotId, seasonId, joinedAt, status WAITING|INVITED|ACCEPTED|EXPIRED|CANCELLED, invitationExpiresAt. Enforce one active entry per member and plot/season. Order candidates by joinedAt with a stable ID tie-breaker. When capacity becomes available, create an expiring invitation in a transaction and dispatch notification through an outbox. Accepting an invitation must revalidate membership, deadline, and current capacity. An expired or already accepted invitation cannot be reused. Prevent one cancellation event from issuing several invitations for the same released slot.
API CONTRACTS
GET /api/plots?seasonId=<uuid> returns public inventory and authorized availability. POST /api/bookings accepts {plotId, seasonId, startAt, endAt, requestKey}; memberId and initial status are server-owned. GET /api/bookings returns only the signed-in member's records unless an administrator endpoint is explicitly used. POST /api/bookings/:id/cancel applies ownership and deadline rules. POST /api/admin/bookings/:id/decision accepts {decision: APPROVE|REJECT, reason}; authorize the administrator before fetching private booking details. Use 401 for missing sessions, 403 for denied access, 404 for unavailable owned records, 409 for state/capacity conflicts, 422 for invalid input, and 429 for exceeded request limits.
VALIDATION & ERROR FORMAT
Validate request bodies with a shared schema library. Reject unknown fields, malformed UUIDs, invalid timestamps, excessive nesting, oversized strings, and unsupported content types. Bound request bodies before parsing. Normalize human-readable text without destroying legitimate multilingual names. Return errors as {code, message, fieldErrors?, requestId}; never return SQL fragments, stack traces, provider payloads, or private records. Distinguish a capacity conflict from a temporary service outage. Client retries must reuse requestKey for the same command and must not repeat a completed decision because a response arrived late.
SQL INJECTION DEFENSE
Use bound parameters for every query and ORM expression containing user input. Do not concatenate search terms, IDs, date ranges, sort directions, or pagination values into SQL. Map sort choices to a server-owned allowlist of database columns; enforce numeric bounds on pagination. Run the application with a database role that cannot create extensions or alter the schema. Use a separate migration credential during deployment. Add tests for quoted search text, comment markers, Unicode edge cases, and unexpected object values; they must remain ordinary data and cannot broaden query ownership or reveal administrative records.
XSS & CONTENT SECURITY POLICY
Render member names, descriptions, and decision notes as escaped text. Avoid dangerouslySetInnerHTML and raw HTML templates for user content. If rich text is introduced, sanitize it through a maintained allowlist and validate link protocols. Set a Content Security Policy appropriate to the chosen framework, disallow framing except where explicitly needed, and avoid broad unsafe-inline exceptions. Do not interpolate untrusted values into script blocks, style attributes, or event handlers. Test stored and reflected payloads in plot descriptions, membership names, request reasons, search parameters, and error messages.
CSRF, IDOR & SESSION DEFENSE
Require the trusted application Origin for state-changing browser requests, with CSRF protection supplied by the authentication framework where appropriate. GET handlers must not change membership, bookings, or approval state. Include ownership predicates in update and delete queries; check affected-row counts before reporting success. A valid UUID does not authorize access. Verify that a member's request for another member's booking returns no private record. Rate-limit sign-in attempts and sensitive commands, bind administrative operations to a real signed administrator session, and audit session revocation and role changes.
SSRF & REMOTE CODE EXECUTION
The application does not need arbitrary URL fetching or server-side execution of submitted code. Do not add a proxy endpoint, shell invocation, template evaluator, or dynamic package installation to implement bookings. If notification integrations require outbound requests, use fixed provider endpoints, explicit timeouts, response-size limits, and restricted credentials. Block redirects to internal or link-local addresses if URL fetching becomes a requirement. User-controlled data cannot become filesystem paths, executable commands, module names, or database connection strings. Document any new outbound-network capability with its authorization and validation boundary.
UPLOADS, SECRETS & PAYMENT SKIMMING
Do not enable uploads or payments unless the approved scope requires them. If plot images are supported, allowlist formats, verify signatures, cap size, generate server-owned storage keys, and serve uploads from an isolated origin. Never expose private storage credentials. Keep authentication secrets, database URLs, provider tokens, and email credentials in deployment secret storage. Redact them from logs and exception reporting. If payments are later introduced, use a hosted payment provider and do not collect card credentials in the application. Restrict third-party scripts on payment and authentication pages and record approved integrations.
DDoS, RESOURCE LIMITS & TRANSPORT
Terminate public HTTPS at a trusted edge or reverse proxy and configure secure cookies consistently with the public origin. Redirect public HTTP to HTTPS and use HSTS after confirming the HTTPS deployment. Add bounded pagination, connection pools, request timeouts, per-account command limits, and edge-level abuse controls. Avoid unbounded availability queries spanning arbitrary date ranges. Add maximum lengths to search and filtering fields. Keep health checks lightweight and separate readiness from public application behavior. Test service overload gracefully: users should receive a safe retry message, and database transactions must not remain open after cancellation.
NOTIFICATIONS & TRANSACTIONAL OUTBOX
Write BookingNotification events into an outbox table in the same transaction as the booking transition. A worker claims pending rows, sends the configured notification, records delivery status, and retries with bounded exponential backoff. Deduplicate by event ID so retries do not send repeated approval messages. Never send approval before the transaction commits. Include the booking reference and a link to the authenticated application, excluding unnecessary personal details. Record provider request IDs without storing provider credentials. Expose failed delivery status to administrators without claiming the underlying booking has failed.
AUDIT LOG & OBSERVABILITY
Audit membership status changes, plot capacity changes, season edits, booking approvals, cancellations, and administrative access. Store actorId, action, subjectType, subjectId, timestamp, requestId, and sanitized before/after values. Member clients cannot edit the audit trail. Emit structured operational logs with latency, outcome code, and correlation IDs; avoid logging full request bodies or personal contact information. Monitor failed sign-ins, repeated ownership denials, approval conflicts, queue backlog, and database connectivity. Provide actionable alerts and an operator runbook rather than relying on browser console output.
ACCESSIBILITY & RESPONSIVE BEHAVIOR
Use semantic headings, landmarks, labels, native buttons, and keyboard-operable forms. Announce submission errors and saved results through appropriate live regions. Restore focus after a dialog closes; modal dialogs require an explicit closing control. Availability states must not rely on color alone. Format dates consistently and explain approval status in text. Respect reduced-motion preferences. Validate layouts at 360, 390, 768, and 1440 pixels; tables must have a contained horizontal scroll region rather than widening the whole page. Include sufficient contrast and visible focus indicators across light and dark interface states.
TEST PLAN & ACCEPTANCE MATRIX
Unit-test date overlap logic, status transitions, input schemas, and cancellation deadlines. Integration-test PostgreSQL constraints, transaction rollback, idempotency, ownership, inactive membership, and concurrent last-slot approvals. Browser-test Google session handling with signed isolated fixtures, booking review, pending status, administrator decisions, waitlist acceptance, and phone layouts. Add negative tests for IDOR, CSRF, malformed request bodies, oversized content, and missing credentials. Every test creates isolated records and removes only its own fixtures. A passing screenshot is not evidence that authorization or booking concurrency is correct.
DEPLOYMENT & ENVIRONMENT
Ship a multi-stage container build running as a non-root user. Keep databases private to the service network, expose the application through a configured HTTPS proxy, and use persistent database storage. Apply committed migrations before accepting traffic. Supply DATABASE_URL, AUTH_SECRET, Google client credentials, public origin, garden timezone, and notification provider settings through server-only configuration. Provide an environment template containing names and placeholders, never real credentials. Add readiness checks, restart policies, resource bounds, and a documented backup/restore process. Test restoration into a separate database before treating backups as recoverable.
RELEASE CHECKLIST & DEFINITION OF DONE
A member can sign in only with active membership, request an available plot, see the pending request, and receive its recorded decision. An administrator can approve within capacity and cannot approve an invalid or already finalized request. Two concurrent approvals cannot overbook the last slot. Another member cannot read or mutate the booking. Waitlist invitations expire and cannot be reused. Errors preserve recoverable client input without leaking internals. Migrations, tests, container startup, phone navigation, notification retries, and a backup restore have been verified. Document remaining assumptions and external setup; do not label placeholders or untested integrations as production-ready.