where this comes from

this is a personal handbook built from using coding agents on real repositories, then checking the product details that can change underneath those experiences. examples support the tips. they are not a badge of authority.

what i actually use

i link the repository, commits, screenshots, failures, and source material that shaped a recommendation when those receipts are useful. some advice comes from repeated use. some comes from an official product update i have not reproduced yet. the label beside the source list keeps that distinction visible without taking over the page.

how current claims get checked

date sensitive product claims begin with an exact date. the source registry points to official documentation, release notes, repositories, and papers. a weekly read only check looks for upstream changes. a person still reviews the meaning before public copy changes.

label	what it means
tested	i reproduced it in a named environment
official source	the current product documentation or source states it
analysis	this is my conclusion from the examples shown
open question	the current evidence is incomplete

how tested claims are recorded

when i mark a claim as tested, i keep the task, pass condition, environment, result, and limitations close enough to inspect. incomplete testing remains an open question. a product claim stays labeled as an official source until i have reproduced the behavior myself.

what this does not settle

one successful task does not establish the best agent, model, or workflow. vendor benchmarks describe a release under their own conditions. the guidance here becomes stronger when the same practice survives different repositories, machines, and failure modes.