B. Quality, Speed & Resilience · Prompt 17
Code Quality & Maintainability
Get the free PDFWhy it matters
The cost of messy generated code shows up when someone has to change it safely later.
Modeled on
Maintainability reviews of the kind static-analysis tools such as SonarQube score.
How to run this prompt
- Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
- Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
- Read the report. Keep the IDs you agree with.
- Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
- Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.
- Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
- Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
- Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.
The audit prompt
MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.
Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
so I can run them and paste the output.
Code Quality & Maintainability: what to check
Do a maintainability review. Do not refactor in this pass. Rank issues by how much they would slow a new contributor.
1. Flag functions that are very long (roughly over 50 lines) or nest conditionals more than about 4 levels. Cite the file. The number is a heuristic, not a law.
2. Find logic copied in two or more places that should be one function. Quote a short identifying line from each copy.
3. Find unused exports, imports, and variables you can confirm. If a symbol is used from outside the repo, say you are not sure.
4. Flag magic numbers and repeated hardcoded strings that should be named constants. Ignore one-off layout values unless they encode a business rule.
5. Find inconsistent error handling: some paths log and recover, others swallow the error with an empty catch.
6. Flag functions that mix layers, such as raw SQL next to JSX in the same function.
7. Rank the top 10 by drag on a new contributor. Recommend only the top 3 as the first fix-prompt IDs. Do not apply them.
8. Do not restyle the project or rename files for taste. Stick to changes that reduce risk.
Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.
Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.
Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
(IDs for this prompt use the prefix P17, for example P17-1, P17-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.
Then stop. Do not fix anything. Ask me which IDs I want fixed.