Telling an assistant to be an RTL expert leaves basic decisions open: may it edit the design, assume an asynchronous reset, or call a simulator? A task contract makes these boundaries visible. It records the input snapshot, the permitted actions, the required output and the condition for stopping. This helps an engineer locate a workflow failure without having to reconstruct an entire conversation from memory.
For this team, the spec reviewer extracts obligations and ambiguities from the specification. The RTL reviewer reads the same specification plus the RTL and proposes requirement mappings and counterexamples. Each begins before seeing the other's draft to reduce anchoring. The coordinator then checks citations, merges duplicates and records disagreements. These are separate passes, but they remain potentially correlated judgments; no role can certify its own accuracy by naming itself a reviewer.
Course contract v1; all files are synthetic and read-only.
snapshot: enable-demo-v1; inputs: spec.txt S1-S3, rtl.txt R1-R6
spec reviewer: extract {requirement_id, obligation, ambiguity, source}
RTL reviewer: return {claim_id, requirement_id, code_ref,
claim, counterexample_or_unknown, status}
coordinator: return {accepted_candidates, disagreements,
missing_inputs, human_checks}; do not edit either source.
All roles: no tools, network, writes, waivers or signoff claims.
Allowed statuses: supported_candidate, unsupported, unresolved.
Stop after one draft each and one coordinator pass.An output field is useful only when a consumer knows its meaning. Here, supported_candidate means the reviewer supplied inspectable evidence, not that a design defect is proven. A code reference identifies the statement being discussed; a requirement reference identifies why it matters. The counterexample field describes reset, enable and data values over an edge. If the source packet does not determine the behavior, the correct entry is unknown with a specific question.
Contracts also protect the receiving engineer from scope drift. Suppose the RTL reviewer proposes changing a clock-gating cell because it dislikes a coding style. That observation is outside this functional review unless it connects to an explicit requirement. Preserve useful out-of-scope questions separately, but do not count them as defects or implement fixes. STA and PD reviewers need the same discipline when a report excerpt lacks constraints, corners or physical context.
Rewrite this assignment: 'Review the reset and fix anything suspicious; ask another agent if needed.' State exactly which inputs are available, who can produce a finding, what evidence is required and which actions are disallowed. Include how the reviewer should handle an absent reset requirement. Your contract should be short enough to read before work starts and precise enough that a coordinator can reject a nonconforming response without guessing intent.
Read only snapshot enable-demo-v1 and inspect reset behavior against the provided spec. Return a requirement ID, RTL reference, claim and edge-by-edge counterexample or unknown. Do not edit files, invoke tools, delegate further or approve the design. If reset behavior is unspecified, return an unresolved requirement question rather than a defect or an assumed convention. Stop after the requested draft.
A prompt contract describes behavior; a real execution wrapper must enforce access boundaries separately. Even perfect field names cannot prevent an incorrect interpretation of RTL. The least-privilege principle in NIST SP 800-53 Rev. 5, September 2020, AC-6 is relevant background for restricting actual capabilities. The role fields above are a local teaching format, not an API standard or a vendor feature.