Coding And Debugging Prompts

INPUTS
[language]; [code]; [error message]; [expected behavior]; [actual behavior]; [environment]

PROMPT
Act as a careful software developer. Diagnose the bug using the supplied code and observations. Identify the likely failure point, alternative explanations, and any missing information. Propose the smallest justified fix and explain how it changes the behavior. Preserve unrelated functionality and follow the existing style. Provide corrected code or a focused patch, then a meaningful reproduction and verification procedure. Do not assume access to files or execution tools you do not have. End with remaining risks and environment-dependent details to check.

INPUTS
[language]; [function purpose]; [input types]; [output contract]; [edge cases]; [constraints]

PROMPT
Implement the function according to the supplied contract. State assumptions about inputs, invalid values, and edge cases before presenting the code. Choose a straightforward approach appropriate to the performance constraints and explain the key design decision briefly. Include examples covering normal use, a boundary case, and a failure case. Avoid unnecessary dependencies or speculative features. If execution is available, run meaningful checks and report actual results; otherwise provide verification instructions. End with limitations and any contract ambiguity requiring a decision.

INPUTS
[code or diff]; [requirements]; [language]; [runtime]; [review focus]

PROMPT
Review the code for defects affecting correctness, maintainability, security, and performance within the requested scope. Prioritize actionable findings and reference the relevant function or line. Explain the concrete failure scenario and a proposed fix for each material issue. Separate confirmed problems from questions and stylistic preferences. Consider edge cases and whether the implementation meets the requirements. Do not claim to have run tests unless you actually did. End with a concise overall assessment and the most useful checks still needed.

INPUTS
[code]; [language]; [business context]; [reader experience]

PROMPT
Explain the legacy code so a developer can safely work on it. Describe its purpose, entry points, data flow, dependencies, side effects, and important assumptions. Walk through one realistic example using supplied inputs. Identify confusing names or implicit behavior without guessing the original author's intentions. Provide a plain-language summary and a function-by-function reference. Flag code paths needing inspection or execution to understand fully. End with three safe starting points for maintenance and the behaviors that should be preserved.

INPUTS
[code]; [behavior to preserve]; [maintenance problem]; [constraints]; [existing checks]

PROMPT
Propose a focused refactor that addresses the stated maintenance problem. Identify the current responsibilities and coupling, then explain the smallest structural improvement. Preserve public behavior and avoid adding features. Provide a stepwise plan, representative code changes, and checks that would detect unintended differences. Discuss tradeoffs and whether the benefit justifies the effort. Distinguish necessary changes from optional cleanup. End with rollback considerations and any unknown behavior that should be clarified before implementation begins.

INPUTS
[component]; [requirements]; [known bugs]; [test framework]; [risk areas]

PROMPT
Design tests that verify meaningful behavior rather than reproduce implementation details. Map requirements and risk areas to representative cases, including boundaries, invalid inputs, and known failure modes. Explain which tests belong at unit, integration, or end-to-end level. Provide focused test examples compatible with the supplied framework. Avoid brittle assertions and unnecessary mocking. Identify behavior the current contract leaves undefined. End with the smallest useful test set and a description of what failures would reveal about the component.

INPUTS
[API documentation]; [request]; [response]; [environment]; [expected result]

PROMPT
Troubleshoot the API integration using the supplied documentation and observed exchange. Check authentication handling, endpoint, method, headers, payload schema, version, and error response. Do not expose credentials or invent undocumented behavior. Identify likely causes in priority order and give a minimal diagnostic request with placeholders for secrets. Explain expected outcomes for each check. Provide a focused fix when evidence supports one. End with logging recommendations that preserve useful context without recording sensitive values and documentation details needing current verification.

INPUTS
[code]; [workload]; [timings]; [environment]; [performance goal]

PROMPT
Investigate the performance problem before suggesting optimization. Identify likely bottlenecks and distinguish computational work, I/O, repeated operations, allocation, and waiting. Recommend measurements that can confirm the dominant cause. Propose changes in order of evidence and simplicity, explaining tradeoffs and expected mechanisms without inventing speedup numbers. Provide benchmarking guidance using representative inputs and comparable conditions. End with correctness checks, a stopping criterion for optimization, and uncertainties that require profiling rather than intuition.

INPUTS
[task]; [operating system]; [inputs]; [outputs]; [failure handling]; [constraints]

PROMPT
Write a command-line script for the task using clear arguments and explicit input validation. Explain what files or systems it reads or changes. Include useful error messages, logging, and a dry-run mode when actions could overwrite or remove data. Handle missing inputs and partial failures. Avoid embedding secrets or assuming unavailable dependencies. Provide usage examples and a minimal verification procedure. End with operational limitations and checks the user should complete before running the script on important data.

INPUTS
[repository summary]; [setup instructions]; [architecture notes]; [common tasks]; [environment]

PROMPT
Create a developer onboarding guide from the supplied repository information. Explain the project's purpose, prerequisites, setup, configuration, local execution, meaningful checks, and common development workflows. Map important directories and describe where new changes usually belong. Keep commands grounded in the actual project and mark missing details instead of inventing them. Include troubleshooting for known setup issues and a small first task. End with a checklist that confirms a developer can run, understand, and safely modify the project.