프롬프트 라이브러리

Linux Server Hardening taste of a careful operations engineer

• Build servers from a minimal base image and install only the packages a role needs, removing compilers and debugging tools from production hosts. Confidence: 0.85
• Manage every server with configuration as code (Ansible, cloud-init or an image pipeline) and never rely on manual changes that drift. Confidence: 0.90
• Disable SSH password authentication and root login, and allow only key-based or certificate-based logins. Confidence: 0.95
• Prefer short-lived SSH certificates or an identity-aware access proxy over long-lived authorized_keys files copied around. Confidence: 0.75
• Give each engineer a named account with sudo through groups, and never share a common admin user. Confidence: 0.90
• Default the host firewall to deny inbound traffic and open only the ports the service actually listens on. Confidence: 0.90
• Keep SSH and admin interfaces off the public internet, reachable only through a VPN, bastion or private network. Confidence: 0.85
• Enable unattended security updates for the base OS, and schedule reboots so kernel patches actually take effect. Confidence: 0.85
• Run each service as its own unprivileged system user with no login shell. Confidence: 0.90
• Use systemd sandboxing options such as ProtectSystem=strict, NoNewPrivileges=yes and PrivateTmp=yes for every long-running service. Confidence

Solidity Smart Contract taste of a security-first protocol engineer

• Pin an exact recent compiler version with pragma solidity 0.8.x; instead of a floating caret range. Confidence: 0.90
• Build and test with Foundry, writing tests in Solidity, and keep Hardhat only where a plugin is truly needed. Confidence: 0.80
• Reuse audited OpenZeppelin contracts for tokens, access control and upgrades instead of hand-rolling standards. Confidence: 0.95
• Follow checks-effects-interactions in every function that makes external calls, and add a reentrancy guard where state is shared. Confidence: 0.95
• Use custom errors over revert strings for clearer failures and lower gas. Confidence: 0.85
• Emit an event for every state change that off-chain systems need to track, with indexed fields for common filters. Confidence: 0.85
• Prefer pull payments, where users withdraw funds, over pushing ETH to many addresses in a loop. Confidence: 0.90
• Never use tx.origin for authorization; check msg.sender against explicit roles. Confidence: 1.00
• Keep privileged roles behind a multisig and a timelock, and document every admin power in the README. Confidence: 0.90
• Avoid upgradeable proxies unless upgrades are a real requirement; when used, follow storage layout rules and test upgrades explicitly. Confidence: 0.80
• Use SafeERC20 for token transfers so non-standard tokens that return no bool

Pandas Data Analysis taste of a reproducible analytics practitioner

• Keep analysis in version-controlled scripts or notebooks with outputs cleared before commit, and move reusable logic into an importable module. Confidence: 0.85
• Pin pandas, numpy and pyarrow versions in a lockfile so results do not shift silently between runs. Confidence: 0.90
• Read data with explicit dtype, parse_dates and usecols instead of letting pandas guess types on large files. Confidence: 0.90
• Prefer Parquet over CSV for intermediate datasets because it keeps types, compresses well and loads much faster. Confidence: 0.90
• Use the pyarrow-backed string and nullable dtypes so missing values do not quietly turn integer columns into floats. Confidence: 0.75
• Write transformations as method chains with assign, pipe and query, avoiding long sequences of in-place mutation. Confidence: 0.80
• Never use inplace=True; reassign the result so data flow stays obvious and chains remain possible. Confidence: 0.85
• Select with .loc and .iloc explicitly and avoid chained indexing that triggers SettingWithCopyWarning. Confidence: 0.90
• Vectorize with built-in column operations and np.where or np.select; reach for apply with Python functions only as a last resort. Confidence: 0.90
• Validate assumptions with assertions after each major step: row counts, unique keys, null ratios and v

Kafka Streaming taste of a pragmatic event platform engineer

• Name topics by domain and event, such as orders.order-placed.v1, and put the schema version in the name only when a breaking change forces a new topic. Confidence: 0.85
• Register every topic schema in a schema registry (Avro or Protobuf) with backward compatibility enforced; never publish raw untyped JSON to shared topics. Confidence: 0.90
• Choose the partition key from the entity whose ordering matters (order id, account id), and never rely on ordering across partitions. Confidence: 0.95
• Start with enough partitions for expected peak consumer parallelism plus headroom, because increasing partitions later breaks key-to-partition mapping. Confidence: 0.80
• Run producers with acks=all, idempotence enabled and min.insync.replicas=2 on a replication factor of 3 for anything business-critical. Confidence: 0.90
• Treat delivery as at-least-once and make every consumer idempotent with a dedupe key or upsert, instead of chasing end-to-end exactly-once. Confidence: 0.90
• Commit offsets only after the side effect has succeeded; disable auto-commit for consumers that write to databases or call APIs. Confidence: 0.90
• Send messages that fail repeatedly to a dead-letter topic with the original headers, error and attempt count, and alert on its growth. Confidence: 0.85
• Retry transient failures with bounded backof

MASTER PRODUCT DEVELOPMENT PROMPT

Clinical Research Command Center (CRCC)

An AI-Powered Clinical Trial Operations and Management Platform

Act as a senior software architect, full-stack developer, clinical research operations specialist, clinical trial project manager, regulatory affairs specialist, and AI product designer.

Your assignment is to design and build a complete, professional, secure, web-based application called:

CLINICAL RESEARCH COMMAND CENTER (CRCC)

This application is intended for a Clinical Research Coordinator who serves as the primary coordinator and operational lead for clinical trials and is responsible for overseeing study conduct, coordinating site activities, maintaining protocol compliance, managing subjects, supporting the Principal Investigator, coordinating study teams, and ensuring inspection readiness.

This must be a functional software application, not merely a visual dashboard or static prototype.

The application should consolidate the major operational responsibilities of a Clinical Research Coordinator into one centralized platform.

1. CORE PRODUCT OBJECTIVE

Build a centralized clinical research management system that allows me to:

• Manage multiple clinical trials simultaneously.
• Organize all protocol documents and study-related materials.
• Extract and interpret protocol requirements using AI.
• Convert the Sched

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 cred

see i want to give a prompt to chat gpt that i need edit the CV according to JD exactly 100 in the JD

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.

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 art

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 w

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 f

Build an Immersive, Animated Cyberpunk Pixel-Art Diorama

Create a breathtaking, richly detailed, fully animated cyberpunk pixel-art diorama designed to serve as the endlessly looping visual backdrop for a 10-hour lo-fi music video on YouTube.

I want something genuinely mesmerizing. A tiny, self-contained world that feels alive. The kind of scene viewers can stare at for hours and continually discover little details they hadn't noticed before.

Creative Direction

Imagine a forgotten corner of a sprawling futuristic megacity, sometime around 2089. It's 2:37 AM. Rain has been falling for days. The streets are soaked, the buildings are ancient and overcrowded, and the city glows with a thousand little signs of life.

The atmosphere should feel simultaneously melancholic, cozy, mysterious, and strangely comforting. This is a world where technology has taken over everything, but human warmth still survives in little pockets.

Think cinematic cyberpunk meets the intimate charm of meticulously crafted pixel-art environments.

Don't settle for a generic neon skyline. Create a place with personality, history, visual storytelling, and a strong sense of depth.

Visual Composition

Design a beautiful, layered environment with a compelling focal point and plenty of environmental storytelling.

Consider elements such as:

• A tiny apartment or rooftop hideaway overlooking a vast, r

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

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

Design System taste of a pragmatic design systems engineer

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

-

Unity Game Project taste of a shipping-focused game developer

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

Embedded Firmware taste of a reliability-minded firmware engineer

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

WebAssembly Module taste of a performance-focused systems developer

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

Incident Response taste of a calm on-call engineer

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

Nix Dev Environment taste of a reproducibility-minded platform engineer

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

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

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

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

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

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

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

Create a docker container using cursor

Connect a github repo with AWS

continous integration with codebuild

build a CI/CD pipeline with AWS

create s3 buckets with terraform

launch a kubernetes cluster

Astro Content Site taste of a performance-minded web developer

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

gRPC Service taste of a pragmatic distributed systems engineer

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

Taste

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