Claude-Tools-for-Delphi: Skill for Claude Code

Delphi Post Change

You just wrote new code. Some of it is wrong. Find the problems before the user does.

Precondition: if no code changes were made in this session, stop and tell the user: "No prior changes found in this session — there is nothing to verify." Do not invent edits to verify.

Step 1 — List what you changed

For each edit you applied in this session:

• file:line of the change
• one sentence: what the code does now (new feature) OR what the original did vs. what the new code does (bug fix)
• one sentence: WHY you made the change (the feature requirement or the bug you were fixing)

If you cannot state the "why" clearly, the change is suspect — flag it.

Step 2 — Load the false-positive memory and match against the list

1. Read c:/Users/<you>/.claude/agent-memory/light-review/patterns_common_false_positives.md if it exists.
2. Glob c:/Users/<you>/.claude/agent-memory/light-review/patterns_*.md and read the 2–5 files whose filename keywords match the files you edited (e.g., edited FormLessonChat.pas → read patterns_formlessonsetup_*.md, patterns_formview_main_chat.md, etc.).

For every edit in your Step 1 list, check: does this change contradict a known-good pattern? If yes, quote the line of the pattern file it contradicts, then revert immediately and note the revert. No quoted pattern line, no revert.

If the memory directory does not exist, skip this step.

Step 3 — Critical analysis of each change, including the opposite case

This is the ONLY judgement pass over the edits. Ask all of it here, in one go — do not judge the edits and then judge them again, because a second pass over your own first pass is the worst-scoring way to review anything (21.7% of planted errors caught against 28.6% for a fresh console, and 4.4 wrong complaints per document against 3.1 — Song, arXiv:2603.12123).

For every edit:

• Does the code match the stated intent? Does the new code actually do what you described, or does it just appear to?
• For bug fixes: did you fix the root cause or just paper over a symptom? Could the underlying problem still manifest in a different code path?
• For new features: does the feature handle the obvious edge cases — empty input, nil references, boundary values, range-check errors, missing objects, double-invocation?
• Did you change observable behavior the original code did not need to change? Unintended side effects: wrong default, swapped order of operations, different exception type, weakened invariant.
• Did you touch one call site but miss another? Grep for the procedure name or pattern across the project.
• Did you change a procedure signature, class layout, or DFM/FMX-bound field? If yes, find every caller and confirm they still work.
• Did the change introduce a new exception path, ownership shift, or broken invariant? Watch for: Free on a non-owned object, missing try/finally, FreeAndNil on a borrowed reference, dangling event handlers after a form closes.
• Resource leaks. New TStringList.Create, TFileStream.Create, TBitmap.Create etc. — is there a matching Free or try/finally?
• Threading. Did you touch code that runs on a non-main thread? Synchronize / Queue boundary preserved?
• What if the original code was actually correct (for fixes), or the new feature is solving the wrong problem?
• What if the change is correct but overshot — could a smaller change have worked?
• What if a related guarantee exists upstream that the new code now violates downstream?
• What if the feature is correct in isolation but breaks an assumption another part of the code relies on?