What this prompt does
This prompt makes the model a senior Python engineer who values testability over cleverness and asks it to refactor a monolithic script into an installable package without changing its behavior, returning working code rather than pseudocode. It defines six deliverables: a module split by responsibility (input/IO, core processing, output, orchestration), type hints throughout with small pure functions where the logic allows, dependency injection for the external services you name so they can be mocked, a pytest suite with mocks covering the main path and at least two failure cases, a pyproject.toml with build config and a console_scripts entry point, and a short CHANGES note listing any subtle behavior differences. The structure works because it creates seams — the boundaries that make a previously untestable script testable.
Four variables drive it. [package_name] names the target package (default report_toolkit). [python_version] sets the language target. [external_deps] lists the services to isolate behind DI, like a database client, S3, and SMTP. [script] is where you paste the actual code to refactor. Dependency injection in deliverable three is the load-bearing part: pinning it carefully is what makes the pytest suite in deliverable four genuinely meaningful, because mockable external services let the tests exercise real logic instead of hitting live systems.
When to use it
- You have a standalone Python script that two or more people now depend on.
- A 300-line file has hit a ceiling and needs seams for testing and mocking.
- You want behavior preserved exactly while structure improves.
- External services like a database, S3, or SMTP need to be injected and mockable.
- You want a pytest suite covering the main path and at least two failure cases.
- You need a proper package with pyproject.toml and a console_scripts entry point.
Example output
Expect the file tree first, then each file in full, targeting [python_version]. The script is split into input/IO, core processing, output, and orchestration modules under the [package_name] package; type hints run throughout with small pure functions where possible; [external_deps] are injected so tests can mock them; a pytest suite covers the main path plus at least two failure cases; a pyproject.toml provides build config and a console_scripts entry point; and a CHANGES note lists any subtle behavior differences that could not be avoided. Behavior is preserved, so it is a faithful restructuring rather than a rewrite.
Pro tips
- Paste the complete script into
[script]; partial code forces the model to guess at the behavior it must preserve. - List every service in
[external_deps]you want mockable, since each becomes a DI seam for tests. - Pin the DI carefully — it is what makes the pytest suite actually meaningful rather than testing nothing.
- Read the CHANGES note closely; subtle behavior differences are where a "behavior-preserving" refactor can surprise you.
- Set
[python_version]to your real interpreter so type-hint syntax and packaging metadata match. - If the module split feels off, re-run clarifying which logic is IO versus core processing in your
[script].
