Start from a reviewable output

A brief Grok Bot can finish names five things, which the official getting started guide lists as questions: the outcome (what should be finished), the sources (which apps, sites, files or conversations matter), the constraints (what to avoid or ask about first), the deliverable (what to return) and the review point (when to stop for you).

The files and results guide adds the other half: ask for the artifact and its acceptance criteria up front, and for consequential work have the Bot separate facts found in sources, assumptions, actions already completed, actions waiting for approval and open questions. The brief below combines both 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]. Evidence: source links, timestamps with time zone, and a list of anything you could not verify. 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 list separately the facts found, assumptions, actions completed, actions awaiting approval, and open questions.

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

Match the brief to Grok Bot's controls

A brief states intent; the app enforces it. Write the review boundary in the brief, then check that a setting backs it up. Sending, purchasing, deleting and publishing belong behind Ask first rules, which since 0.68.0 appear under Custom Rules in Settings. Email and Slack draft cards are the review point for messages; 0.64.0 lets you disable drafts for a Bot so it sends directly, so leave them on while a workflow is new.

Keep the deliverable in the conversation. Bots can read files other Bots save in /workspace, which helps handoffs, but the docs treat it as a place for intermediate material; the final result or a link to it belongs in the chat. When you want changes, ask the Bot to update the existing artifact rather than produce another copy.

Documentation: Official approvals and privacy guide ↗ Official files and results guide ↗ Grok Bot changelog ↗

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, and name lasting preferences explicitly, as the getting started guide suggests, so the Bot carries them into future work. Give each Bot one focus: the docs say focused Bots build more useful context than one catch-all Bot. Once the method is stable, ask the Bot to save it as a skill. Our workflow brief builder turns these fields into a brief you can copy, and the evaluation guide shows how to score the results.

Documentation: Official getting started guide ↗

  • 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 ↗