Use a portable CI validation policy with Grok.

Install the repository-level guidance

init writes portable instruction files and diffci.config.json. Where Grok reads repository instructions, the policy travels with the checkout rather than depending on a chat-only prompt.

The policy is explicit about authority: DiffCI can propose and measure a selected command, but it cannot convert that proposal into skipped, canceled, or reordered CI.

Use the correct execution mode

check may run both the inferred full and selected test commands. That makes it appropriate for validation tasks where repository scripts are allowed to execute. Use observe --no-send when only static analysis and a report are wanted.

• Test commands may write generated files. Review the worktree after execution.
• A fallback is not a failure. It means the change could not be narrowed with sufficient evidence.
• A refused analysis needs normal validation. Do not summarize it as a pass.

Make the final answer auditable

Grok should report the verdict, the selection or fallback reason, commands executed, pass/fail state, timings when measured, and the output path. This keeps the handoff grounded in repository evidence rather than a confident summary alone.

Because repository-instruction discovery differs by Grok client, verify that the client actually loads the generated policy. When it does not, call the CLI directly and include the same guardrails in the task prompt.

Verify the Grok setup

• Confirm the specific Grok client loads the generated repository instructions before relying on an automatic DiffCI run.
• If instruction discovery is unavailable, invoke the CLI directly and include the same fallback and reporting requirements in the task prompt.
• Check the final answer for the verdict, commands executed, fallback reason, timing scope, and report path before treating it as validation evidence.