프롬프트 라이브러리

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

Act as an expert web developer & copywriter. Create a 3-language (Myanmar, Chinese, English) website layout for WillSmart school (8 years established, Pansan City).
​Note: English & Myanmar languages only. Target: Age 3+.
​Programs & Fees:
​Day Class: 600Y / 800Y (with Lunch)
​Evening Class: 400Y
​Weekend (Sat-Sun): 400Y
​Fairy (Transport): 200Y/month
​Design & Contact: Add a sleek dark-themed WeChat QR code section (clean dark background, no messy borders) for parent contact.
​Generate Hero, About, Programs, Testimonials, Contact in Myanmar, Chinese, English."*

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

Act as an expert frontend developer specializing in Three.js and WebGL. I want to build a premium 3D sneaker showcase website. Write a complete, single-file HTML code. Requirements: 1) Load a 3D model named 'shoe.glb' using GLTFLoader. 2) Center the model automatically and add responsive scaling. 3) Implement smooth auto-rotation and mouse-tracking parallax effects. 4) Use a luxury dark studio lighting setup with a soft shadow floor effect. 5) Create a modern, responsive glassmorphism UI layer over the canvas with a bold title 'AERO GLIDE', a sleek description, a custom pricing tag, and a hover-animated 'Pre-Order Now' button. Ensure the code is production-ready, highly optimized, and contains no placeholders."

I have discussed with product team and defined the metrics and another team memebr have designed silver tables for this use case now i need to find a way how can i design gold layer MV table which can consit of these metrics so that i can easily map out and connect this mv tables to power BI to build the dashboards. help me with it i will give you the fact tables and the metric defination

Tauri Desktop App taste of a cross-platform desktop developer

• Choose Tauri over Electron for new desktop apps when bundle size and memory use matter. Confidence: 0.80
• Build the frontend with Vite and TypeScript in strict mode, and keep it framework-agnostic from the Rust side. Confidence: 0.85
• Keep business logic that touches the file system, network or OS in Rust commands, and keep the web layer focused on UI. Confidence: 0.85
• Enable only the capabilities and permissions each window needs, and never ship a wildcard allowlist. Confidence: 0.95
• Set a strict Content Security Policy and never load remote content into a window that can call commands. Confidence: 0.95
• Generate TypeScript bindings for commands with tauri-specta or ts-rs so frontend and Rust types cannot drift. Confidence: 0.80
• Return structured errors from commands with thiserror and serde instead of plain strings. Confidence: 0.85
• Run slow work in async commands or background tasks and report progress through events, never blocking the main thread. Confidence: 0.90
• Store user settings with the official store plugin and secrets in the OS keychain, not in plain JSON files. Confidence: 0.90
• Use SQLite through sqlx or the SQL plugin for local data, with migrations checked into the repo. Confidence: 0.80
• Resolve paths with the path API for app data and config folders instead of hardcoding location

Vue App taste of a frontend engineer

• Start new projects with Vite and Vue 3, or Nuxt when server rendering or file-based routing is needed. Confidence: 0.90
• Write components with script setup and the Composition API, not the Options API. Confidence: 0.90
• Use TypeScript everywhere and check templates with vue-tsc in CI. Confidence: 0.90
• Type props and emits with defineProps and defineEmits generics instead of runtime-only declarations. Confidence: 0.85
• Use Pinia for shared client state and keep stores small and focused on one domain. Confidence: 0.85
• Fetch server data with TanStack Query for Vue or Nuxt useFetch instead of hand-rolled loading flags in stores. Confidence: 0.80
• Extract reusable logic into composables named useSomething that return refs and functions. Confidence: 0.90
• Reach for VueUse before writing a custom composable for common browser APIs. Confidence: 0.75
• Prefer computed over watch, and use watch only for side effects. Confidence: 0.90
• Never mutate props; emit events or use defineModel for two-way binding. Confidence: 0.95
• Always give v-for items a stable key from the data, never the index. Confidence: 0.90
• Never combine v-if and v-for on the same element. Confidence: 0.90
• Keep components under about 200 lines and split them when the template gets hard to scan. Confidence: 0.70
• Use multi-word PascalCase component names and colocat

Background Jobs taste of a backend reliability engineer

• Make every job idempotent so a retry or duplicate delivery never charges a card or sends an email twice. Confidence: 0.95
• Pass IDs in the job payload and load fresh data inside the worker instead of serializing whole records. Confidence: 0.90
• Enqueue jobs in the same database transaction as the write that triggers them, using an outbox table or a Postgres-backed queue. Confidence: 0.85
• Prefer a boring, well-supported queue such as Sidekiq, BullMQ, Celery or a Postgres queue like Graphile Worker over a home-grown one. Confidence: 0.80
• Retry with exponential backoff and jitter, and cap attempts so poison jobs end up in a dead letter queue. Confidence: 0.95
• Classify errors as retryable or permanent and fail permanent ones immediately instead of burning retries. Confidence: 0.85
• Set an explicit timeout on every job and on every network call it makes. Confidence: 0.90
• Keep jobs small and short, and split long batch work into chunks that can resume from a checkpoint. Confidence: 0.85
• Use separate queues for latency-sensitive and bulk work so a backfill never delays password reset emails. Confidence: 0.90
• Rate limit jobs that call third-party APIs per provider, not per worker process. Confidence: 0.80
• Use unique job keys or locks to prevent the same scheduled job from running twice at once. Confidence: 0.8

Technical Documentation taste of a developer-focused writer

• Keep docs in the same repository as the code and review them in the same pull request as the change. Confidence: 0.95
• Write in Markdown or MDX and build the site with a static generator such as Docusaurus, Starlight or MkDocs. Confidence: 0.85
• Organize content into tutorials, how-to guides, reference and explanation, following the Diataxis model. Confidence: 0.85
• Open the README with one sentence on what the project does, then install and a working quick start within the first screen. Confidence: 0.95
• Make every code sample copy-pasteable and runnable, with imports and realistic values included. Confidence: 0.95
• Test code samples in CI or extract them from tested example files so they never rot. Confidence: 0.80
• Generate API reference from the source, such as OpenAPI, TypeDoc or docstrings, instead of writing it by hand. Confidence: 0.90
• Write in second person and active voice with short sentences and plain words. Confidence: 0.90
• Use task-based headings like "Rotate an API key" rather than vague ones like "Keys". Confidence: 0.85
• State prerequisites and versions at the top of every guide. Confidence: 0.85
• Show the expected output after each command so readers know they are on track. Confidence: 0.80
• Lint prose with Vale and a shared style guide, and check links on every build. Confidence: 0.8

React Native App taste of a cross-platform mobile engineer

• Start new apps with Expo and the prebuild workflow instead of a bare React Native project, and eject only when a native module truly needs it. Confidence: 0.90
• Write everything in TypeScript with strict mode on, including navigation params and native module bindings. Confidence: 0.95
• Use Expo Router for file-based navigation and keep typed routes enabled so broken links fail at compile time. Confidence: 0.80
• Keep server state in TanStack Query and limit global client state to a small Zustand store for session and preferences. Confidence: 0.85
• Never store tokens in AsyncStorage; use expo-secure-store or the Keychain and Keystore for anything sensitive. Confidence: 0.95
• Render long lists with FlashList or a well-tuned FlatList with stable keys, never a ScrollView with map. Confidence: 0.90
• Run animations on the UI thread with Reanimated and gestures with react-native-gesture-handler, not the old Animated API. Confidence: 0.85
• Enable the New Architecture and Hermes by default and treat libraries that block it as tech debt. Confidence: 0.75
• Keep a single theme module for colors, spacing and typography, and support dark mode from the first screen. Confidence: 0.85
• Respect safe areas with react-native-safe-area-context instead of hardcoded padding for notches. Confidence: 0.90
• Put platform-specific cod

Feature Flag Rollout taste of a release engineer

• Separate deploy from release: ship code dark behind a flag and turn it on independently of the deployment. Confidence: 0.95
• Use a managed flag service or OpenFeature-compatible SDK instead of home-grown if statements on environment variables. Confidence: 0.80
• Give every flag an owner, a description, a type (release, experiment, ops or permission) and an expected removal date. Confidence: 0.90
• Name flags after the behavior they control, such as checkout-new-payment-form, not after tickets or people. Confidence: 0.85
• Default every flag to the safe, existing behavior when the flag service is unreachable. Confidence: 0.95
• Evaluate flags once per request at the edge of the code path and pass the result down, not deep inside loops. Confidence: 0.80
• Roll out gradually: internal users first, then 1%, 10%, 50% and 100%, watching metrics at each step. Confidence: 0.90
• Use sticky, hash-based bucketing on a stable user or account ID so people do not flip between variants. Confidence: 0.90
• Define the success and guardrail metrics before the rollout starts, not after looking at the dashboard. Confidence: 0.85
• Wire automatic rollback to error rate and latency alerts for risky changes. Confidence: 0.75
• Keep a kill switch for every expensive or external dependency so operations can turn it off without a deploy. Confidence:

LLM Application taste of an AI product engineer

• Treat prompts as code: keep them in version-controlled files with names, versions and owners, not inline strings scattered around. Confidence: 0.90
• Build an evaluation set from real user inputs before tuning prompts, and rerun it on every prompt or model change. Confidence: 0.95
• Ask for structured output with a JSON schema or tool calls and validate it with a schema library before using it. Confidence: 0.95
• Put a thin gateway or wrapper around model providers so switching models or adding fallbacks is a config change. Confidence: 0.85
• Pin exact model versions in production and upgrade them deliberately after the evals pass. Confidence: 0.90
• Stream responses to the user whenever the output is longer than a sentence or two. Confidence: 0.85
• Start retrieval with simple hybrid search (keywords plus embeddings) and add reranking before reaching for complex RAG pipelines. Confidence: 0.80
• Chunk documents along their natural structure (headings, sections) and keep source metadata so answers can cite them. Confidence: 0.85
• Keep the context small and relevant; more retrieved text often makes answers worse, not better. Confidence: 0.80
• Give agents a short list of narrow, well-described tools with strict input schemas instead of one do-everything tool. Confidence: 0.85
• Put hard limits on agent loops: maximum steps, ma

Jetpack Compose Android App taste of an Android engineer

• Build new screens entirely in Jetpack Compose and keep Views only behind interop for legacy parts. Confidence: 0.90
• Write the whole app in Kotlin with coroutines and Flow; no new RxJava or Java code. Confidence: 0.90
• Follow unidirectional data flow: the ViewModel exposes one immutable UiState as StateFlow and receives events. Confidence: 0.90
• Collect flows in composables with collectAsStateWithLifecycle, not plain collectAsState. Confidence: 0.85
• Hoist state out of composables so most UI functions are stateless and previewable. Confidence: 0.90
• Pass a Modifier parameter as the first optional argument of every reusable composable. Confidence: 0.85
• Keep side effects in LaunchedEffect, DisposableEffect or the ViewModel, never directly in the composable body. Confidence: 0.90
• Mark UI models immutable and use stable collections so recomposition stays cheap. Confidence: 0.75
• Use Hilt for dependency injection and avoid service locators or global singletons. Confidence: 0.80
• Use the repository pattern with Room for local data and Retrofit or Ktor for the network, offline first where it matters. Confidence: 0.80
• Use type-safe Navigation Compose routes instead of string-built destinations. Confidence: 0.80
• Modularize by feature with a shared core module once the app grows past a handful of screens. Confide

Data Pipeline taste of a data engineer

• Prefer ELT: land raw data unchanged first, then transform inside the warehouse. Confidence: 0.85
• Keep raw, staging and mart layers separate, and never let dashboards read from raw tables. Confidence: 0.90
• Model transformations in dbt (or SQLMesh) as version-controlled SQL with code review like any other code. Confidence: 0.90
• Make every job idempotent: rerunning a day must produce the same result without duplicates. Confidence: 0.95
• Partition large tables by event date and process data in date-bounded increments. Confidence: 0.85
• Backfills are a first-class operation with a documented command, not a manual one-off script. Confidence: 0.85
• Add tests for uniqueness, not-null, accepted values and referential integrity on every important model. Confidence: 0.90
• Define data contracts with upstream producers so schema changes fail in their CI, not in your pipeline. Confidence: 0.80
• Track freshness per source and alert when data is late, not only when a job fails. Confidence: 0.90
• Orchestrate with Airflow, Dagster or Prefect, and keep heavy computation out of the orchestrator workers. Confidence: 0.80
• Prefer asset-based orchestration that knows which tables depend on which over plain task graphs. Confidence: 0.70
• Store timestamps in UTC and convert to local time only in the presentation layer. Confidence: 0.95
• Use Parq