Guiding the agent

Use your coding agent to prepare the application change for review. Use the CLI and MCP setup, load its packaged guidance and inspect the current application before choosing assertions.

1. Choose what to check

Name the journeys, target and source revision you intend to inspect. Separate what ran from what was omitted. Passing checks cover their declared assertions; they do not establish exhaustive application coverage or target/build identity.

2. Write deterministic checks

Load plugin-execution and flow-authoring with load_skill, then inspect list_plugins for the installed schemas and exact pins. Name the behavior in the step heading and put executable RFL in its fence. This is a step excerpt from a flow with Browser selected in plugins and site: Browser in providers frontmatter:

### Check the confirmation after payment

```rfl
site.click selector="[data-testid='place-order']"
site.expect selector="[data-testid='order-number']"
site.snapshot name="confirmation"
```

Adapt this example to your application’s state and test data. Prose is useful context but does not execute. Keep the plugin frontmatter from the complete flow example. The deterministic path needs no model call; set self_heal: false and validate: false to disable execution-time repair and semantic validation while preserving assertions.

Use the flow format and RFL reference for syntax. Do not silently weaken assertions to make a failure pass. Preserve the original and run a justified candidate repair separately.

3. Maintain current application knowledge

Load load_skill({"name":"knowledge-corpus"}), read the selected revision with search_kb and get_kb_page, and verify it against relevant source and observations. Knowledge pages describe what the application is at that revision. Replace outdated facts; keep chronology, work notes and change narrative outside those pages. Immutable prior revisions retain history.

For committed source changes, prepare_knowledge_refresh returns a bounded brief for a fresh knowledge maintainer chosen by the author host. The host owns its budget and authority. Planning makes no model call or product write and does not launch an autonomous backend author. Publication and accepted roots are distinct decisions; unchanged source inputs do not prove knowledge accuracy.

4. Prepare the comparison

Retain the exact base and candidate evidence. Show changed visuals or outputs, current knowledge patches and a relevant walkthrough when useful. Leave the unchanged declared inventory, omissions and originals reachable. Application source code stays in version control.

A separate fresh agent can inspect originals and add advisory review notes. Keep implementation notes separate from the fresh review. Resolve missing evidence before marking the comparison ready. Follow PR preparation for the exact selection and export workflow. Human acceptance belongs to PR merge.

Optional execution assistance

Assistance requires the execution path’s configured provider authority. Device jobs use an explicitly approved provider grant and private key installation. The separate remote runner has its own provider-key configuration. Do not send private keys in MCP inputs.

Autoheal repairs selector failures. Assertions and visual mismatches are excluded. Empty ts step bodies and semantic validation are separate model-assisted execution paths; they are not needed for the deterministic author workflow above. A model’s interpretation is evidence to inspect, not human acceptance or proof of correctness.