Persona/Role Assignment

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

You are reviewing an API retry loop with its code and write contract available. You want an agent to examine failure paths rather than invent a finding to live up to an expert persona.

Teaching fixture, retry.ts: line 1 is for (let attempt = 0; attempt < 3; attempt++); line 2 is try { return await createOrder(); }; line 3 is catch (error) { if (attempt === 2) throw error; }. The supplied contract says createOrder has no idempotency key and may create the order before the client receives a timeout. Both instructions use these same inputs.

Mechanism

1. Describe an actual responsibility, such as failure-path reviewer, and name the file in scope.
2. Supply questions belonging to that responsibility: duplicate writes, final error reporting and a bounded retry count.
3. Require each finding to identify its location, trigger and observable consequence. List missing evidence when necessary; zero supported findings is a valid result.

The role directs attention. Code, interface contracts and check records still support the judgment.

Bad example

Review the retry.ts fixture and contract above. You are an elite expert. You must find a serious problem and prove that this implementation is unreliable.

Good example

Act as a failure-path reviewer of the retry.ts fixture and supplied contract above. Examine duplicate writes, the retry bound and final errors. Report only supported defects. For each, identify the code location, triggering condition, execution path and observable consequence. State missing evidence when necessary. Report zero findings if none are supported; do not invent a defect to satisfy the role.

Why the change matters

The bad instruction combines a prestigious identity with a predetermined verdict, encouraging a search for evidence that fits it. The improved instruction turns the role into review questions and requires conclusions to follow from the inputs. Readers can inspect the evidence instead of relying on a title.

Observable expectation

Check that a duplicate-order finding connects lines 2 and 3 with the supplied timeout-after-write contract. An illustrative result is: the first creation succeeds but its response times out; catch retries createOrder; a second order may be created. The loop allows at most three attempts.

This illustrates evidence organization, not an executed result. If all calls instead share an idempotency key, analyze that contract again rather than copying this conclusion. A finding without a location or trigger does not pass the check.

Limits

A role cannot replace missing code, domain knowledge or tests. Some checks require the real service contract or fault injection; this static example does not establish that production has created duplicate orders. The method’s source remains unconfirmed, and its label is retained.