# Workflow-to-evals task brief

Reusable brief for your development team. Use with the available FieldSignal Claude or Codex skill. This is an example request, not an installation command or an additional product skill.

## Scope

- Workflow and decision boundary:
- Intended user outcome:
- FieldSignal evidence available through the supported MCP or CLI interface:
- Reviewed business rule and owner:
- Questions that are not yet resolved:
- Approved working environment for the data:
- Intended eval runner, if selected:

## Task

Using the evidence within this scope, prepare candidate evals for the specified decision. Identify which sources support each fact. Preserve missing information and uncertain case links. Separate observed behavior, practitioner explanation and reviewed expected behavior.

Give the agent only information available at the chosen decision point. Keep later outcomes, evaluator reference material and scoring criteria outside the agent input unless they are legitimately part of the task.

Include a case where the agent should proceed and a case where it should stop or request review. Add other cases only when they test a distinct condition. Label each case as observed, adapted or constructed. Do not invent missing facts or business authority.

## Requested output

For each case provide: identifier, evidence references, decision-time context, rule reference, required actions, forbidden actions, expected state or outcome, proposed assessment method, missing facts, review questions and coverage limits.

List the changes needed to adapt the cases to the selected runner. Use actual documented tool names when available. Otherwise describe the action in plain language and mark the mapping as unresolved.

## Review and execution

The process owner reviews intended behavior. The developer reviews executability and the grading method. Record the accepted version and open issues. Do not call a test passed until the identified runner has executed it and returned supporting results.

Keep evidence access separate from permission to change business systems or release software. Use the team’s existing development and release process.
