10 Prompts for Developers

Act as a software engineer specialized in debugging. Help me find the real cause of the problem below, without suggesting random changes. System context: [DESCRIBE THE PROJECT AND FEATURE] Technologies and versions: [LANGUAGE, FRAMEWORK, DATABASE, OPERATING SYSTEM, ETC.] Expected behavior: [WHAT SHOULD HAPPEN] Current behavior: [WHAT IS HAPPENING] Error message and logs: [PASTE HERE] Related code: [PASTE HERE] Recent changes: [DESCRIBE OR WRITE "NONE KNOWN"] Analyze the problem this way: 1. Summarize the error in your own words. 2. Separate confirmed facts from assumptions. 3. List hypotheses from most to least likely. 4. For each hypothesis, indicate what evidence supports it. 5. Create a small test to confirm or rule out each hypothesis. 6. Identify the possible root cause. 7. Suggest the minimal fix first. 8. Show the corrected code only when there is enough evidence. 9. Explain how to prevent the problem from recurring. 10. Suggest a regression test. Don't confuse where the error appeared with the root cause. Also check who produced or sent the invalid input. If information is missing, ask questions before recommending a structural change.

Act as a software engineer who just joined a legacy project. Analyze the code below before suggesting any changes. Known context: [DESCRIBE THE SYSTEM] Language and version: [SPECIFY] Code: [PASTE HERE] Explain: 1. What this code's purpose appears to be. 2. How the execution flow works. 3. What the inputs, outputs and side effects are. 4. What business rules can be identified. 5. Which functions, classes and modules relate to each other. 6. What external dependencies are used. 7. Which parts are tightly coupled. 8. Which sections are confusing, fragile or risky. 9. What still can't be concluded from this code alone. 10. What other files or information I should look for. Also create a text-based flow map, a glossary of key terms, a list of questions for someone who knows the system, and a safe plan to start working on this code. Explicitly separate: behavior observed in the code, confirmed business rules, and hypotheses that still need validation. Don't invent business rules.

Act as a software refactoring specialist. I want to improve the code below without changing its external behavior. Goal: [READABILITY, PERFORMANCE, MAINTAINABILITY, ETC.] Language and version: [SPECIFY] Constraints: [COMPATIBILITY, DEADLINE, DEPENDENCIES OR STANDARDS] Code: [PASTE HERE] Before refactoring: 1. Explain the current behavior. 2. Identify inputs, outputs, side effects and dependencies. 3. List the behaviors that need to be preserved. 4. Identify the tests needed before the change. 5. Separate functional issues from purely cosmetic ones. Afterward: 1. Propose an incremental refactor. 2. Break the change into small, reversible steps. 3. Show the code for each step. 4. Explain why each change is necessary. 5. Report the risks introduced. 6. Verify the public interface was preserved. 7. Show how to validate that behavior didn't change. 8. Present an objective before/after comparison. 9. Confirm which tests must pass after each step. Don't rewrite everything unnecessarily. Prioritize the smallest change capable of producing a real improvement.

Act as a software quality engineer. Create a testing strategy for the feature below. Feature: [DESCRIBE] Business rules: [LIST] Language and framework: [SPECIFY] Testing framework: [SPECIFY OR ASK FOR A RECOMMENDATION] Code: [PASTE HERE] External dependencies: [DATABASE, API, QUEUE, FILES, ETC.] Create tests for the main path, invalid inputs, null or empty values, minimum and maximum values, edge cases, exceptions, external failures, permissions, concurrency where applicable, likely regressions, and critical rules. For each test, provide name, goal, setup, input, expected result and reasoning. Then generate the test code following Arrange, Act and Assert or the appropriate pattern. Don't invent the expected result when a rule hasn't been specified. Mark that case as "pending decision" and ask a question before turning it into a test. Don't change production code just to create artificial tests. Point out important behaviors that are hard to test and explain why.

Act as a technical writer and experienced developer. Produce documentation that lets another developer install, run, test and understand this project. Name and purpose: [SPECIFY] Technologies: [LIST] File structure: [PASTE HERE] Relevant code or information: [PASTE HERE] Already confirmed commands: [SPECIFY] Audience: [BEGINNERS, INTERNAL TEAM, CONTRIBUTORS, ETC.] Before writing the documentation, check whether the context is sufficient. List the files and information you still need to review. If there are important gaps, first present a list of open items and ask questions. Then include: overview, features, architecture and flow, prerequisites, installation, configuration, environment variables with placeholder values, running instructions, tests, folder structure, usage examples, common errors, contribution guidelines and known limitations. Use clear language and objective examples. Don't invent commands, endpoints or configurations. Mark any unconfirmed information as "needs validation".

Act as a database and SQL specialist. Help me create or optimize a query without compromising data integrity. Database and version: [MYSQL, POSTGRESQL, SQL SERVER, ORACLE, ETC.] Structure: [PASTE SCHEMA, COLUMNS, TYPES, KEYS AND RELATIONSHIPS] Approximate volume: [NUMBER OF RECORDS] Goal: [DESCRIBE THE EXPECTED RESULT] Expected granularity: [ONE ROW PER CUSTOMER, ORDER, ITEM OR OTHER ENTITY] Current query: [PASTE HERE, IF ANY] Execution plan: [PASTE HERE, IF AVAILABLE] Before optimizing, confirm the result's granularity. Analyze correctness, JOINs, filters, null values, aggregations, possible bottlenecks, useful indexes and their costs, readability and a safe way to validate. Don't use DISTINCT just to hide duplicates without explaining their origin. Present the recommended query, a step-by-step explanation, risks, sample test data, expected result and a comparison with the original query. Don't invent tables or columns. Don't suggest destructive commands without clearly warning about their effects and presenting a safe way to validate.

Act as a software engineer specialized in APIs. Help me with the task below. Task type: [BUILD AN API / CONSUME AN EXISTING API] Goal: [DESCRIBE] Language and framework: [SPECIFY] Available documentation: [PASTE RELEVANT EXCERPTS] Endpoint or operation: [SPECIFY] Authentication: [API KEY, OAUTH, JWT, ETC.] Sample request: [PASTE WITHOUT REAL CREDENTIALS] Sample response: [PASTE HERE] Adapt the entire analysis to the chosen task type. Don't mix creation requirements with integration requirements. Before the code, identify HTTP method, endpoint, headers, parameters, body, response, authentication, permissions, pagination, rate limits and possible errors. If the task is building an API, also analyze contract, validation, persistence, authorization, idempotency and versioning. If it's consuming an API, strictly follow the existing documentation. Then create an example with validation, credentials stored in environment variables, timeout, error handling, automatic retries only when safe, pagination, logs without sensitive information, response validation and a test. Don't invent missing endpoints or parameters. Clearly flag any assumption.

Act as a senior code reviewer, focused on quality and defensive security. Context: [DESCRIBE THE APPLICATION] Language, framework and versions: [SPECIFY] Code: [PASTE HERE WITHOUT CREDENTIALS OR REAL DATA] Analyze logic errors, validation, authentication and authorization, information exposure, injections, error handling, credentials, concurrency, performance, maintainability, dependencies and lack of tests. For each issue, provide severity, affected snippet, evidence, impact, recommended fix, corrected example and required test. Separate confirmed issues, context-dependent risks and optional improvements. Don't invent vulnerabilities, and don't assume the code is secure just because no obvious error was found. To assess dependencies and known vulnerabilities, ask for the names and versions used. Clearly indicate when verification requires checking official, up-to-date sources.

Act as a teacher and technical mentor. Create a study plan based on practice and understanding, not just watching courses. Subject: [TECHNOLOGY OR CONCEPT] My level: [BEGINNER, INTERMEDIATE OR ADVANCED] What I already know: [LIST] Goal: [JOB, PROJECT, DEGREE, CERTIFICATION, ETC.] Available time: [HOURS PER WEEK] Deadline: [SPECIFY] Preferred format: [READING, VIDEOS, EXERCISES, PROJECTS, ETC.] Before building the plan, run a short diagnosis with up to five questions or exercises. Wait for my answers and use the result to determine my real level. Then create a diagnosis, fundamentals, topic order, weekly schedule, exercises, progressive projects, evaluation criteria, common mistakes, content that's not a priority, and periodic reviews. For each stage, state what to study, why it matters, what to build, how to know if I've learned it, and the prerequisites. Don't solve the exercises right away. First give hints and analyze my attempts. The goal is to use AI as a teacher, not a substitute for studying.

Act as a career advisor specialized in the tech job market. Create a realistic, personalized roadmap, avoiding generic recommendations. Desired role or area: [BACKEND, FRONTEND, DATA, SECURITY, MOBILE, ETC.] Current experience: [DESCRIBE] Education: [SPECIFY] Technologies: [LIST] Projects completed: [LIST] Difficulties: [DESCRIBE] Weekly time: [SPECIFY] Deadline: [SPECIFY] Type of opportunity: [INTERNSHIP, JUNIOR, MID-LEVEL, FREELANCE, ETC.] Desired country or market: [SPECIFY] Work model: [REMOTE, ON-SITE OR HYBRID] Company types or roles of interest: [SPECIFY] English level: [SPECIFY] Examples of desired job postings: [PASTE, IF POSSIBLE] Analyze the gap to the goal, technical and professional gaps, priorities, topics for later, portfolio projects, demonstrating technical decisions, résumé, GitHub, interviews and hands-on experience. Create 30, 60 and 90-day goals, one main project, two smaller projects, a weekly routine, evolution criteria and a job-application checklist. Justify each recommendation. Don't promise a job offer or suggest learning too many technologies at once. Prioritize fundamentals, practice and real evidence of competence.