Help me implement [TASK] in Python. The code will run in [PYTHON VERSION AND ENVIRONMENT]. Here is the existing code, interface, or relevant context: [EXISTING CONTEXT]. These are the input and output requirements: [CONTRACT]. These constraints apply: [CONSTRAINTS]. First, state any assumptions and identify ambiguities that could change the implementation. Then provide: 1. A short implementation plan naming the functions or modules you will add or change. 2. Complete, runnable code in fenced Python blocks. Preserve the existing public API unless I explicitly request a change. Include imports and dependency instructions; use only the standard library unless I authorize other packages.
3. A concise explanation of the key choices, including error handling, time and space complexity where meaningful, and any security or data-validation concern.
4. A pytest test file or test functions covering the normal case, boundary cases, invalid input, and the failure mode most likely in this task.
5. A short “How to run” section with the exact command or commands.
Treat [CONTRACT] as the source of truth. Do not invent endpoint behavior, database schema, credentials, package availability, or sample production data. If the task touches files, network calls, money, authentication, or destructive operations, make those effects explicit and default examples to safe, non-production behavior.
Before answering, self-check that every symbol referenced is defined or imported and mentally trace the supplied examples plus at least two edge cases. If a required input is missing, ask up to 3 clarifying questions; otherwise, provide the requested implementation.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TASK] | Describe the feature, script, bug fix, or function you need. | Add a CSV importer that validates rows and returns accepted records plus row-level errors. |
| [PYTHON VERSION AND ENVIRONMENT] | Enter the Python version, operating environment, and relevant framework or runtime. | Python 3.12, FastAPI service, pytest available |
| [EXISTING CONTEXT] | Paste the relevant existing code, file layout, API signatures, or error output. | models.py defines Customer(email: str, joined_at: date); import_csv(content: str) is the new function. |
| [CONTRACT] | Specify valid inputs, expected outputs, examples, and error behavior. | CSV headers are email,joined_at. Trim whitespace; email must contain one @; dates use YYYY-MM-DD; keep valid rows and report 1-based CSV row numbers for invalid rows. |
| [CONSTRAINTS] | List limits such as allowed packages, performance targets, compatibility, or style requirements. | standard library only, files up to 10 MB, do not write to the database |
How to use
- Paste the relevant function signatures and exact examples, not just a broad feature request.
- Run the generated tests in your project and verify that imports, paths, and package versions match your environment.
- Check every external effect, especially file writes, network requests, and database changes, before executing code.
- Follow up with: “Now adapt this to my actual file layout below and show only the diff plus any changed tests.”
Variations
Debug traceback
Use this when you have a reproducible Python error.
Diagnose and fix this Python failure: [TRACEBACK]. The relevant code is [CODE], running on [ENVIRONMENT]. The expected behavior is [EXPECTED BEHAVIOR], while the observed behavior is [OBSERVED BEHAVIOR]. Explain the root cause before proposing a minimal patch. Then provide the corrected code and pytest coverage for the regression and one nearby edge case. Do not hide errors with a broad except clause or alter unrelated behavior. Self-check that the patch addresses the traceback path and that every changed assumption is stated. Ask up to 3 questions only if the reproduction is incomplete.
Code review
Use this before merging a Python change.
Review this Python change for correctness, maintainability, security, and test gaps: [CODE OR DIFF]. Its intended contract is [CONTRACT], and it runs in [ENVIRONMENT]. Return findings ordered by severity: blocker, important, and minor. For each finding, cite the relevant code behavior, explain the concrete risk, and give a focused fix. Then list missing tests, including boundary and invalid-input cases. Do not recommend style changes that are not tied to readability, correctness, or project conventions. Self-check that every finding is supported by the supplied code and avoid inventing repository context.
Data script
Use this for a safe one-off transformation or report.
Write a Python script to transform [INPUT FORMAT] into [OUTPUT FORMAT] for [PURPOSE]. Sample input and desired output are [EXAMPLES]. The script must obey [RULES] and run on [ENVIRONMENT]. Provide complete code, command-line usage, input validation, and a dry-run or preview mode if the operation can overwrite files. For each rejected record, report a useful reason without exposing sensitive values. Add tests for malformed input, empty input, and duplicate or conflicting records as applicable. Self-check that paths are user-provided rather than hard-coded and that the script does not overwrite output without an explicit option.
Tips
- State the contract with concrete examples, including what should happen for invalid input; edge cases cannot be inferred safely from a one-line request.
- Ask for a minimal patch against pasted code when maintaining an existing project, because full rewrites often break hidden interfaces.
- Treat generated dependency commands as suggestions until you confirm your project’s package manager and lockfile conventions.
- For parsing and data code, require tests for empty values, malformed values, duplicates, and encoding or timezone assumptions when relevant.
FAQ
Can I run AI-generated Python code immediately?
Run it first in a test environment and inspect external effects. Generated code can make inaccurate assumptions about your project or dependencies.
Should I paste my whole repository?
Usually no. Share the function signatures, relevant files, data contract, and full traceback; add more context only when the answer identifies a dependency.
Why ask for tests in the prompt?
Tests make input assumptions visible and catch common happy-path-only implementations. They also give you a quick way to verify the suggested fix.