Know what to check
before you merge.

One public API disappears. An existing caller breaks.

This synthetic JavaScript fixture originally exports chargeCard and refund. The change removes chargeCard. OpenThunder checks the API diff, and a separate Node test attempts to import and call both functions.

export function refund(id) { return { ok: true, id }; }

export function chargeCard(amount) { return { ok: amount > 0, amount }; }
export function refund(id) { return { ok: true, id }; }

Executed 2026-09-11 with Node v24.17.0. Inspect commands, output, commits, and CLI hash.

import { test } from 'node:test';
import assert from 'node:assert/strict';
import { chargeCard, refund } from './lib.js';
test('existing consumer can import and call both public functions', () => {
  assert.deepEqual(chargeCard(10), { ok: true, amount: 10 });
  assert.deepEqual(refund('order-1'), { ok: true, id: 'order-1' });
});

What this establishes: the restored function passes this consumer check. The CLI result is a separate static recommendation. This is not a real payment integration, a complete behavior test, or a guarantee that the change can ship.

The useful question is what remains untested.

The repair preserves this caller, but refund failures, invalid amounts, and duplicate requests are outside this check. A useful review names those limits so a person can decide what else matters.

1. Inspect the change: which public behavior or caller could be affected?
2. Run the relevant check: use a test that would fail if that behavior broke.
3. Review the new evidence: confirm its commit, inspect failures, and decide what still needs checking.

Start with one change in your repository.

From a Git repository with uncommitted changes or a branch ahead of its base, run:

npx @skillstech/openthunder can-i-ship

Requires Node.js and access to the package registry on first install. Package download is separate from analyzing your source locally.

The default command analyzes the change; it does not establish that your tests ran. Run relevant tests separately and keep their output with the reviewed version. A missing environment is a setup problem to resolve, not a passing result.

Make the next review easier for your team.

Use the review brief to hand over what was checked and what remains uncertain. When your team needs shared review history and repository quality gates, explore Team.