Before you submit

The self-check that catches what tests and CI do not — the browser console, the click nobody made, and what happens when something fails.

One command, about a minute

/kaeru:check — run it before /kaeru:submit. It only looks; it never changes anything.

Tests catch what someone wrote a test for. CI catches what the tests catch. What reaches a reviewer anyway, over and over, is a short list of things neither of them is watching — and every item on that list is something you can see for yourself in under a minute.

> /kaeru:check

  Before you submit

    Tests and lint ................ ✅ 3 passed
    Browser console ............... ⚠️  2 hydration warnings on /pricing
    Clicked what changed .......... ✅ the sign-in link opens /sign-in
    If it fails ................... ⚠️  nothing handles the error yet
    Runs on every request ......... ✅ the answer is remembered
    Not sure about ................ the wording on the button

  ⚠️ means worth a look before you submit, not that you did something wrong.

Here it is on a real project — a small static site with a sign-in link added to the home page:

A real run on a throwaway site, asked to print its table and nothing else. This is a recording of a real run — press play, then select any of it and copy.

What each line is, and why

Tests and lint

The project's own checks, run before you send it rather than after CI turns red. Nothing clever — it just happens first.

Browser console

Your change is opened in a real browser and the console is read.

This is the one that matters most, because some problems appear nowhere else. A hydration warning does not fail a test, does not show up when you check a URL, and does not make the page look wrong in a screenshot. It appears in the console and nowhere else, and it is usually the first sign that something will misbehave on somebody's phone.

Clicked what changed

If you added a link, it follows it and tells you where it went. A button, it presses it. A form, it fills it in and submits it.

A link that points at the wrong page looks perfect in a diff and perfect in a screenshot. The only way to find out is to click it, so the check clicks it.

If it fails

Only when the change touches something that talks to a server or fetches data: what happens when that call fails? If it errors, times out, or comes back empty, does the page still work, or does it break?

Things work in development because the network is your own machine and nothing is slow. Everything else is where the failures live.

Runs on every request

Same situation: does this run every single time somebody opens the page, and does anything remember the answer? A call that runs once per visit is invisible until the site is busy, and then it is the reason the site is slow.

Not sure about

Anything the check could not settle, in your own words. /kaeru:submit puts these in the pull request.

Writing down a doubt feels like admitting you did not finish. It is the opposite: it points the reviewer straight at the part that needs their judgement, instead of making them find it. "I wasn't sure whether this should say Welcome or ようこそ" saves more review time than a confident silence.

It runs whether you remember or not

/kaeru:submit runs the same checks before it commits, and stops if something is unresolved. You can tell it to go ahead anyway — that is your call — but you make it knowing.

A check that only happens when somebody remembers to ask for it is a check that stops happening.

Without the plugin

Not using the plugins, or working in a repo that has no .kaeru/where.md? Paste this before you open a pull request. It is the same list, as a prompt:

Before I open the PR, self-review this change and show me the results as a table.

1. Open every page my change affects in a browser on the dev server. Are there
   any new console errors or warnings — hydration warnings especially? Compare
   against a page I did not touch so you don't report noise that was already there.
2. Click the thing that changed: follow new links, press new buttons, submit
   changed forms. Tell me what actually happened, not what should happen.
3. Run the project's lint, type-check and tests.
4. If this change calls a server, an API or another service, answer two questions
   honestly: what happens when that call fails, and does it run on every request
   with nothing remembering the answer?
5. List anything you could not check or are unsure about, in plain words, so I
   can put it in the PR description.

Do not fix anything yet. Show me the table first, and mark a check you skipped
as skipped rather than passed.

Why a skipped check is never a tick

The check reports what it actually ran. A tick nobody earned is worse than a warning, because it spends the reviewer's trust as well as their time.

Whose job is which

/kaeru:check is yours, before the pull request exists: did I break anything I can see?

Sanity-testing the pull request afterwards — merging it with the latest main, walking the whole feature, comparing before and after — is the developer's, and it happens on their machine after you submit. You are not expected to do that part.

What's next

Making a change — where this fits in the flow
For developers — the review side

On this page