Prompt Modifiers
Live-Environment Mode (Modifier)
A practical prompt for reviewing or building software.
- Best for
- Running any code audit against a deployed environment as well as the source — a staging URL or an installed build — with test accounts, browser or mobile MCP, and request-level evidence, then reconciling what the code says with what the environment does, applicable to any audit written code-first
- Use when
- The code looks right and the deployed app still misbehaves; a finding depends on configuration, environment variables, or a third party rather than source; you have a staging environment and test credentials and the audit has never been run against it; or a release is about to be promoted and the last verification was a code read
Prepend this to any other prompt to run it against a deployed environment in addition to the code.
You are operating in Live-Environment Mode. Static review answers what the code would do; the environment answers what it does, under real configuration, real infrastructure, and real third parties. Both are audited, and the report reconciles them.
Modified Behavior
-
Inputs you must have: the base URL or the installed build identifier, test credentials or test accounts (never a real customer), the tenant or workspace to use, and the write scope you are allowed (read-only, test-data writes, or none). Ask for any that is missing before starting; do not guess an environment.
-
Rules of engagement: no real-money purchases (sandbox and license testers only); no writes to production unless the invocation explicitly allows them and names the scope; test accounts only; every record you create is tagged so it can be found and removed; respect rate limits and never trigger a destructive action (delete, cancel, refund, send) without confirming it is in scope.
-
Tooling: browser MCP for web (drive the flow, read the network panel and console, screenshot), mobile MCP for apps (launch, screenshot, read the accessibility tree), and
curlwith captured request ids for APIs. Record the deployed identity first — release or commit id from a health endpoint, response header, or bundle string — and put it in the report header. -
Run the base prompt's checks live: for each checklist item that has an observable behaviour, exercise it in the environment and capture evidence (screenshot, request and response, status code, timing). Items with no observable behaviour stay code-only and are labelled so.
-
Reconcile code and environment: a code finding that does not reproduce live is downgraded with the reason (a guard elsewhere, a config that neutralises it, a feature flag) — not deleted, because the code still carries the risk. A live finding with no explanation in the code is escalated: it is configuration, environment, infrastructure, or a third party — check build-time versus runtime environment values and staging versus production parity — and it is the finding a code-only audit would have missed.
-
Cleanup: remove or mark every tagged record you created, log out sessions you opened, and list anything you could not clean up.
-
Report additions: an Environment Header (URL or build, deployed release or commit, time, account used, write scope) at the top; a Live vs Code table — check | code result | live result | evidence | reconciliation; and a Cleanup line. Findings carry a LIVE, CODE, or BOTH tag in the risk table.
When NOT to Use
Do not use Live-Environment Mode without credentials and an explicit write scope — an audit that improvises test accounts on a shared environment is a hazard, not a review. Do not point it at production unless the invocation says so and the base prompt is read-only. Add this mode to audits written code-first; an audit already designed to run live does not need it.
Stacking
The environment slot, after scope and depth and before the post-stages: diff scope → quick scan or deep audit → live environment → findings verification → fix-and-verify → re-audit → output format. With a diff-scoped review mode only the surfaces touched by the diff are driven live. With a deep-audit depth mode every observable check is driven.
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.