The reviewer's procedure for a finished engineering task: what is read and what is deliberately not, the order that makes the review cheap (paths, checks, criteria, then the request), how findings are keyed to the contract, the three verdicts and what each…
What to do the moment a person asks for something new in conversation — a feature, a fix, a change, a rename. The answer is never a paragraph promising to file it and never a silent write: it is a card in the conversation the person can approve to start the…
How a request — a bug report, a store review, a support email, a chat message, an incident, a dogfood note — is read once and ends in exactly one of three places: an engineering task, an honest written answer, or a link to the open request it duplicates.…
One page: the question the Design seat is judged by, the states a design must cover before build starts, and the ways this seat has failed. Read before drawing, and before calling a design done.
One page: the question the Eng seat is judged by, what a verifiable change carries, and the ways this seat has failed. Read at the start of every worker run and before completing it.
One page, not a manifesto: the question the PM seat is judged by, the five things a decision-ready card must carry, and the ways this seat has actually failed. Read before filing any recommendation, and again when one is returned.
One page: the question the QA seat is judged by, what an independent verdict is made of, and the ways this seat has failed. Read before every review and before writing a verdict.
How a request that changes what people see gets a visual a person decides against — one mockup or one flow diagram, as an artifact on the request — and how the same request is closed with an after-shot from the running product. Covers when a visual is owed,…