Start from the markup
Design the DOM before the API. If the element you would have written by hand is
a details, the component is a details. Props exist to arrange markup, not to
hide it.
Measure instead of reasoning
Where a question has a number attached, get the number. Whether a rebuild is redundant is a hash comparison, not an argument. Whether a role belongs on an element is a count of how many appear on a page. Whether a colour passes is a pixel read back off a canvas with the whole ancestor stack composited onto it.
Reasoning is what you do when measurement is impossible, not when it is inconvenient.
Verify the thing that ships
A green build proves the code compiles. It proves nothing about what a browser does with the output. After a component change, open the page.
The corollary is that verification has to be hostile: run the check against a case whose answer you already know, and if it agrees, then trust it on the cases you do not.
Let the gate do the blocking
A check you read with your eyes is a report. If it is meant to block, the exit code has to be the condition.
Write down what you decided not to do
A decision that produces no diff leaves no trace. The next review will reach the same question, spend the same time, and may answer it differently. Where it matters, a test pins the current shape and names the reason in its title.
Prefer the boring failure
Given two designs, prefer the one whose failure is loud. A class name assembled from a template literal produces no CSS and no error — the markup looks correct and the element is simply unstyled. A literal string that is wrong produces a rule you can see in the stylesheet.