Replit Agent Prompts

Build a full-stack task management app:
- Next.js frontend with TypeScript
- Node.js/Express backend
- PostgreSQL database with Prisma ORM
- JWT authentication (register, login, logout)
- Task CRUD: create, read, update, delete, mark complete
- Filter tasks by status, priority, and due date
- Input validation on frontend and backend
- Error boundaries and toast notifications
- Responsive Tailwind CSS layout

Create a full-stack e-commerce platform:
- Next.js App Router frontend
- Product listing with search, filter, pagination
- Shopping cart with localStorage persistence
- Stripe checkout integration (test mode)
- Order management and history
- User authentication with email/password
- Admin dashboard for product management
- Mobile-responsive with Tailwind CSS
- Environment-based configuration

Develop a real-time collaborative notes app:
- React frontend with Socket.io client
- Node.js/Express backend with Socket.io server
- PostgreSQL for notes persistence
- User authentication and note ownership
- Real-time sync across multiple open sessions
- Conflict resolution for concurrent edits
- Rich text formatting (bold, italic, headings, lists)
- Auto-save every 30 seconds
- Invite other users to collaborate

Build a job board platform:
- Next.js frontend
- Employers can post jobs, applicants can apply
- Job search with filters (location, salary, type)
- Application tracking: applied, reviewed, rejected, offered
- Email notifications using Resend or Nodemailer
- File upload for CV (store in Supabase storage)
- Protected routes: employer dashboard, applicant profile
- PostgreSQL with proper relational schema
- Rate limiting on public endpoints

Build a RESTful API in Node.js/Express:
- Resource: [your resource — e.g., articles, products, users]
- CRUD endpoints following REST conventions
- JWT authentication middleware
- Request validation with Zod or Joi
- Rate limiting: 100 requests/hour per IP
- Consistent error response format: { error, message, statusCode }
- Request logging with Morgan
- Swagger/OpenAPI documentation at /api/docs
- Pagination for list endpoints

Design a GraphQL API with Apollo Server:
- Schema for [domain — e.g., social feed, e-commerce]
- Queries: fetch users, posts, comments with pagination
- Mutations: create, update, delete with auth guards
- Subscriptions for real-time updates on new posts
- DataLoader to batch and cache DB queries
- Authentication via JWT in Authorization header
- Input validation and meaningful error messages
- Rate limiting per operation type
- Introspection disabled in production

Create a webhook handler in [language] for [service — e.g., Stripe, GitHub]:
- Receive POST requests at /webhooks/[service]
- Verify webhook signature using the secret key
- Parse event type and route to handler function
- Handle these events: [list your event types]
- Return 200 quickly; process async via queue
- Idempotency: skip events already processed
- Log every event with timestamp and outcome
- Return 400 for invalid signatures, 200 for all valid events
- Retry handling: accept the same event multiple times safely

Design a microservices architecture:
Services: User Service, Order Service, Notification Service

Each service:
- Independent Express API on separate port
- Own database (no cross-service direct queries)
- Communicates via RabbitMQ/Redis pub-sub
- Health check endpoint at /health

Flows:
- User creates order → Order Service publishes event → Notification Service sends email
- Handle partial failures: what if Notification is down?

Provide: service structure, message schemas, error handling, and local dev setup

Design a PostgreSQL schema for a multi-tenant SaaS app:
- Tables: organisations, users (with roles), projects, tasks, audit_log
- Row-Level Security (RLS) for tenant data isolation
- Roles: owner, admin, member, viewer per organisation
- Soft deletes on all main tables (deleted_at)
- Indexes on: user_id, organisation_id, created_at, status
- Audit log: track who changed what and when
- Foreign keys and constraints for data integrity
- Include migration scripts and seed data
- Document the schema with comments

Create a normalized schema for an e-learning platform:
- Entities: users, instructors, courses, lessons, quizzes, questions, answers, enrolments, progress
- A course has many lessons; a lesson has a quiz
- Track progress per user per lesson (started, completed, score)
- Enrolment: paid or free, start date, completion date
- Efficient queries for: "show my courses", "lesson completion rate", "quiz scores"
- Views for common dashboard queries
- Partitioning strategy for large progress table
- Read vs. write optimisation (heavy reads)

Design a MongoDB schema for an analytics dashboard:
- Collections: events, sessions, page_views, metrics, aggregated_hourly, aggregated_daily
- Events: high-volume writes (1000+ events/sec)
- TTL index: delete raw events after 90 days
- Aggregation pipeline to roll up events into hourly/daily summaries
- Efficient queries for: "clicks by page last 7 days", "unique visitors this month"
- Sharding strategy for events collection
- Indexes to support dashboard queries without full scans
- Document all collection schemas with field types

My application has this existing schema: [paste current schema]

I need to:
- [Describe the schema change — e.g., add user_preferences table, rename column, split table]

Provide:
1. Migration SQL (safe to run on live database with zero downtime)
2. Rollback SQL if the migration needs to be reversed
3. Steps to verify the migration succeeded
4. Any application code changes needed before and after
5. How to handle rows that violate new constraints
6. Estimated migration time for [N] rows

My Node.js app crashes after ~24 hours with out-of-memory errors.

Current setup:
- Express API with WebSocket connections
- [Approx N] concurrent connections at peak
- Heap grows steadily without dropping

Help me:
1. Profile the heap (heap snapshot, clinic.js)
2. Identify the top memory leak suspects in this code: [paste code]
3. Check for missing event listener cleanup
4. Implement proper connection teardown
5. Add memory usage logging (log every 5 min)
6. Set up alerts when heap exceeds [threshold]
7. Write a test to reproduce and verify the fix

My React app is slow — components re-render on every keystroke even when their data hasn't changed.

Symptoms:
- Janky animations and delayed input responses
- React DevTools Profiler shows components re-rendering unnecessarily
- Component tree: [describe structure]

Help me:
1. Identify which components are over-rendering and why
2. Apply useMemo and useCallback where appropriate
3. Fix context usage causing unnecessary re-renders
4. Implement code splitting for large components
5. Add performance metrics logging
6. Set React Profiler budgets to catch future regressions

Here is the component in question: [paste code]

This SQL query takes 8 seconds on a table with 2M rows:
[paste query]

Table schema: [paste schema including indexes]

Help me:
1. Run EXPLAIN ANALYZE on the query and interpret the output
2. Identify the bottleneck (missing index, bad join, full scan)
3. Rewrite the query to be faster (maintain same results)
4. Add the correct indexes (without blocking production writes)
5. Verify with EXPLAIN that the new plan is better
6. Estimate the expected query time after the fix
7. Check if this query runs frequently and should be cached

My application has a race condition:

Symptoms: [describe what goes wrong — e.g., duplicate orders created, balance goes negative, data overwrites]

Code involved: [paste the relevant section]

Help me:
1. Identify where the race condition occurs
2. Reproduce it deterministically in a test
3. Fix using [atomic DB operations / mutex / optimistic locking / transaction]
4. Handle the failure case when the condition is detected
5. Add a regression test that fails without the fix
6. Verify under load that the fix holds (stress test strategy)

Write a production-ready Dockerfile for this [language] application:
- Use an official minimal base image (not :latest)
- Multi-stage build: build stage and runtime stage
- Run as a non-root user in production
- Copy only necessary files to final image
- Use .dockerignore to exclude node_modules, .env, logs
- EXPOSE the correct port
- Set NODE_ENV=production (or equivalent)
- Health check instruction
- Final image should be under [target size]MB

Also write a docker-compose.yml for local dev with the app + database + any other services.

Create a GitHub Actions workflow for this project:

On every PR:
- Run linting and type checking
- Run unit and integration tests
- Build the Docker image
- Run security scan (Snyk or Trivy)
- Comment test coverage on the PR

On merge to main:
- Build and push Docker image to [registry — e.g., GHCR, Docker Hub]
- Deploy to [environment — e.g., Railway, Fly.io, ECS]
- Run smoke tests post-deploy
- Notify Slack on success or failure

Include secrets management (never log secrets). Cache dependencies for speed.

Design a config management strategy for three environments: local, staging, production.

Requirements:
- Never commit secrets to git
- Different DB, API keys, and feature flags per environment
- Local: use .env file with example .env.example committed
- Staging/Prod: use [platform secrets — e.g., Fly.io secrets, AWS SSM, Vercel env vars]
- Type-safe config loading with validation at startup (fail fast if required env var missing)
- Feature flags: some features enabled in staging but not prod

Provide: the config module code, validation schema, and deployment setup.

Add observability to this Node.js application:

1. Structured logging: replace all console.log with pino (JSON logs with request ID, user ID, duration)
2. Health check endpoint /health returning: uptime, DB connection status, memory usage, version
3. Prometheus metrics endpoint /metrics exposing: request count, response time histogram, error rate
4. Error tracking: integrate Sentry (capture unhandled exceptions and promise rejections)
5. Uptime monitoring: what to configure in UptimeRobot or Better Uptime
6. Alert conditions: when to alert (error rate > 1%, response time > 2s, DB unavailable)

Write a complete unit test suite for this service using [Jest / Vitest / Pytest]:
[paste service code]

Cover:
1. Happy path for each public method
2. All error states (invalid input, not found, unauthorised)
3. Edge cases: empty arrays, null values, boundary numbers
4. Mock all external dependencies (DB, HTTP calls, file system)
5. At least one test verifying error messages are human-readable
6. Performance: no test should take more than 100ms

Targets:
- 90%+ branch coverage
- Clear test names: "should [behaviour] when [condition]"
- Grouped with describe blocks

Write integration tests for this API endpoint: [endpoint and method]

Test these scenarios:
1. Valid request — correct response body and status code
2. Missing required fields — 400 with field-specific error
3. Invalid auth token — 401
4. Insufficient permissions — 403
5. Resource not found — 404
6. Database error (mock DB failure) — 500 with safe error message

Setup:
- Use supertest or similar to make real HTTP requests
- Use a test database (not mocked)
- Seed test data in beforeEach, clean up in afterEach
- Assert exact response shape, not just status code

Write Playwright end-to-end tests for this user flow:
[describe the flow — e.g., user registers, creates a task, marks it complete, logs out]

Cover:
1. Full happy path from start to finish
2. Error state: submit form with invalid data
3. Authenticated vs unauthenticated access
4. Mobile viewport (375px wide)

Best practices:
- Use data-testid attributes for selectors (not CSS classes)
- Create reusable Page Object classes for shared interactions
- Screenshot on failure for debugging
- Run in CI with headless Chromium
- Keep test isolation: each test starts from clean state

Design a load testing strategy for this API:
[describe endpoints and expected traffic]

Provide:
1. k6 or Artillery test script for the most critical endpoints
2. Test scenarios: steady state (100 RPS), spike (500 RPS for 30s), soak (100 RPS for 1 hour)
3. Metrics to watch: response time p50/p95/p99, error rate, throughput
4. Acceptance criteria: p95 < 500ms, error rate < 0.1%
5. How to identify the bottleneck when the limit is hit (DB? App? Network?)
6. Recommended infrastructure for the expected load