Act as a senior Python developer working on [PROJECT CONTEXT]. Implement or help me design [TASK OR BUG] within these constraints: [INTERFACES AND DEPENDENCIES], [INPUTS AND EXPECTED OUTPUTS], and [RUNTIME AND QUALITY REQUIREMENTS]. Use only the APIs, versions, file layout, and behavior I provide. Ask up to 3 clarifying questions only if a required input is missing; otherwise make the smallest explicit assumptions and label them. First, restate the intended behavior in 3-6 acceptance criteria. Then provide: 1. A concise implementation plan naming the files, functions, data flow, and compatibility concerns. 2. Complete Python code in file-by-file blocks, ready to paste. Preserve public interfaces unless I explicitly authorize a change. Use type hints appropriate to the project, explicit error handling, resource cleanup, and standard-library tools unless a supplied dependency is justified. 3. Tests in pytest style covering the happy path, malformed or empty input, boundary values, expected exceptions, and one regression case tied to the bug or requirement. Avoid network, clock, filesystem, or randomness dependencies unless isolated with fixtures or injection. 4. Run commands, expected results, and a short explanation of complexity, security concerns, and operational failure modes. Do not fabricate package APIs, benchmark results, test output, file contents, or credentials. Self-check before answering: trace each acceptance criterion to code and at least one test; then inspect the code for unhandled None values, mutable defaults, unsafe parsing, leaked resources, and errors that lose useful context. If a request touches authentication, payments, deletion, or production migrations, call out the review and rollback requirements.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT CONTEXT] | Describe the repository purpose, Python version, relevant files, framework, and current behavior. | Python 3.12 FastAPI service. app/imports.py parses uploaded CSV files; tests use pytest. The endpoint currently accepts duplicate customer emails. |
| [TASK OR BUG] | State the feature to build or bug to fix, including the user-visible outcome. | Reject duplicate normalized email addresses within one uploaded CSV and return row numbers for all duplicates. |
| [INTERFACES AND DEPENDENCIES] | Paste relevant function signatures, schemas, APIs, allowed packages, and integration constraints. | Keep parse_customers(upload: UploadFile) -> list[Customer]. Pydantic v2 is installed. Do not add packages. |
| [INPUTS AND EXPECTED OUTPUTS] | Give representative valid and invalid inputs with the exact results or errors you expect. | Rows '[email protected]' and '[email protected] ' should raise DuplicateEmailError with rows 2 and 5; a blank email should keep the existing validation error. |
| [RUNTIME AND QUALITY REQUIREMENTS] | List performance limits, security needs, testing tools, deployment environment, and compatibility requirements. | Files may have 100,000 rows; do not load a second copy into memory; preserve the current JSON error envelope. |
How to use
- Paste the relevant function, schema, failing test, or stack trace along with the prompt so the AI does not guess at your codebase.
- Give examples of invalid input and the exact error contract, especially when another service consumes it.
- Run the generated tests, then inspect the diff for changed public behavior and dependency additions.
- Follow up with: “Here is the failing test output: [OUTPUT]. Diagnose the smallest fix and return only the changed files.”
Variations
Bug triage
Use this when you need to diagnose a reproducible Python failure before changing code.
Diagnose a Python failure in [PROJECT AND VERSION] using [ERROR OUTPUT], [MINIMAL REPRODUCTION], and [RELEVANT CODE]. First distinguish confirmed facts from hypotheses and rank the three most likely causes. Then give the smallest safe patch as a unified diff, with a pytest regression test. Explain why the test failed before and passes after. Do not invent missing source files, dependency behavior, or logs. Check for exception masking, version mismatch, input mutation, and concurrency or async misuse where applicable.
Code review
Use this when reviewing an existing function or pull-request snippet.
Review this Python code for [INTENDED BEHAVIOR]: [CODE]. It runs under [PYTHON VERSION] with [DEPENDENCIES]. Return findings ordered by severity: correctness, security, data loss, performance, maintainability, and test gaps. For every finding, cite the exact construct, show a concrete failure case, and propose a minimal corrected snippet. Include only findings supported by the code provided. Finish with pytest cases that would catch the highest-risk defects, including boundary and malformed inputs.
CLI script
Use this when building a reliable command-line automation tool.
Build a Python CLI for [JOB TO AUTOMATE] with inputs [INPUTS], output [OUTPUT], and environment constraints [CONSTRAINTS]. Use argparse unless I specify another interface. Provide a package layout, complete code, help-text examples, exit codes, logging approach, and pytest tests. Validate paths and user input before destructive operations; use dry-run by default when the task changes or deletes data. Do not execute commands, make network calls, or assume credentials in the generated example. State any operating-system differences.
Tips
- Give the AI the existing interface and a failing test before asking for code; this sharply reduces code that works only in isolation.
- Require errors to preserve the offending input or row number where it is safe to do so, since generic exceptions make production diagnosis slower.
- For parsing and I/O work, test empty values, invalid encoding, partial reads, and cleanup after exceptions, not only normal records.
- Avoid accepting a new package for a small utility until you have checked licensing, maintenance, dependency weight, and whether the standard library already covers it.
FAQ
Should I ask for a whole application in one prompt?
For meaningful projects, start with one bounded behavior and its tests. You will get code that is easier to run, review, and integrate.
Can I paste proprietary code?
Follow your organization’s data-handling rules. Remove secrets, customer data, private keys, and production URLs before sharing code with any external service.
Why request tests if the code looks correct?
Tests make the behavior executable and expose assumptions about invalid inputs, boundaries, and compatibility. They also prevent the same bug from returning later.