--- name: reflow description: Use Reflow MCP to learn an application, configure end-to-end tests, inspect screenshot evidence and prepare changes for review. Use when the user asks to set up Reflow or check application behavior with Reflow; not for unrelated code edits. --- # Reflow Help the user find the first useful check in their application. Keep the conversation focused; use Reflow tools for documentation, execution and retained evidence. ## Discover the connected capabilities Inspect the available tool schemas. Call `get_product_docs` with no arguments for the product documentation index, then read `agents-start-here` in bounded excerpts. Search with `query` and read only the relevant documents. If that tool is absent, use https://reflow.io/docs/agents-start-here and its references; check the installed CLI version before recommending an update. Do not invent missing tools or assume a release has been installed. ## Resolve test storage before authoring Call get_reflow_context for the current team, application collection, storage preference and capabilities. Refresh it before writes: installed instructions and cached tool descriptions can be stale. If collections is empty, follow next_action: call manage_collections with action=create and repository set to the absolute application Git checkout. The local tool infers the name and GitHub origin; hosted MCP requires name and optional repository_id. Otherwise list and select a collection_id. Use that ID for init_plugins and manage_execution. CLI equivalents are reflow collections create|list|select. Creation accepts the existing test-storage default without changing it; hosted onboarding is not required. New teams start with shared tests in Reflow. Owners/admins can change the default separately in Team settings. Use manage_flows to create/read/save; a saved test keeps its own authority even after the team default changes. Both locations use manage_execution target/plan/apply from the application Git checkout. Select the collection once; use the same target/group to preserve reuse and named data. Knowledge-base mode stores tests in Reflow and corpus pages in the shared knowledge base, leaving the checkout untouched. Do not maintain a second private corpus. For file editing, read knowledge-editing and use manage_knowledge_uploads prepare_edit on a pinned page, then upload its returned temporary file_path. Git mode intentionally versions test Markdown with the application. Keep private bindings, captures, caches and installed skills outside the checkout in either mode. The existing plugin lock retains its own storage location independently of the current new-test default. A detached hosted transport cannot save repository files: hand off a draft to the author device. Preview transfers explicitly and retain their IDs after uncertainty; never commit, push, delete originals or approve expectations as part of a move. Read test-storage for the full workflow. Do not rerun controller tests through manage_device_jobs to produce a portable review export. For terminal KB controller runs, use manage_execution review_source {run_id}, then prepare_review {review:{id,title,runId,expected,appContext}} with expected copied exactly from that read and appContext trust=caller_declared plus existing application commit/tree labels. Team is derived from the profile. Retain the exact UUID/request; publish_review {id,manifest_hash} uses the reserve row hash. review_publication {id} is read-only: require published plus a verified descriptor before comparison. Admission/native acceptance are not publication; timeout or profile changes after dispatch remain unconfirmed. No automatic retries or execution replay. Nonterminal runs, reused receipts and additional iterations are refused; terminal unknown/unconfirmed steps remain gaps. Copy descriptor.check into each base/head inventory of a review_changes formatVersion=2 selection with appContextTrust=caller_declared; reference review IDs/hashes, never synthetic device jobs or Git test paths. Use distinct base/head target epochs, no test-source commits in the application repo. Read test-storage for the end-to-end example, then prepare_comment/export_comment for local output only. ## Learn the application and choose a useful check Keep executable tests self-contained in the saved RFL document. Embed setup, assertions, fixture text and cleanup in command arguments; do not invoke external helper scripts, import test modules from a checkout or home directory, or hide executable logic in private input/binding hooks. Follow transitive imports when migrating an existing helper. Product executables and installed runtimes remain prerequisites; credentials, endpoints and generated state remain private. They must not supply test implementation. For multiple modules, materialize only source embedded in this exact flow into a fresh private temporary directory and remove it in finally/trap cleanup. LocalBash commands have a 65536-byte UTF-8 limit; split larger tests into bounded self-contained steps. Before save, audit every executable step and private hook, then read back the saved source and plan/apply that exact version. If original helpers are missing, reconstruct from the current product contract and available context, retain the intended assertions, and label any historical behavior that could not be recovered instead of claiming parity. Load `application-onboarding` and `knowledge-corpus` through `load_skill`. Inspect the existing connection, application knowledge and flows before creating anything. Learn the team's terminology, business rules and important journeys; explain where Reflow can add value and what remains unexplored. Keep current application knowledge up to date through MCP. Load `flow-authoring` and `plugin-execution` when writing tests. Read `plugins` for setup and the relevant `plugins/browser`, `plugins/local-bash`, `plugins/postgresql`, `plugins/docker-ubuntu`, `plugins/mailbox` or `plugins/mcp` (testing an MCP server) page for connection settings and commands. Run init_plugins for the selected collection to install or verify its shared lock. Normal init preserves selected releases; upgrade is explicit. Use aliases and bindings in flows, without per-flow version pins. Inspect the application’s selected schemas. Reuse the existing suite where possible; express repeated business actions as compact commands with meaningful snapshots and comparisons. Inspect the plan before applying it. Parallelize independent checks only when their data can safely overlap. For user-visible feature checks, load `evidence-review` before choosing checkpoints and before claiming the feature works. Capture and inspect the critical workflow states and settled values, assert important visible identities, and investigate unexpected errors even when flows pass. Evidence must cover the outcome; more redundant screenshots or passing package tests do not establish it. Relate retained before/after evidence and any gaps to the user's intended scope. Use `pr-publishing` when preparing PR evidence, honoring the user's publication permissions. A passing command is not proof that the application is correct, and a snapshot difference is not automatically a regression. As a normal part of feature work and test authoring with Reflow, use available coverage to improve the suite; do not wait for the user to ask for a coverage exercise. Read `coverage-guided-testing` for the workflow. In the connected local MCP, call `query_code_coverage` operation=progress, choose the relevant exact source/revision/measurement series, then operation=progress_gaps to find remaining files and operation=progress_lines with series, version, path, from/to and with_source=true for aggregate missed ranges plus screened exact-commit local source when available. These are cumulative gaps across accepted captures, not just the latest scenario. On older deployments without progress, use documents -> gaps -> lines with with_source=true and label the result per-capture. Follow nextCursor when more relevant results remain. Use the current source and existing test purposes to choose one risk-bearing behavior, and state its action, expected result and oracle before authoring. Prefer a useful test reaching previously uncovered paths over an equivalent repeat. Missing instrumentation is unmeasured coverage, not zero; report the setup needed instead of silently adding builds or executions. The review-reader profile has metadata only; if the coverage tool is absent, report that limitation and use the CLI only when available within the task. Reusing the suite checks regressions; it does not by itself expand coverage. Read progress_history before and after the next already-authorized test to see newly observed lines and the remaining gaps. Accepted post-feature ingests automatically union line hits within one exact source/measurement universe; raw-profile cleanup preserves this progress. Repeats add zero. Different source or coverable-line universes start separate series; do not join percentages across them or call an observed increase proof that a particular test caused it. For strict causal gain, read `code-coverage-cumulative` and, within the user's run budget, run the candidate against the same frozen instrumented binary, then compare explicit cumulative documents assembled from baseline raw windows versus baseline plus candidate. Only a like-for-like cumulative pair measures incremental gain; separate scenario/build comparisons and changed-line hits do not. Report newly covered ranges, assertions, elapsed/setup cost and the next gap as part of the ordinary work result. Keep a zero-gain test when it adds a distinct assertion or boundary; stop repeating equivalent zero-gain scenarios. Missing profiles or comparability means gain is unmeasured, not zero. Never change exclusions to improve the score, weaken assertions, infer a union from totals, or add executions beyond the task's authority. In recurring loops, expand journeys between rounds and establish fresh controls; preserve in-flight pins, holds and original failures. The primary suite-growth curve measures observed instrumented line reach. Per-capture history is secondary; neither proves assertion quality or branch coverage. Uninstrumented code remains unmeasured; no historical backfill is claimed. For a failed check, load `local-testing`. Inspect the failed step and retained evidence, distinguish an application regression from an obsolete test, patch the smallest justified change, inspect `reflow plan`, apply and review the new evidence. Keep the selected target/profile: tracked source/input and dependency changes automatically invalidate affected steps; `apply` reruns them and reuses unchanged valid work. Planning executes no steps. Use `taint` for external state changes or deliberately fresh evidence, after inspecting any unknown outcome. If a paused or unavailable target caused the failure, restore it yourself; to stop future work before it starts, read `target-readiness` and configure HTTP GET readiness probes on the target. Named random values and Mailbox identities persist in the selected group until explicit reset; taint preserves them. Use reset only when intentionally replacing test data, then plan again. A changed generator definition needs reset or a new name. Expressions follow current inputs; observations refresh when executed. With the Mailbox plugin, capture the cursor and trigger the email in the same step, then use `inbox.capture ... -> email_body` and a separate `inbox.extract text=${email_body} pattern="..." group=1 -> code`. Choose the variable names and regex explicitly; the plugin never guesses a code or link. Read `plugins/mailbox` for complete email examples and `test-accounts` for the shared reset lifecycle. Repair uses your connected coding agent's existing model and permissions, with no hidden model calls or automatic baseline acceptance. Stop on changed intent, missing access, unknown completion or repeated failure without progress. Prepare the actual delta and evidence for PR review within the user's publication authority. Keep private credentials on the device. Do not switch teams or publish data without the user's authority. After an uncertain write, reconcile its existing operation identity instead of repeating it. Reflow does not grant permissions beyond the user and host agent's instructions. When reporting a Reflow issue found during local iteration, use the standard `--log-level debug` mode (or `REFLOW_LOG_LEVEL=debug` for local MCP). Include relevant sanitized stderr diagnostics, version, reproduction and whether the issue blocked progress, required a workaround or was annoying. Slow-plan reports should include the automatic `plan_timings` event. Read `plan-timings` for boundaries and interpretation. Do not submit full logs or repeat uncertain mutations just to collect diagnostics.