프롬프트 라이브러리

React State Management taste

• Start with local useState and lift state only when two siblings truly need it. Confidence: 0.95
• Treat server data as a cache and manage it with TanStack Query instead of a global store. Confidence: 0.90
• Keep URL-worthy state such as filters, tabs and pagination in search params. Confidence: 0.90
• Reach for Zustand when shared client state outgrows a single component tree. Confidence: 0.80
• Avoid Redux for new projects unless the team already depends on its devtools and middleware. Confidence: 0.70
• Use React Context for rarely changing values like theme, locale and the current user, not for fast-changing data. Confidence: 0.90
• Derive values during render instead of syncing them into extra state with useEffect. Confidence: 0.95
• Model complex local state with useReducer and a discriminated union of actions. Confidence: 0.80
• Represent async status as one union like idle, loading, success and error rather than several booleans. Confidence: 0.85
• Keep form state in React Hook Form with a zod schema instead of hand-rolled useState per field. Confidence: 0.80
• Select the smallest slice of a store in each component to avoid needless re-renders. Confidence: 0.85
• Store ids in state and look up the full objects, instead of duplicating nested data. Confidence: 0.80
• Use optimistic updates for quick user actions and roll back on error. Conf

Database Migrations taste

• Keep every schema change in a versioned migration file committed next to the code that needs it. Confidence: 0.95
• Write migrations in plain SQL rather than ORM-generated diffs you have not read. Confidence: 0.80
• Never edit a migration that has already run in a shared environment; add a new one instead. Confidence: 0.95
• Use the expand and contract pattern: add the new column, backfill, switch reads, then drop the old column in a later release. Confidence: 0.90
• Make every migration safe to run while the previous app version is still serving traffic. Confidence: 0.90
• Add new columns as nullable or with a constant default to avoid long table rewrites. Confidence: 0.85
• Create indexes on large Postgres tables with CREATE INDEX CONCURRENTLY outside a transaction. Confidence: 0.90
• Set a short lock_timeout and statement_timeout at the top of each migration. Confidence: 0.85
• Run large backfills as batched background jobs, not inside the migration itself. Confidence: 0.90
• Keep one logical change per migration so failures are easy to read and retry. Confidence: 0.80
• Name migration files with a UTC timestamp prefix and a short verb phrase like 20261017_add_orders_status. Confidence: 0.75
• Prefer forward-only migrations and fix mistakes with a new migration instead of relying on down scripts. Confidence: 0.70
• Run migrations as a separate d

Observability taste

• Instrument with OpenTelemetry first and treat vendor SDKs as exporters, not the API you call. Confidence: 0.90
• Emit structured JSON logs with a stable schema (level, msg, service, trace_id) instead of free-form strings. Confidence: 0.95
• Propagate trace_id and span_id into every log line so logs and traces join automatically. Confidence: 0.95
• Prefer RED metrics for services (rate, errors, duration) and USE metrics for resources (utilization, saturation, errors). Confidence: 0.85
• Keep cardinality under control: never put user IDs or raw URLs into metric labels. Confidence: 0.95
• Sample traces head-based in production and always keep errors and slow requests. Confidence: 0.85
• Name spans after the work unit (http.server, db.query, queue.publish), not after internal function names. Confidence: 0.80
• Log at info for successful business events, warn for recoverable problems, error only when a human should look. Confidence: 0.85
• Never log secrets, tokens, passwords or full request bodies with PII. Confidence: 0.95
• Define SLOs with error budgets and alert on burn rate, not on every raw CPU spike. Confidence: 0.85
• Prefer exemplars that link a metric spike to an example trace over guessing from dashboards alone. Confidence: 0.80
• Ship a bare-minimum dashboard per service: traffic, latency p95/p99, error rate, saturation. Confide

Python Packaging taste

• Use pyproject.toml as the single source of truth and drop setup.py for new packages. Confidence: 0.95
• Prefer the src/ layout so tests never accidentally import an unpackaged tree. Confidence: 0.90
• Use uv for installs, lockfiles and virtualenvs instead of pip plus venv by hand. Confidence: 0.85
• Build with hatchling (or another PEP 517 backend) and never commit built wheels to git. Confidence: 0.90
• Pin the minimum Python version explicitly and test the oldest supported version in CI. Confidence: 0.90
• Declare dependencies with lower bounds you actually need; avoid open-ended upper pins unless forced. Confidence: 0.80
• Keep optional extras ([dev], [docs]) for tooling that end users should not install. Confidence: 0.85
• Format with Ruff format and lint with Ruff; drop Black plus flake8 for new projects. Confidence: 0.85
• Type-check with pyright or basedpyright in strict mode on the public API. Confidence: 0.80
• Test with pytest and keep tests outside src/ under tests/. Confidence: 0.90
• Use trusted publishing from GitHub Actions to PyPI instead of long-lived API tokens. Confidence: 0.90
• Version with dynamic versioning from git tags (hatch-vcs or setuptools-scm). Confidence: 0.75
• Ship a short README with install, a minimal example and a link to docs; keep the long story in docs/. Confidence: 0.90
• Include py.typed when yo

API Design taste

• Prefer resource-oriented URLs with nouns and HTTP verbs for actions, not RPC-style verbs in the path. Confidence: 0.95
• Version APIs in the URL path (/v1/...) and keep breaking changes out of an existing major version. Confidence: 0.90
• Use plural collection names (/users, /orders) and nest only one level deep when the child has no meaning alone. Confidence: 0.85
• Return JSON with consistent camelCase field names and never mix snake_case in the same API. Confidence: 0.85
• Use standard HTTP status codes: 201 for creates, 204 for empty deletes, 404 for missing resources, 409 for conflicts. Confidence: 0.90
• Put pagination, sorting and filtering in query params; return pagination metadata in a stable envelope (data, nextCursor). Confidence: 0.85
• Prefer cursor-based pagination over offset for any list that can grow large. Confidence: 0.90
• Validate every request body with a schema (zod, OpenAPI, JSON Schema) and reject unknown fields. Confidence: 0.90
• Shape error responses the same way everywhere: code, message, and optional details. Confidence: 0.90
• Prefer idempotency keys on POST endpoints that create money, orders or side effects. Confidence: 0.85
• Use ETags or If-Match for concurrent updates on contested resources. Confidence: 0.75
• Document the API with OpenAPI 3 and generate clients from that contract, not hand-written SDKs

Dockerfile and CI taste

• Use multi-stage builds and ship only the runtime artifacts in the final stage. Confidence: 0.95
• Pin base images to a specific version tag, and to a digest for production. Confidence: 0.90
• Prefer slim or distroless final images over full OS images. Confidence: 0.85
• Run the container as a non-root user. Confidence: 0.95
• Order layers so dependency manifests are copied and installed before source code. Confidence: 0.95
• Always keep a .dockerignore that excludes node_modules, .git and local env files. Confidence: 0.95
• Add a HEALTHCHECK or an equivalent readiness probe. Confidence: 0.80
• Use BuildKit cache mounts for package manager caches. Confidence: 0.80
• Never bake secrets into images; pass them at runtime or use build secrets. Confidence: 0.95
• Use exec-form CMD so the process receives signals correctly. Confidence: 0.90
• Scan images with Trivy in CI and fail on critical vulnerabilities. Confidence: 0.80
• Cache dependencies in GitHub Actions keyed on the lockfile hash. Confidence: 0.85
• Run lint, type check and tests as separate parallel CI jobs. Confidence: 0.80
• Tag images with the git SHA and never rely on the latest tag for deploys. Confidence: 0.90
• Keep workflows short and move repeated steps into reusable workflows. Confidence: 0.70

Next.js App Router taste

• Default to Server Components and add "use client" only at leaf components that need interactivity. Confidence: 0.95
• Fetch data in Server Components directly instead of using API routes for internal reads. Confidence: 0.90
• Use Server Actions for mutations and validate input with zod. Confidence: 0.85
• Colocate components, loaders and tests by feature instead of by file type. Confidence: 0.80
• Use Tailwind CSS with a small set of design tokens in CSS variables. Confidence: 0.85
• Use next/image and next/font for all images and fonts. Confidence: 0.90
• Add loading.tsx and error.tsx to every route segment that fetches data. Confidence: 0.85
• Use Prisma or Drizzle with typed queries and keep the client in a single lib/db.ts. Confidence: 0.80
• Cache with fetch tags and revalidateTag instead of manual in-memory caches. Confidence: 0.75
• Keep environment variables validated at startup with a typed env module. Confidence: 0.85
• Generate metadata with generateMetadata and always set Open Graph images. Confidence: 0.85
• Avoid barrel files in large apps because they hurt build times. Confidence: 0.70
• Use middleware only for auth redirects and locale routing, never heavy logic. Confidence: 0.80
• Test critical flows with Playwright and components with vitest. Confidence: 0.80
• Deploy on Vercel with preview deployments for every pull request. Confi

TypeScript library taste

• Use pnpm as the package manager. Confidence: 0.95
• Enable strict mode and noUncheckedIndexedAccess in tsconfig. Confidence: 0.95
• Build with tsup and emit both ESM and CJS with .d.ts files. Confidence: 0.90
• Declare the exports map in package.json instead of relying on main. Confidence: 0.90
• Test with vitest and keep tests next to source as *.test.ts. Confidence: 0.90
• Use Changesets for versioning and changelogs. Confidence: 0.85
• Lint and format with Biome instead of ESLint plus Prettier. Confidence: 0.70
• Keep runtime dependencies at zero where practical. Confidence: 0.85
• Mark the package with "sideEffects": false to enable tree shaking. Confidence: 0.85
• Prefer named exports over default exports. Confidence: 0.90
• Validate untrusted input with zod and infer types from the schemas. Confidence: 0.80
• Run publint and arethetypeswrong in CI before every release. Confidence: 0.80
• Use type-only imports (import type) for types. Confidence: 0.85
• Publish with npm provenance enabled from GitHub Actions. Confidence: 0.75
• Write a short README with an install line, a minimal example and an API table. Confidence: 0.90
• Start versions at 0.1.0 and follow semver strictly once stable. Confidence: 0.70

role: >
You are a senior site reliability engineer who has written and maintained
on-call runbooks for web services, APIs, data pipelines, and background
workers. You write runbooks for a tired engineer paged at 3 a.m.: short,
ordered steps, exact places to look, safe mitigations first, and clear
rules for when to escalate. You never invent dashboard names, commands, or
contacts that the user did not give you; you leave clearly marked
placeholders instead.

task: >
Build an on-call runbook scaffold for the service described below:
severity levels, detection signals and alerts, a triage flow, mitigation
playbooks for each common incident, a rollback procedure, communication
templates, an escalation path, and a post-incident checklist, ready to be
pasted into the team's docs and filled in.

inputs:
service_name: "${service:checkout-api}"
what_it_does: "${purpose:handles cart checkout and payment authorization for the web shop and mobile app}"
architecture: "${architecture:stateless Node.js service on Kubernetes, 6 pods, PostgreSQL primary with one replica, Redis cache, calls an external payment provider}"
traffic_and_slo: "${slo:about 40 requests per second at peak, 99.9 percent availability and p95 latency under 400 ms}"
common_incidents: "${incidents:payment provider timeouts, database connection pool exhaustion, bad deploys, Redis eviction sto

role: >
You are a senior Site Reliability Engineer who designs Service Level Objectives
(SLOs) that match what users actually experience. You favor a few meaningful
objectives over many vanity metrics, and you turn every SLO into an error
budget policy and alerts a team can act on.

task: >
Design user-centric SLIs, SLOs, error budgets, burn-rate alerts, and an error
budget policy for the service described in the inputs. Then return the result
in the exact YAML output schema below.

inputs:
service_name: "${service_name:checkout-api}"
what_users_do: "${user_journeys:browse cart, apply coupon, place order, view order status}"
architecture: "${architecture:Node.js API behind a load balancer, PostgreSQL, Redis cache, Stripe for payments}"
traffic: "${traffic:about 40 requests per second at peak, strong evening and weekend peaks}"
telemetry_available: "${telemetry:load balancer access logs, Prometheus metrics, OpenTelemetry traces}"
current_pain: "${pain:slow order placement during sales, on-call fatigue from noisy CPU alerts}"
business_constraints: "${constraints:payments must never be double-charged; marketing runs flash sales monthly}"
compliance_window_days: ${window_days:28}

method:

• step: Map critical user journeys

detail: List 3-5 journeys from what_users_do and rank them by business impact. Ignore internal-only endpoints unless a user w

Act as an elite full-stack developer and UI/UX expert. Update, refactor, and finalize our corporate project management and inventory system with the following 11 comprehensive features and modifications. Ensure absolute state management using React hooks, strict validation, dynamic workflows, and high-fidelity conditional rendering.

1. Multi-Tenant Multi-Project Login Isolation
2. Behavior: Implement a multi-tenant authentication rule based on a unique combination of Company Name, Project Name, and Password.
3. Logic: If user A logs in with Company A and Project CC, they must see distinct dataset A. If user B logs in with Company B and Project CC, the system must treat this as a completely separate unique project because the Company Names differ. Prevent data cross-contamination between different companies using identical project names.

1. Store Request Received Menu UI & Column Labels
2. Page Workflow: On the Store Page -> Request Received Menu -> View section:
3. UI Updates: Display the item Description. Rename the column header Parameter to "Unit", and rename the column header Note to "Remark".
4. Data Visibility: Ensure the data for "Unit" and "Quantity (QTY)" MUST be fully visible and readable to the user under their respective columns. Do not hide these core transaction details.
5. Header Branding: Bind the Company Name entered at login dynamically to the header layout of th

I want you to act as a Senior Software Engineer performing a rigorous code quality, maintainability, and technical debt audit on a codebase.

Your objective is to aggressively yet safely simplify the codebase, improve maintainability, and highlight anything that provides zero value to the application.

Analyze the provided codebase, directory tree, or code snippets and systematically evaluate:

1. Dead Code: Unused functions, files, components, routes, APIs, variables, imports, and dependencies.
2. Duplicate Logic: Redundant blocks or patterns that should be consolidated into reusable utilities or abstraction layers.
3. Unused UI Components: Orphaned views, unused design components, or obsolete style files.
4. Overly Complex Implementations: Code that can be simplified or refactored without altering expected behavior.
5. Legacy & Deprecated Code: Outdated patterns or unneeded legacy fallback logic.
6. Redundant Queries & API Calls: Unnecessary database operations, duplicate fetch requests, or N+1 query risks.
7. Abandoned Files: Disconnected, unreachable, or unreferenced files in the repository.
8. Technical Debt: Code smells, poor abstractions, or high-risk areas lacking maintainability.

For every issue identified, structure your analysis with:

• Issue & Location: File path and code block.
• Reason for Action: Why this code is unnecessary, redundant, or overly complex.
• Impa

User accounts and profiles for individuals or campus teams.
Carbon calculator covering electricity, travel, food, and waste, with clearly stated calculation factors.
Interactive dashboard showing emissions by category and trends over time.
Reduction planner where users compare scenarios, such as switching transport or reducing electricity use.
Goals and challenges with progress tracking and team leaderboards.
Downloadable reports summarizing emissions and suggested actions.

I want a bank app prompt and I want it professional and better. I want it to be name FATE BANK

🚀 URL Shortening Service — Full-Stack Application

📋 Project Overview

Build a production-ready, full-stack URL shortening service with a modern, accessible frontend and a robust RESTful backend API. The application must handle the complete lifecycle of shortened links: creation, redirection, tracking, management, and expiration. Prioritize performance, security, and an exceptional user experience across all devices.

🛠️ Tech Stack

Frontend:

• Semantic HTML5 with ARIA attributes for accessibility (WCAG 2.1 AA compliance)
• CSS3 with CSS Custom Properties (variables), Flexbox, and CSS Grid
• Vanilla JavaScript (ES2022+) using modular architecture (ES Modules)
• No heavy frameworks — keep the bundle lightweight and fast

Backend API:

• RESTful API design following OpenAPI 3.0 specification
• JSON request/response format with proper HTTP status codes
• CORS configuration for cross-origin requests
• Rate limiting per IP and per API key

Libraries (CDN or bundled):

• QR Code generation (e.g., qrcode.js or qr-creator)
• Charting library for analytics (e.g., Chart.js or lightweight alternative)
• Date picker for expiration (e.g., flatpickr)
• Toast notification system (custom-built, no dependency)

🎨 Frontend — UI/UX Requirements

Layout & Design:

• Clean, minimalist design with a hero section featuring a **large, prominent URL input

Using this app to record time of starting and ending shifts for multi workers to save the date,time and duration of each shift and giving a report in the end of each month.it can be run offline and online by starting counting time until the mobile is connected .each shift should not be more than ten hours continously in single shift.each worker has his own profile can see his own shifts reports and editing is not allowed only by the owner which is me.
There is a space to leave a notes in each shift by worker or owner or both . The worker to sign in need to use there own email . There is a botton for start shift and end shift .

Analyze the provided Python file like a senior/veteran Python developer who is seeing it for the first time.

Explain it in simple, easy-to-understand language while preserving the technical context.

Cover:

1. Purpose — what this file does and why it exists.
2. Flow — explain the main execution flow from entry point to completion.
3. Functions/Classes — explain the important functions/classes, their inputs, outputs, and responsibilities.
4. Dependencies — explain important imports, external APIs, files, databases, services, or modules it interacts with.
5. Data Flow — explain how important data moves, changes, and is passed between functions/classes.
6. Conditions & Loops — explain important if/else, loops, retries, exceptions, and decision points.
7. Side Effects — identify file writes, database/API calls, state changes, external operations, etc.
8. Risks & Issues — identify bugs, edge cases, unnecessary complexity, coupling, or maintainability concerns.
9. Summary — give a short step-by-step flow that a developer can remember easily.

Focus on understanding the actual code and execution flow, not merely describing each line. Do not invent behavior that cannot be determined from the file. If something depends on another file/module that is not provided, clearly mention it.

Keep the explanation structured, concise, and easy to follow

complete source code for the application + build.bat + PyInstaller configuration + installer configuration + CSV template + documentation, rather than just a partial prototype. i will upload csv and bulk pdf file. after clickig button match name and pdf file process file will be send to provided email id which in csv
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for Levenshtein
Failed to build Levenshtein
error: failed-wheel-build-for-install

× Failed to build installable wheels for some pyproject.toml based projects
╰─> Levenshtein
ERROR: Failed to install required packages
cpanel webmail Set up email on application tool
PDF Auto MATCHING LOGIC: EmployeeID, FirstName, MiddleName, LastName
NAME-BASED MATCHING
If Employee ID is not found in the filename, implement a controlled secondary matching method based on employee name.
Example:
PDF:

Abel Harry Anthony.pdf

CSV:

10152 | Abel | Harry | Anthony | abel@example.com

The application should identify:

Abel Harry Anthony

and match it with the CSV record.
The matching logic can be changed so the application uses any 3 of the 4 CSV fields:

• ID
• First Name
• Middle Name
• Last Name

Input PDF:
10004_Vihang_Wani_SalarySlip_March_2026.pdf

no need to rename the pdf file once it's attached also show dashboard me all attachment

Assume you are a 10+ years of experienced in Azure Data Engineer with most intelligent, expertised smartly working professional.
And you are too perfect in creating the .md file so that it will give the accurate solutions and results for the same. This makes that you are too intelligent in everything that related to azure data engineer.

According to my resume, I am currently working in the EY project where 50% development and 50% of Ops and support work is involved.

I want you to read my resume and create the .md file soo perfectly and accurately so that in future if i want to alter that .md it also there should be possibility that can edit and work that accurately with ease it should be.

What ever the work i get from my team. I will provude you related pictures, pdf, or any kind of document you should process that file with most advanced technology you have in a fraction of seconds and give me the accurate result and solution required.

I want you to think most advanced way and accurate way which is really and reasonably required with out any unnecessary actions to be suggested.

If there is any email actions or texts actions requested. Yoy have to provide me the matter in such a way that it should be most professional, human style with less corporative words and most natural style with intelligently, smartly written. So that whom ever recieves my email and text should as

Set up an OpenAPI spec-sync workflow in this project

I want the same backend-spec workflow I use in another repo: a script that diffs the live
OpenAPI spec against a local snapshot and writes a frontend-oriented change report, plus a
/api-sync slash command that turns that report into a phased plan.

Fill these in from the repo before you start (ask me only if you can't work it out):

• Spec source: find it yourself — see Part 0. Don't ask me for the URL until you've looked.

Whatever you find becomes the script's default, overridable via an OPENAPI_URL env var.

• Snapshot path: api-spec/openapi.yaml · Report path: api-spec/CHANGES.md
• Source root to cross-reference: src/ (adjust to this repo's layout)
• Response-validation library: zod (adjust if this repo uses something else)
• Snapshot in git? Keep the yaml gitignored (too large/noisy for history) but **commit

CHANGES.md** — the generated report is the durable record of what changed and when. Also
ignore api-spec/openapi-*.yaml and api-spec/CHANGES-*.md (dated manual archives).

Read this repo first (package manager, script conventions, how API calls and response schemas are
written) and match its style. Don't invent paths — grep for the real ones.

Part 0 — find the spec before you write anything

Do this first and tell me what you found. Don't guess a URL,

MVP Phase 1 — Foundation

Objective

Create the technical foundation of the Local Business Management System.

Do NOT implement business features yet.

The goal is to have a clean Go application that:

1. Starts successfully
2. Loads configuration
3. Connects to PostgreSQL
4. Runs database migrations
5. Exposes an HTTP API
6. Has structured logging
7. Has health checks
8. Has clean application startup/shutdown

Stack

• Go
• PostgreSQL
• HTTP REST API
• SQL migrations
• Environment/configuration system
• Structured logging

Initial Structure

cmd/
  server/
    main.go

internal/
  platform/
    config/
    database/
    http/
    logging/

  core/

migrations/

api/

go.mod

Required Endpoint

GET /health

Expected response:

{
  "status": "ok",
  "database": "ok"
}

Requirements

Implement graceful shutdown.

Database connection must use connection pooling.

Configuration must come from environment variables/configuration rather than hardcoded values.

Create a migration mechanism that can safely evolve PostgreSQL schemas.

Do not create the module/plugin architecture yet beyond the minimal structure necessary to keep future boundaries clean.

Deliverable

A running local Go server connected to PostgreSQL with a clean project structure and migration system.

Nothing else.

Act as an Expert Chrome Extension Developer (Manifest V3) and Backend Engineer.

I need you to write the complete, production-ready code for a premium Chrome Extension called "ARIX Pro SEO Toolkit".

CRITICAL RULES:

1. NO SCRAPING. Use ONLY official, top-tier SEO APIs.
2. Use Manifest V3, Vanilla JavaScript, HTML, and CSS. No React, no build steps.
3. To protect API keys, the extension must NOT call the APIs directly from the popup. It must call a simple, free Vercel Serverless Function (backend proxy) which I will deploy.

TECH STACK & DATA SOURCES:

1. Off-Page SEO (DR, Traffic, Backlinks): DataForSEO API (or Moz API as a fallback).
2. Technical SEO / Core Web Vitals: Google PageSpeed Insights API.

FILE STRUCTURE REQUIRED:
Please provide the complete code for:

1. manifest.json (Manifest V3, permissions: activeTab, storage).
2. popup.html (Clean, modern, dark-mode UI with tabs for Overview, Off-Page, and Technical).
3. popup.css (Premium styling, clean typography, loading states).
4. popup.js (Main controller. It should fetch data from my Vercel backend URL, not directly from the APIs).
5. api/index.js (The Vercel Serverless function. This file will hold the API keys securely and make the actual requests to DataForSEO and Google PSI, then return the JSON to the extension).

SPECIFIC LOGIC REQUIREMENTS:

• BACKEND (api/index.js):
• Accept a domain and type (of

I wanna build an AI that can learning a deck in Master duel called Kewl Tune that can win against pro players with differents decks , This AI can build combos and evo his level with a tool called ygo agent on git hub and with Kaggle Notebook , Im vibe coder have a little bit of info about python and linux commands , This project is only for fun

Create a point and click game with the theme and mechanic of the AI choice, make me surprise