100 Claude-Native Coding Prompts

<context> Domain: [e.g. e-commerce, project management, healthcare] Resources: [list the main entities — e.g. users, orders, products] Consumers: [e.g. mobile app, third-party developers, internal frontend] Auth: [e.g. JWT, API keys, OAuth2] </context> <task> Design a RESTful API for this domain: [DESCRIBE THE FEATURE OR SYSTEM] Provide: 1. Resource hierarchy and URL structure 2. HTTP methods and status codes for each endpoint 3. Request/response schemas (JSON) 4. Authentication and authorization model 5. Filtering, sorting, and pagination conventions </task> <constraints> - Follow REST conventions strictly: proper HTTP verbs, meaningful status codes, resource-oriented URLs - Use plural nouns for collections - Avoid verbs in URLs - Version from day one: /v1/ - Design for the consumer, not the database schema </constraints>

<context> Domain: [e.g. social platform, SaaS dashboard] Main entities: [list types — e.g. User, Post, Comment, Organization] Primary consumers: [e.g. React web app, mobile client] Auth model: [e.g. JWT with role-based access] </context> <task> Design a GraphQL schema for this domain: [DESCRIBE THE PRODUCT OR FEATURE] Provide: 1. Type definitions for all entities 2. Query root fields with arguments 3. Mutation definitions with input types 4. Subscription definitions (if real-time is needed) 5. Pagination approach (cursor vs offset) 6. Error handling strategy </task> <constraints> - Design for the client's data needs, not the server's data model - Use connections pattern for paginated lists - Input types should be separate from output types - Avoid over-fetching — design fields the client actually needs - Use enums for fixed value sets </constraints>

<context> API type: [REST / GraphQL] Framework: [e.g. Express, FastAPI, NestJS] Consumers: [e.g. mobile clients, third-party integrators] Existing error format: [paste current error response if any] </context> <task> Design a comprehensive error handling strategy for this API: [DESCRIBE YOUR API OR PASTE EXISTING CODE] Define: 1. Error response schema (error code, message, details, request ID) 2. Error code taxonomy (validation, auth, not found, rate limit, server error) 3. HTTP status code mapping 4. How validation errors surface field-level details 5. How to distinguish client errors from server errors 6. Error logging strategy (what to log vs. what to return) </task> <constraints> - Error messages for clients must never expose stack traces or internal details - Every error must have a stable machine-readable code, not just an HTTP status - Validation errors must identify which field failed and why - Include example responses for each error category </constraints>

<context> API type: [REST / GraphQL] Current state: [e.g. no versioning yet, on v1, breaking changes needed] Consumer types: [e.g. mobile apps with slow update cycles, third-party integrators, internal frontend] Breaking change: [describe what needs to change] </context> <task> Design an API versioning strategy for this situation: [DESCRIBE YOUR API AND THE CHANGES NEEDED] Cover: 1. Versioning mechanism (URL path, header, query param — recommend with rationale) 2. Deprecation policy and timeline 3. How to maintain multiple versions without code explosion 4. Migration guide for consumers 5. Sunset header implementation </task> <constraints> - Recommend based on consumer type — mobile apps need longer deprecation windows than internal frontends - Show concrete implementation code for the chosen mechanism - Define what constitutes a "breaking change" for your API - Include a deprecation notice template </constraints>

<context> API type: [REST / GraphQL] Infrastructure: [e.g. single Node.js server, multi-instance behind load balancer, serverless] Consumer types: [e.g. free tier users, paid subscribers, internal services] Current traffic: [e.g. 500 req/min peak] </context> <task> Design a rate limiting system for this API: [DESCRIBE YOUR API AND USE CASES] Define: 1. Rate limit tiers per consumer type 2. Algorithm choice (token bucket, sliding window, fixed window — with rationale) 3. Rate limit headers (X-RateLimit-*) 4. Response when limit is exceeded (429, Retry-After) 5. Implementation approach for your infrastructure 6. Exemptions (health checks, internal services) </task> <constraints> - Distributed deployments need Redis or similar — don't use in-memory for multi-instance - Include burst allowance to handle legitimate traffic spikes - Rate limit by API key, not just IP (IPs change and are shared) - Show the middleware implementation code </constraints>

<context> Application type: [e.g. SaaS with multi-tenancy, B2C mobile app, internal tool] User types: [e.g. admins, members, guests, service accounts] Permissions model: [e.g. RBAC, ABAC, simple boolean flags] Tech stack: [e.g. Node.js + PostgreSQL, Python + Redis] </context> <task> Design the authentication and authorization flow for this system: [DESCRIBE YOUR PRODUCT AND ACCESS REQUIREMENTS] Cover: 1. Authentication flow (login, token issuance, refresh, logout) 2. Token storage and transmission strategy 3. Permission model with example roles and policies 4. How authorization is enforced (middleware, decorators, policy engine) 5. Multi-tenancy isolation if applicable 6. Service-to-service auth </task> <constraints> - JWT access tokens should be short-lived (15 min), refresh tokens longer - Never store tokens in localStorage for web apps — use httpOnly cookies - Authorization checks must happen server-side - Show the database schema for roles and permissions </constraints>

<context> Platform type: [e.g. SaaS, payment processor, e-commerce] Events to emit: [list the event types — e.g. order.created, payment.failed] Consumer types: [e.g. third-party developers, internal microservices] Expected volume: [e.g. 10K events/day, 1M events/day] </context> <task> Design a webhook delivery system: [DESCRIBE YOUR PLATFORM AND USE CASES] Cover: 1. Event payload schema 2. Delivery mechanism (at-least-once vs exactly-once) 3. Retry strategy with backoff 4. Signature verification (HMAC) 5. Consumer registration and management API 6. Dead letter queue handling 7. Observability — delivery logs and dashboards </task> <constraints> - Always sign payloads — consumers must verify signatures - Retry with exponential backoff, cap at 24 hours - Include idempotency keys so consumers handle duplicates safely - Delivery should be async — never block the main request </constraints>

<context> API type: [REST / GraphQL] Data size: [e.g. up to 10M rows, stable dataset, frequently updated] Sort requirements: [e.g. by date, by relevance score, user-defined] Consumer: [e.g. infinite scroll UI, batch data export, admin table] </context> <task> Design the pagination strategy for this API: [DESCRIBE THE RESOURCE BEING PAGINATED] Cover: 1. Pagination mechanism (cursor vs. offset — recommend with rationale) 2. Request parameters and response envelope 3. How to handle insertions/deletions during pagination 4. Deep pagination performance at scale 5. Total count: when to include it and when not to </task> <constraints> - Cursor pagination for frequently updated data - Offset pagination only for stable data or when jump-to-page is required - Cursors must be opaque to clients — base64 encode internal state - Page size caps: set a maximum, default to a reasonable value - Show example request/response pairs </constraints>

<context> Framework: [e.g. Express, FastAPI, NestJS, Django REST] API version: [e.g. v1] Auth mechanism: [e.g. Bearer JWT, API key header] </context> <task> Generate a complete OpenAPI 3.1 specification for this API: [PASTE ROUTE HANDLERS OR API DESCRIPTION] Include: 1. Info block (title, version, description) 2. Server definitions 3. Security schemes 4. All paths with methods, parameters, request bodies, and responses 5. Reusable schemas in components 6. Error response schemas </task> <constraints> - Use $ref to avoid repeating schemas - Document all response codes, including 4xx and 5xx - Mark required fields explicitly - Add descriptions to all fields, not just types - Output valid YAML </constraints>

<context> API type: [REST / GraphQL] Consumer types: [e.g. mobile apps, third-party integrators, internal clients] Release timeline: [e.g. deploy in 2 weeks, mobile app update cycle is 6 weeks] </context> <task> Analyze these API changes for backward compatibility: Before: [PASTE OLD API CONTRACT / SCHEMA] After: [PASTE NEW API CONTRACT / SCHEMA] For each change: 1. Is it breaking? (yes/no — with explanation) 2. Who is affected and how 3. Migration options for consumers 4. Recommended approach: simultaneous support, versioning, or staged rollout </task> <constraints> - Breaking = any change that requires consumer code to change to avoid errors - Additive changes (new optional fields, new endpoints) are generally safe - Removing fields, changing types, or making optional fields required are always breaking - Factor in mobile app update cycles for your timeline recommendation </constraints>

<context> Language: [LANGUAGE] Test framework: [e.g. Jest, Vitest, pytest, JUnit] Assertion library: [e.g. built-in, Chai, AssertJ] Mocking library: [e.g. Jest mocks, unittest.mock, Mockito] Coverage target: [e.g. 80% line coverage, all public methods] </context> <task> Write unit tests for this code: [PASTE CODE HERE] For each test: 1. Descriptive test name following: "should [behavior] when [condition]" 2. Arrange / Act / Assert structure 3. One assertion per test where possible 4. All edge cases and error paths </task> <constraints> - Test behavior, not implementation — don't test private methods directly - Mock all external dependencies (network, database, filesystem) - Include: happy path, boundary values, null/empty inputs, error conditions - Don't test framework code — test your logic - Each test must be independent and runnable in isolation </constraints>

<context> Framework: [e.g. Express, FastAPI, NestJS] Test framework: [e.g. Supertest + Jest, pytest + httpx] Database: [e.g. PostgreSQL — use test DB or in-memory?] Auth: [e.g. JWT — how to generate test tokens] </context> <task> Write integration tests for these API endpoints: [PASTE ROUTE HANDLERS OR ENDPOINT DESCRIPTIONS] For each endpoint, test: 1. Successful response with valid input 2. Input validation failures (400) 3. Auth failures (401/403) 4. Not found cases (404) 5. Concurrent access if relevant </task> <constraints> - Use a real test database, not mocks — integration tests should hit the actual DB - Reset database state between tests - Test the full HTTP request/response cycle - Include setup and teardown fixtures - Seed realistic test data </constraints>

<context> Project type: [e.g. REST API, React SPA, CLI tool, microservice] Tech stack: [STACK] Team size: [e.g. 4 developers] Current test coverage: [e.g. 0%, 40%, "unit tests only"] Deployment frequency: [e.g. daily, weekly] </context> <task> Design a testing strategy for this project: [DESCRIBE THE PROJECT AND ITS MAIN FEATURES] Define: 1. The testing pyramid — ratio of unit / integration / E2E tests 2. What to test at each level and what not to 3. Recommended frameworks and libraries with rationale 4. CI integration — what runs on PR, what runs on merge 5. Coverage targets by module type 6. How to test the hardest parts (auth, payments, real-time features) </task> <constraints> - Optimize for fast feedback in CI — slow tests don't get run - E2E tests for critical user paths only - Define clear rules for when to write unit vs. integration tests - Include a prioritized backlog for reaching target coverage </constraints>

<context> Language: [LANGUAGE] Test framework: [FRAMEWORK] Domain: [e.g. payment processing, user authentication, file parsing] </context> <task> Generate exhaustive edge case tests for this function: [PASTE FUNCTION CODE HERE] Cover: 1. Boundary values (min, max, min-1, max+1) 2. Empty and null inputs 3. Malformed or unexpected input types 4. Concurrent access scenarios 5. Floating point precision issues (if numeric) 6. Unicode and special characters (if string) 7. Timezone edge cases (if date/time) </task> <constraints> - Each test should target a specific edge — don't combine multiple in one test - Include a comment explaining why each edge case matters - Focus on cases that could cause data corruption or security issues - Don't retest what unit tests already cover </constraints>

<context> Language: [LANGUAGE] Test framework: [e.g. Jest, pytest, Go testing] Mocking library: [e.g. Jest mocks, unittest.mock, testify/mock] Dependencies to mock: [e.g. Stripe API, SendGrid, PostgreSQL, Redis] </context> <task> Set up mocks and stubs for this code's dependencies: [PASTE CODE WITH DEPENDENCIES] Provide: 1. Mock setup for each external dependency 2. Realistic test data that covers the contract of each dependency 3. How to simulate error responses 4. Shared fixtures for reuse across test files 5. How to verify the mock was called correctly </task> <constraints> - Mocks should match the actual interface of the dependency - Include both success and failure scenarios for each mock - Don't over-specify mocks — only assert on calls that matter to the test - Provide factory functions for test data, not hard-coded objects </constraints>

<context> Database: [e.g. PostgreSQL 16] ORM: [e.g. Prisma, SQLAlchemy, GORM] Test framework: [FRAMEWORK] Test database strategy: [e.g. Docker container, in-memory SQLite, shared test DB] </context> <task> Write database integration tests for this repository layer: [PASTE REPOSITORY/DAO CODE] Test: 1. Basic CRUD operations 2. Complex queries with filters and joins 3. Transaction rollback behavior 4. Constraint violations (unique, foreign key, not null) 5. Concurrent writes and optimistic locking 6. Migration compatibility </task> <constraints> - Use transactions to isolate tests and roll back after each - Seed realistic data volumes to catch query performance issues - Test that constraints are enforced, not just the happy path - Include a database setup/teardown fixture </constraints>

<context> Framework: [e.g. Playwright, Cypress, Selenium] Application URL: [local dev URL] Browser targets: [e.g. Chrome, Firefox, Safari] Critical user paths: [list the flows that must never break] </context> <task> Write end-to-end tests for these critical user flows: [DESCRIBE THE USER FLOWS] For each flow: 1. Full step-by-step test script 2. Assertions at each significant step 3. How to handle dynamic content (loading states, async data) 4. Cleanup after each test </task> <constraints> - Test only the critical paths — E2E tests are expensive - Use data-testid attributes for selectors, not CSS classes - Make tests independent — each test creates its own data - Add retries for flaky network interactions - Tests must pass in headless mode for CI </constraints>

<context> Language: [LANGUAGE] Library: [e.g. fast-check, Hypothesis, QuickCheck, proptest] Function type: [e.g. pure function, parser, serializer, sort algorithm] </context> <task> Write property-based tests for this function: [PASTE FUNCTION CODE] For each property: 1. State the property in plain English 2. The generator(s) for input data 3. The property assertion 4. Why this property should always hold </task> <constraints> - Focus on universal properties: commutativity, idempotency, round-trip, invariants - Use realistic generators — not just random bytes - Include at least one shrinking example to show how failures are reported - Complement, don't replace, example-based tests </constraints>

<context> Language: [LANGUAGE] ORM/schema: [e.g. Prisma schema, SQLAlchemy models] Test framework: [FRAMEWORK] Entities needed: [list the main entities — e.g. User, Order, Product] </context> <task> Build a test data factory for these entities: [PASTE SCHEMA OR MODEL DEFINITIONS] Provide: 1. Factory functions for each entity with sensible defaults 2. Override support for specific fields 3. Relationship builders (e.g. createUserWithOrders) 4. Trait/state support (e.g. createUser.admin(), createOrder.cancelled()) 5. Database insertion helpers </task> <constraints> - Defaults should be valid and realistic, not "test", "[email protected]" - Factories must respect database constraints - Make it easy to create related entities in one call - Factories should be composable and reusable across all test files </constraints>

<context> Language: [LANGUAGE] Test framework: [FRAMEWORK] Bug report or incident: [describe the bug that occurred] Affected version: [e.g. v2.3.1] </context> <task> Write regression tests for this bug: Bug description: [DESCRIBE THE BUG] Affected code: [PASTE THE FIXED CODE] Provide: 1. A failing test that reproduces the original bug 2. Confirmation the test passes after the fix 3. Related edge cases that could regress similarly 4. A test name that documents the bug clearly </task> <constraints> - The test must fail on the pre-fix code and pass on the fixed code - Name the test to include the bug/ticket ID for traceability - Cover the exact input that triggered the original bug - Add a comment linking to the incident or ticket </constraints>

<context> Language: [LANGUAGE] Framework: [FRAMEWORK] Environment: [e.g. production, staging, local dev] Recent changes: [any deployments or code changes before this error appeared] Frequency: [e.g. happening on every request, 1% of requests, only under load] </context> <task> Diagnose this stack trace: [PASTE FULL STACK TRACE] Relevant code: [PASTE THE RELEVANT FUNCTION(S)] Provide: 1. What the error means 2. The most likely root cause 3. Step-by-step fix 4. How to verify the fix worked 5. How to prevent this class of error in future </task> <constraints> - Don't just explain the error type — identify the root cause in the pasted code - If multiple causes are possible, rank them by likelihood - If you need more context to be certain, say exactly what additional information would help </constraints>

<context> Language: [LANGUAGE] Runtime: [e.g. Node.js 20, JVM 21, Python 3.12] Symptoms: [e.g. memory grows 50MB/hour, OOM after 6 hours] Profiling data: [paste heap snapshot summary or memory profiler output if available] Load pattern: [e.g. 200 req/min, batch job running hourly] </context> <task> Help me find the memory leak in this code: [PASTE CODE / RELEVANT MODULES] Identify: 1. The likely leak source(s) 2. Why the memory isn't being released 3. The fix 4. How to verify the leak is resolved using profiling tools </task> <constraints> - Check for: unclosed resources, event listener accumulation, circular references, growing caches without eviction, closures holding large objects - Show before/after code for the fix - Recommend the specific profiling command to confirm the fix </constraints>

<context> Language: [LANGUAGE] Concurrency model: [e.g. async/await, threads, goroutines] Symptoms: [e.g. intermittent data corruption, occasional 500s under load, test passes locally but fails in CI] Reproduction rate: [e.g. 1 in 50 runs, only under 100 concurrent users] </context> <task> Find and fix the race condition in this code: [PASTE CODE] Provide: 1. The exact sequence of events that causes the race 2. Why it's hard to reproduce (timing sensitivity) 3. The fix 4. A test that can reliably detect this race </task> <constraints> - Draw a timeline diagram showing the interleaved execution if helpful - The fix should be minimal — don't introduce unnecessary locking - If a database transaction can solve it, prefer that over application-level locks - Explain why the fix eliminates the race, not just that it does </constraints>

<context> Language: [LANGUAGE] Test framework: [FRAMEWORK] When did it start failing: [e.g. after a specific commit, always been flaky, failing since dependency upgrade] CI environment details: [e.g. Ubuntu, Node 20, timezone UTC] </context> <task> Fix this failing test: Test code: [PASTE TEST] Implementation code: [PASTE IMPLEMENTATION] Test output: [PASTE FULL TEST FAILURE OUTPUT] Determine: 1. Is the test wrong or is the implementation wrong? 2. What exactly is failing and why? 3. The fix — test code, implementation, or both 4. If it's a flaky test, how to make it deterministic </task> <constraints> - Don't fix a test by weakening its assertions — that just hides the bug - If the implementation is wrong, fix the implementation - For flaky tests: eliminate time dependencies, random data, and shared state </constraints>

<context> Client: [e.g. React app, mobile app, backend service] Server: [e.g. REST API, third-party service] Protocol: [HTTP/HTTPS, WebSocket, gRPC] Error observed: [e.g. CORS error, 401 on specific endpoints, timeout after 30s] </context> <task> Debug this network/API issue: Request details: [PASTE CURL COMMAND, REQUEST CODE, OR NETWORK TAB SCREENSHOT DESCRIPTION] Response received: [PASTE RESPONSE OR ERROR] Diagnose: 1. What's causing the error 2. Is it a client-side or server-side issue 3. Step-by-step fix 4. How to verify it's resolved </task> <constraints> - For CORS: explain which header is missing and why - For auth errors: check token format, expiry, and header name - For timeouts: distinguish between connection timeout vs. read timeout - Provide the exact code or header change needed </constraints>

<context> Browser: [e.g. Chrome 124, Safari 17] Framework: [e.g. Tailwind, plain CSS, styled-components] Screen size: [e.g. issue on mobile only, all sizes, 1280px viewport] Expected behavior: [describe what it should look like] Actual behavior: [describe what you're seeing] </context> <task> Debug this CSS layout issue: HTML: [PASTE HTML] CSS: [PASTE CSS] Diagnose: 1. What's causing the layout to break 2. Why the browser is rendering it this way 3. The fix with corrected CSS 4. Cross-browser considerations </task> <constraints> - Explain the box model, stacking context, or flexbox/grid rule that's causing the issue - Fix the root cause — don't use magic numbers or negative margins to compensate - Test the fix against the stated browser and screen size </constraints>

<context> Database: [e.g. PostgreSQL 16] Table sizes: [e.g. orders: 5M rows, customers: 200K rows] Current query time: [e.g. 8 seconds] Target query time: [e.g. under 200ms] Existing indexes: [paste d tablename output or index list] </context> <task> Debug and fix this slow query: Query: [PASTE SQL QUERY] EXPLAIN ANALYZE output (if available): [PASTE EXPLAIN ANALYZE] Diagnose: 1. Why the query is slow 2. Which part of the execution plan is the bottleneck 3. Exact indexes to create (CREATE INDEX statements) 4. Query rewrite if needed 5. Expected performance after the fix </task> <constraints> - Show the EXPLAIN ANALYZE interpretation, not just the fix - Specify index type: B-tree, GIN, partial, composite - Consider write performance cost of new indexes - If the query can't be made fast, suggest an alternative architecture (materialized view, denormalization) </constraints>

<context> Language: [LANGUAGE] System components involved: [e.g. API → queue → worker → database → webhook] Input: [describe the data entering the system] Expected output: [describe what should come out] Actual output: [describe what's actually happening — wrong value, missing data, corruption] </context> <task> Trace this data flow to find where it goes wrong: [PASTE RELEVANT CODE ACROSS THE PIPELINE] For each stage: 1. What data enters 2. What transformation happens 3. What data exits 4. Where the data could be getting corrupted or lost </task> <constraints> - Follow the data from input to output step by step - Identify every transformation, serialization, and type conversion - Flag any implicit type coercions or lossy conversions - Show what to log at each stage to verify the fix </constraints>

<context> Auth mechanism: [e.g. JWT, session cookies, OAuth2, API keys] Framework: [FRAMEWORK] Error: [e.g. 401 on all requests, token expires immediately, login loop] When it started: [e.g. after dependency upgrade, after env change, intermittent] </context> <task> Debug this authentication failure: Auth middleware/code: [PASTE AUTH CODE] Token generation code: [PASTE TOKEN GENERATION] Error/symptom: [DESCRIBE IN DETAIL] Diagnose: 1. What's failing and at which step 2. The most likely cause 3. How to verify the diagnosis 4. The fix </task> <constraints> - Check: token expiry, clock skew, signing key mismatch, cookie attributes, CORS headers - Trace the full auth lifecycle: issue → transport → validate - Don't suggest disabling auth checks as a debugging step </constraints>

<context> Incident type: [e.g. production outage, data loss, performance degradation] Duration: [e.g. 45 minutes] Impact: [e.g. 20% of users affected, all writes failed] Timeline: [list events with timestamps] </context> <task> Perform a root cause analysis for this incident: Incident description: [DESCRIBE WHAT HAPPENED] Available evidence: [PASTE LOGS, METRICS, ALERTS] Using the 5 Whys method: 1. Walk through each "Why" level 2. Identify the true root cause (not just the proximate cause) 3. Distinguish between root cause, contributing factors, and triggers 4. Propose fixes at each level 5. Suggest monitoring to detect recurrence </task> <constraints> - The root cause is never "human error" — find the systemic condition that made error possible - Propose both immediate fix and long-term prevention - Include a postmortem action item list with owners and deadlines </constraints>

<context> Product type: [e.g. SaaS B2B, consumer mobile app, internal tool] Scale targets: [e.g. 10K users at launch, 1M users in 2 years] Team size: [e.g. 3 engineers] Budget constraints: [e.g. early-stage, minimize infrastructure cost] Non-functional requirements: [e.g. 99.9% uptime, GDPR compliance, sub-200ms response time] </context> <task> Design the system architecture for this product: [DESCRIBE THE PRODUCT AND ITS MAIN FEATURES] Provide: 1. Component diagram description 2. Technology choices with rationale 3. Data flow between components 4. How the architecture scales to the stated targets 5. What you'd build differently at 10x scale 6. The biggest architectural risks and mitigations </task> <constraints> - Match complexity to team size — a 3-person team shouldn't operate Kubernetes - Optimize for shipping speed at early stage, for scale at later stage - Explicitly state what's out of scope for v1 - Prefer managed services over self-hosted where practical </constraints>

<context> Current state: [e.g. monolith, planning new system, existing microservices with pain points] Team structure: [e.g. 5 engineers on one team, 3 teams of 8] Deployment frequency: [e.g. once a week, multiple times daily] Main pain points: [e.g. slow deployments, scaling bottleneck, team coordination] </context> <task> Advise on monolith vs. microservices for this situation: [DESCRIBE THE SYSTEM AND CONTEXT] Cover: 1. Recommendation with rationale specific to this context 2. The specific benefits and costs of each approach here 3. If microservices: service decomposition boundaries 4. If monolith: how to structure it for future extraction 5. Migration path if changing approaches </task> <constraints> - Don't give a generic answer — tie the recommendation to the stated team and scale - Microservices have real operational costs: quantify them - "Modular monolith first" is often the right answer — say so if appropriate - If recommending microservices, define the service boundaries explicitly </constraints>

<context> Database: [e.g. PostgreSQL 16] Domain: [e.g. multi-tenant SaaS, e-commerce, healthcare records] Scale: [e.g. 100K users, 50M events/month] Access patterns: [describe the main queries — reads and writes] </context> <task> Design the database schema for this system: [DESCRIBE THE DOMAIN AND ENTITIES] Provide: 1. Complete table definitions with types and constraints 2. Primary and foreign key strategy 3. Index strategy based on stated access patterns 4. Multi-tenancy isolation approach (if applicable) 5. Soft delete strategy (if needed) 6. Audit trail approach (if needed) </task> <constraints> - Normalize to 3NF by default, denormalize only where access patterns require it - UUIDs vs. serial integers — recommend based on use case - Timestamps: always store in UTC - Index every foreign key - Show the schema as valid SQL DDL </constraints>

<context> System type: [e.g. e-commerce, fintech, IoT platform] Current pain points: [e.g. tight coupling, scaling bottlenecks, temporal dependencies] Scale: [e.g. 10K events/sec, 1M events/day] Infrastructure: [e.g. AWS, GCP, self-hosted, Kafka, RabbitMQ available] </context> <task> Design an event-driven architecture for this system: [DESCRIBE THE SYSTEM AND ITS PROCESSES] Cover: 1. Event taxonomy (domain events, commands, integration events) 2. Event schema design and versioning 3. Message broker choice with rationale 4. Consumer group strategy 5. Error handling: dead letter queues, retry policy 6. Idempotency handling 7. Observability: event tracing and monitoring </task> <constraints> - Define the event contract clearly — events are a public API - Address eventual consistency explicitly: what UI/UX does it require? - Don't use events where a simple synchronous call is clearer - Show a concrete example for the most complex flow </constraints>

<context> Application type: [e.g. read-heavy API, real-time dashboard, e-commerce] Current performance issue: [e.g. DB CPU at 90%, p99 latency 2s] Data characteristics: [e.g. user profiles change rarely, product catalog updated hourly, prices change per-request] Infrastructure: [e.g. Redis available, CDN available, no additional infrastructure] </context> <task> Design a caching strategy for this system: [DESCRIBE THE SYSTEM AND ITS DATA ACCESS PATTERNS] For each cache layer: 1. What data to cache 2. Where to cache it (CDN, application, database) 3. Cache key design 4. TTL strategy 5. Invalidation approach 6. Consistency guarantees </task> <constraints> - Don't cache user-specific data in shared caches - Cache invalidation is the hard part — explain it explicitly - Estimate the cache hit ratio you expect - For financial or inventory data: explain consistency tradeoffs carefully </constraints>

<context> Product type: [e.g. B2B SaaS, mobile app, data pipeline] Team existing skills: [e.g. Python, Java, JavaScript] Scale requirements: [e.g. launch with 100 users, scale to 100K] Time to market: [e.g. MVP in 3 months] Budget: [e.g. bootstrapped, seed-funded, enterprise budget] </context> <task> Recommend a tech stack for this product: [DESCRIBE THE PRODUCT AND ITS REQUIREMENTS] For each layer (frontend, backend, database, infrastructure): 1. Recommended choice 2. Why it fits this specific context 3. The main alternative and when you'd choose it instead 4. Key risks and mitigations </task> <constraints> - Match the stack to the team's existing skills — retraining time is a real cost - Boring technology is often the right choice — don't recommend new tech for its own sake - Consider hiring: can you find engineers for this stack? - Estimate operational cost at stated scale </constraints>

<context> Source control: [e.g. GitHub, GitLab, Bitbucket] Deployment target: [e.g. AWS ECS, Kubernetes, Heroku, VPS] Team size: [e.g. 4 engineers] Deployment frequency goal: [e.g. multiple times daily, weekly releases] Current pain points: [e.g. slow builds, manual deployments, flaky tests blocking deploys] </context> <task> Design a CI/CD pipeline for this project: [DESCRIBE THE APPLICATION AND DEPLOYMENT REQUIREMENTS] Define: 1. Pipeline stages and what runs at each stage 2. PR checks vs. merge checks vs. deploy pipeline 3. Test parallelization strategy 4. Deployment strategy (blue/green, canary, rolling) 5. Rollback mechanism 6. Secrets management in CI 7. Estimated pipeline run time </task> <constraints> - PR pipeline must complete in under 5 minutes — fast feedback is critical - Never put secrets in pipeline YAML files - Deployment should be one command or one button - Include a rollback procedure that takes under 2 minutes </constraints>

<context> Current architecture: [describe your current setup] Current scale: [e.g. single server, handling 500 req/min] Target scale: [e.g. 50K req/min, 10x current] Current bottleneck: [e.g. CPU bound, database connections, in-memory session state] </context> <task> Design the path to horizontal scaling for this system: [DESCRIBE THE CURRENT ARCHITECTURE] Address: 1. Current bottlenecks that prevent horizontal scaling 2. What needs to be made stateless 3. Database scaling strategy (read replicas, sharding, connection pooling) 4. Session and cache distribution 5. Load balancing strategy 6. The step-by-step migration plan </task> <constraints> - Identify what needs to change before adding more instances - Stateful components (sessions, file storage, queues) must be externalized first - Database connections per instance × instance count must not exceed DB limits - Provide a migration path that doesn't require downtime </constraints>

<context> Decision to document: [e.g. "switch from REST to GraphQL", "adopt Kafka for event streaming"] Decision status: [Proposed / Accepted / Deprecated] Decision makers: [who was involved] </context> <task> Write an Architecture Decision Record (ADR) for this decision: Context and problem: [DESCRIBE THE PROBLEM BEING SOLVED] Options considered: [LIST THE OPTIONS EVALUATED] Write the ADR with: 1. Title (ADR-NNN: Short noun phrase) 2. Status 3. Context (problem and forces) 4. Decision (what was decided and why) 5. Consequences (positive, negative, neutral) 6. Alternatives considered and why they were rejected </task> <constraints> - An ADR is a record of a decision, not a proposal — write in past/present tense - Be honest about the negative consequences - Future readers should understand why this was right for the time, even if circumstances change - Keep it under 1 page </constraints>

<context> Data sources: [e.g. PostgreSQL, Kafka events, third-party APIs, S3 files] Destination: [e.g. data warehouse, analytics DB, ML feature store] Volume: [e.g. 10GB/day, 1M events/hour] Latency requirement: [e.g. real-time, near-real-time <5min, daily batch] Infrastructure: [e.g. AWS, GCP, Azure, self-hosted] </context> <task> Design a data pipeline for this use case: [DESCRIBE THE DATA AND BUSINESS REQUIREMENTS] Cover: 1. Pipeline architecture (batch, streaming, lambda, kappa) 2. Technology choices with rationale 3. Data transformation strategy (ELT vs. ETL) 4. Schema evolution handling 5. Error handling and data quality checks 6. Monitoring and alerting 7. Estimated cost at stated volume </task> <constraints> - Match latency requirement to pipeline type — don't use streaming for batch use cases - Data quality checks must happen before data reaches consumers - Plan for schema changes in the source systems - Include idempotent reprocessing capability </constraints>

<context> Project type: [e.g. open source library, internal tool, API service, CLI] Target audience: [e.g. external developers, internal team, end users] Tech stack: [STACK] </context> <task> Write a README for this project: [DESCRIBE THE PROJECT OR PASTE KEY CODE/CONFIG] Include: 1. One-line description 2. Why it exists (problem it solves) 3. Quick start (get it running in under 5 minutes) 4. Installation 5. Usage with realistic examples 6. Configuration reference 7. Contributing guide (if open source) 8. License </task> <constraints> - The quick start should work copy-paste — test every command - Lead with value, not with implementation details - Use code blocks with language hints for all code samples - No badges unless they provide real information </constraints>

<context> API type: [REST / GraphQL / SDK] Audience: [e.g. third-party developers, internal team] Format: [e.g. Markdown, OpenAPI, JSDoc] Existing docs: [none / partial — describe what exists] </context> <task> Write API documentation for these endpoints: [PASTE ROUTE HANDLERS, SCHEMA, OR ENDPOINT DESCRIPTIONS] For each endpoint/method: 1. Purpose (one sentence) 2. Request: method, URL, headers, parameters, body schema 3. Response: status codes, body schema 4. Error responses with codes 5. A working code example in [LANGUAGE] </task> <constraints> - Show realistic values in examples, not "string" or 123 - Document every possible error response - Code examples must be copy-pasteable and correct - Mark deprecated endpoints clearly </constraints>

<context> Language: [e.g. TypeScript, Python, Java] Doc format: [e.g. JSDoc, Google docstrings, NumPy docstrings] Generator tool: [e.g. TypeDoc, Sphinx, Javadoc] </context> <task> Write documentation comments for these functions/classes: [PASTE CODE HERE] For each function/class: 1. Summary (one sentence describing what it does) 2. All parameters with types and descriptions 3. Return value and type 4. Exceptions/errors thrown 5. Usage example 6. Any gotchas or important behavior notes </task> <constraints> - Don't restate the code — explain intent and behavior - Document edge cases: what happens on null input, empty array, etc. - Use the exact doc format for the stated tool - Examples must be minimal and correct </constraints>

<context> Audience: [e.g. engineering team, cross-functional stakeholders] Scope: [e.g. new feature, system redesign, API change] Timeline: [e.g. 6-week implementation] </context> <task> Write a technical design document for this feature: [DESCRIBE THE FEATURE OR SYSTEM CHANGE] Include: 1. Problem statement 2. Goals and non-goals 3. Proposed solution with rationale 4. Alternative approaches considered 5. System design (components, data flow, API changes) 6. Data model changes 7. Migration plan 8. Testing strategy 9. Open questions 10. Timeline and milestones </task> <constraints> - Non-goals are as important as goals — be explicit - The document should enable an engineer to start implementation without asking questions - Alternatives section must explain why they were rejected, not just list them - Open questions should have an owner and a deadline </constraints>

<context> Role: [e.g. backend engineer, full-stack developer] System complexity: [e.g. monolith, 5 microservices, 3 external integrations] Existing documentation: [describe what exists] Typical onboarding pain points: [what takes new engineers the longest to understand] </context> <task> Write a developer onboarding guide for this codebase: [DESCRIBE THE SYSTEM ARCHITECTURE AND KEY COMPONENTS] Cover: 1. System overview — what it does and why 2. Local dev environment setup (step-by-step) 3. Architecture overview with key components 4. How to make a change and deploy it 5. Common tasks with examples (add an endpoint, add a migration, etc.) 6. How to debug common issues 7. Who to ask when stuck </task> <constraints> - Every setup step must have a success verification command - Anticipate the top 5 things new engineers get stuck on - Link to relevant code files by path, not by description - The guide should get a new engineer making their first commit in one day </constraints>

<context> Project name: [PROJECT NAME] Version: [e.g. v2.4.0] Audience: [e.g. end users, developers, internal team] Format: [e.g. Keep a Changelog, GitHub releases, internal] </context> <task> Generate a changelog entry for this release: [PASTE GIT LOG OR LIST OF CHANGES] Format the changes as: - Added: new features - Changed: modifications to existing behavior - Deprecated: features to be removed - Removed: features that were removed - Fixed: bug fixes - Security: security patches For each entry: 1. User-facing description (not a commit message) 2. Upgrade notes if behavior changed 3. Migration steps if breaking changes </task> <constraints> - Write for the reader, not the developer — explain impact, not implementation - Breaking changes must be prominently marked - Don't include internal refactors that don't affect users - Keep each entry to one sentence </constraints>

<context> OS targets: [e.g. macOS, Ubuntu 22.04, Windows WSL2] Tech stack: [STACK] External services: [e.g. Stripe test account, AWS credentials, SendGrid] </context> <task> Write a local development environment setup guide: [DESCRIBE THE PROJECT AND ITS DEPENDENCIES] Cover: 1. Prerequisites with version requirements 2. Step-by-step installation 3. Environment variable setup with .env.example 4. Database setup and seeding 5. Running the development server 6. Running tests 7. Common setup errors and fixes </task> <constraints> - Every step must have a success verification command - Include the exact error messages for common failures, not just "it might not work" - Never put real credentials in examples — use placeholder values - Specify exact versions for all dependencies </constraints>

<context> System: [describe the production system] On-call audience: [e.g. engineers who may not know the system deeply] Critical paths: [e.g. checkout flow, auth service, data pipeline] Monitoring stack: [e.g. Datadog, Grafana, CloudWatch] </context> <task> Write a production runbook for this system: [DESCRIBE THE SYSTEM AND KNOWN FAILURE MODES] Include for each operation: 1. When to perform it (trigger conditions) 2. Step-by-step procedure with exact commands 3. Expected output at each step 4. How to verify success 5. Rollback procedure 6. Escalation path Operations to cover: - Restart service - Roll back deployment - Scale up/down - Clear cache - Handle database failover </task> <constraints> - Commands must be copy-pasteable — no pseudocode - Include the exact metrics and thresholds that trigger each procedure - Runbook must be usable by someone who doesn't know the system - Every procedure must have a "success" and "still broken" path </constraints>

<context> Diagram type: [e.g. system context, component, sequence, deployment] Audience: [e.g. engineers, non-technical stakeholders, new hires] Format: [e.g. Mermaid, PlantUML, text description for Lucidchart] </context> <task> Generate architecture diagram code for this system: [DESCRIBE THE SYSTEM ARCHITECTURE] Produce: 1. The diagram code in the specified format 2. A legend explaining any non-obvious notation 3. Key observations the diagram highlights </task> <constraints> - Keep diagrams focused — one diagram per concern - Use standard C4 model notation if doing context/component diagrams - Label all arrows with the protocol or data type - Don't try to show everything in one diagram </constraints>

<context> Migration type: [e.g. v1 to v2 API, library upgrade, database schema change] Audience: [e.g. external API consumers, internal developers] Breaking changes: [list what changed] Migration effort estimate: [e.g. 1 hour, 1 day, 1 week] </context> <task> Write a migration guide for this change: Before (v1): [PASTE OLD API / CODE / SCHEMA] After (v2): [PASTE NEW API / CODE / SCHEMA] Cover: 1. Summary of what changed and why 2. Step-by-step migration instructions 3. Before/after code examples for each breaking change 4. Automated migration tools if available 5. How to run old and new versions in parallel during transition 6. Deadline for old version deprecation </task> <constraints> - Every breaking change must have a before/after code example - Include a migration checklist readers can check off - Estimate the effort required per change type - Provide a way to validate the migration succeeded </constraints>

<context> Language: [LANGUAGE] Runtime: [e.g. Node.js 20, Python 3.12] Profiling data: [paste profiler output, or describe: "called 10K times, avg 80ms"] Input characteristics: [e.g. array of 10K items, nested object 5 levels deep] </context> <task> Optimize this function for performance: [PASTE FUNCTION CODE] Provide: 1. Identify the bottleneck (algorithmic, I/O, memory allocation, etc.) 2. The optimized implementation 3. Time/space complexity before and after 4. Any tradeoffs (readability, memory for speed, etc.) 5. How to benchmark the improvement </task> <constraints> - Don't optimize at the cost of correctness — verify edge cases are preserved - Prefer algorithmic improvements over micro-optimizations - If the bottleneck is I/O, restructuring beats micro-optimization - Include the benchmark command to verify improvement </constraints>

<context> Application: [describe your system] Expensive operation: [e.g. DB query taking 500ms, third-party API call] Data characteristics: [e.g. per-user data, global catalog, session data] Cache infrastructure: [e.g. Redis, Memcached, in-memory, CDN] Consistency requirement: [e.g. eventual OK, must be fresh within 30 seconds] </context> <task> Design a caching layer for this operation: [PASTE THE CODE TO CACHE] Design: 1. Cache key schema 2. TTL and expiration strategy 3. Cache-aside, write-through, or write-behind — choose and justify 4. Cache invalidation on data change 5. Cache stampede prevention 6. Implementation code </task> <constraints> - Cache stampede (dog-pile effect) must be addressed - User-specific data must never bleed between users - Show the cache hit/miss code path - Include monitoring: what metrics to track </constraints>

<context> Database: [e.g. PostgreSQL 16] ORM: [e.g. Prisma, raw SQL] Table sizes: [e.g. orders: 8M rows] EXPLAIN ANALYZE: [paste if available] Current query time: [e.g. 3.2 seconds] </context> <task> Optimize these database queries: [PASTE QUERIES OR ORM CODE] For each query: 1. Current execution plan bottleneck 2. Exact CREATE INDEX statements 3. Optimized query rewrite 4. Expected improvement 5. Any data model changes that would help long-term </task> <constraints> - Show CREATE INDEX with all options (CONCURRENTLY, partial conditions, composite columns) - If N+1: show the batched replacement - Consider index bloat on write-heavy tables - If a query cannot be made fast, propose materialized view or denormalization </constraints>

<context> Framework: [e.g. React, Next.js, Vue] Target metrics: [e.g. LCP < 2.5s, FID < 100ms, CLS < 0.1] Current Lighthouse score: [if available] Device target: [e.g. mobile on 4G, desktop broadband] </context> <task> Perform a performance audit of this frontend code: [PASTE COMPONENT CODE, BUILD CONFIG, OR DESCRIBE THE PAGE] Identify and fix: 1. Render-blocking resources 2. Unnecessary re-renders 3. Large bundle imports 4. Missing code splitting 5. Unoptimized images 6. Layout shifts 7. Missing memoization </task> <constraints> - Prioritize by Core Web Vitals impact - Show the React DevTools or bundle analyzer finding alongside the fix - Code splitting: show the exact dynamic import syntax - Memoization: only where it actually saves renders </constraints>

<context> Framework: [e.g. React, Next.js, Vue] Bundler: [e.g. webpack, Vite, Rollup] Current bundle size: [e.g. 1.2MB gzipped main chunk] Bundle analyzer output: [paste top modules by size if available] </context> <task> Reduce the JavaScript bundle size for this application: [PASTE PACKAGE.JSON AND/OR KEY IMPORT PATTERNS] Identify: 1. Largest dependencies and whether they can be replaced 2. Tree-shaking opportunities (bad: import lodash, good: import debounce from lodash/debounce) 3. Code splitting opportunities with exact dynamic import code 4. Dependencies used only server-side that are leaking to the client 5. Duplicate dependencies </task> <constraints> - Show exact before/after import syntax for each fix - Estimate size reduction for each recommendation - Don't replace stable dependencies with obscure alternatives - Test that tree-shaking is actually working — many libraries claim it but don't </constraints>

<context> Framework: [e.g. Express, FastAPI, NestJS] Current p50/p99: [e.g. 200ms / 1.8s] Target p99: [e.g. 300ms] Profiling available: [e.g. APM traces, yes/no] </context> <task> Optimize the response time of this API endpoint: [PASTE ROUTE HANDLER AND CALLED FUNCTIONS] Analyze and fix: 1. Serial operations that can be parallelized 2. Unnecessary data loading (overfetching from DB) 3. Missing DB indexes for this query path 4. N+1 query patterns 5. Synchronous operations that should be async 6. Response payload size (projection, pagination) </task> <constraints> - Parallelize independent operations with Promise.all or equivalent - Reduce DB round trips first — they dominate latency - Show the before/after execution timeline - Don't add caching without defining invalidation </constraints>

<context> Language: [LANGUAGE] Runtime: [e.g. Node.js, JVM, Python] Memory limit: [e.g. container limited to 512MB] Current usage: [e.g. peaks at 900MB, OOM after processing 10K records] Data volume: [e.g. processes files up to 5GB, 1M objects in memory] </context> <task> Optimize memory usage in this code: [PASTE CODE] Identify and fix: 1. Large objects loaded fully when streaming would work 2. Unnecessary data copies 3. Objects held in memory longer than needed 4. Memory-inefficient data structures 5. Missing pagination on large data sets </task> <constraints> - Stream large data instead of loading into memory - Show memory before/after estimates - Buffer/batch size should be tunable, not hardcoded - Don't sacrifice error handling for memory savings </constraints>

<context> Framework: [e.g. React, Vue, Angular] Type of lazy loading needed: [e.g. route-level, component, images, data] Current behavior: [e.g. all components bundled in main chunk, all images load on page load] Target: [e.g. reduce initial load by 40%] </context> <task> Implement lazy loading for this application: [PASTE CURRENT ROUTING/COMPONENT CODE] Implement: 1. Route-level code splitting with dynamic imports 2. Component lazy loading with loading fallbacks 3. Image lazy loading with placeholder strategy 4. Data lazy loading on scroll or interaction 5. Prefetching strategy for likely-next resources </task> <constraints> - Show exact dynamic import syntax for your framework - Loading fallbacks must prevent layout shift - Prefetch on hover/focus, not on page load - Don't lazy-load above-the-fold content </constraints>

<context> Language: [LANGUAGE] Current throughput: [e.g. 500 records/second] Target throughput: [e.g. 5,000 records/second] Data source: [e.g. PostgreSQL, S3 CSV, Kafka] Bottleneck: [e.g. DB writes, CPU processing, I/O] </context> <task> Optimize this batch processing job: [PASTE PROCESSING CODE] Improve: 1. Batch size tuning 2. Parallel processing with worker pools 3. DB bulk operations instead of row-by-row 4. Memory-efficient streaming 5. Checkpointing for resumable processing 6. Progress reporting </task> <constraints> - Bulk DB inserts/updates are always faster than row-by-row - Worker pool size should be tunable, not hardcoded - Include checkpointing so the job can resume after failure - Show before/after throughput estimate </constraints>

<context> Language: [LANGUAGE] Benchmark framework: [e.g. Benchmark.js, criterion, pytest-benchmark, JMH] What to benchmark: [describe the function or operation] Comparison: [e.g. old vs. new implementation, algorithm A vs. B] </context> <task> Write a performance benchmark for this code: [PASTE CODE TO BENCHMARK] Provide: 1. Benchmark setup that eliminates JIT warmup bias 2. Multiple input sizes to show scaling behavior 3. Statistical correctness (multiple runs, confidence intervals) 4. Memory allocation measurement where relevant 5. Interpretation: what the numbers mean for production </task> <constraints> - Prevent dead code elimination — use benchmark results - Include warmup iterations before measuring - Test at multiple input sizes, not just one - Translate microbenchmark results into real-world impact estimates </constraints>

<context> Application type: [e.g. SaaS web app, public API, internal tool] Tech stack: [STACK] Data sensitivity: [e.g. PII, financial data, health records] Compliance requirements: [e.g. SOC 2, HIPAA, PCI-DSS, GDPR] Last security review: [e.g. never, 6 months ago] </context> <task> Perform a security audit of this codebase: [PASTE CODE OR DESCRIBE THE SYSTEM] Check for: 1. OWASP Top 10 vulnerabilities 2. Authentication and authorization flaws 3. Input validation gaps 4. Sensitive data exposure 5. Dependency vulnerabilities 6. Security misconfigurations 7. Secrets in code or config For each finding: severity, exploit scenario, and fix. </task> <constraints> - Focus on exploitable findings, not theoretical risks - Compliance gaps should map to specific controls (SOC 2 CC6, PCI DSS 6.3, etc.) - Rank by CVSS score or practical impact - Provide a prioritized remediation backlog </constraints>

<context> Application type: [e.g. SaaS, B2C mobile app, API] Auth requirements: [e.g. social login, SSO/SAML, MFA, magic links] Compliance: [e.g. SOC 2, HIPAA] Tech stack: [STACK] </context> <task> Design a secure authentication system for this application: [DESCRIBE THE PRODUCT AND USER TYPES] Cover: 1. Registration and login flow 2. Token strategy (access + refresh tokens) 3. MFA implementation 4. Password storage (hashing algorithm and parameters) 5. Session invalidation 6. Brute force and credential stuffing protection 7. Account recovery flow security </task> <constraints> - Passwords: bcrypt with cost factor 12 or Argon2id - Access tokens: short-lived (15 min), never stored client-side in localStorage - Refresh tokens: rotate on use, store hash in DB - Rate limit all auth endpoints - Account recovery must not be weaker than the primary auth </constraints>

<context> Language: [LANGUAGE] Framework: [FRAMEWORK] Input sources: [e.g. HTTP request body, query params, file uploads, webhook payloads] Validation library: [e.g. Zod, Joi, Pydantic, manual] </context> <task> Implement comprehensive input validation for these endpoints: [PASTE ROUTE HANDLERS OR DESCRIBE INPUTS] For each input: 1. Type validation 2. Format validation (regex, enum, range) 3. Business rule validation 4. Sanitization where needed 5. Error messages that are helpful but not exploitable </task> <constraints> - Validate on ingress — never trust external input - Server-side validation is mandatory even if client-side exists - Error messages must not leak schema or internal details - File uploads: validate type by magic bytes, not extension - Reject unexpected fields — don't silently ignore them </constraints>

<context> Language: [LANGUAGE] Database: [e.g. PostgreSQL, MySQL] Frontend framework: [e.g. React, Vue, plain HTML] User input surfaces: [e.g. search, comments, profile fields, file names] </context> <task> Review this code for SQL injection and XSS vulnerabilities: [PASTE CODE] For each vulnerability: 1. Exact location 2. Attack vector with a concrete payload example 3. Severity and impact 4. The secure replacement code </task> <constraints> - SQL injection: parameterized queries are the fix — not escaping - Stored XSS: find where user content is persisted and where it's rendered - Reflected XSS: find where input echoes back in responses - DOM XSS: find innerHTML, document.write, eval with user data - Show the exploit payload and the sanitized output </constraints>

<context> Application type: [e.g. multi-tenant SaaS, internal tool] User types: [describe roles — e.g. owner, admin, member, viewer, billing-only] Resource types: [e.g. projects, documents, team members, billing] Multi-tenancy: [yes/no — describe isolation requirements] </context> <task> Design a role-based access control system: [DESCRIBE THE PERMISSION REQUIREMENTS] Provide: 1. Role and permission taxonomy 2. Database schema for roles and permissions 3. Permission check implementation 4. Middleware/decorator for enforcing access 5. How to handle cross-tenant access 6. Audit logging for access decisions </task> <constraints> - Default deny: if no explicit permission, access is denied - Permissions must be checked server-side, every time - Tenant isolation must be enforced at the query level, not just application level - Show how permission checks compose for nested resources </constraints>

<context> Infrastructure: [e.g. AWS, GCP, self-hosted, Docker Swarm] Current approach: [e.g. .env files, hardcoded, environment variables] Secrets types: [e.g. DB passwords, API keys, JWT secrets, TLS certificates] Team size: [e.g. 5 engineers] Compliance: [e.g. SOC 2, PCI-DSS] </context> <task> Design a secrets management system for this infrastructure: [DESCRIBE YOUR CURRENT SETUP AND PAIN POINTS] Cover: 1. Secrets storage and retrieval (vault solution) 2. Secrets rotation strategy per secret type 3. Access control (who/what can access which secret) 4. Audit logging 5. CI/CD integration — how secrets reach the pipeline 6. Developer workflow — how engineers use secrets locally 7. Incident response if a secret is compromised </task> <constraints> - Never store secrets in version control, even encrypted - Secrets in environment variables are better than hardcoded, but not a complete solution - Define rotation frequency by secret risk level - Every secret access must be auditable </constraints>

<context> Application type: [e.g. SPA with separate API, server-rendered app, public API] Frontend origin(s): [e.g. https://app.example.com] API origin: [e.g. https://api.example.com] Third-party resources: [e.g. Google Fonts, Stripe.js, Intercom, analytics] </context> <task> Configure CORS and Content Security Policy for this application: [DESCRIBE THE APPLICATION ARCHITECTURE] Provide: 1. CORS configuration (allowed origins, methods, headers, credentials) 2. CSP header with all required directives 3. How to handle CDN and third-party scripts in CSP 4. Nonce or hash strategy for inline scripts 5. Report-only mode for testing CSP before enforcing </task> <constraints> - Never use wildcard (*) origins with credentials: true - CSP should block inline scripts except via nonce - Start with report-only, then enforce - Provide the exact header values, not just directive descriptions - Include frame-ancestors to prevent clickjacking </constraints>

<context> Service: [describe the system with API keys] Key types: [e.g. customer API keys, internal service keys, third-party API keys] Current rotation: [e.g. never rotated, rotated manually, no process] Key usage: [e.g. 10K keys issued, used in customer integrations, webhooks] </context> <task> Design an API key rotation system: [DESCRIBE THE KEY MANAGEMENT REQUIREMENTS] Cover: 1. Key format and structure (prefix, entropy, checksum) 2. Storage: hash the key, never store plaintext 3. Rotation workflow — how to rotate without breaking integrations 4. Overlapping validity windows for zero-downtime rotation 5. Key revocation and emergency rotation 6. Audit logging per key usage </task> <constraints> - Never store API keys in plaintext — store a hash, show the key once - Keys must be revocable immediately - Support key prefixes for easy identification (e.g. sk_live_, pk_test_) - Rotation must not require downtime for the key owner </constraints>

<context> Language: [LANGUAGE] Package manager: [e.g. npm, pip, cargo, go mod] Deployment environment: [e.g. production server, Docker container] </context> <task> Analyze these dependencies for security vulnerabilities: [PASTE package.json, requirements.txt, go.mod, OR EQUIVALENT] For each vulnerable dependency: 1. CVE identifier 2. Vulnerability description 3. CVSS score and severity 4. Fixed version 5. Whether it's a direct or transitive dependency 6. Migration notes if the fix requires API changes </task> <constraints> - Prioritize by CVSS score and whether the vulnerable code path is reachable - Distinguish between "severity critical" and "exploitable in this context" - Flag dependencies that are abandoned (no updates in 2+ years) - Recommend a scanning tool to automate this ongoing </constraints>

<context> System type: [e.g. SaaS with PII, fintech, e-commerce] Team size: [e.g. 5-person engineering team] Compliance: [e.g. GDPR, HIPAA, PCI-DSS] On-call setup: [e.g. no formal on-call, PagerDuty, manual] </context> <task> Write a security incident response plan for this system: [DESCRIBE THE SYSTEM AND ITS MOST LIKELY INCIDENT TYPES] Cover: 1. Incident classification (P1/P2/P3) 2. Detection and alerting 3. Containment steps by incident type 4. Communication templates (internal, customer, regulator) 5. Evidence preservation 6. Regulatory notification timelines (GDPR 72-hour, etc.) 7. Post-incident review process </task> <constraints> - GDPR breaches must be reported within 72 hours — make this explicit - Containment steps must be actionable without deep system knowledge - Communication templates must be pre-approved, not written during an incident - Define "breach" clearly — not every security event is a reportable breach </constraints>

<context> Framework: [e.g. React, Next.js, Django, Spring Boot] Current version: [e.g. v14] Target version: [e.g. v15] Codebase size: [e.g. 50 components, 30 API routes] Key dependencies: [list major libraries that may also need upgrading] </context> <task> Plan and execute the upgrade from [CURRENT VERSION] to [TARGET VERSION]: [PASTE RELEVANT CODE SAMPLES OR DESCRIBE KEY PATTERNS USED] Provide: 1. All breaking changes that affect this codebase 2. Automated migration steps (codemods, CLI commands) 3. Manual migration steps with before/after code 4. Testing strategy to verify the upgrade 5. Rollback plan if the upgrade fails 6. Estimated effort per section </task> <constraints> - Apply automated codemods before manual changes - Test after each breaking change, not only at the end - List deprecated features separately from breaking changes - Rollback plan must be executable in under 10 minutes </constraints>

<context> Database: [e.g. PostgreSQL 16] ORM/migration tool: [e.g. Prisma, Flyway, Alembic, raw SQL] Change type: [e.g. add column, rename table, change column type, split table] Table size: [e.g. 10M rows] Downtime tolerance: [e.g. zero downtime, up to 5 minutes maintenance window] </context> <task> Write a safe database migration for this change: Current schema: [PASTE CURRENT SCHEMA] Target schema: [PASTE TARGET SCHEMA] Provide: 1. Migration script 2. Is this zero-downtime or does it require a maintenance window? 3. If zero-downtime: the expand/contract pattern steps 4. Data backfill strategy for existing rows 5. Rollback migration 6. Estimated runtime at stated table size </task> <constraints> - Never rename a column directly — use expand/contract - Backfill in batches to avoid lock escalation - Test the migration on a copy of production data first - Include the rollback migration alongside the forward migration </constraints>

<context> Current REST API: [describe endpoints and consumers] GraphQL server: [e.g. Apollo Server, Strawberry, GraphQL Yoga] Consumer types: [e.g. React frontend, mobile app, partner integrations] Timeline: [e.g. 3 months, must not break existing consumers] </context> <task> Plan the migration from REST to GraphQL: [PASTE REST ROUTE DEFINITIONS] Provide: 1. GraphQL schema that covers all current REST capabilities 2. Resolver implementations for key queries and mutations 3. How to run both REST and GraphQL in parallel during migration 4. Consumer migration guide 5. Which REST endpoints can be retired and when 6. N+1 query prevention strategy (DataLoader) </task> <constraints> - Don't break existing REST consumers during migration - The GraphQL schema should be designed for clients, not as a 1:1 REST map - Implement DataLoader for all list resolvers from day one - Define a sunset date for each REST endpoint </constraints>

<context> Current state: [e.g. pure JS, JSDoc-annotated JS, mixed JS/TS] Framework: [e.g. Node.js, React, Next.js] Codebase size: [e.g. 50 files, 10K lines] Strictness target: [e.g. strict mode, noImplicitAny only] </context> <task> Plan the JavaScript to TypeScript migration: [PASTE KEY FILES OR DESCRIBE THE CODEBASE STRUCTURE] Provide: 1. tsconfig.json for a gradual migration (allowJs: true) 2. Migration order: which files to migrate first 3. Type annotation strategy for common patterns in this codebase 4. How to handle third-party packages without types 5. Common "any" patterns to avoid 6. Strictness ramp-up plan </task> <constraints> - Gradual migration: start with allowJs, tighten over time - Never use any as a permanent solution — use unknown or proper types - Migrate leaf files (no dependencies) before core modules - Add types to shared utilities first for maximum leverage </constraints>

<context> Current monolith: [describe the application] Pain points driving the migration: [e.g. deploy conflicts, scaling a specific feature, team autonomy] Team structure: [e.g. 3 teams of 6] Timeline: [e.g. 12-month migration] Infrastructure: [e.g. AWS, Kubernetes available] </context> <task> Plan the migration from monolith to microservices: [DESCRIBE THE MONOLITH ARCHITECTURE AND MODULES] Provide: 1. Service decomposition based on domain boundaries 2. Which service to extract first and why 3. The strangler fig pattern implementation 4. Data ownership strategy — how to split the database 5. Inter-service communication approach 6. Timeline and risk assessment per extraction </task> <constraints> - Extract the least-coupled service first to build the muscle - Don't split the database until the service boundary is proven - Distributed monolith is worse than a monolith — get service boundaries right - Each service must be independently deployable before the migration is done </constraints>

<context> Current ORM: [e.g. Sequelize v6, TypeORM 0.2] Target ORM: [e.g. Prisma 5, Drizzle, SQLAlchemy 2.0] Database: [e.g. PostgreSQL] Codebase size: [e.g. 20 models, 50 query files] </context> <task> Plan the migration from [CURRENT ORM] to [TARGET ORM]: [PASTE CURRENT MODEL DEFINITIONS AND KEY QUERIES] Provide: 1. New schema definition equivalent 2. Query migration for the most common patterns 3. Transaction handling in the new ORM 4. Migration and seeder equivalent 5. Testing strategy during the migration 6. How to run both ORMs in parallel if needed </task> <constraints> - Migrate the schema definition first, then queries - Test each migrated query against the same database - Don't change business logic during the ORM migration - Document any behavior differences (e.g. eager vs. lazy loading defaults) </constraints>

<context> Framework: [e.g. React, Vue] Current state management: [e.g. Redux, Vuex, MobX, Context API] Target state management: [e.g. Zustand, Pinia, Jotai, TanStack Query] App size: [e.g. 30 stores, 80 components] Main pain points: [e.g. boilerplate, performance, async complexity] </context> <task> Plan the migration to [TARGET STATE MANAGEMENT]: [PASTE CURRENT STORE DEFINITIONS AND KEY USAGE PATTERNS] Provide: 1. New store structure equivalent to current 2. Migration for async action patterns 3. Component update patterns 4. How to migrate incrementally without a big bang rewrite 5. Testing strategy for migrated state </task> <constraints> - Migrate one store at a time, not all at once - Keep existing tests passing throughout the migration - Async patterns: map thunks/sagas to the new async model explicitly - Don't change component behavior while migrating state management </constraints>

<context> Language: [LANGUAGE] Framework: [FRAMEWORK or "no framework"] Code age: [e.g. 8-year-old codebase] Main problems: [e.g. untestable global state, callback hell, no types, deprecated APIs] Constraints: [e.g. can't break existing API, no downtime, limited test coverage] </context> <task> Create a modernization plan for this legacy code: [PASTE LEGACY CODE SECTIONS] Provide: 1. Current state assessment — what's most painful 2. Prioritized modernization backlog 3. Which patterns to migrate and in what order 4. How to introduce tests before refactoring 5. A strangler fig approach to replace components incrementally 6. What NOT to modernize (working code that doesn't change) </task> <constraints> - Don't rewrite working code — modernize only what's actively painful - Add tests before refactoring legacy code - The public API must remain stable throughout - Deliver value incrementally — no big bang rewrites </constraints>

<context> Current provider: [e.g. AWS] Target provider: [e.g. GCP, Azure, self-hosted] Services used: [e.g. EC2, RDS, S3, SQS, Lambda] Downtime tolerance: [e.g. zero downtime, 4-hour maintenance window] Data volume: [e.g. 500GB database, 2TB S3] Timeline: [e.g. 3 months] </context> <task> Plan the cloud provider migration: [DESCRIBE THE CURRENT ARCHITECTURE] Provide: 1. Service mapping: current service → target service equivalent 2. Data migration strategy (database, object storage, queues) 3. DNS cutover strategy 4. Running both providers in parallel during migration 5. Rollback plan 6. Cost comparison estimate 7. Critical path and timeline </task> <constraints> - Database migration is the highest-risk step — plan it in detail - DNS TTL must be reduced before cutover - Run both environments in parallel for at least one week before cutover - Define the exact rollback trigger conditions </constraints>

<context> Current database: [e.g. MySQL 5.7] Target database: [e.g. PostgreSQL 16] Data volume: [e.g. 200GB, 50 tables] Downtime tolerance: [e.g. zero downtime, 2-hour window] Application tech stack: [STACK] </context> <task> Plan the migration from [CURRENT DB] to [TARGET DB]: [DESCRIBE THE SCHEMA AND CRITICAL TABLES] Provide: 1. Schema compatibility differences to address 2. Data type mapping between engines 3. Migration tool selection and configuration 4. Application changes needed (connection strings, SQL dialect, ORM config) 5. Data validation strategy post-migration 6. Zero-downtime migration approach (dual-write or CDC) 7. Rollback plan </task> <constraints> - Validate row counts and checksums after migration — don't assume success - Test the application fully on the new database before cutover - Dual-write period should be at least 1 week for high-stakes migrations - Document every SQL dialect difference found in the codebase </constraints>