How I direct an AI website project with Codex, browser checks and Vercel
DLVX Academy | 1 October 2026
Use fictional or authorised inputs. Replace the bracketed details.

WORKING TEMPLATE 1

Act as the implementation agent for this website change.

Outcome: A qualified visitor understands the service and can send
an enquiry that reaches the agreed destination with its context.

First inspect the current source, project instructions and live state.
Identify the route, shared components, form handler and deployment.
Do not infer that the newest local branch is the live website.

Preserve approved design and unrelated work. Propose the smallest
change that solves the stated buyer problem, then implement it.

Before release, provide:
- The changed files and why they changed.
- A preview link tied to the reviewed version.
- Desktop and mobile evidence.
- Relevant route, form and attribution checks.
- Remaining failures and the concrete release decision.

Keep the previous release recoverable. Do not claim a production
switch until the destination has been checked after the switch.

================================

WORKING TEMPLATE 2

Review this rendered page against the accepted buyer journey.

Report material problems only. For each problem:
1. Name the visible element and viewport.
2. Explain what a visitor is likely to misunderstand or miss.
3. Propose the smallest correction that preserves the design.
4. State what should remain unchanged because it is good enough.

Separate factual proof problems from visual preferences.
Do not invent a client result to make a section feel stronger.
After the correction, render the same route and viewport again.

================================

WORKING TEMPLATE 3

Prepare the release decision for a non-developer owner.

State the intended production version and the prior recoverable version.
List the buyer journeys checked and link to their evidence.
Separate source checks, browser checks and persisted-data checks.
Name any failed or untested condition and its practical consequence.

Recommend release or hold. Do not call a blocked check a pass.
If release is authorised and the agreed checks pass, carry it through,
then verify the actual public URL and recovery link.

Return a short outcome report. Keep detailed receipts with the work.

================================

WORKING TEMPLATE 4

AI-ASSISTED WEBSITE RELEASE
Business owner:
Implementation owner:
Repository and current production version:
Accepted design reference:

BUYER JOURNEY
Entry page and audience:
What the visitor must understand:
Action they should be able to complete:
Destination system and owner:
Required source or service context:

CHANGE BOUNDARY
Files or routes expected to change:
Approved work that must remain:
Other active work to integrate:
Actions authorised for this release:

EVIDENCE
Source and build checks:
Desktop and mobile browser checks:
Internal destinations and redirects:
Real or controlled form receipt:
Attribution result:
Human verification still required:
Untested production differences:

RELEASE DECISION
Exact reviewed preview/version:
Release or hold, with reason:
Previous version and recovery method:
Old-site link and form/search policy:
Public URL checks after release:
Owner for follow-up failures: