operator-brief

# Operator brief Make the operator understand the practical meaning of a complex technical finding and any decision it requires while preserving the technical finding as the evidence-bearing authority. ## Input Use the technical finding supplied in `$ARGUMENTS`, named by the user, or already established in the current task. Read the complete finding and any directly referenced material needed to interpret it. If the finding cannot be identified, ask for it rather than reconstructing one from hints. Do not edit the finding, its subject, or supporting artifacts unless the user separately asks for those changes. ## Write the brief Start with what happens, why it matters, or what the operator needs to decide. Keep conditions that control reachability, scope, impact, or confidence next to the claims they qualify. Do not turn a narrow but serious problem into a general one, or make a qualified conclusion sound certain. Use ordinary domain language and project terms with canonical definitions normally. Expand or define terms coined for this task and terms inherited from artifacts that have no canonical definition. A literal code or schema identifier may remain, but state what it represents before relying on the identifier. Do not promote vocabulary during this operation. Add only enough mechanism to connect the practical account to the technical finding. Put deeper mechanism after the practical explanation. When the technical finding is retained in a file or report, point to...