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

/light-review-RedGreen — Test first, then make it pass

This skill enforces one discipline: a failing test that fails on its own assertion exists and is confirmed RED before any production code is written. Then you make it green. Nothing else.

Why it matters: a test written after the code is tautological — it confirms the code does what the code does, not what the requirement says. Red-first is the only cheap proof the test can actually fail.

Two entry modes

• New behavior — the test encodes the requirement the new code must satisfy. It is red because the behavior does not exist yet.
• Bug fix — the test reproduces the bug: it asserts the correct result and therefore fails against today's buggy code. Green then means the bug is fixed AND a regression test guards it forever. This is the highest-value use — never fix a bug without it, unless the bug is genuinely untestable (see "When not to use").

The loop (one behavior at a time)

1. Locate the test project (usually UnitTesting\Tests.dproj) and the unit under test. If the project has no test project, do NOT guess a layout — ask the user whether to create one (template: c:\AI\Claude Code\TEMPLATE FOLDER\UnitTesting (TEMPLATE)\) and wait.
2. Write ONE failing [Test] for this behavior. It MUST:
   • use a real assertion (Assert.AreEqual, Assert.IsTrue, Assert.WillRaise, …) — never Assert.Pass as the sole assertion, never zero Assert.* calls;
   • assert behavior (a returned value, a raised exception, a state change), not "the type exists" or "the function is callable";
   • have a name that states what is verified.
3. Confirm RED — and for the RIGHT reason. Compile the test .dproj via the light-compiler agent (see Compiling), then launch the test EXE yourself and read the DUnitX counts. The test must fail on its assertion (DUnitX reports a failure — e.g. "Expected 5 but got 0") — NOT fail to compile, and NOT error out for an unrelated reason. A compile error or an unexpected exception means the test is wrong; fix the test before writing any product code.
4. Green — implement the smallest change that makes it pass. Reuse LightSaber before writing new code — a LightCore.* / LightVcl.* / LightFmx.* unit may already do it; uses that unit instead of hand-rolling, and say you checked. Then compile via the agent, launch the EXE, and confirm the test now passes and nothing else went red.
5. Refactor only if needed, then re-run the EXE to confirm it is still green.
6. Stop — do not commit. Leave the change for the user to review and commit; git is theirs to trigger.