Coding Prompts

# 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 minutes. Confidence: 0.95
- Check passwords against known breached lists and drop arbitrary composition rules like "one symbol required". Confidence: 0.85
- Use OAuth 2.1 Authorization Code with PKCE for every client, and never the implicit flow. Confidence: 0.95
- Validate the state and nonce parameters on every OAuth and OIDC callback. Confidence: 0.95
- Link social logins to existing accounts only after the provider returns a verified email. Confidence: 0.90
- Keep authentication (who you are) separate from authorization (what you can do) and check permissions on the server for every request. Confidence: 0.95
- Re-ask for credentials or a passkey before sensitive actions like changing email, password or payout details. Confidence: 0.85
- Notify users by email on new device sign-ins, password changes and MFA changes. Confidence: 0.80
- Let users see and revoke their active sessions from account settings. Confidence: 0.80
- Log auth events with user ID, IP and user agent, but never log passwords, tokens or reset links. Confidence: 0.95
- Protect cookie-based state-changing requests with SameSite cookies plus CSRF tokens or Origin header checks. Confidence: 0.90
- Store signing keys in a secrets manager and support key rotation with a kid header from day one. Confidence: 0.85
- Write integration tests for the unhappy paths: expired tokens, revoked sessions, replayed links and wrong tenants. Confidence: 0.85

# Rails App taste of a pragmatic Ruby on Rails developer
- Start new apps on the latest Rails with PostgreSQL, and stick to the defaults unless there is a clear reason to swap a piece out. Confidence: 0.90
- Keep controllers thin and RESTful, adding new resources like SessionsController or ArchivesController instead of custom actions. Confidence: 0.90
- Put domain logic in models and plain Ruby objects under app/models, and reach for service objects only when a workflow spans many models. Confidence: 0.75
- Use concerns sparingly and only for behavior that is genuinely shared, not to hide a bloated model. Confidence: 0.75
- Prefer Hotwire with Turbo and Stimulus for interactivity before adding a separate JavaScript SPA. Confidence: 0.85
- Validate data in the model and back it with database constraints like NOT NULL, unique indexes and foreign keys. Confidence: 0.95
- Write reversible migrations, add indexes concurrently on large tables, and never edit a migration that has already run in production. Confidence: 0.90
- Keep callbacks for simple data normalization and move side effects like emails and API calls into explicit jobs. Confidence: 0.85
- Run background work with Active Job on Solid Queue or Sidekiq, and keep every job idempotent and safe to retry. Confidence: 0.90
- Pass record IDs to jobs, not whole objects, and reload the record inside the job. Confidence: 0.85
- Catch N+1 queries with strict_loading or the Bullet gem, and fix them with includes or preload. Confidence: 0.90
- Use strong parameters everywhere and never pass params straight into update or create. Confidence: 0.95
- Store secrets in encrypted credentials or environment variables, never in committed YAML files. Confidence: 0.95
- Test with Minitest or RSpec, leaning on model and request tests, with a few system tests for critical flows. Confidence: 0.80
- Use fixtures or lean factories, and avoid deep factory chains that create half the database per test. Confidence: 0.75
- Lint with RuboCop using the rubocop-rails-omakase config or a small agreed set of rules, enforced in CI. Confidence: 0.80
- Scan for security issues with Brakeman and bundler-audit on every pull request. Confidence: 0.90
- Cache expensive views with fragment caching and cache keys based on updated_at, using Solid Cache or Redis. Confidence: 0.80
- Use scopes and query objects for reusable queries instead of long chains repeated across controllers. Confidence: 0.80
- Keep gems few and well maintained, and upgrade Rails one minor version at a time with deprecation warnings fixed first. Confidence: 0.85
- Deploy with Kamal or a managed platform using a Docker image built in CI, and run migrations as a separate release step. Confidence: 0.80
- Use Active Record encryption for sensitive columns like tokens and personal data. Confidence: 0.80

# 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 module and use typed request and response helpers for runtime messaging. Confidence: 0.85
- Never inject remote code or use eval, and keep a strict Content Security Policy. Confidence: 0.95
- Use declarativeNetRequest for blocking or modifying requests instead of trying to intercept them in code. Confidence: 0.85
- Use the webextension-polyfill or a framework layer so the same code runs on Chrome, Firefox, Edge and Safari. Confidence: 0.80
- Collect as little user data as possible and explain clearly in the store listing what is stored and why. Confidence: 0.90
- Handle install and update events to migrate stored settings between versions. Confidence: 0.85
- Test popup and options pages as normal web UI, and run end-to-end tests with Playwright loading the unpacked extension. Confidence: 0.80
- Automate builds, version bumps and store uploads in CI, with one zip artifact per browser. Confidence: 0.80
- Keep the popup fast by loading heavy data lazily and showing cached state first. Confidence: 0.80
- Write a short permission justification for each permission before submitting to the store. Confidence: 0.85

# 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 disable the endpoint and notify its owner. Confidence: 0.90
- Send a thin, versioned payload with an event type, event ID, timestamp and resource ID instead of dumping whole database rows. Confidence: 0.80
- Name event types as resource.action in the past tense, like invoice.paid or user.deleted. Confidence: 0.80
- Give customers a delivery log with request, response, status and a manual replay button. Confidence: 0.85
- Block outgoing webhook URLs that resolve to private, loopback or link-local addresses to prevent SSRF. Confidence: 0.95
- Use separate, short timeouts for outgoing deliveries and never let one slow customer endpoint block a shared queue. Confidence: 0.90
- Require HTTPS for all webhook endpoints outside local development. Confidence: 0.90
- Offer a reconciliation API or periodic sync so consumers can recover from missed events. Confidence: 0.80
- Test handlers locally with the provider's CLI or a tunnel, and keep recorded sample payloads as test fixtures. Confidence: 0.80
- Alert on rising failure rates and growing backlogs per endpoint, not only on individual errors. Confidence: 0.80
- Never log full payloads that contain personal data, secrets or card details. Confidence: 0.90

# 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 from the first release. Confidence: 0.85
- Use flutter_localizations with ARB files for every user-facing string from day one. Confidence: 0.80
- Run heavy parsing or image work in an isolate with compute or Isolate.run so the UI thread stays smooth. Confidence: 0.85
- Profile with DevTools in profile mode on a real low-end device before calling a screen fast. Confidence: 0.85
- Use ListView.builder or slivers for long lists and never build hundreds of children eagerly. Confidence: 0.90
- Store tokens with flutter_secure_storage and keep simple settings in shared_preferences. Confidence: 0.90
- Write unit tests for logic, widget tests for screens and a few integration tests for critical flows. Confidence: 0.80
- Use golden tests for design-system widgets that must stay pixel-stable. Confidence: 0.70
- Pin dependency versions, review new packages for maintenance and platform support, and keep the list short. Confidence: 0.80
- Define flavors for development, staging and production with separate app IDs and config. Confidence: 0.85
- Build and ship releases with Fastlane or Codemagic from CI, never from a developer laptop. Confidence: 0.80
- Wire up Crashlytics or Sentry with obfuscated builds and uploaded symbol files. Confidence: 0.80

# Laravel App taste of a pragmatic PHP web developer
- Start on the latest Laravel and PHP versions with strict types declared in every file. Confidence: 0.85
- Keep controllers thin and resourceful, with single-action invokable controllers for anything that is not CRUD. Confidence: 0.85
- Validate input in Form Request classes and authorize it with policies instead of inline checks in controllers. Confidence: 0.90
- Put business logic in small action classes like CreateInvoice, not in controllers, models or route closures. Confidence: 0.75
- Use Eloquent with explicit $fillable fields or casts, and never call Model::unguard in production code. Confidence: 0.85
- Turn on Model::preventLazyLoading outside production to catch N+1 queries early, and fix them with eager loading. Confidence: 0.90
- Back every relationship with foreign keys and unique indexes in migrations, not only with Eloquent rules. Confidence: 0.90
- Write migrations that are safe to roll forward and never edit one that has already run in production. Confidence: 0.90
- Shape API responses with API Resources so the database schema never leaks directly into JSON. Confidence: 0.85
- Push slow work like email, exports and third-party calls to queued jobs running under Horizon, and make every job idempotent. Confidence: 0.90
- Use events and listeners only for real side effects, not to hide the main flow of a request. Confidence: 0.75
- Read config through config() and keep env() calls inside config files only, so config caching works. Confidence: 0.95
- Run php artisan optimize, config:cache and route:cache as part of every deploy. Confidence: 0.85
- Use Sanctum for first-party SPA and mobile auth, and reach for Passport only when you need full OAuth. Confidence: 0.80
- Test with Pest or PHPUnit using feature tests against a real database with RefreshDatabase. Confidence: 0.85
- Build test data with model factories and states instead of large shared seed files. Confidence: 0.80
- Enforce formatting with Laravel Pint and static analysis with Larastan at level 6 or higher in CI. Confidence: 0.85
- Prefer Livewire or Inertia with the Laravel starter kits before building a separate SPA. Confidence: 0.75
- Rate limit login and public API routes with named rate limiters. Confidence: 0.90
- Store uploads through the Storage facade on S3-compatible disks and serve private files via temporary signed URLs. Confidence: 0.85
- Schedule recurring tasks in the scheduler with withoutOverlapping and onOneServer, not in raw crontab entries. Confidence: 0.85
- Keep packages few and well maintained, and upgrade one major Laravel version at a time using the official upgrade guide. Confidence: 0.80

# .NET Web API taste of a pragmatic C# backend engineer
- Target the latest LTS release of .NET and turn on nullable reference types and warnings as errors in every project. Confidence: 0.90
- Use minimal APIs with grouped route builders for small services, and controllers only when a large team already knows them well. Confidence: 0.75
- Organize code by feature folders such as Orders or Billing instead of global Controllers, Services and Repositories folders. Confidence: 0.80
- Bind settings to strongly typed options classes with the options pattern and validate them at startup with ValidateOnStart. Confidence: 0.90
- Keep secrets out of appsettings.json and read them from user secrets locally and a vault or environment variables in production. Confidence: 0.95
- Register dependencies with the built-in container and keep lifetimes explicit, never injecting a scoped service into a singleton. Confidence: 0.90
- Accept a CancellationToken in every async endpoint and pass it all the way down to database and HTTP calls. Confidence: 0.90
- Never block on async code with .Result or .Wait(), and use async all the way through the call stack. Confidence: 0.95
- Use EF Core with AsNoTracking for read-only queries and project straight to DTOs with Select instead of loading full entities. Confidence: 0.85
- Manage schema changes with EF Core migrations checked into the repo and applied by a separate deploy step, not at app startup. Confidence: 0.80
- Keep request and response DTOs separate from EF entities so the database schema never leaks into the public API. Confidence: 0.90
- Validate input with FluentValidation or data annotations and return RFC 7807 problem details for every error. Confidence: 0.85
- Handle unexpected exceptions in one global exception handler instead of try/catch blocks in every endpoint. Confidence: 0.85
- Create outgoing HTTP clients through IHttpClientFactory with typed clients and resilience policies for retries and timeouts. Confidence: 0.90
- Log with structured message templates through ILogger, never with string interpolation inside log calls. Confidence: 0.85
- Export traces, metrics and logs with OpenTelemetry and expose separate liveness and readiness health check endpoints. Confidence: 0.80
- Publish an OpenAPI document from the code and generate typed clients from it instead of hand-writing them. Confidence: 0.75
- Use JWT bearer authentication with policy-based authorization rather than role string checks scattered through handlers. Confidence: 0.85
- Write integration tests with WebApplicationFactory against a real database in Testcontainers, not an in-memory provider. Confidence: 0.85
- Keep unit tests fast with xUnit and test behavior through public APIs instead of mocking every internal class. Confidence: 0.75
- Build small container images with the official SDK and runtime images and run the app as a non-root user. Confidence: 0.85
- Pin package versions centrally with Directory.Packages.props so every project in the solution uses the same versions. Confidence: 0.80

# 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: 0.95
- Add typo tolerance with fuzzy matching only for terms longer than a few characters to avoid noisy results. Confidence: 0.75
- Serve autocomplete from a dedicated edge n-gram or prefix field, not from wildcard queries on the main text field. Confidence: 0.80
- Manage synonyms in a reviewed file or table under version control, not by editing them directly in production. Confidence: 0.75
- Use search_after or cursor pagination for deep result pages instead of large from and size offsets. Confidence: 0.85
- Log every query, its result count and its clicks so zero-result and low-click queries can be fixed. Confidence: 0.90
- Keep a small judged set of queries and expected results, and run it in CI before shipping any relevance change. Confidence: 0.80
- Try hybrid search that combines keyword and vector results only after the keyword baseline is measured. Confidence: 0.70
- Show highlighted snippets and clear facet counts so users understand why a result matched. Confidence: 0.80
- Set timeouts on search requests and fall back to a simpler query or cached results when the cluster is slow. Confidence: 0.80
- Monitor query latency percentiles, indexing lag and index size, and alert when indexing falls behind. Confidence: 0.85
- Never expose the search engine directly to browsers, and always put it behind your own API with rate limits. 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 migrations and keep Hibernate ddl-auto set to validate or none. Confidence: 0.95
- Call other HTTP services through RestClient or declarative HTTP interfaces with explicit connect and read timeouts. Confidence: 0.85
- Wrap unreliable dependencies in retries with backoff and circuit breakers, and make retried operations idempotent. Confidence: 0.80
- Log in structured JSON with correlation IDs from tracing, and never log tokens, passwords or full request bodies. Confidence: 0.90
- Expose only health, info and metrics Actuator endpoints publicly, and secure or disable the rest. Confidence: 0.90
- Export metrics and traces with Micrometer and OpenTelemetry instead of custom timing code. Confidence: 0.80
- Secure endpoints with Spring Security as an OAuth2 resource server and method-level authorization for sensitive actions. Confidence: 0.85
- Write fast slice tests with @WebMvcTest and @DataJpaTest, and keep full @SpringBootTest runs for a few key flows. Confidence: 0.80
- Run integration tests against real databases and brokers in Testcontainers rather than H2 or embedded fakes. Confidence: 0.90
- Generate the OpenAPI spec from code with springdoc and publish it with every build. Confidence: 0.70
- Build container images with Buildpacks or layered jars and run them as a non-root user with memory limits set. Confidence: 0.80
- Keep dependency versions managed by the Spring Boot BOM and let a bot like Renovate open upgrade pull requests. Confidence: 0.80

# 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 error details with the richer error model for validation failures instead of packing them into the message string. Confidence: 0.75
- Require a deadline on every client call and propagate the remaining deadline to downstream calls. Confidence: 0.95
- Retry only idempotent methods, with backoff and a retry budget configured in the service config, not in hand-written loops. Confidence: 0.85
- Pass request IDs, auth tokens and tracing context in metadata, and keep business data in the message body. Confidence: 0.85
- Put logging, auth, metrics and tracing in interceptors instead of repeating them inside each handler. Confidence: 0.90
- Use mutual TLS between internal services and verify per-call credentials on the server for anything sensitive. Confidence: 0.85
- Implement the standard gRPC health checking service and enable server reflection only outside production. Confidence: 0.80
- Prefer unary calls, and use streaming only when the data is truly incremental or long-lived. Confidence: 0.80
- Apply flow control and backpressure on streams, and send keepalive pings within limits the load balancer allows. Confidence: 0.70
- Balance load per request with an L7 proxy or client-side balancing, because HTTP/2 connections pin traffic to one backend. Confidence: 0.85
- Expose a REST or JSON gateway generated from the same protos for browsers and partners instead of maintaining a second API by hand. Confidence: 0.70
- Test handlers with an in-process server and real generated clients rather than mocking the generated stubs. Confidence: 0.80
- Document each service, method and field with comments in the proto file, since that is where readers look first. Confidence: 0.85

# Phoenix App taste of a pragmatic Elixir engineer
- Start new projects on the latest stable Elixir and Phoenix releases, and pin Erlang/OTP and Elixir versions in .tool-versions. Confidence: 0.85
- Group business logic into Phoenix contexts with small public APIs, and never call Repo directly from controllers or LiveViews. Confidence: 0.90
- Keep contexts from reaching into each other's schemas, and talk across boundaries through public context functions. Confidence: 0.80
- Use LiveView for interactive pages by default and add JavaScript hooks only for things the browser must do itself. Confidence: 0.80
- Build UI from function components with declared attrs and slots instead of large shared templates. Confidence: 0.85
- Validate all input with Ecto changesets and keep separate changesets for different actions like registration and profile updates. Confidence: 0.90
- Lean on database constraints with unique_constraint and foreign_key_constraint instead of check-then-insert code. Confidence: 0.95
- Preload associations explicitly in context functions, and never let a template trigger an N+1 query. Confidence: 0.85
- Use Ecto.Multi or Repo.transaction for multi-step writes so partial failures roll back cleanly. Confidence: 0.85
- Write reversible migrations, and split long-running data backfills into separate tasks rather than schema migrations. Confidence: 0.85
- Read runtime settings and secrets in config/runtime.exs from environment variables, never in compile-time config. Confidence: 0.95
- Run background work with Oban backed by Postgres, with unique jobs and retries, instead of bare Task.start calls. Confidence: 0.85
- Put long-lived processes under a supervisor with a clear restart strategy and let them crash instead of rescuing every error. Confidence: 0.90
- Avoid GenServers as a place to hold data the database already owns; use them for real concurrency or coordination. Confidence: 0.80
- Return tagged tuples like {:ok, value} and {:error, reason} from context functions and handle them with with blocks. Confidence: 0.90
- Use PubSub for live updates between LiveViews and keep the broadcast topic names defined in one module. Confidence: 0.75
- Generate auth with phx.gen.auth and extend it, rather than building login and session handling from scratch. Confidence: 0.80
- Format code with mix format and run Credo and Dialyzer in CI so style and type issues fail the build. Confidence: 0.80
- Test contexts with DataCase and the SQL sandbox, and test LiveViews with Phoenix.LiveViewTest instead of a browser. Confidence: 0.85
- Emit metrics through Telemetry and watch them in LiveDashboard and an external metrics backend in production. Confidence: 0.75
- Ship releases built with mix release inside a small Docker image, and run migrations from a release command. Confidence: 0.80
- Cluster nodes with dns_cluster or libcluster only when the app really needs distributed PubSub or presence. Confidence: 0.70

# 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 the content collections instead of maintaining them by hand. Confidence: 0.85
- Keep URLs stable and add redirects in config whenever a slug changes, so old links never return 404. Confidence: 0.90
- Use semantic HTML with one h1 per page, real headings in order, and alt text required by the content schema for images. Confidence: 0.90
- Use View Transitions sparingly for page navigation and respect prefers-reduced-motion. Confidence: 0.70
- Load third-party scripts like analytics and chat widgets late, or move them off the main thread with Partytown. Confidence: 0.75
- Keep framework islands in one UI library per site rather than mixing React, Vue and Svelte without a reason. Confidence: 0.80
- Run astro check and TypeScript in strict mode in CI so broken frontmatter and props fail the build. Confidence: 0.85
- Check every pull request with link checking and Lighthouse budgets for performance, accessibility and SEO. Confidence: 0.80
- Deploy previews for each pull request so writers and reviewers can read changes before they merge. Confidence: 0.85
- Add search with a static index like Pagefind before reaching for a hosted search service. Confidence: 0.75
- Read secrets only in server code through typed environment variables, and never expose them with a public prefix. Confidence: 0.95

# 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. Confidence: 0.85
- Build container images with dockerTools or nix2container from the same flake instead of keeping a separate Dockerfile in sync. Confidence: 0.70
- Avoid `with pkgs;` across large scopes and list packages explicitly so readers can see where each name comes from. Confidence: 0.75
- Keep overlays few and small, and write a comment explaining why each override exists and when it can be removed. Confidence: 0.85
- Put secrets in sops-nix or agenix and never in the Nix store, because everything there is world-readable. Confidence: 0.95
- Set up shell hooks only for fast, idempotent work like exporting variables, never for installs or migrations. Confidence: 0.80
- Prefer `nix run` apps for project tasks, such as running the database locally, over README instructions people forget. Confidence: 0.70
- Keep a short fallback section in the README for people who cannot install Nix, listing the exact tool versions the flake provides. Confidence: 0.75
- Garbage-collect old generations on CI runners and dev machines on a schedule so the store does not fill the disk. Confidence: 0.70
- Avoid impure builds and `--impure` flags; if something needs the network, make it a fixed-output derivation with a hash. Confidence: 0.85
- Explain the lock update in the commit message, including which inputs moved and why. Confidence: 0.75

# 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 investigating". Confidence: 0.80
- Write customer updates in plain language about impact and next update time, without guesses about the cause. Confidence: 0.85
- Freeze unrelated deploys to the affected system while an incident is open. Confidence: 0.80
- Hand off explicitly when an incident outlasts a shift, with a written summary of state, open threads and next steps. Confidence: 0.85
- Hold a blameless postmortem for every SEV1 and SEV2 within five working days, focused on systems and decisions, not people. Confidence: 0.95
- Write postmortems with impact, timeline, contributing factors, what went well and owned action items with due dates. Confidence: 0.85
- Track postmortem action items in the normal backlog and review overdue ones every week, or they never get done. Confidence: 0.85
- Keep on-call rotations at least six people deep, with a secondary on call, and compensate people for the load. Confidence: 0.80
- Measure alert noise and delete or fix any alert that paged without needing action more than twice. Confidence: 0.85
- Run game days or chaos drills each quarter to practice the response process on purpose, not only during real outages. Confidence: 0.70
- Track time to detect, time to mitigate and incident count by severity, and avoid using them as individual performance targets. Confidence: 0.75

# 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 cross-origin isolated with COOP and COEP headers. Confidence: 0.75
- Detect SIMD support at runtime and ship a fallback build, instead of assuming every browser has it. Confidence: 0.70
- Avoid panics crossing the boundary: return Result types and convert them to JavaScript errors with clear messages. Confidence: 0.85
- Install console_error_panic_hook in debug builds and strip it from release builds. Confidence: 0.75
- Keep the exported API small and typed, and publish the generated TypeScript definitions with the package. Confidence: 0.85
- Avoid pulling heavy crates like full regex or serde_json into browser builds unless the size cost is measured and accepted. Confidence: 0.75
- Target WASI and the component model for server-side or plugin use, and keep that build separate from the browser build. Confidence: 0.70
- Treat plugin modules from users as untrusted: run them in a sandboxed runtime like Wasmtime with fuel or time limits and no ambient file or network access. Confidence: 0.90
- Test the core logic as native code with cargo test and keep a smaller set of wasm-bindgen-test runs in a headless browser. Confidence: 0.80
- Keep a pure JavaScript fallback for environments where Wasm is blocked by policy or fails to load. Confidence: 0.65

# 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 registers, protocols or storage formats are involved. Confidence: 0.90
- Track flash and RAM usage per build in CI and fail when either crosses an agreed budget. Confidence: 0.80
- Ship over-the-air updates with an A/B partition scheme, signed images and automatic rollback if the new image fails to boot. Confidence: 0.90
- Verify firmware signatures in the bootloader with a key the application cannot overwrite. Confidence: 0.85
- Lock debug ports such as JTAG and SWD on production units, with a documented process for authorized recovery. Confidence: 0.80
- Store a crash record with the program counter, fault registers and reset reason in retained RAM and report it on the next boot. Confidence: 0.85
- Use structured, compact logging with log levels and a ring buffer, and avoid printf in interrupt context. Confidence: 0.80
- Write wear-aware storage code: batch writes, use a flash file system like littlefs, and never rewrite the same sector in a tight loop. Confidence: 0.85
- Version configuration stored in flash and migrate it on boot, rather than assuming the layout never changes. Confidence: 0.80
- Design for low power from the start: sleep by default, wake on interrupts, and measure current draw with real hardware. Confidence: 0.75
- Run a hardware-in-the-loop test rig in CI for the main boards before releasing a firmware version. Confidence: 0.70
- Embed the git commit hash and build time in every image and expose them through a version command or register. Confidence: 0.85

# Ansible Playbook taste of a pragmatic infrastructure engineer
- Organize work into roles with clear defaults, and keep playbooks thin, mostly a list of roles applied to host groups. Confidence: 0.90
- Use fully qualified collection names like ansible.builtin.copy in every task so modules are never ambiguous. Confidence: 0.85
- Pin collection and role versions in a requirements.yml file and install them in CI from that file only. Confidence: 0.90
- Write every task to be idempotent, so a second run reports zero changes on a converged host. Confidence: 0.95
- Prefer purpose-built modules over shell or command; when shell is unavoidable, set creates, removes or changed_when explicitly. Confidence: 0.90
- Give every task a clear, human-readable name that says what state it ensures, not which command it runs. Confidence: 0.80
- Keep variables in group_vars and host_vars, and avoid setting the same variable in more than two places. Confidence: 0.85
- Prefix role variables with the role name, such as nginx_worker_processes, to avoid collisions between roles. Confidence: 0.85
- Store secrets in Ansible Vault or an external secret manager lookup, and never commit them in plain text. Confidence: 0.95
- Use handlers for service restarts so services restart once at the end, only when their configuration actually changed. Confidence: 0.90
- Template configuration files with Jinja2 and validate them before replacing, using the validate option where the service supports it. Confidence: 0.85
- Run ansible-lint and yamllint in CI on every pull request. Confidence: 0.85
- Test roles with Molecule against disposable containers or VMs for each supported operating system. Confidence: 0.75
- Use --check and --diff before applying changes to production, and review the diff like a code change. Confidence: 0.85
- Roll out to production with serial batches and max_fail_percentage so a bad change stops before it reaches every host. Confidence: 0.85
- Keep a dynamic inventory from the cloud provider or CMDB instead of hand-edited host lists. Confidence: 0.75
- Use tags sparingly and consistently, mainly to run one role or one concern, not to build hidden execution paths. Confidence: 0.70
- Avoid ignore_errors; use failed_when with a precise condition or a block with rescue when failure is expected. Confidence: 0.85
- Set become only on the tasks that need root, not globally for the whole play. Confidence: 0.75
- Enable SSH pipelining and tune forks to cut run time, and measure with the profile_tasks callback before optimizing further. Confidence: 0.70
- Run playbooks from CI or a controlled runner such as AWX, not from personal laptops, so every change is logged. Confidence: 0.80

# 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 memory and download size stay under control. Confidence: 0.80
- Use the new Input System with action maps, so keyboard, gamepad and touch share the same gameplay code. Confidence: 0.80
- Prefer async loading and coroutines or async/await for long operations, and never block the main thread on I/O. Confidence: 0.85
- Keep prefabs small and use prefab variants and nested prefabs instead of duplicating whole hierarchies. Confidence: 0.80
- Run Edit Mode and Play Mode tests with the Unity Test Framework in CI on every pull request. Confidence: 0.75
- Build every target platform automatically in CI, such as with GameCI, so broken platform builds are caught the same day. Confidence: 0.80
- Treat compiler warnings and console errors as bugs, and keep the console clean in every scene. Confidence: 0.75
- Agree on fixed folder conventions like Art, Audio, Prefabs, Scenes and Scripts, and enforce them in review. Confidence: 0.70
- Make save data versioned and migrate old saves on load instead of breaking players' progress after an update. Confidence: 0.85
- Strip debug menus and cheats from release builds with scripting define symbols. Confidence: 0.80

# 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
- Run visual regression tests with Chromatic or Playwright screenshots on every pull request. Confidence: 0.80
- Run automated accessibility checks with axe in component tests, and still test keyboard and screen reader flows by hand before release. Confidence: 0.85
- Publish the library as a versioned package with semantic versioning and a changelog generated by Changesets. Confidence: 0.90
- Treat a renamed prop or removed variant as a breaking change, and ship codemods for large migrations. Confidence: 0.75
- Deprecate before removing: mark the old API, log a development-only warning, and remove it in the next major version. Confidence: 0.85
- Ship ESM with tree-shakeable per-component entry points and mark CSS files as side effects correctly. Confidence: 0.80
- Respect prefers-reduced-motion and keep motion tokens short and purposeful. Confidence: 0.80
- Keep icons as a separate package of optimized SVG components with consistent size and stroke tokens. Confidence: 0.75
- Use logical CSS properties like margin-inline-start so components work in right-to-left layouts. Confidence: 0.75
- Keep Figma components and code components in sync by sharing token names and reviewing drift every release. Confidence: 0.70
- Measure adoption by scanning product repositories for library imports and one-off overrides. Confidence: 0.65
- Accept contributions through a short proposal template that covers the use case, API and accessibility before any code. Confidence: 0.70

# dbt Analytics Project taste of a careful analytics engineer
- Layer models into staging, intermediate and marts folders, with one staging model per source table. Confidence: 0.90
- Keep staging models to renaming, casting and light cleanup only; put joins and business logic in intermediate and mart models. Confidence: 0.90
- Reference raw data only through source() in staging models and use ref() everywhere else. Confidence: 0.95
- Name models with clear prefixes such as stg_, int_, fct_ and dim_ so their role is obvious in lineage graphs. Confidence: 0.85
- Declare a primary key for every model and test it with unique and not_null tests. Confidence: 0.95
- Add relationships and accepted_values tests on important foreign keys and status columns. Confidence: 0.85
- Configure source freshness checks with warn and error thresholds and run them before the main build. Confidence: 0.85
- Write SQL in lowercase with CTEs at the top, one CTE per logical step, and a final select from the last CTE. Confidence: 0.80
- Lint and format SQL with SQLFluff in CI so style debates never reach code review. Confidence: 0.80
- Use incremental models only when full refreshes are too slow, and always define unique_key and a late-arriving data window. Confidence: 0.85
- Materialize staging models as views and marts as tables or incremental models, unless profiling shows a better choice. Confidence: 0.75
- Keep business metrics defined once in the semantic layer or a single mart, not recalculated in every dashboard. Confidence: 0.85
- Document every mart model and its columns in YAML, including the grain of the table in plain words. Confidence: 0.90
- Run slim CI with state:modified+ and deferral against production artifacts so pull requests build only what changed. Confidence: 0.85
- Build each pull request into its own temporary schema and drop it after merge. Confidence: 0.80
- Pin dbt and package versions in packages.yml and the project requirements, and upgrade them deliberately. Confidence: 0.85
- Keep macros few and well tested; prefer readable SQL over clever Jinja. Confidence: 0.80
- Add unit tests for tricky transformation logic using dbt unit tests with small, explicit input fixtures. Confidence: 0.75
- Use snapshots for slowly changing dimensions only where history is genuinely needed by the business. Confidence: 0.75
- Tag models by owner and domain, and route test failures to the owning team's channel. Confidence: 0.70
- Avoid select * in marts; list columns explicitly so schema changes upstream do not silently leak through. Confidence: 0.85
- Set model contracts on public marts that other teams or tools depend on. Confidence: 0.70

# 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 or generators instead of callbacks. Confidence: 0.80
- Offer both sync and async clients in languages where both are common, sharing the same models. Confidence: 0.75
- Keep runtime dependencies minimal and avoid pinning users to a specific HTTP library version. Confidence: 0.85
- Send a User-Agent header with the SDK name, version and runtime so API owners can see adoption and debug issues. Confidence: 0.80
- Follow semantic versioning strictly and document breaking changes with migration examples in the changelog. Confidence: 0.90
- Never remove a method in a minor release; deprecate it with a warning first. Confidence: 0.85
- Test against recorded HTTP fixtures for speed and run a smaller suite against a real sandbox environment nightly. Confidence: 0.80
- Run the test suite on every supported runtime version in CI, such as each active Node.js LTS or Python release. Confidence: 0.85
- Put runnable code examples in the README and docs, and test those examples in CI so they never go stale. Confidence: 0.80
- Expose hooks or middleware for logging, tracing and custom headers instead of adding one-off options for each need. Confidence: 0.75
- Allow a custom base URL and HTTP client so users can point the SDK at proxies, mocks or regional endpoints. Confidence: 0.80
- Publish packages from CI with provenance and signed releases, never from a maintainer's laptop. Confidence: 0.75

# Neovim Config taste of a minimalist terminal-first developer
- Write the whole config in Lua, starting from a single init.lua that requires small modules under lua/config and lua/plugins. Confidence: 0.90
- Use lazy.nvim as the plugin manager and commit lazy-lock.json so every machine gets the same plugin versions. Confidence: 0.90
- Lazy-load plugins by event, command, filetype or key mapping, and keep startup time under 50 ms measured with :Lazy profile. Confidence: 0.80
- Prefer the built-in LSP client with nvim-lspconfig over heavier all-in-one language plugins. Confidence: 0.85
- Install language servers, formatters and linters with mason.nvim, but pin the tool list in config instead of installing by hand. Confidence: 0.80
- Format on save with conform.nvim and lint with nvim-lint, using the same tools and settings the project runs in CI. Confidence: 0.85
- Use nvim-treesitter for highlighting, indentation and text objects, and list the parsers you need explicitly. Confidence: 0.85
- Pick one fuzzy finder, such as telescope.nvim or fzf-lua, and route files, grep, buffers and LSP symbols through it. Confidence: 0.85
- Set the leader key to space before loading any plugin so every mapping uses it. Confidence: 0.90
- Give every custom mapping a desc field so which-key and :map show what it does. Confidence: 0.85
- Group mappings by prefix, like leader f for find, leader g for git and leader l for LSP, and avoid overriding core Vim motions. Confidence: 0.80
- Keep options in one options.lua file using vim.opt, with a short comment for anything that is not obvious. Confidence: 0.80
- Use relative line numbers, a sign column that is always shown, and persistent undo files. Confidence: 0.75
- Use autocommand groups with clear = true so reloading the config never duplicates handlers. Confidence: 0.90
- Respect .editorconfig files and avoid hard-coding indentation per language unless a project has no settings. Confidence: 0.80
- Show git changes in the sign column with gitsigns.nvim and stage hunks from the editor. Confidence: 0.80
- Use the built-in completion engine or blink.cmp, with LSP and snippet sources only, to keep the popup fast and relevant. Confidence: 0.70
- Choose one colorscheme with good Tree-sitter and LSP semantic token support, and do not chase new themes every week. Confidence: 0.65
- Add a plugin only when it replaces a repeated manual step, and remove plugins you have not used in a month. Confidence: 0.80
- Keep machine-specific settings in a git-ignored local.lua file so the main config stays portable. Confidence: 0.75
- Run :checkhealth after upgrades and fix warnings before adding new plugins. Confidence: 0.80
- Store the config in a dotfiles repository and upgrade plugins deliberately, reviewing the lazy.nvim changelog first. Confidence: 0.85

# Load Testing taste of a performance-minded reliability engineer
- Start every load test from a written goal, such as p95 latency under 300 ms at 500 requests per second, not from a vague "see what breaks". Confidence: 0.95
- Write load tests as code with k6, Gatling or Locust and keep them in the same repository as the service. Confidence: 0.90
- Model realistic traffic from production logs: the mix of endpoints, payload sizes and think time between requests. Confidence: 0.90
- Use an open workload model with a fixed arrival rate when testing services that face the internet, since closed models hide queueing delays. Confidence: 0.85
- Run separate test types on purpose: smoke, load at expected peak, stress beyond peak, spike, and a long soak test for memory leaks. Confidence: 0.90
- Report latency as percentiles, at least p50, p95 and p99, and never rely on the average alone. Confidence: 0.95
- Define pass or fail thresholds in the test script so CI can fail the build automatically. Confidence: 0.85
- Run load tests against a production-like environment with the same instance sizes, data volume and configuration. Confidence: 0.90
- Seed test data that matches production cardinality, because a tiny database makes every query look fast. Confidence: 0.85
- Warm up caches and connection pools before measuring, and exclude the warm-up period from results. Confidence: 0.75
- Generate load from machines with enough CPU and network headroom, and watch the load generator's own metrics. Confidence: 0.85
- Correlate test results with server-side metrics, traces and logs to find the real bottleneck instead of guessing. Confidence: 0.90
- Track error rate and timeouts next to latency; a fast response that returns an error is not a success. Confidence: 0.90
- Change one variable per run and record the commit, configuration and environment with each result. Confidence: 0.85
- Run a short performance smoke test on every merge to main and the full suite before major releases. Confidence: 0.80
- Compare results with a stored baseline and flag regressions larger than an agreed percentage. Confidence: 0.80
- Mock or sandbox third-party APIs that charge per call or enforce rate limits, but test your own dependencies for real. Confidence: 0.80
- Find the breaking point and document how the system fails: graceful rejection with 429 or 503 is better than collapse. Confidence: 0.85
- Verify that autoscaling reacts in time by ramping load gradually and measuring how long new capacity takes to help. Confidence: 0.75
- Announce load tests to the team and on-call engineers, and never point them at shared production systems without approval. Confidence: 0.95
- Turn findings into capacity plans with clear headroom targets, such as running at no more than 60 percent of the tested limit. Confidence: 0.70

# Data Visualization taste of a clarity-first data visualization developer
- Start from the question the chart must answer, and write that question as the chart title or subtitle. Confidence: 0.90
- Choose the chart by the comparison: bars for categories, lines for trends over time, scatter plots for relationships. Confidence: 0.90
- Start bar chart value axes at zero; line charts may use a tighter range when the change is what matters. Confidence: 0.90
- Avoid pie charts with more than three slices, and never use 3D charts. Confidence: 0.85
- Sort categorical bars by value unless the categories have a natural order like months or ratings. Confidence: 0.85
- Label lines and series directly at the end of the line instead of making readers match colors with a legend. Confidence: 0.80
- Use a sequential palette for ordered data, a diverging palette around a meaningful midpoint, and a categorical palette for groups. Confidence: 0.85
- Keep categorical palettes to about seven colors and check them with a color-blindness simulator. Confidence: 0.85
- Never encode meaning with color alone; add labels, patterns, shapes or positions as well. Confidence: 0.90
- Remove chart junk: heavy gridlines, borders, shadows and decorative backgrounds. Confidence: 0.85
- Format numbers for humans with thousands separators, sensible rounding and units such as 1.2M or 35 percent. Confidence: 0.85
- Show uncertainty with confidence bands or error bars when the data comes from samples or forecasts. Confidence: 0.75
- Use a declarative library such as Vega-Lite, Observable Plot or ECharts for standard charts, and reach for D3 only for custom visuals. Confidence: 0.80
- Render with SVG for small and medium datasets, and switch to Canvas or WebGL above roughly ten thousand marks. Confidence: 0.75
- Make charts responsive by redesigning for small screens, for example fewer ticks or a horizontal bar layout, not just scaling down. Confidence: 0.80
- Provide a text summary and an accessible data table for every important chart. Confidence: 0.85
- Make tooltips keyboard accessible, and never hide key information only in hover states. Confidence: 0.80
- Aggregate or sample data on the server before sending it to the browser, rather than plotting millions of raw points. Confidence: 0.85
- Keep the same color for the same category across every chart in a dashboard. Confidence: 0.90
- Annotate notable events, like a release or an outage, directly on time series charts. Confidence: 0.75
- Show the data source and the last refresh time under each chart. Confidence: 0.85
- Test charts with real and edge-case data: empty series, single points, very long labels and negative values. Confidence: 0.80

# Next.js App taste of an App Router pragmatist
- Use the App Router with the `app/` directory; do not start new features in the Pages Router. Confidence: 0.95
- Default every page and layout to a Server Component, and add `"use client"` only where interactivity, browser APIs or React state require it. Confidence: 0.95
- Colocate route files as `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx` and `not-found.tsx` next to the segment they own. Confidence: 0.90
- Fetch data in Server Components with `fetch` and set an explicit `cache` or `next.revalidate` policy; never leave caching accidental. Confidence: 0.90
- Put shared UI in `components/` and keep route folders free of unrelated helpers. Confidence: 0.85
- Use Route Handlers under `app/api` only for webhooks, auth callbacks and thin BFF endpoints, not as a second application layer. Confidence: 0.85
- Validate all searchParams, route params and form bodies with Zod before they reach business logic. Confidence: 0.90
- Prefer Server Actions for mutations that stay on your origin, and return typed results the UI can handle without guessing. Confidence: 0.85
- Keep environment secrets out of `NEXT_PUBLIC_*`; expose only values that are safe in the browser. Confidence: 0.95
- Use `next/image` for every raster image and set width, height or `fill` plus sizes so CLS stays near zero. Confidence: 0.90
- Configure absolute imports with `@/` in `tsconfig.json` and ban deep relative paths like `../../../`. Confidence: 0.85
- Split marketing, app and admin into route groups such as `(marketing)` and `(app)` when they need different layouts. Confidence: 0.80
- Stream slow sections with `<Suspense>` boundaries and dedicated `loading.tsx` files instead of blocking the whole page. Confidence: 0.85
- Pin Node and package-manager versions in `package.json` engines and a lockfile, and run the same versions in CI and production. Confidence: 0.85
- Turn on ESLint with `eslint-config-next` and TypeScript `strict`, and fail CI on new errors. Confidence: 0.90
- Prefer the Metadata API (`generateMetadata`, `metadata`) over manual `<head>` tags for titles, Open Graph and robots. Confidence: 0.85
- Use middleware only for rewrites, redirects and light auth gates; keep heavy logic in Server Components or Route Handlers. Confidence: 0.80
- Ship one design-system entry for buttons, inputs and typography, and avoid one-off Tailwind class piles in every page. Confidence: 0.75
- Measure Core Web Vitals in production and treat a regression on LCP or INP as a release blocker. Confidence: 0.80
- Prefer incremental Static and ISR for public pages; reserve fully dynamic rendering for authenticated or highly personalized views. Confidence: 0.85

# Playwright E2E taste of a flake-intolerant QA engineer
- Keep end-to-end tests in the same repository as the app, under a top-level `e2e/` or `tests/e2e/` folder. Confidence: 0.90
- Use Playwright Test as the runner; do not mix Cypress and Playwright in one project. Confidence: 0.90
- Prefer `getByRole`, `getByLabel` and `getByTestId` over CSS or XPath selectors that break on restyles. Confidence: 0.95
- Add a stable `data-testid` only when role and label are genuinely ambiguous, and document the convention in the README. Confidence: 0.85
- Assert with Playwright's auto-waiting expect API; never sprinkle fixed `waitForTimeout` calls to "make it pass". Confidence: 0.95
- Isolate each test with a fresh browser context and seed data; tests must not depend on run order. Confidence: 0.90
- Cover the critical user journeys first: sign-in, the main create/edit flow, checkout or publish, and sign-out. Confidence: 0.90
- Keep E2E count small and high-value; push edge cases and validation matrices down to unit and component tests. Confidence: 0.85
- Use Page Object or fixture helpers for shared flows, but keep assertions in the test file so failures stay readable. Confidence: 0.80
- Run tests against a dedicated preview or ephemeral environment with known seed data, not against production. Confidence: 0.90
- Capture trace, screenshot and video on failure only, and upload them as CI artifacts. Confidence: 0.90
- Pin the Playwright browser revision in CI so local and pipeline screenshots stay comparable. Confidence: 0.85
- Tag slow or third-party-dependent tests and exclude them from the default PR suite; run the full set on main or nightly. Confidence: 0.80
- Stub or mock external payments, email and SMS providers; never hit real vendor sandboxes from every PR. Confidence: 0.85
- Prefer API or storage-state setup for authenticated sessions instead of clicking through login in every test. Confidence: 0.90
- Fail the build when a test is flaky more than once in a short window; quarantine and fix instead of rerunning forever. Confidence: 0.85
- Use `test.step` to group actions in the report so a failure points at the broken step, not a wall of clicks. Confidence: 0.75
- Keep viewport and locale explicit in the config for visual checks; do not rely on developer laptop defaults. Confidence: 0.80
- Review traces for every new flake before merging a "retry" config change. Confidence: 0.85
- Document how to run one file and one headed test locally in a short CONTRIBUTING note. Confidence: 0.80

# Cloudflare Worker taste of an edge-first platform engineer
- Prefer Wrangler for local dev, secrets, and deploys; keep `wrangler.toml` (or `wrangler.json`) as the source of truth for bindings. Confidence: 0.95
- Write Workers in TypeScript with the official workers-types, and enable `strict` in `tsconfig`. Confidence: 0.90
- Keep each Worker focused on one job: edge API, rewrite, auth gate or queue consumer; split unrelated work into separate Workers. Confidence: 0.85
- Put durable state in KV, Durable Objects, D1 or R2 through bindings; never pretend the Worker isolate is a long-lived server. Confidence: 0.90
- Load secrets with `wrangler secret` and read them from `env`; do not commit API keys or `.dev.vars` with real values. Confidence: 0.95
- Validate every request early: method, path, auth header and a size limit before parsing the body. Confidence: 0.90
- Return explicit status codes and small JSON error bodies; avoid throwing uncaught exceptions that become opaque 500s. Confidence: 0.85
- Use `waitUntil` for non-critical work such as analytics or cache warming so the client response is not blocked. Confidence: 0.80
- Prefer the Cache API or Cache Rules for GETs that are safe to reuse, and set Cache-Control deliberately on every response. Confidence: 0.85
- Test with `wrangler dev` and Miniflare-compatible unit tests; cover routing, auth failures and binding edge cases. Confidence: 0.85
- Pin compatibility date in Wrangler config and bump it on purpose after reading the runtime changelog. Confidence: 0.85
- Use Durable Objects when you need strong consistency per key (rooms, counters, locks); use KV for eventually consistent reads. Confidence: 0.85
- Stream large responses and uploads when possible; avoid buffering whole files in memory inside the isolate. Confidence: 0.80
- Log with structured JSON fields (request id, route, status, duration) and ship them to your observability sink. Confidence: 0.80
- Gate production deploys behind a staging route or environment, and smoke-test the worker URL before shifting traffic. Confidence: 0.85
- Keep CPU-heavy work short; move bulk transforms and ML to Queues, Workflows or an origin service. Confidence: 0.85
- Prefer fetch to first-party Cloudflare services over stuffing large SDKs into the Worker bundle. Confidence: 0.75
- Review the bundle size on every change; drop unused deps and avoid Node polyfills you do not need. Confidence: 0.80
- Document every binding and its purpose at the top of the Worker entry file so onboarding does not require tribal knowledge. Confidence: 0.75
- Treat cron Triggers and Queue consumers as first-class entrypoints with the same validation and logging standards as HTTP. Confidence: 0.80

# GitHub Actions taste of a CI-first platform engineer
- Keep every workflow under `.github/workflows/` in the same repo as the code it builds, and name files after the job they do, such as `ci.yml` or `release.yml`. Confidence: 0.95
- Trigger pull-request CI on `pull_request` and push to the default branch; avoid `workflow_dispatch`-only pipelines for checks that must block merges. Confidence: 0.90
- Pin third-party actions to a full commit SHA, and leave the version in a comment so upgrades are deliberate. Confidence: 0.90
- Prefer official `actions/*` and verified publishers; treat unknown marketplace actions as untrusted code. Confidence: 0.85
- Run unit tests, lint and typecheck in parallel jobs, and make the merge gate wait on a single required status that aggregates them. Confidence: 0.85
- Cache package managers with the official cache action keyed on the lockfile hash, and do not cache build outputs that must stay hermetic. Confidence: 0.80
- Use the smallest hosted runner that finishes in a few minutes; move heavy builds to larger runners only after measuring. Confidence: 0.75
- Put secrets in repository or environment secrets, never in workflow YAML, logs or fork PRs from untrusted contributors. Confidence: 0.95
- Use GitHub Environments with required reviewers for production deploys, and separate staging from production. Confidence: 0.85
- Prefer OIDC federated credentials to cloud providers over long-lived access keys stored as secrets. Confidence: 0.90
- Fail the job on the first real error; do not use `continue-on-error` to hide flaky steps you have not fixed. Confidence: 0.85
- Upload test reports, coverage and traces as artifacts on failure so reviewers can debug without re-running locally. Confidence: 0.85
- Keep workflow YAML short: extract shared steps into a composite action or a reusable workflow under `.github/workflows/`. Confidence: 0.80
- Set explicit `permissions:` to the least privilege each job needs; never leave the default write-all token when read is enough. Confidence: 0.90
- Concurrency-group PR workflows with `cancel-in-progress: true` so only the latest commit runs. Confidence: 0.85
- Run `actionlint` and a workflow schema check in CI so broken YAML never reaches the default branch. Confidence: 0.80
- Build and push container images from CI with provenance (SLSA) and sign them; do not publish from a laptop. Confidence: 0.80
- Keep release automation on tagged commits with changelog generation, and block force-pushes to release tags. Confidence: 0.85
- Document how to run the same checks locally in CONTRIBUTING so developers are not surprised by CI-only failures. Confidence: 0.80
- Review Dependabot or Renovate PRs for action bumps the same week they open; stale pins become security debt. Confidence: 0.75

# Prisma ORM taste of a type-safe database pragmatist
- Treat `schema.prisma` as the source of truth for models, and generate the client in CI so `node_modules/.prisma` never drifts. Confidence: 0.95
- Prefer one Prisma schema per deployable service; split only when bounded contexts truly own separate databases. Confidence: 0.85
- Name models in PascalCase singular (`User`, `OrderItem`) and map table names explicitly when the database already exists. Confidence: 0.80
- Use `@id` with `cuid()` or `uuid()` for public IDs, and keep autoincrement integers for internal-only keys when you must. Confidence: 0.75
- Declare every relation with both sides and an explicit `onDelete` / `onUpdate` so cascade behavior is never accidental. Confidence: 0.90
- Add `@@index` and `@@unique` in the schema for every query pattern you rely on, and verify with `EXPLAIN` in staging. Confidence: 0.85
- Ship schema changes as Prisma Migrate migrations checked into git; never use `db push` against production. Confidence: 0.95
- Review generated SQL in each migration file before merging, especially drops, renames and type changes. Confidence: 0.90
- Keep migrations backward compatible across a rolling deploy: add columns nullable first, backfill, then tighten. Confidence: 0.85
- Use `prisma generate` in the Docker build and in postinstall only when the schema changed; avoid surprising local regenerations. Confidence: 0.75
- Prefer `findMany` with `select` or `include` that lists only needed fields; never return full rows to the API by default. Confidence: 0.85
- Wrap multi-step writes in `prisma.$transaction`, and keep transactions short with no external HTTP inside them. Confidence: 0.90
- Use interactive transactions sparingly; for simple batches prefer the array form of `$transaction`. Confidence: 0.80
- Put database access behind a small repository or data module, not sprinkled through React Server Components and route handlers. Confidence: 0.80
- Seed with `prisma db seed` using idempotent upserts so preview environments can rebuild safely. Confidence: 0.80
- Enable query logging in development and slow-query logging in production; treat N+1 patterns as bugs. Confidence: 0.85
- Use Prisma's typed `Prisma.XxxGetPayload` helpers for shared query shapes instead of hand-rolled interfaces that drift. Confidence: 0.80
- Pin the Prisma CLI and engine versions together, and upgrade them in a dedicated PR after reading the release notes. Confidence: 0.85
- For raw SQL, use `Prisma.sql` tagged templates only, never string concatenation with user input. Confidence: 0.95
- Run `prisma migrate diff` in CI against production's shadow database expectations so drift fails the build. Confidence: 0.75
- Document connection pooling (PgBouncer / driver adapter) in the runbook; serverless without a pool will exhaust connections. Confidence: 0.85

# Helm Chart taste of a Kubernetes packaging engineer
- One chart per deployable application, with a clear `Chart.yaml` name, version and `appVersion` that track semver. Confidence: 0.90
- Keep default `values.yaml` safe for a non-production install, and document every key in `values.schema.json` or a VALUES.md. Confidence: 0.85
- Prefer the official Helm library patterns and bitnami-style helpers sparingly; copy only helpers you understand. Confidence: 0.75
- Template labels and selectors from a single `_helpers.tpl` so Services always match Pods. Confidence: 0.95
- Never hard-code namespaces in templates; take them from `Release.Namespace` or an explicit value. Confidence: 0.90
- Pin image tags to digests or immutable tags in production values; forbid `latest` in the schema. Confidence: 0.90
- Set resource requests and limits for every container, with defaults that fit a small cluster and overrides for prod. Confidence: 0.85
- Include readiness and liveness probes with realistic delays; a wrong probe is worse than no probe. Confidence: 0.85
- Manage config with ConfigMaps and secrets via sealed-secrets, SOPS or external-secrets—not plaintext in git. Confidence: 0.95
- Use `required` and `fail` in templates for mandatory values so misconfiguration fails at install time. Confidence: 0.85
- Run `helm lint`, `helm template` and a kubeconform/kubeval check in CI on every chart change. Confidence: 0.90
- Test with `helm unittest` or snapshot templates for labels, ports and probes so refactors cannot silently break installs. Confidence: 0.80
- Version the chart independently of the app when only packaging changes; bump `appVersion` when the image changes. Confidence: 0.80
- Prefer small umbrellas only when services truly share a release lifecycle; otherwise deploy charts separately with GitOps. Confidence: 0.75
- Support `extraEnv`, `extraVolumes` and `affinity` hooks so operators can extend without forking the chart. Confidence: 0.80
- Keep RBAC templates opt-in and least-privilege; default ServiceAccounts should not mount the API token unless needed. Confidence: 0.85
- Document upgrade notes in `README.md` for breaking values renames, and provide a values migration example. Confidence: 0.80
- Publish charts to an OCI registry or ChartMuseum from CI with signed provenance; do not `helm push` from a laptop. Confidence: 0.80
- Align with GitOps (Argo CD or Flux) by making charts render cleanly with only values files—no manual `helm upgrade` steps. Confidence: 0.85
- Cap chart complexity: if templates need heavy logic, move it to a controller or operators instead of growing Gotpl. Confidence: 0.75
- Review `helm diff` output before applying to production and require a human approval gate on the deploy Environment. Confidence: 0.85