Use this as the standing prompt template for any future "review this package" request — to any AI, not just Claude — on drugs-and-users.org mod packages (BBCode mods, admin tools, standalone CLI scripts, etc.).
Do a deep code and security review of the attached package. This is a
review only — do NOT edit, patch, or regenerate any file. Findings first,
fix only if I explicitly ask afterward.
Read every file in the archive in full, including any file marked
"reference only" or "not currently used" in its own header — bugs there
still matter if the file is ever copied from again.
Specifically check for:
1. STRING/LENGTH ARITHMETIC BUGS — any substr(), strpos(), array offset,
or length comparison involving a literal (e.g. checking a file
extension, a fixed-width prefix/suffix). Don't eyeball it — compute
it against 4-5 concrete real-world example inputs (including edge
cases: empty string, string shorter than the slice length, exact
match, near match) and show the actual result, not just "looks right."
2. CROSS-FILE CONSISTENCY — if the same check/string/constant is meant
to appear in more than one place (e.g. an install script and its
matching uninstall "needle", or a live code path and a reference/
mirror copy of it), diff them explicitly. Flag ANY drift, even in
files marked unused/reference-only.
3. SQL INJECTION — confirm every query uses parameterized placeholders
(SMF: {int:...}/{string:...} via $smcFunc['db_query']), not string
concatenation, including inside loops or dynamically-built WHERE
clauses.
4. XSS — every value that reaches HTML output and could originate from
user input (filenames, URLs, post content, attachment metadata) must
be htmlspecialchars()'d (or equivalent) at the point of output, not
just at the point of storage.
5. SSRF / URL-FETCH SURFACES — any code that fetches a URL supplied by
a normal (non-admin) user. Check: is the scheme restricted (http/https
only)? Is the HOST restricted (no loopback/private/link-local/
metadata ranges)? Are redirects followed, and if so, is the final
resolved host re-validated? Assume any forum member can supply this
URL unless the tag is admin-gated — check whether it is.
6. PATH TRAVERSAL / LOCAL FILE DISCLOSURE — any filesystem path built
by concatenating a DB-stored or user-influenced value (filename,
ID, etc.) without basename()/realpath()-containment. Flag even
"legacy fallback" or "old data" code paths — those are exactly where
older/looser sanitization is most likely to have let something
through.
7. JS/CSS NAMESPACE COLLISIONS — if this mod's rendered output shares a
page with sibling mods already built (check localStorage keys, global
JS function names, CSS class names), confirm this mod isn't reading
or writing another mod's storage key or clobbering its global by
accident (typically a copy-paste artifact from mirroring another
mod's architecture — check explicitly for this if the header/comments
say "mirrors X's architecture").
8. INSTALLER IDEMPOTENCY — confirm install scripts detect and don't
duplicate their own prior insertion on a reinstall, AND correctly
detect/replace OLDER versions of their own inserted block (not just
"does an LMV/PDF/etc. block exist at all" — a stale block should
count as needing replacement, not as "already installed").
9. RESOURCE CAPS — any remote fetch or local file read should have an
explicit byte cap; confirm it's actually enforced (not just declared
as a constant and never applied).
10. DOC-BLOCK / VERSION-BANNER CONVENTION — every module (including
small installer/register/uninstall scripts, not just the main class
file) needs the standard @version/@date doc-block header, AND its
live output/behavior needs a visible version+date stamp if it
produces any output at all — including error/die() messages for
scripts with no normal page output. Flag any file in the package
missing either.
11. PER-INSTANCE OUTPUT DUPLICATION — if a render function can be
called multiple times on one page (multiple tags, autodisplay of
multiple attachments), check whether it emits full <style>/<script>
blocks each time rather than once per page. Not a bug exactly, but
flag it as a real efficiency/bloat finding.
Also cross-check package-info.xml itself: does every <require-file>,
<remove-file>, <hook>, and <code> action actually correspond to a real
file/behavior in this package (e.g. flag <remove-file> entries for CSS
or asset files that no install step in THIS package actually creates —
usually leftover cruft from an earlier architecture)?
Deliver two things:
1. A findings doc — one finding per issue, each with: what you found,
exact file/line, concrete reproduction/evidence (not just an
assertion), and severity (critical/security/functional/minor/
documentation/convention). End with a short "checked and clean"
section listing what you verified was NOT a problem, so I know the
difference between "not found" and "not checked."
2. Nothing else changed — no code, no zip, unless I ask for the fix
separately after reviewing findings. Deliver both docs as actual
downloadable .md files, not just chat text.Built from the LMV v3.3.4 review (Sept 2026), where the highest-severity finding — is_md never matching due to a substr(-4) vs .md length mismatch — was only caught by actually computing the string operation against real filenames rather than reading the code and assuming it was right. That's the recurring failure mode worth guarding against in every future review: a length/offset bug reads as correct at a glance and only fails empirically.