A finished message is not the acceptance test

Official guidance emphasizes reviewable artifacts and testing workflows before automation. The scorecard here is our original evaluation framework. It is not a SpaceXSI benchmark, a certification, or evidence of measured Grok Bot performance.

The skills and routines docs give a short review list for every test run: did the Bot select current inputs, meet the output format, leave an audit trail, stop at the intended approval point, and report failures explicitly? Use it as the floor for the scorecard below.

Documentation: Official files and results guide ↗ Official skills and routines guide ↗

Build a small set with known answers

Choose examples where a human can establish the expected result. For an action extractor, include notes with clear assignments, ambiguous ownership, and no actions. For a reconciliation, include a correct match, an intentional mismatch, and a missing record.

Keep the inputs and expected outputs before you run the Bot. Otherwise, it is easy to accept a plausible result and redefine success around it. A few cases expose obvious failure modes; they do not measure every situation the workflow might encounter.

  1. Write three to five acceptance checks specific to the job.
  2. Prepare a normal input, an ambiguous input, an empty input, and an unavailable-source case.
  3. Run with safe records and preparation-only permissions.
  4. Score each result against the checks before changing the instructions.
  5. Revise the method, then retest failed cases and one previously passing case.

Score usefulness, completeness, and boundaries

For each case, record pass, fail, or not assessable for correctness, completeness, traceability, permission behavior, and usability. Keep the reason beside the score. 'Not assessable' is a useful result when the source cannot establish truth; do not count it as a pass.

Measure your review and correction time separately from machine run time. A report that arrives overnight may still take too long to verify. Compare the human effort with a similar manual task, including setup and maintenance. Publish a time-saving claim only with the measurement method and sample size.

  • Correctness: the result agrees with known source facts.
  • Completeness: expected items are present, including awkward cases.
  • Traceability: another person can locate the supporting evidence.
  • Boundaries: the workflow stays within the authorized actions.
  • Usability: the artifact answers the intended question without major repair.

Ask for a review packet

Let the Bot help assemble evidence, while retaining an independent human check of the outcome.

Try this brief

For this workflow run, return a review packet containing the exact input scope, source links or record IDs, the final artifact, checks performed, unresolved uncertainties, and any actions taken. Compare the output with these acceptance criteria: [criteria]. Mark criteria that cannot be assessed rather than assuming success. Do not claim time saved or production reliability. Include enough detail for me to verify a sample independently.

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

Retest the change that matters

When a website, source format, connector, or instruction changes, rerun the cases that depend on it; the docs make the same recommendation for routines. Keep the previous accepted result for comparison. Promote a workflow gradually: useful draft, repeatable draft, supervised action, then only the specific unattended behavior you have chosen to authorize. The research and review team recipe applies this to a two-Bot setup, with a deliberately flawed answer to catch.

Documentation: Official skills and routines guide ↗

Evaluate a routine, not just a run

A workflow that passes in chat can still fail on a schedule. Test performs real work and spends usage, so run it with safe inputs and keep write actions behind approval. A new routine does not run when created; it waits for its next scheduled time, so check the first unattended run as carefully as the test.

Keep your own record of accepted outputs. The docs say each routine keeps only its 20 most recent run records, and the phone app's Run history shows Running, Succeeded or Failed, not whether the result was right. For webhook triggers, Cursor's help notes that a 200 response means the run started, not that it finished.

Count an expired approval as a failed run, not a pass. Approvals raised by routines, triggers or other Bots expire after about 10 minutes and the action does not run, so an unattended run can end quietly incomplete. Record weekly usage before and after a few runs as well: frequent schedules and busy Slack triggers can use a large share of the allowance.

Documentation: Official skills and routines guide ↗ Cursor help: Grok Bot routines ↗ Cursor help: how-tos (approval expiry) ↗

Bots for this job

Directory listings that match this guide, read from each creator's public share page. They are not tested picks: check what a Bot can reach before you add it.

Browse: Research & briefings Bots

  • Research Bot by Arthur MacWaters: Deep research that returns concise answers with verified citations
  • Competitor Watching by Andrej Šimunaj: Snapshots you against 3-8 competitors and alerts only on material change
  • PR Reviewer by Mustafa: Reviews pull requests risk-first

Sources & next steps

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

Build your own workflow brief ↗