PHP prompts for ChatGPT, Claude and Codex

These 13 PHP prompts help ChatGPT, Claude, Claude Code and Codex write PHP that matches your version and holds up in production: modern PHP 8.4 and 8.5 syntax, SQL injection and password fixes, PHPUnit tests, legacy refactors and upgrade plans. Each prompt is a template with blanks you fill in, and none is tied to a framework.

For framework-specific work, the Laravel prompts cover Eloquent, queues and Artisan.

How to use these prompts

Copy a prompt, replace each blank in double braces, or keep the default after the colon. {{php_version:8.4}} means PHP 8.4 unless you change it.

State your PHP version first. The PHP supported versions page lists 8.2, 8.3, 8.4 and 8.5 as supported as of 26 October 2026. PHP 8.5 was released on 20 November 2025 and gets security fixes until 31 December 2029. PHP 8.2 security support ends on 31 December 2026, so code on 8.2 needs an upgrade plan now.

Paste real code, not a description of it. Include the class and the code that calls it, because PHP behavior often depends on the caller: under declare(strict_types=1), the type declarations manual says strict typing applies to calls made from inside that file, not to functions declared in it.

In an agent, let it run your tests and static analysis after each change. Ask it to list anything it changed outside the files you named.

Which PHP versions are supported?

Use this table to fill the version blank and decide how urgent an upgrade is. Dates are from the PHP supported versions page, read on 26 October 2026.

If you're on 8.2, prompt 11 helps plan the move. If you're on 8.4 or 8.5, prompts 1 and 2 put the newer syntax to work. Code that must run on several versions should name the oldest one, so the model doesn't use syntax that version can't parse.

How do you write modern PHP?

1. Modernize a class to PHP 8.4

The PHP 8.4 release page introduces property hooks, asymmetric visibility such as public private(set), and calling methods on new MyClass() without extra parentheses.

Modernize this class for PHP {{php_version:8.4}}:

{{code}}

Use constructor promotion, readonly properties, enums for fixed sets of
values, typed properties and return types, and match instead of long
switch blocks. Replace getter and setter pairs with property hooks or
public private(set) only where it keeps the public API the same for
callers. Add declare(strict_types=1) if it's missing and list any call
sites that will now throw TypeError. Show the new class, then list
every behavior change, however small.

2. Use the PHP 8.5 pipe operator and clone with

PHP 8.5 adds the pipe operator |>, clone($obj, [...]) for updating properties while cloning, array_first() and array_last(), and the #[\NoDiscard] attribute.

Our app runs PHP 8.5. Rewrite these functions where the new features
make them clearer:

{{code}}

Use the |> pipe operator for chains of single-argument transforms,
clone($this, [...]) for with-er methods on readonly classes,
array_first() and array_last() instead of reset() and end() tricks,
and #[\NoDiscard] on functions whose return value must be used. Leave
code alone where the new syntax isn't clearer. For each change, show
before and after and say why.

3. Replace magic strings with enums

This code passes {{concept:order status}} around as strings and
constants:

{{code}}

Design a backed enum for it with the right backing type, methods for
behavior that currently lives in switch or if chains, and a static
constructor for parsing input that fails clearly on unknown values
(tryFrom versus from, with a reason). Update the call sites, the
database mapping and any JSON output. List places where an invalid
value could still get in.

How do you secure PHP code?

4. Fix SQL injection with PDO prepared statements

The PDO prepared statements manual says that if an application exclusively uses prepared statements, no SQL injection will occur, but "if other portions of the query are being built up with unescaped input, SQL injection is still possible."

Find every SQL injection risk in this PHP code:

{{code}}

Rewrite each query with PDO prepared statements and bound parameters.
For LIKE searches, bind the whole value including the % signs. For
dynamic column names, sort direction or table names, which can't be
bound, use an allowlist. Set PDO::ERRMODE_EXCEPTION and turn off
emulated prepares if it suits {{database:MySQL}}. Show the fixed code
and list every query you changed with the risk it had.

5. Fix password storage

The password_hash() manual recommends a column that can expand beyond 60 bytes ("255 bytes would be a good choice") and notes that the default bcrypt cost rose from 10 to 12 in PHP 8.4.

Review how this app stores and checks passwords:

{{code}}

Replace anything custom (md5, sha1, salts we made up) with
password_hash() using PASSWORD_DEFAULT and password_verify(). Add
password_needs_rehash() on login so old hashes upgrade silently. Plan
the migration for existing users without forcing a reset, check the
column length, and flag the 72-byte input limit of bcrypt. Show the
code and a migration plan.

6. Stop XSS in templates

Since PHP 8.1, htmlspecialchars() defaults to ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401, so single quotes are escaped by default.

Find every place this PHP code prints user-controlled data:

{{code}}

For each, say the output context (HTML body, attribute, URL, inline
JavaScript or CSS) and apply the right escaping: htmlspecialchars()
for HTML, rawurlencode() for URL parts, json_encode() with
JSON_HEX_TAG and related flags for data passed to scripts. Add a small
escape helper if output is repeated. List any context where escaping
isn't enough and the design should change.

How do you refactor legacy PHP?

7. Split a legacy script into testable pieces

This is a legacy PHP page that mixes SQL, business rules and HTML:

{{code}}

Refactor it in safe steps: first extract the database access into a
repository class, then the business rules into a service with no
global state, then leave a thin script or controller that renders a
template. Keep the URL and output byte-for-byte the same. After each
step, tell me what to test by hand. Use Composer PSR-4 autoloading
under the {{namespace:App}} namespace.

8. Explain an error and its stack trace

Explain this PHP error and stack trace from {{environment:production}}:

{{error}}

The code on the lines it mentions:
{{code}}

Say what the error means in plain words, the most likely cause in our
code, and two other possible causes ranked by likelihood. Give the fix
and a test that would have caught it. If the error depends on a php.ini
setting or extension, say which one and how to check it.

9. Add types to untyped code

Add parameter, return and property types to this untyped PHP code for
PHP {{php_version:8.4}}:

{{code}}

Infer types from how the code is used, use union and nullable types
where the code really accepts several, and mark anything you can't
infer with a TODO instead of guessing mixed. List each place where
adding a type could change behavior for existing callers, such as
string-to-int coercion that will now throw under strict_types.

How do you test and upgrade PHP?

10. Write PHPUnit tests

Write PHPUnit tests for this class:

{{code}}

Cover the happy path, each branch, invalid input and one edge case
from the code. Use data providers for input tables, test doubles only
for things we don't own (HTTP, clock, file system), and clear test
names that describe behavior. Don't test private methods directly. If
the class is hard to test, say which dependency to inject and why.

11. Plan an upgrade to PHP 8.5

The PHP 8.5 deprecations list includes the backtick operator, non-canonical casts such as (integer) and (boolean), null as an array offset, and a soft deprecation of __sleep() and __wakeup().

Plan an upgrade from PHP {{from:8.3}} to 8.5. Here is composer.json and
a sample of our code:

{{files}}

Check the code against the PHP 8.5 deprecations: the backtick
operator, (integer), (boolean), (double) and (binary) casts, null used
as an array offset, __sleep and __wakeup, curl_close and imagedestroy,
and incrementing non-numeric strings. List packages that need new
versions. Give a step-by-step plan with tests to run after each step,
and mark anything you're unsure applies.

12. Speed up a slow PHP endpoint

This PHP endpoint takes {{time:1.8 seconds}}. Here is the code and a
profile or slow log if we have one:

{{code}}

Find the cost: repeated queries in loops, missing indexes, work that
could be cached, large arrays held in memory, and slow external calls
without timeouts. Rank fixes by expected gain. Check our OPcache
settings if I include php.ini. Tell me how to measure each fix before
and after.

13. Write a Composer package skeleton

Create a Composer package called {{package:acme/money}} for PHP
{{php_version:8.4}} that does this:

{{purpose}}

Include composer.json with PSR-4 autoloading and a PHP version
constraint, a src folder with one main class, PHPUnit tests, a README
with install and usage examples, and a GitHub Actions workflow that
runs the tests on each supported PHP version. Keep dependencies to
zero unless the purpose needs one.

Turn your favorite one into a skill

If you run the SQL injection or upgrade prompt on every pull request, make it a skill so Claude Code or Codex applies it when the task matches. Paste the prompt into the free SKILL.md generator to get a valid SKILL.md in your browser. For broader checks, the security review prompts work in any language, and the SQL prompts help when the query itself is slow.

To keep these prompts close at hand, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, blanks like {{php_version:8.4}} stay fillable, and Cmd+K finds any prompt by name or tag.