프롬프트 라이브러리

Go service taste of a backend engineer

• Use the standard library net/http router from Go 1.22 before reaching for a framework. Confidence: 0.85
• Lay the project out as cmd/<service>/main.go plus internal/ packages, and skip pkg/. Confidence: 0.80
• Keep main.go thin: read config, wire dependencies and start the server. Confidence: 0.90
• Pass context.Context as the first argument to every function that does I/O. Confidence: 0.95
• Wrap errors with fmt.Errorf and %w, and check them with errors.Is and errors.As. Confidence: 0.95
• Log with log/slog in JSON format and include a request ID on every line. Confidence: 0.90
• Read configuration from environment variables into one typed struct at startup. Confidence: 0.85
• Fail fast at startup when required configuration is missing. Confidence: 0.90
• Write SQL by hand and generate typed code with sqlc instead of using an ORM. Confidence: 0.80
• Use pgx as the Postgres driver with a connection pool. Confidence: 0.85
• Define small interfaces in the package that consumes them, not the one that implements them. Confidence: 0.85
• Use table-driven tests with t.Run subtests. Confidence: 0.90
• Run go test with -race in CI on every pull request. Confidence: 0.90
• Lint with golangci-lint using a short, curated list of linters. Confidence: 0.80
• Shut down gracefully on SIGTERM with signal.NotifyContext and server.Shutdown. Confidence:

Testing taste of a pragmatic TypeScript team

• Use vitest as the default test runner for unit and integration tests. Confidence: 0.90
• Keep test files next to the code they cover as *.test.ts. Confidence: 0.85
• Name tests as plain sentences that describe behavior, not method names. Confidence: 0.90
• Follow arrange, act, assert with a blank line between each phase. Confidence: 0.75
• Test public behavior through the module API instead of private functions. Confidence: 0.90
• Prefer real collaborators and in-memory fakes over mocks. Confidence: 0.85
• Mock only at process boundaries such as the network, the clock and randomness. Confidence: 0.90
• Intercept HTTP with msw instead of stubbing fetch by hand. Confidence: 0.80
• Run database tests against a real Postgres in Testcontainers, not SQLite. Confidence: 0.80
• Freeze time with fake timers and pass seeds to anything random. Confidence: 0.90
• Build test data with small factory functions that accept overrides. Confidence: 0.85
• Keep snapshot tests rare and small, and review every snapshot diff. Confidence: 0.75
• Use Playwright for a thin layer of end-to-end tests on critical user flows only. Confidence: 0.85
• Select elements by role and accessible name in UI tests, never by CSS class. Confidence: 0.90
• Treat a flaky test as a bug: quarantine it the same day and fix or delete it within a week. Confidence: 0.85
• Never

role: Performance engineer who designs safe, realistic load tests
task: >
Turn a short description of a web service, API, or background worker into a complete
load test plan in YAML that a team can review, run, and repeat. The plan must protect
production, model real traffic, and define clear pass/fail criteria before any test runs.

ask_first:

• What is being tested (service name, endpoints or jobs, dependencies such as databases, caches, queues, third-party APIs)
• Current traffic shape (average and peak requests per second, daily pattern, read/write mix, payload sizes)
• Business goal for the test (launch readiness, capacity for an event, regression check, cost tuning)
• Existing SLOs or latency targets, if any
• Target environment (staging, production-like, production with guard rails) and who owns it
• Preferred tool (k6, Locust, Gatling, JMeter, Artillery, or "recommend one")

rules:

• Never plan an unannounced test against production or a third-party API. Mock or stub external services unless the provider explicitly allows load.
• Always include abort conditions and a named person who can stop the test.
• Use realistic think time, data variety, and auth flows; avoid hammering a single cached URL.
• Ramp gradually; never start at peak load.
• If inputs are missing, fill reasonable defaults and list them under assumptions.
• Output only valid

Rust CLI taste

• Parse arguments with clap using the derive API and doc comments as help text. Confidence: 0.95
• Return anyhow::Result from main and add context to every fallible step with .context(). Confidence: 0.90
• Define library error types with thiserror and keep anyhow in the binary only. Confidence: 0.85
• Split the crate into a thin main.rs and a lib.rs that holds the real logic for testing. Confidence: 0.85
• Write normal output to stdout and logs, progress and errors to stderr. Confidence: 0.95
• Offer a --json flag for machine-readable output and serialize it with serde. Confidence: 0.85
• Use tracing with an env filter controlled by -v flags and a RUST_LOG override. Confidence: 0.80
• Respect NO_COLOR and disable colors automatically when stdout is not a terminal. Confidence: 0.90
• Show progress bars with indicatif only for operations longer than about a second. Confidence: 0.75
• Exit with distinct, documented exit codes instead of always returning 1. Confidence: 0.80
• Read configuration in the order flags, then environment variables, then a TOML config file. Confidence: 0.80
• Find config and cache paths with the directories crate rather than hardcoding home paths. Confidence: 0.80
• Test the binary end to end with assert_cmd and snapshot output with insta. Confidence: 0.85
• Avoid async and tokio unless the tool really does concurrent network work. Confide

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

Project Prompt: TrustShield — Hackathon-Ready Web Application

Act as a senior full-stack developer, UI/UX designer, and cybersecurity engineer. Build a complete, professional, responsive web application for my hackathon project.

1. Project Identity

Project Name: TrustShield
Tagline: Securing Online Transactions with Multi-Layered Identity Verification Protocols
Team Name: SudoX
Team Number: T-0002
Institution: Rungta College of Engineering and Technology
Event: Cyber AI Hackathon 2026 — University of Derby, UK

The goal is to demonstrate a risk-adaptive transaction verification system that evaluates transaction signals, calculates a risk score, explains suspicious indicators, and recommends an appropriate verification action.

2. Design Requirements

Create a premium fintech cybersecurity dashboard with:

• Clean white background with restrained navy-blue, light-blue, and red accents.
• Modern typography, rounded cards, subtle shadows, and consistent spacing.
• Professional icons and simple visualizations.
• Responsive layouts for desktop, laptop, tablet, and mobile.
• Smooth but subtle transitions and clear loading, success, warning, and error states.
• No excessive gradients, unnecessary animations, or overcrowded content.
• A polished, realistic interface suitable for a university-level international hackathon presentation.

The U

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 wanna build an website with ai assistant for a hotel called the village in kilimani nairobi it has to have whatsapp empessa empessa prompt I want It to be an ai frondesk ai call

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