skills/harry-writing-style-skill/EXAMPLES/technical-review/good.md

Good Examples: technical-review

1. Yeah that works, it should be lazy loaded if possible. Also, when an image is selected it takes up to 10 seconds to show cropperjs. That is unacceptable.

   Works because it accepts the good part, then names the unacceptable failure plainly.

2. We recently updated River, so we are able to use unique jobs, but only on specific parts of the input payload. Would it be worth making sure these jobs are consistently queued and not submitting duplicates correctly first?

   Works because uncertainty is technical, not politeness. It points to the ordering problem.

3. Okay, so of all the attempts, the in-browser approach is the one that works. So we should consolidate on that one. I'm looking for a clean, beautiful approach. As if you're going to be presenting your code to the entire internet.

   Works because it makes a decision, rejects scattered attempts, and sets a high quality bar.

4. The dialog should not change size when I change tab. It should have an internal scroll.

   Works because it states the UI invariant directly.

5. Planetscale uses pgBouncer to my knowledge, if we moved to planetscale we wouldn't keep timescale because the compression policies aren't supported. Either way the cost increase seems quite excessive.

   Works because it combines domain detail, uncertainty, and blunt cost judgement.

6. Take a look at 592 in a worktree, before we'd call a trpc endpoint in a railway function every hour to do this work, now it should be self contained within a pgBoss chunked job?

   Works because it frames the architecture change as a specific before/after.

7. Yes. Caddy should be the default gateway. I'm not sure how we'd handle efficient routing for multiple web instances though. Ideally we'd want to find the lowest latency path available but that would require an edge network of some sorts right?

   Works because it gives a clear default, then names the unresolved scaling problem.

8. The display should be like this.

   Works because sometimes the right technical review is a direct visual correction, not prose.

9. Review the recent changes for craftsmanship, simplicity, naming, and maintainability. Focus only on these touched files. Read-only review only; do not edit files.

   Works because it scopes review quality and permissions tightly.

10. This seems wrong.

Works when attached to concrete output/logs. Do not soften it to "unexpected behaviour" by default.