프롬프트 라이브러리

Nix Dev Environment taste of a reproducibility-minded platform engineer

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

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

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

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

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

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

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

Create a docker container using cursor

Connect a github repo with AWS

continous integration with codebuild

build a CI/CD pipeline with AWS

create s3 buckets with terraform

launch a kubernetes cluster

Astro Content Site taste of a performance-minded web developer

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

gRPC Service taste of a pragmatic distributed systems engineer

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

Taste

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

Spring Boot Service taste of a pragmatic Java backend engineer

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

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

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

Flutter App taste of a pragmatic cross-platform mobile developer

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

Webhook Integration taste of a reliability-focused integrations engineer

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

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