How I work with AI

I write guidance that helps an agent find the existing components, types, design tokens and conventions before it starts changing code.

For example: A new results view should start with the shared table and data contract. The skill points the agent toward those patterns and asks it to check the callers before inventing another implementation.

A change that fits the product and its codebase.

I build review workflows around requirements, the current code and evidence. A convincing comment still needs to hold up when you follow the actual behavior.

For example: If a reviewer says an empty result will crash, trace that state through the caller and reproduce it. Fix the failure if it exists; record the evidence if the code already handles it; keep the question open if the evidence is incomplete.

Findings that explain what fails, why it matters and how it was checked.

I turn recurring corrections into guidance that can be reused. That includes keeping agent instructions and review guidance aligned with the conventions they summarize.

For example: A keyboard-focus problem keeps appearing. Capture the recurring pattern, strengthen the relevant interaction guidance, and add a targeted check where it can catch the problem. Revisit that guidance when the component changes.

A lesson with a home, instead of the same comment on another pull request.

I give workflows a clear finish: the relevant checks, the state of the change, and an explanation a reviewer can use. Local changes, published fixes and untested behavior need distinct labels.

For example: For an interface change, the handoff includes the behavior that changed, the checks run and browser observations at the relevant sizes. A later edit means revisiting any evidence that the edit could invalidate.

A reviewable result with clear limits and next steps.