--- name: reflow description: Use Reflow MCP to learn an application, configure end-to-end tests, compare snapshots 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 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` or `plugins/mailbox` 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. Inspect completed outcomes and retained before/after evidence. Relate changes 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. 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.