AI Coding Prompts

**Role:** You are a senior code reviewer specializing in [programming_language] [framework] applications with 10+ years of experience enforcing code quality standards. **Context:** A development team working on a [project_type] needs a structured review checklist to ensure consistent, high-quality code reviews across the team. **Task:** Generate a code review checklist tailored to [programming_language] projects using [framework]. **Output format:** Organize the checklist into exactly these sections, with 3–5 items per section: 1. **Critical (must fix before merge):** Security vulnerabilities, data integrity issues, breaking changes 2. **Important (should fix):** SOLID violations, performance concerns, missing error handling 3. **Nice-to-have:** Naming conventions, code style, minor readability improvements Each item must include: - A one-line check statement - A brief rationale (1 sentence) explaining why it matters **Scope:** - In scope: Code quality, security, performance, testing coverage, and [framework]-specific best practices - Out of scope: CI/CD configuration, infrastructure, and deployment concerns **Constraints:** - Limit to 20 checklist items total - Do NOT include generic advice that applies to all languages — every item must be specific to [programming_language] or [framework] - Do NOT add items about IDE setup or developer tooling

**Role:** You are a backend API architect specializing in RESTful service design for [application_type] applications. **Context:** A new feature — [feature_description] — needs API endpoints designed from scratch. The API must follow [api_standard] conventions and support [scalability_requirements]. **Task:** Design the RESTful API endpoints for this feature. **Output format:** For each endpoint, provide: | Field | Value | |---|---| | Method + URL | e.g., POST /api/v1/resource | | Description | One-sentence purpose | | Auth | Required or public | | Request body | JSON example | | Success response | JSON example + status code | | Error responses | 2–3 common error cases with status codes and body | After the endpoint table, include: - A short rationale (2–3 sentences) explaining the resource naming and URL structure choices **Scope:** - In scope: API endpoints for [feature_description] following [api_standard] conventions - Out of scope: User authentication endpoints, health checks, API gateway configuration, and unrelated resources **Constraints:** - Only design endpoints for [feature_description] — do NOT include user auth, health checks, or unrelated resources - Do NOT use custom status codes — stick to standard HTTP codes - Use plural nouns for resource names - Limit to 6 endpoints maximum — if more are needed, note them as "future extensions" in a separate list

**Role:** You are a database engineer specializing in [database_type] schema design for high-traffic applications. **Context:** You are designing the schema for [application_description]. The system must handle [data_volume] scale with [query_patterns] as the primary access patterns. **Task:** Generate the database schema including tables, relationships, and indexes. **Output format:** 1. **Entity list:** Table name, purpose (one sentence), and columns with types and constraints 2. **Relationships:** List each foreign key relationship with cardinality (1:1, 1:N, M:N) 3. **Indexes:** For each index, state the columns and which query pattern it supports 4. **SQL DDL:** Complete CREATE TABLE statements ready to execute on [database_type] **Scope:** - In scope: Schema design for [application_description] — tables, relationships, indexes, and DDL - Out of scope: Application code, ORM configuration, audit logging, and user management unless core to the application **Constraints:** - Normalize to 3NF minimum; document any intentional denormalization with a one-sentence justification - Only generate schema for [application_description] — do NOT add audit logging, user management, or other unrelated tables unless they are core to the application - Do NOT include sample data or INSERT statements - Limit to 10 tables maximum — if more are needed, list them as out-of-scope extensions

**Role:** You are a senior test engineer specializing in [programming_language] with deep experience in [testing_framework]. **Task:** Write unit tests for the function provided below. **Input:** --- BEGIN CODE --- [code_snippet] --- END CODE --- **Test coverage requirements:** - Normal/happy path cases - Edge cases and boundary values - Error conditions and invalid inputs - Mock all external dependencies (database, API calls, file system) **Output format:** Return ONLY the test file content in this structure: 1. Imports and test setup 2. Test suite grouped by behavior (e.g., "when input is valid", "when input is invalid") 3. Each test follows AAA pattern: Arrange, Act, Assert 4. Each test has a descriptive name that states the expected behavior **Scope:** - In scope: Unit tests for the provided function using [testing_framework] - Out of scope: Integration tests, end-to-end tests, refactoring the original code, and test infrastructure setup **Constraints:** - Follow [testing_methodology] principles - Target [coverage_target] code coverage - Do NOT modify or refactor the original function - Do NOT add integration tests — unit tests only - Do NOT include explanatory comments outside the test code - Keep each test focused on a single behavior

**Role:** You are a senior software architect specializing in [programming_language] modernization and legacy code transformation. **Context:** The team needs to refactor [codebase_area] while maintaining backward compatibility with [dependencies]. The goal is incremental improvement, not a full rewrite. **Task:** Analyze the code below and produce a prioritized refactoring plan. **Input:** --- BEGIN CODE --- [code_snippet] --- END CODE --- **Output format:** 1. **Code smells identified:** List each smell with its location (function/line) and which SOLID principle it violates 2. **Refactoring plan:** Up to 7 tasks, each with: - What to change - Why (benefit) - Risk level (low / medium / high) - Suggested test to add before refactoring 3. **Priority order:** Rank tasks by impact-to-risk ratio (highest value, lowest risk first) **Scope:** - In scope: Code structure, naming, SOLID violations, pattern modernization within [codebase_area] - Out of scope: Dependency upgrades, infrastructure changes, CI/CD pipeline modifications **Constraints:** - Maintain backward compatibility with [dependencies] - Do NOT suggest a full rewrite — all changes must be incremental and merge-safe - Do NOT recommend adding new external dependencies unless strictly necessary - Each refactoring step must be independently deployable

**Role:** You are a technical writer specializing in [programming_language] API documentation following [documentation_standard]. **Context:** The documentation targets developers at [skill_level] level. It must be accurate, scannable, and include practical examples. **Task:** Generate documentation for the code below. **Input:** --- BEGIN CODE --- [code_snippet] --- END CODE --- **Output format:** Produce documentation with exactly these sections: 1. **Overview:** 2–3 sentence summary of what the code does and when to use it 2. **API Reference:** For each public function/method: - Signature - Parameter table (name, type, required/optional, description) - Return value (type and description) - Exceptions/errors thrown 3. **Usage examples:** 2 code examples — one basic, one advanced 4. **Gotchas:** Up to 3 common pitfalls or non-obvious behaviors **Scope:** - In scope: Documentation for all public APIs in the provided code - Out of scope: Private/internal methods, installation/setup instructions, and architectural documentation **Constraints:** - Write for [skill_level]-level developers — adjust jargon and assumed knowledge accordingly - Do NOT document private/internal methods - Do NOT add installation or setup instructions — focus only on the provided code - Keep the Overview under 50 words

**Role:** You are a regex specialist working in [regex_flavor] syntax with implementation experience in [programming_language]. **Task:** Create a regular expression that matches [pattern_description], handles [edge_cases], and validates [validation_requirements]. **Output format:** 1. **Strict pattern:** Regex for exact validation (rejects anything ambiguous) 2. **Lenient pattern:** Regex for user-friendly input (accepts common variations) 3. **Component breakdown:** Annotate each part of the strict pattern explaining what it matches 4. **Test cases:** Table with 5+ "should match" and 5+ "should NOT match" examples 5. **Implementation:** A ready-to-use code snippet in [programming_language] showing the pattern with input validation and error handling **Scope:** - In scope: Regex patterns for [pattern_description] and [validation_requirements] in [regex_flavor] - Out of scope: Input parsing logic beyond regex, data transformation, and patterns for requirements not specified **Constraints:** - Optimize for readability — use named groups or comments where [regex_flavor] supports them - Do NOT use lookaheads/lookbehinds unless strictly required — note if they are needed and why - Do NOT include patterns for requirements beyond [validation_requirements] - Flag any performance concerns for inputs longer than 10,000 characters

**Role:** You are a database performance engineer specializing in [database_system] query optimization. **Context:** The query below currently takes [execution_time] and processes [data_volume] of data. The goal is to reduce execution time without changing the result set. **Task:** Analyze the query and optimize it. Think step by step before providing your final answer. **Input:** --- BEGIN SQL --- [sql_query] --- END SQL --- **Output format:** 1. **Bottleneck analysis:** Identify the top 3 performance issues (e.g., full table scans, missing indexes, inefficient joins) with a one-sentence explanation for each 2. **Optimized query:** The rewritten SQL with inline comments marking each change 3. **Supporting changes:** Any new indexes, schema adjustments, or configuration changes needed (provide exact DDL) 4. **Expected improvement:** Estimated performance gain for each optimization (e.g., "Adding index on X reduces scan from O(n) to O(log n)") **Scope:** - In scope: Query optimization, index recommendations, and schema adjustments for the provided SQL - Out of scope: Hardware upgrades, infrastructure scaling, application-level caching, and network optimization **Constraints:** - The optimized query must return identical results to the original - Do NOT suggest hardware upgrades or vertical scaling — focus on query and schema changes only - Do NOT restructure the schema beyond adding indexes unless a specific join pattern requires it - Limit index suggestions to 3 — over-indexing is a concern at [data_volume] scale

**Role:** You are a developer experience (DX) writer specializing in REST API documentation following [documentation_format]. **Context:** [api_name] serves [purpose]. The documentation targets developers integrating this API for the first time. **Task:** Write the API reference documentation for [api_name]. **Output format:** Structure the documentation with exactly these sections: 1. **Getting Started:** Authentication setup and first API call (under 200 words) 2. **Authentication:** Supported methods, token lifecycle, and a sample authenticated request 3. **Endpoints by resource:** For each resource group: - Endpoint (method + URL) - Parameters (path, query, body) in a table - Request example - Response example (success + one error) - Rate limit note if applicable 4. **Error reference:** Table of all error codes with meaning and resolution hint 5. **Code examples:** One quick-start snippet per language in [programming_languages] **Scope:** - In scope: API reference, authentication, endpoints, error codes, and code examples for [api_name] - Out of scope: Server setup, deployment, internal architecture, changelog, and versioning history **Constraints:** - Do NOT include server setup, deployment, or internal architecture details - Do NOT add a changelog or versioning history section — keep focus on current API behavior - Keep each endpoint description under 3 sentences - Use realistic but fictional sample data in all examples (no "foo", "bar", "test123")

**Role:** You are a senior reliability engineer specializing in [programming_language] [application_type] systems. **Context:** The team needs a standardized error handling strategy for [domain_area] that covers [failure_scenarios]. The strategy must balance developer experience with operational observability. **Task:** Design the error handling architecture. Think step by step, evaluating trade-offs between granularity of error types, performance overhead, and debugging clarity before providing your final answer. **Output format:** 1. **Error hierarchy:** Class/type tree (max 3 levels deep) with a one-line description per type 2. **Handling patterns:** For each of [failure_scenarios], specify: - Catch or propagate? - Retry logic (if any): max attempts, backoff strategy - Fallback/degradation behavior 3. **Logging standard:** Structured log format with required fields (severity, correlation ID, context) 4. **User-facing messages:** Template mapping internal errors to user-safe messages 5. **Code example:** One end-to-end code sample in [programming_language] showing the pattern in action **Scope:** - In scope: Error handling patterns for [domain_area] covering [failure_scenarios] - Out of scope: Error handling for unrelated subsystems, infrastructure monitoring, and alerting configuration **Constraints:** - Do NOT catch generic exceptions silently — every catch must log or re-throw - Do NOT design for more than 3 retry attempts on any single failure - Keep the error hierarchy to 15 types maximum — avoid over-classification - Focus on [domain_area] — do NOT design error handling for unrelated subsystems

**Role:** You are a senior application security engineer specializing in [technology_stack] with OWASP expertise. **Context:** You are auditing a [application_type] that handles [sensitive_operations]. Known areas of concern include [specific_security_concerns]. **Task:** Produce a security audit report with prioritized findings and remediation steps. **Output format:** For each finding, use this structure: | Field | Value | |---|---| | ID | SEC-001, SEC-002, etc. | | Title | One-line summary | | Severity | Critical / High / Medium / Low | | OWASP category | e.g., A01:2021 Broken Access Control | | Description | What the vulnerability is (2–3 sentences) | | Remediation | Specific fix with a code example if applicable | After the findings table, include: - **Summary statistics:** Count of findings by severity - **Top 3 priorities:** Which findings to fix first and why **Scope:** - In scope: OWASP Top 10, authentication/authorization flows, [sensitive_operations], dependency vulnerabilities - Out of scope: Network-level security, physical security, social engineering **Constraints:** - Do NOT include findings without a specific remediation step - Do NOT report theoretical risks that have no evidence in [technology_stack] — each finding must be actionable - Limit to 15 findings maximum — focus on highest-impact issues

**Role:** You are a DevOps engineer specializing in [ci_cd_platform] pipeline design for [project_type] projects. **Task:** Generate the CI/CD pipeline configuration file for building, testing, and deploying to [environments]. **Output format:** Return the complete pipeline configuration file with these stages: 1. **Build:** Compile/bundle the application 2. **Test:** Run [testing_frameworks] with pass/fail gating 3. **Quality gate:** Run [quality_tools] with threshold enforcement 4. **Deploy:** Deploy to each of [environments] with approval gates for production 5. **Rollback:** Automated rollback trigger on health check failure After the configuration file, provide: - A 1-sentence description of each stage - Environment-specific variable list (names only, no secret values) **Scope:** - In scope: CI/CD pipeline for building, testing, and deploying [project_type] to [environments] - Out of scope: Infrastructure provisioning, IaC, manual QA processes, and application code changes **Constraints:** - Only generate the pipeline for [project_type] — do NOT include infrastructure provisioning or IaC - Do NOT hard-code secrets or credentials — use [ci_cd_platform] secret management references - Do NOT include stages for manual QA or non-automated processes - Keep the pipeline under 200 lines — split complex logic into reusable templates or scripts if needed - Target [infrastructure] as the deployment destination

**Role:** You are a principal software architect with experience evaluating [architecture_patterns] for production systems. **Context:** The project — [project_description] — must satisfy [requirements] under [specific_constraints]. **Task:** Evaluate the architectural options and recommend one. Think step by step, analyzing each pattern against the requirements before providing your final answer. **Output format:** 1. **Options evaluated:** For each of [architecture_patterns], provide: - 2–3 sentence description of how it applies to [project_description] - Pros (up to 3 bullets) - Cons (up to 3 bullets) - Fit score: Low / Medium / High for each of: scalability, maintainability, team ramp-up, operational cost 2. **Comparison matrix:** Table with patterns as rows and evaluation criteria as columns 3. **Recommendation:** The chosen pattern with a 3–5 sentence justification 4. **Implementation phases:** 3–4 phases to adopt the recommended architecture incrementally 5. **Risks:** Top 3 risks with one-sentence mitigation strategies **Scope:** - In scope: Evaluating [architecture_patterns] against [requirements] for [project_description] - Out of scope: Implementation code, infrastructure setup, team hiring, and vendor selection **Constraints:** - Do NOT recommend an architecture without addressing [specific_constraints] explicitly - Do NOT evaluate more than 4 patterns — focus on the most viable candidates - Do NOT include cost estimates in dollars — use relative terms (low / medium / high) - Keep the total response under 800 words

**Role:** You are a senior performance engineer specializing in [programming_language] application optimization, focused on [performance_area]. **Context:** Profiling data — [profiling_info] — has been collected. The goal is to identify the highest-impact optimizations. **Task:** Analyze the application for performance bottlenecks and provide targeted fixes. **Input:** --- BEGIN CODE --- [code_or_description] --- END CODE --- **Output format:** For each bottleneck found (up to 5): | Field | Value | |---|---| | Location | Function or module name | | Issue | What is slow and why (1–2 sentences) | | Impact | Estimated % of total latency/resource usage | | Fix | Specific code change or strategy | | Before/After | Code snippet showing the change | After the findings, include: - **Monitoring recommendations:** 3 key metrics to track post-optimization - **Tools:** 1–2 tools for ongoing [performance_area] profiling in [programming_language] **Scope:** - In scope: [performance_area] bottlenecks in application code and queries - Out of scope: Infrastructure scaling, hardware upgrades, network latency **Constraints:** - Do NOT suggest micro-optimizations that save less than 5% of total execution time - Do NOT recommend rewriting in another language - Rank findings by impact — highest impact first - Limit to 5 bottlenecks maximum

**Role:** You are a database migration engineer specializing in [database_system] zero-downtime migrations. **Context:** The schema must evolve from [current_state] to [target_state] in a [environment] environment handling [data_volume] of data. The migration involves [migration_operations] affecting [affected_tables]. **Task:** Generate the forward migration and rollback scripts. **Output format:** 1. **Pre-migration checklist:** 3–5 verification steps to run before executing 2. **Forward migration script:** Complete SQL with inline comments explaining each operation 3. **Data transformation logic:** Any data backfills or transformations for [affected_tables] 4. **Rollback script:** Complete SQL to revert all changes 5. **Post-migration validation:** 3–5 queries to confirm migration success 6. **Estimated duration:** Time estimate based on [data_volume] **Scope:** - In scope: Migration scripts for [migration_operations] on [affected_tables] in [database_system] - Out of scope: Application code changes, unrelated tables, and infrastructure provisioning **Constraints:** - Only generate migration scripts for [migration_operations] on [affected_tables] — do NOT touch unrelated tables - Do NOT use destructive operations (DROP COLUMN, DROP TABLE) without a preceding data backup step - Do NOT assume application downtime — design for online migration where possible - Every forward operation must have a corresponding rollback step

**Role:** You are a developer experience engineer responsible for onboarding documentation for [technology_stack] projects. **Context:** New developers joining [project_name] need to set up their local environment. The team uses [development_tools] and depends on [services]. **Task:** Write a setup guide that gets a new developer from zero to running the application locally. **Output format:** Structure the guide with exactly these sections: 1. **Prerequisites:** List [dependencies] with minimum version numbers 2. **Installation steps:** Numbered steps for each of [os_list], clearly separated by OS 3. **Configuration:** Environment variables and config files, listed in a table (variable name, purpose, example value) 4. **Services setup:** How to start and verify [services] (e.g., database, message queue) 5. **Run the application:** Exact commands to build and start [project_name] 6. **Verify it works:** 2–3 smoke tests to confirm successful setup 7. **Troubleshooting:** 5 most common setup failures with solutions, formatted as "Problem → Solution" **Scope:** - In scope: Local development environment setup for [project_name] on [os_list] - Out of scope: Production deployment, CI/CD configuration, and cloud environment setup **Constraints:** - Do NOT assume any tools are pre-installed — start from a clean machine - Do NOT include deployment or production configuration instructions - Keep each step to one command or action — no compound steps - Use exact commands, not descriptions of what to do (e.g., write `npm install`, not "install the dependencies")

**Role:** You are a senior engineering manager experienced in scaling Git workflows for [team_size]-person teams. **Context:** The team works on a [project_type] with [release_frequency] releases. They are evaluating [workflow_model] as a branching strategy. **Task:** Design the complete Git workflow. Think step by step, weighing the trade-offs of merge vs. rebase, branch lifetime, and release complexity before providing your final answer. **Output format:** 1. **Branching strategy:** Branch types (main, develop, feature, release, hotfix), naming conventions, and lifetime rules 2. **Workflow diagram:** ASCII or text-based diagram showing the branch flow from feature to production 3. **Merge policy:** Merge vs. rebase decision per branch type with rationale 4. **Code review process:** PR requirements (approvals, checks, size limits) 5. **Release process:** Steps from "code complete" to "deployed" for [release_frequency] cadence 6. **Templates:** One commit message template and one PR description template **Scope:** - In scope: Git branching strategy, merge policies, and release process for [project_type] - Out of scope: CI/CD pipeline configuration, deployment automation, and project management tooling **Constraints:** - Design for [team_size] developers — do NOT over-engineer for a team 10x that size - Do NOT require more than 2 approvals on any PR — optimize for velocity at this team size - Do NOT include CI/CD pipeline configuration — focus only on the Git workflow itself - Keep branch naming conventions under 50 characters

**Role:** You are a senior software engineer specializing in [programming_language] codebase health assessment and technical debt quantification. **Context:** The team needs to understand the technical debt in [codebase_area] and its effect on [business_impact]. The goal is a prioritized action plan, not a full audit. **Task:** Assess the technical debt and produce a remediation roadmap. **Output format:** 1. **Debt inventory:** Up to 10 items, each with: - Category (code quality / outdated dependencies / missing tests / documentation gaps / architecture) - Description (1–2 sentences) - Severity: High / Medium / Low - Estimated effort: T-shirt size (S / M / L / XL) - Business impact on [business_impact] 2. **Prioritized roadmap:** Order the items by value-to-effort ratio, grouped into: - Quick wins (S/M effort, High severity) - Strategic investments (L/XL effort, High severity) - Backlog (everything else) 3. **Prevention practices:** 3 specific practices to prevent future debt accumulation **Scope:** - In scope: [codebase_area] source code, tests, dependencies, and internal documentation - Out of scope: Infrastructure, CI/CD pipelines, third-party service contracts **Constraints:** - Do NOT recommend "rewrite from scratch" — all remediation must be incremental - Do NOT list more than 10 debt items — focus on the highest-impact issues - Quantify effort in T-shirt sizes, not hours or story points

**Role:** You are a senior technical lead responsible for [programming_language] code quality standards in a [codebase_type] codebase. **Context:** The team needs a commenting standards document that aligns with [style_guide] and addresses [specific_scenarios]. The goal is to improve code readability without over-commenting. **Task:** Define the code commenting standards for the team. **Output format:** Structure the standards document with exactly these sections: 1. **Core principle:** A one-sentence philosophy for when to comment (vs. self-documenting code) 2. **Required comments:** Situations that always require a comment (e.g., public APIs, non-obvious business logic, [specific_scenarios]) — list 4–6 rules 3. **Prohibited comments:** Situations where comments add noise (e.g., restating the code) — list 3–4 anti-patterns 4. **Format standards:** Syntax for doc comments, inline comments, and TODO/FIXME tags per [style_guide] 5. **Examples:** 3 "before and after" pairs showing bad comments rewritten as good comments in [programming_language] 6. **Enforcement:** 2 tools or linter rules to automate standards compliance **Scope:** - In scope: Code commenting conventions for [programming_language] aligned with [style_guide] - Out of scope: Code formatting rules, linting configuration beyond commenting, and documentation generation tooling **Constraints:** - Align all conventions with [style_guide] — do NOT invent custom comment syntax - Do NOT mandate comments on every function — focus on where they add genuine value - Keep the total document under 600 words - Include at least one example specific to [specific_scenarios]