Start from a reviewable output

The official guides recommend giving a task an outcome, sources, constraints, deliverable, and review point. They also describe returning artifacts with evidence and distinguishing completed actions from pending ones. The brief below extends that idea into an original planning template; it is not a vendor feature or an executed workflow.

Documentation: Official getting started guide ↗ Official files and results guide ↗

Define the last mile first

'Be my research assistant' does not say what would make the task complete. 'Compare three scheduling tools against our requirements and return a cited decision table' gives the Bot a finish line. Add the columns you need, the audience, and the decision the output should support.

Separate inclusion rules from preference. 'Only evaluate products with a publicly documented export option' is a rule; 'I prefer a simple interface' needs interpretation. Ask for uncertainty when a requirement cannot be checked. Otherwise, the output may silently treat missing evidence as a pass.

For anything involving dates, name the time zone and cutoff. For changing information, ask for when it was checked. For an existing file, identify whether the deliverable is a revised original or a new copy. These small choices prevent review friction.

  1. Name the decision or job the artifact will help you finish.
  2. List the smallest source set that can answer it.
  3. Define inclusion, exclusion, and freshness rules.
  4. State which actions are permitted now and which require a separate decision.
  5. Specify what the Bot should return if only part of the task is possible.

Copy and fill in the brief

Replace the placeholders with concrete names. Remove fields that do not apply, but keep the acceptance checks and the failure behavior.

Try this brief

Outcome: [decision or finished job]. Audience: [who will use it]. Sources: [files, URLs, accounts, and authoritative source if they conflict]. Scope: [included records/topics], excluding [out of scope]. Time window: [start/end, time zone, freshness requirement]. Deliverable: [artifact and required sections/columns]. Allowed actions: [reads or explicitly authorized edits]. Review boundary: [actions requiring separate approval]. Acceptance checks: [three observable conditions]. If blocked: return the completed portion, identify missing evidence, and explain the smallest next step. Do not invent missing facts or quietly substitute old inputs. At completion: link the artifact, summarize validation, and distinguish work completed from proposals.

Original editorial template. Replace placeholders and review access before running.

Review the brief before the answer

Imagine the Bot delivers exactly what you asked for. Would that be enough to make your decision? If a critical comparison is absent from the specification, add it now. A more elaborate prompt is not automatically better; the useful detail is whatever prevents an expensive misunderstanding.

After the first run, improve one instruction at a time. Keep the failed example and the corrected rule together. Over several runs, this becomes a small record of why the method is written that way.

  • A reviewer can tell when the task is complete.
  • Source conflicts have a rule or remain explicit.
  • The Bot knows what to do with partial results.
  • The final output distinguishes evidence from recommendations.

Sources & next steps

Capabilities are grounded in the documentation below. The workflow design and acceptance checks are editorial suggestions.

Build your own workflow brief ↗