tradecraft

Adversarial review of an artifact against its stated purpose — a panel the owner buys by asking on a pull request, and the once-per-PR contract for connected reviewers. Use when the owner asks for a panel, when choosing or running that panel's lane, seats, defense or terminal stage, when dispositioning a connected reviewer's comment or what a review tool you invoked returned, or when deciding whether another bought pass is worth running; not for choosing what to build, not for a panel nobody asked for, and not for committing and pushing fixes afterward.

How to create and revise this practice's prose — the purpose header every governing document carries, which home each kind of content takes, what a cell carries, and the writing standards that keep it lean. Use when writing, restructuring or revising a skill or governing document, including a description alone or what sheds behind a pointer; when deciding where content belongs; or when a write-up, a pre-implementation artifact included, states derived figures or describes current behaviour; not for how code is written, though where such a rule belongs is here; not for reviewing finished content, and not for deciding what a change is for.

The binding rules every session receives first—ownership, the decision boundary, convergence before build, proof before release, review purchase, and where durable guidance lives. Use before the first substantial action in an adopting repository or whenever those rules are no longer in context; not for detailed implementation, review, writing, or repository-specific procedure.

Run or configure the automatic connected reviewer whose single finder pass reports concrete, evidenced defects. Use for this reviewer's finder, workflow, retry, or replay. Do not use as an internal review stage or for dispositioning comments after publication.

How a session and owner work together—which decisions are whose, the briefs and artifact that carry them, and how dispatched work is staffed, retained and read across changes. Use when deciding what a change is for or whose call it is; designing a change that owes an implementation brief; drafting, scoring, settling, recording or handing off a brief or artifact; putting or reporting a decision; dispatching or retaining an agent; recording or reading change paths; routing evidence to or receiving it as a doctrine-named coordinating session; delivering a review outcome; handing work back after time away; or when the owner cannot be reached. Not for writing skills or governing documents.

A chartered, time-boxed use of a built result as its consumer would use it, reported in a session note — the instrument that finds what only use finds. Use when a change to a skill's behaviour, a mechanism's surface, or what a consumer can do with the running result has been built, and again once a review's fix batch has rewritten what that material instructs or changed what someone using the result can do, before the review closes. Not for judging an artifact's reasoning, prose, or evidence — that is a review; not for testing a load-bearing premise before you assert it — that is a spike; not for anything a reader could settle by reading.

How evidence becomes a facts-only issue stating work the owner bought. Use when creating or extending an issue, deciding whether a finding earns one, or routing an unfixed finding to one of its two ends; not for deciding what work is worth doing, designing its solution, or writing the pre-implementation artifact at pickup.

Land finished work on the current branch safely — stage exactly the intended files, commit with an honest message, push to the branch's tracked remote, and verify the push actually arrived. Use whenever a validated change is ready to commit and push; never for new-branch creation or push-rejection recovery.

Testing a premise by running it before you assert it — a bounded, throwaway experiment that commits nothing, and the cold-seat A/B pattern for premises about what a reader does under a wording. Use when something you are about to assert — a claim in a pre-implementation artifact, a review thesis still disputed after a round, a candidate wording for a rule, an answer you reached while building — rests on material you cannot survey or on behavior no run you can consult has exercised; not for design and reasoning questions, which an adversarial review settles, and not for work that ships.

How this practice writes code that behaves consistently across platforms and runtimes — calling contracts, tests, text output, standard streams, and child-process streams. Use when writing or revising a script, test, hook or guard, when choosing a repository substrate, or when code prints, writes a comparable file, resolves a path, or launches another program; not for prose standards, content placement, review, or committing.

The read-only decision and explicit execution entrance for one product change. Use when the owner names an issue to inspect or continue, when the holder runs one named stage, posts generated proof, prepares connected reviewers, or builds a consumer tree; release and adopt remain registration commands. Not for deciding whether work is worth doing, changing an affirmed brief, choosing vendor defaults, merging, or answering an owner ask.