Define good before judgment-heavy work

Problem

Agents can produce plausible work by inferring the quality bar from nearby context. That inference often works for routine edits, but it breaks down when the task depends on taste, naming, grouping, scope, review shape, public API judgment, or another standard that is easy for the user to hold but hard for the agent to guess.

A long plan is not a substitute for acceptance criteria, validation evidence, or proof that the result satisfies the user's real goal.

Preferred move

Before delegating or starting judgment-heavy execution, identify what "good" means for this task. Ask the model or the maintainer to state the ideas, rules, goal posts, naming criteria, review criteria, or acceptance checks first. Use that stated quality bar to perform the work, then verify the output against it.

Name the observable output, the checks that should pass, the evidence the handoff should include, and the remaining judgment that requires human review.

Translate adjectives such as "polished," "native," or "production-ready" into a few observable user tasks and quality dimensions. For an interactive tool, include discovering the primary action, seeing progress, inspecting results, recovering from failure, and retaining work after reopening where relevant. Add reading comfort, alignment, contrast, and realistic content sizes to a visual pass. Platform conventions help choose controls; they do not replace checking the complete flow.

Use examples and constraints already supplied by the user to set this bar. Ask only where a missing decision materially affects the result. A time limit narrows what can be established; it does not lower the evidence needed for a broad readiness claim.

Tradeoff

Do not over-specify exploratory work before the shape is known. For discovery, define good as a bounded answer with evidence, open questions, and a recommended next move. For taste-heavy work, define the taste criteria without freezing every resulting edit.

Agent instruction

For judgment-heavy work, establish the quality bar before changing the artifact. At handoff, show the proof of work against those criteria instead of relying on the existence of a plan.

Examples

Bad: the agent treats a plan as the artifact.

I wrote a detailed plan for fixing the flaky import workflow.

Good: the agent names the expected proof.

The import workflow is done when the retry test fails on main, passes with the fix, and the handoff
names the remaining external-service risk.

Good: the agent defines the naming bar before renaming.

Rule IDs should be stable handles: short enough to cite, specific enough to preserve meaning, and
careful about connector words when removing them would change the concept. I will rename against
that bar and then check for stale references.

References

W3C preliminary accessibility checks: concrete checks for contrast, focus, and interaction, with explicit limits on what they establish.