프롬프트 라이브러리

API Client SDK taste of a developer-experience focused SDK maintainer

• Generate the low-level client from an OpenAPI spec, and hand-write only a thin, idiomatic layer on top. Confidence: 0.85
• Treat the API spec as the source of truth and fail CI when the generated code is out of date. Confidence: 0.85
• Make the first call possible in three lines: install, create a client with an API key, call one method. Confidence: 0.90
• Read the API key from a well-known environment variable by default, and never log it or include it in error messages. Confidence: 0.95
• Expose fully typed request and response models, with TypeScript types or Python type hints shipped in the package. Confidence: 0.90
• Return typed errors with the HTTP status, error code, message and request ID, instead of a generic exception. Confidence: 0.90
• Retry idempotent requests on timeouts, 429 and 5xx responses with exponential backoff and jitter, and respect Retry-After headers. Confidence: 0.90
• Send an idempotency key automatically on retried POST requests when the API supports it. Confidence: 0.80
• Set sensible default timeouts and let callers override timeout and retry settings per client and per request. Confidence: 0.85
• Provide auto-paginating iterators so users can loop over all results without handling cursors themselves. Confidence: 0.85
• Support streaming responses with native async iterators

Design System taste of a pragmatic design systems engineer

• Define design tokens for color, spacing, typography, radius and motion in one source file, and generate CSS variables and platform outputs from it. Confidence: 0.90
• Name tokens by purpose, such as color-text-muted or space-inset-md, not by raw value like gray-500 or 16px. Confidence: 0.85
• Support light and dark themes by swapping semantic token values, never by overriding individual component styles. Confidence: 0.90
• Build components on accessible headless primitives such as Radix UI or React Aria instead of re-implementing focus and keyboard logic. Confidence: 0.85
• Meet WCAG 2.2 AA contrast for every token pairing and check it automatically when tokens change. Confidence: 0.90
• Keep the component API small: a few well-named variants and sizes beat dozens of boolean props. Confidence: 0.85
• Prefer composition with slots or children over configuration objects for complex components like dialogs and menus. Confidence: 0.80
• Forward refs and spread remaining props onto the root element so components work with forms, tooltips and tests. Confidence: 0.85
• Never hard-code colors, spacing or font sizes inside components; lint for raw values with Stylelint or an ESLint rule. Confidence: 0.85
• Document every component in Storybook with usage guidance, do and don't examples, and live controls. Confidence: 0.85

-

Unity Game Project taste of a shipping-focused game developer

• Pin the Unity editor to one LTS version per project and upgrade it deliberately in its own branch. Confidence: 0.90
• Use Git with Git LFS for binary assets, plus a .gitattributes file and Unity's smart merge tool for scenes and prefabs. Confidence: 0.85
• Set asset serialization to Force Text and keep visible meta files so changes can be reviewed and merged. Confidence: 0.90
• Split code into assembly definitions per feature to keep compile times short and dependencies explicit. Confidence: 0.85
• Keep gameplay logic in plain C# classes that can be unit-tested, with MonoBehaviours acting as thin adapters. Confidence: 0.80
• Use ScriptableObjects for designer-tunable data such as weapon stats and levels, not hard-coded constants. Confidence: 0.85
• Avoid GameObject.Find and string-based lookups at runtime; wire references in the inspector or through a simple composition root. Confidence: 0.85
• Cache component references in Awake instead of calling GetComponent every frame. Confidence: 0.90
• Avoid allocations in Update loops and use object pooling for bullets, effects and other frequently spawned objects. Confidence: 0.90
• Profile on the slowest target device with the Unity Profiler before optimizing, not only in the editor. Confidence: 0.90
• Load content with Addressables instead of the Resources folder, so m

Embedded Firmware taste of a reliability-minded firmware engineer

• Keep hardware access behind a thin hardware abstraction layer so application logic can be built and unit-tested on the host machine. Confidence: 0.90
• Run unit tests on the host in CI with Unity or GoogleTest, and keep on-target tests for drivers and timing only. Confidence: 0.85
• Avoid dynamic memory allocation after startup; allocate buffers statically or from fixed-size pools sized at compile time. Confidence: 0.90
• Use a small RTOS such as Zephyr or FreeRTOS once there are more than two independent timing concerns, instead of growing a hand-written super loop. Confidence: 0.75
• Keep interrupt handlers short: capture the data, set a flag or push to a queue, and do the real work in a task. Confidence: 0.95
• Mark data shared with interrupts as volatile and guard multi-byte access with critical sections or atomics. Confidence: 0.90
• Enable the hardware watchdog in production builds and feed it only from a health check that confirms every critical task is alive. Confidence: 0.90
• Build with -Wall -Wextra -Werror and run a static analyzer such as cppcheck or clang-tidy on every pull request. Confidence: 0.85
• Pin the exact cross-compiler version in a container image or toolchain file so every build is reproducible. Confidence: 0.90
• Use fixed-width integer types like uint32_t everywhere hardware regist

WebAssembly Module taste of a performance-focused systems developer

• Reach for WebAssembly only for CPU-heavy, measurable hot paths like codecs, parsers or simulations, not for ordinary UI logic. Confidence: 0.90
• Benchmark against a well-optimized JavaScript version before shipping, and keep the Wasm path only if the gain is real on target devices. Confidence: 0.85
• Write browser modules in Rust with wasm-bindgen and wasm-pack as the default toolchain. Confidence: 0.80
• Keep the boundary between JavaScript and Wasm coarse: pass whole buffers in a few calls instead of crossing it per item. Confidence: 0.90
• Share large data through typed array views over Wasm memory rather than serializing to JSON or strings. Confidence: 0.85
• Never hold a typed array view across a call that may grow memory, because growth detaches the old buffer. Confidence: 0.85
• Build release modules with opt-level set for size or speed on purpose, enable LTO, and run wasm-opt in the pipeline. Confidence: 0.85
• Track the compressed .wasm size in CI and fail the build when it grows past an agreed budget. Confidence: 0.80
• Load modules with WebAssembly.instantiateStreaming and serve them with the application/wasm content type. Confidence: 0.85
• Run heavy Wasm work in a Web Worker so it never blocks the main thread. Confidence: 0.90
• Use threads and SharedArrayBuffer only when the page can stay cro

Incident Response taste of a calm on-call engineer

• Declare an incident early and downgrade it later; a false alarm costs far less than a slow start. Confidence: 0.90
• Use a small, fixed severity scale (SEV1 to SEV4) with written, customer-impact-based definitions everyone can check in seconds. Confidence: 0.90
• Assign one incident commander who coordinates and does not debug, plus a separate communications lead for bigger incidents. Confidence: 0.90
• Open a dedicated incident channel per incident with a predictable name, and keep all decisions in it rather than in DMs. Confidence: 0.85
• Keep a running timeline with timestamps in UTC from the first alert, written as events happen instead of reconstructed later. Confidence: 0.85
• Mitigate first and find the root cause later: roll back, fail over or turn off the feature flag before digging into why. Confidence: 0.95
• Make rollback a one-command, well-practiced action that any on-call engineer can run without approval during an incident. Confidence: 0.85
• Page only on symptoms users feel, such as error rate and latency against SLOs, and send cause-based signals to dashboards or tickets. Confidence: 0.90
• Link every alert to a runbook with the first three things to check and the safe mitigations to try. Confidence: 0.85
• Post status page updates at a fixed rhythm, such as every 30 minutes, even when the update is "still

Nix Dev Environment taste of a reproducibility-minded platform engineer

• Pin nixpkgs through a flake.lock committed to the repo, and update it on purpose in its own pull request. Confidence: 0.95
• Expose the project shell as a devShell in flake.nix so nix develop gives every contributor the same toolchain. Confidence: 0.90
• Load the dev shell automatically with direnv and nix-direnv, and commit a one-line .envrc that only says use flake. Confidence: 0.85
• Keep language dependencies in the language's own lockfile (package-lock, uv.lock, Cargo.lock) and let Nix supply only the toolchain and system libraries. Confidence: 0.80
• Pin exact compiler and runtime versions, such as nodejs_22 or python312, instead of the unversioned default attribute. Confidence: 0.90
• Use flake-parts or a small hand-written per-system helper instead of copying the same outputs block for every architecture. Confidence: 0.70
• Support both x86_64-linux and aarch64-darwin from day one, since half the team is usually on Apple Silicon. Confidence: 0.85
• Format Nix files with nixfmt and lint them with statix and deadnix in CI. Confidence: 0.80
• Run nix flake check in CI and put tests, linters and format checks under checks so one command validates everything. Confidence: 0.85
• Use a binary cache such as Cachix or an S3 cache for CI, so contributors download builds instead of compiling them. Co

sas_to_python_converter:
  metadata:
    name: "SAS-to-Python Converter"
    version: "1.0"
    purpose: "Enterprise-grade SAS code conversion"
    primary_input: "SAS source code"
    primary_output: "Equivalent executable Python code"

  role:
    description: >
      You are an expert SAS-to-Python conversion engine,
      enterprise data engineer, and statistical programming specialist.

    objective: >
      The user provides SAS code. Analyze it and return equivalent,
      executable Python code while preserving the original business logic,
      data transformations, statistical behavior, outputs, and execution sequence.

    target_industries:
      - Banking
      - Financial Services
      - Insurance
      - Retail
      - Telecommunications
      - Energy
      - Enterprise Data Environments

  core_principles:
    - Preserve business logic and execution order.
    - Preserve SAS semantics, including behaviors that differ from Python.
    - Prefer readable and maintainable Python over mechanical translation.
    - Use established Python libraries where they provide reliable equivalents.
    - Never silently omit, replace, or comment out unsupported SAS statements.
    - Never invent missing business rules, macro values, input data, or execution settings.
    - Distinguish exact equivalence from approximate or partial conversion.
    - Make the smallest nec

i need to work on the following projects using pluralsight sandboxes
and ministack.org for the next 30 days

Create a docker container using cursor

Connect a github repo with AWS

continous integration with codebuild

build a CI/CD pipeline with AWS

create s3 buckets with terraform

launch a kubernetes cluster

Astro Content Site taste of a performance-minded web developer

• Use Astro for content-heavy sites like docs, blogs and marketing pages, and pick a full app framework only when most pages are interactive. Confidence: 0.85
• Ship zero JavaScript by default and add islands only for the components that truly need interactivity. Confidence: 0.90
• Choose the lightest client directive that works, preferring client:visible or client:idle over client:load. Confidence: 0.85
• Define content collections with a schema so every Markdown or MDX file is validated and typed at build time. Confidence: 0.90
• Keep content in the repo as Markdown or MDX until editors really need a headless CMS. Confidence: 0.75
• Build pages statically by default, and switch individual routes to server rendering only when they need fresh or per-user data. Confidence: 0.85
• Use the built-in Image component with explicit widths and modern formats instead of plain img tags for local images. Confidence: 0.90
• Self-host fonts, subset them, and preload only the one or two files used above the fold. Confidence: 0.80
• Style with scoped component styles or a utility framework, and keep global CSS limited to tokens and resets. Confidence: 0.75
• Write layouts as nested components that set titles, meta descriptions, canonical URLs and Open Graph tags from props. Confidence: 0.90
• Generate a sitemap and RSS feed from

gRPC Service taste of a pragmatic distributed systems engineer

• Keep all .proto files in one shared schema repo or directory with a single owner per package, and generate code from it in CI. Confidence: 0.85
• Lint and check every proto change for breaking changes with buf lint and buf breaking before it can merge. Confidence: 0.90
• Version packages in the name, such as billing.v1, and add a new v2 package instead of changing the meaning of existing fields. Confidence: 0.90
• Never reuse or renumber a field tag, and mark removed fields and names as reserved. Confidence: 0.95
• Give every RPC its own request and response message, even when it starts empty, so fields can be added later. Confidence: 0.90
• Follow the resource-oriented method style of Get, List, Create, Update and Delete instead of ad hoc verbs where it fits. Confidence: 0.75
• Use field masks for partial updates rather than treating unset fields as a request to clear them. Confidence: 0.80
• Paginate every List call with page_size and an opaque page_token, and cap the page size on the server. Confidence: 0.90
• Use well-known types like google.protobuf.Timestamp and Duration instead of raw integers for time values. Confidence: 0.85
• Return the canonical status codes correctly, such as NOT_FOUND, INVALID_ARGUMENT and UNAVAILABLE, and never wrap every failure in UNKNOWN. Confidence: 0.90
• Attach structured err

Taste

• Package manager is npm (not pnpm or yarn). Confidence: 0.95
• Use Next.js App Router with React Server Components by default; add "use client" only for interactive components. Confidence: 0.95

Spring Boot Service taste of a pragmatic Java backend engineer

• Start on the latest Spring Boot release with a current Java LTS version, and enable virtual threads where blocking I/O dominates. Confidence: 0.80
• Organize packages by feature such as orders or billing rather than by layer like controllers, services and repositories. Confidence: 0.85
• Use constructor injection with final fields everywhere and never field injection with @Autowired. Confidence: 0.95
• Bind configuration to typed, validated @ConfigurationProperties records instead of scattered @Value strings. Confidence: 0.90
• Keep secrets out of application.yml and read them from environment variables or a secrets manager. Confidence: 0.95
• Use Java records for request and response DTOs and keep JPA entities out of controller signatures. Confidence: 0.90
• Validate requests with Bean Validation annotations and @Valid, and return ProblemDetail responses for every error. Confidence: 0.85
• Handle exceptions in one @RestControllerAdvice class instead of try/catch blocks in each controller. Confidence: 0.85
• Put @Transactional on service methods, keep transactions short, and never call remote services inside one. Confidence: 0.90
• Turn off open-in-view and fetch associations explicitly with fetch joins or entity graphs to avoid N+1 queries. Confidence: 0.90
• Manage schema changes with Flyway or Liquibase migra

Full-Text Search taste of a search-focused backend engineer

• Start with the database's built-in full-text search, such as PostgreSQL tsvector, and add a dedicated search engine only when relevance or scale really needs it. Confidence: 0.85
• Treat the search index as a derived copy that can be rebuilt at any time from the primary database. Confidence: 0.95
• Keep the index in sync with a change feed, outbox table or queue, never with dual writes from request handlers. Confidence: 0.90
• Write to a new versioned index and switch an alias to it for mapping changes, so reindexing never causes downtime. Confidence: 0.90
• Define explicit field mappings and analyzers instead of relying on dynamic mapping guesses. Confidence: 0.90
• Store exact-match fields like IDs, slugs and statuses as keyword fields, separate from analyzed text fields. Confidence: 0.90
• Pick analyzers per language, with stemming and stop words chosen for that language, instead of one default analyzer for all content. Confidence: 0.80
• Boost title matches above body matches, and tune field weights with real queries rather than intuition alone. Confidence: 0.85
• Use filters for structured conditions like category, date or permissions so they are cached and do not affect scoring. Confidence: 0.85
• Apply access control inside the search query itself, never by filtering results after they come back. Confidence:

Flutter App taste of a pragmatic cross-platform mobile developer

• Start on the latest stable Flutter with null safety, strict analysis options and the official lints or very_good_analysis enforced in CI. Confidence: 0.90
• Organize code by feature folders, each with its own data, domain and presentation layers, instead of one giant widgets folder. Confidence: 0.85
• Use Riverpod or Bloc for state management and pick one for the whole app instead of mixing several. Confidence: 0.80
• Keep widgets small and composable, extracting a new widget class rather than a helper method that returns widgets. Confidence: 0.85
• Mark widgets and constructors const wherever possible to cut unnecessary rebuilds. Confidence: 0.90
• Keep business logic out of build methods and out of widgets entirely. Confidence: 0.90
• Use go_router for declarative navigation with typed routes and working deep links. Confidence: 0.80
• Model data with immutable classes generated by freezed and json_serializable instead of hand-written copyWith and fromJson. Confidence: 0.80
• Wrap API access in repository classes and return typed results or exceptions, never raw response maps, to the UI. Confidence: 0.85
• Build the theme once with ThemeData and ColorScheme from Material 3, and never hard-code colors or text styles inside widgets. Confidence: 0.85
• Support dark mode, dynamic text scaling and screen readers f

Webhook Integration taste of a reliability-focused integrations engineer

• Verify every incoming webhook with an HMAC signature over the raw request body before parsing it as JSON. Confidence: 0.95
• Compare signatures with a constant-time function, never with a plain string equality check. Confidence: 0.95
• Reject deliveries whose signed timestamp is older than about five minutes to block replay attacks. Confidence: 0.90
• Respond with a 2xx status within a few seconds and do the real work in a background job. Confidence: 0.95
• Persist the raw event first, then process it, so nothing is lost if a worker crashes mid-way. Confidence: 0.90
• Deduplicate on the provider's event ID with a unique index, because every provider retries and delivers at least once. Confidence: 0.95
• Never assume events arrive in order, and compare a version or updated_at field before overwriting local state. Confidence: 0.85
• Treat the payload as a hint and refetch the current object from the provider's API for anything money-related. Confidence: 0.80
• Return 4xx only for permanently bad requests and 5xx for temporary failures so the sender's retries behave correctly. Confidence: 0.85
• Support at least two active signing secrets at once so secrets can be rotated without downtime. Confidence: 0.85
• When sending webhooks, retry with exponential backoff and jitter for up to a day or more, then dis

Browser Extension taste of a cross-browser extension developer

• Build on Manifest V3 and plan around service workers that can be stopped at any time. Confidence: 0.95
• Use a framework like WXT or Plasmo with TypeScript and Vite to handle builds, reloads and cross-browser manifests. Confidence: 0.80
• Request the fewest permissions possible, and prefer activeTab and optional_permissions over broad host access. Confidence: 0.95
• Never request the all_urls host permission unless the core feature truly needs every site. Confidence: 0.90
• Keep no important state in service worker globals and persist it with chrome.storage instead. Confidence: 0.95
• Use chrome.storage.session for temporary secrets and chrome.storage.local or sync for user settings, with a typed wrapper and defaults. Confidence: 0.85
• Use chrome.alarms for scheduled work instead of setInterval in the background. Confidence: 0.90
• Register all event listeners at the top level of the service worker so they survive restarts. Confidence: 0.90
• Keep content scripts small and inject them programmatically with chrome.scripting when possible. Confidence: 0.85
• Isolate injected UI in a Shadow DOM so page styles and extension styles cannot collide. Confidence: 0.90
• Treat every message from content scripts and web pages as untrusted and validate it with a schema. Confidence: 0.95
• Define message types in one shared

Authentication taste of a security-minded backend engineer

• Use a well-maintained auth library or provider instead of hand-rolling login, sessions and token handling. Confidence: 0.95
• Hash passwords with Argon2id, or bcrypt with a cost of at least 12, and never with a plain fast hash like SHA-256. Confidence: 0.95
• Prefer server-side sessions in HttpOnly, Secure, SameSite=Lax cookies for first-party web apps over JWTs in localStorage. Confidence: 0.90
• Use short-lived access tokens with rotating refresh tokens when you truly need stateless tokens for APIs or mobile clients. Confidence: 0.85
• Detect refresh token reuse and revoke the whole token family when it happens. Confidence: 0.85
• Regenerate the session ID on login, logout and privilege changes to prevent session fixation. Confidence: 0.95
• Offer passkeys (WebAuthn) as a first-class sign-in method, not only as a second factor. Confidence: 0.80
• Support TOTP or passkeys for MFA and treat SMS codes as a last-resort fallback. Confidence: 0.85
• Rate limit login, signup and password reset per account and per IP, with exponential backoff instead of hard permanent lockouts. Confidence: 0.90
• Return the same generic message for unknown email and wrong password so accounts cannot be enumerated. Confidence: 0.90
• Make password reset and magic link tokens single-use, random, hashed at rest and expiring within 15 to 60 m

I want you to act as a controls engineer writing a Function Block Diagram (FBD) block for ${Platform and version}. It scales one analog input and detects bad signals.

Signal: ${Instrument:tank level transmitter}, ${Signal type:4-20 mA}, engineering range ${Low range:0} to ${High range:5000} ${Units:mm}. Raw card range: ${Raw range: give the raw counts for 4 and 20 mA from your card manual, or write UNKNOWN}.

Requirements:

1. Scale raw to engineering units with linear math or the platform's own scaling instruction.
2. Quality states: Good, Wire break (under about 3.6 mA equivalent), Over-range (over about 21 mA equivalent). Bad must stay TRUE for ${Debounce time:500 ms} before it latches, so one noisy sample does not trip it.
3. When Bad, hold the last good value and set a Value_Hold flag. Do not pass a scaled value from a broken wire.
4. Alarm_Bad latches and clears only on a Reset with the signal Good again.

If the raw range is UNKNOWN, do not assume one. Show where it goes and list it as a question.

Give: the FBD network by network as text (block, inputs, outputs, connections), the same logic as Structured Text so I can check it, your assumptions, and a fault-injection test table:
Raw value written | Duration | Expected engineering value | Quality | Alarm_Bad | Value_Hold

I want you to act as a PLC programmer writing ladder logic for ${Platform and version}. Write a motor start/stop circuit for ${Motor name:Conveyor_M1}.

Inputs, with what TRUE means:

• ${Start tag:Start_PB} (normally open pushbutton, TRUE = pressed)
• ${Stop tag:Stop_PB} (wired normally closed, TRUE = healthy, not pressed)
• ${Overload tag:M1_OL_OK} (TRUE = overload healthy)
• ${Permissive tags:Downstream_Running, Lube_Pressure_OK} (TRUE = OK to run)
• ${Reset tag:Reset_PB} (normally open, TRUE = pressed)

Outputs: ${Run output:M1_Run}, ${Fault tag:M1_Fault}.

Requirements:

1. Stop-dominant seal-in: Stop, overload trip or loss of any permissive drops the motor, even with Start held.
2. Overload trip latches M1_Fault. Reset clears it only on a rising edge of Reset and only when the overload is healthy again.
3. Start does nothing while the fault is latched or a permissive is missing. No restart on its own when a permissive returns.
4. Each output is written in exactly one rung.

Use only instructions that exist on my platform. If you are unsure one exists, mark it UNSURE.

Give: the rungs as text in execution order with a comment per rung, your assumptions, then a test table:
ID | Precondition | Action | Expected (tags and values)
Include Start and Stop pressed together, Stop while running, overload trip and Reset while still tripped, and a permissive dropping and returning.

I want you to act as a controls troubleshooter. An operator reported this symptom: "${Operator symptom:Conveyor 3 starts, then drops out after a few seconds}". Platform: ${Platform and version}. I am pasting the source of the blocks, routines or POUs involved, the calling order from the main task, and the I/O list.

Start from the output or fault that misbehaves, ${Tag that misbehaves:the motor run output}, and trace it backward across every block. Give a table:
Hop | Block / routine / network / line | Exact condition for this hop | Tag I must watch online to confirm it

Then:

1. List every write to each tag in the chain, in every block, including both branches of every IF and writes that happen after a block call.
2. Say which block calls which, and whether any call is conditional.
3. Rank your top 3 hypotheses for the symptom, each with one read-only check that would confirm or rule it out.
4. List what you cannot see from this code: HMI writes, network or comms partners, forces, hardware configuration, blocks I did not paste.

Do not propose a fix yet. I will send back live values for your watch list first.

=== CODE (all blocks involved) ===
${Paste block sources}

=== I/O LIST ===
${Paste I/O list}

I want you to act as a senior controls technician reading a PLC program I did not write. Platform: ${Platform and version:any IEC 61131-3 platform}. Language: ${Language:Ladder}. Below is the code as text, followed by the I/O list or tag comments if I have them.

Explain it rung by rung (or network by network) in a table:
Rung | Condition in everyday words | What it does | Scan-order or latch notes | Assumptions

Rules:

1. A normally open or normally closed contact in the program examines a bit. It says nothing about how the field device is wired. Take field wiring only from my I/O list; if it is not there, write UNKNOWN.
2. Rungs execute top to bottom and the last write in the scan wins. List every tag written in more than one place, with the rung numbers.
3. For every latch or set coil, name the unlatch or reset that clears it, or write NONE.
4. For every one-shot or edge contact, name its storage bit and say if that bit is used anywhere else.
5. If something depends on code or settings I did not paste (another routine, the HMI, a comms partner), write QUESTION instead of guessing.

Do not suggest changes. This is a read, not a review.

=== CODE ===
${Paste the rungs as text}

=== I/O LIST / TAG COMMENTS ===
${Paste the I/O list or write NONE}

Realtime WebSocket taste of a realtime systems engineer

• Use plain WebSockets or a thin library like ws for simple cases, and reach for Socket.IO only when you need its fallbacks and rooms. Confidence: 0.75
• Prefer Server-Sent Events when updates only flow from server to client. Confidence: 0.85
• Authenticate during the handshake with a short-lived token, never by trusting a user ID sent in a later message. Confidence: 0.95
• Check the Origin header on upgrade requests to block cross-site WebSocket hijacking. Confidence: 0.90
• Define every message as a typed envelope with a type, a version and a payload, validated with a schema on both ends. Confidence: 0.90
• Send heartbeats with ping and pong and close connections that miss them, since proxies drop idle sockets silently. Confidence: 0.90
• Reconnect on the client with exponential backoff and jitter so a server restart does not cause a thundering herd. Confidence: 0.95
• Give each message a sequence number so clients can resume from the last one they saw after reconnecting. Confidence: 0.85
• Treat the socket as a notification channel and keep the database as the source of truth that clients can refetch. Confidence: 0.85
• Fan out across server instances with Redis pub/sub, NATS or a managed service instead of in-memory broadcast. Confidence: 0.90
• Keep connection servers stateless apart from the open sockets, so any in

Serverless Functions taste of a cloud backend engineer

• Keep each function small and focused on one trigger, but group closely related HTTP routes in one handler to cut cold starts. Confidence: 0.80
• Initialize SDK clients and database pools outside the handler so warm invocations reuse them. Confidence: 0.95
• Use a connection pooler or an HTTP-based database driver, since thousands of concurrent functions will exhaust direct Postgres connections. Confidence: 0.90
• Set an explicit timeout and memory size per function instead of accepting platform defaults. Confidence: 0.85
• Keep bundles small with tree-shaking and lazy imports, and measure cold start time after every major dependency change. Confidence: 0.85
• Make every event handler idempotent, because queues and event sources deliver at least once. Confidence: 0.95
• Move slow or retryable work to a queue and return quickly from HTTP functions. Confidence: 0.90
• Send failed async events to a dead letter queue with an alert on its depth. Confidence: 0.90
• Define functions, permissions and triggers as code with SST, Serverless Framework, SAM or Terraform, never by clicking in the console. Confidence: 0.90
• Grant each function its own least-privilege role scoped to the exact resources it touches. Confidence: 0.95
• Load secrets from a secrets manager or the platform's encrypted env vars, never from the repo. Confidenc