Step 4: Lock Down Current Behavior

Capture the legacy system's behavior as a parity test suite before changing anything. The new system has to match the legacy — including its quirks.

What you're doing in this step

Build a behavior parity test framework, run it against the legacy system in record mode to capture golden responses, then commit the goldens. The new system must match these as it ships.

Recommended prompts

Use one of these to do the work in your IDE

Open the template to read it in full. Click Copy prompt to grab it (with your stack values pre-filled where they apply) — then paste into Claude Code, Cursor, or wherever you build.

Primary recommendation 1-2 days

Behavior Parity Test Suite

Generate tests that lock down current legacy behavior so the new system doesn't accidentally change it during migration.

View template

Template· Template 30 min

Playwright E2E Test Generator

Generate Playwright end-to-end tests from user stories with proper page objects, fixtures, and CI-ready setup.

Use this when: Slice 1 is UI-driven and you want browser-level parity tests rather than API-level

typescript

View template

Recommended skills

Drop these into Claude Code for this phase

Skills auto-trigger on the right kind of request. Install once; they apply to every prompt that fits.

Skill· Skill 5 min setup

Test Generator Skill

Claude Code skill that picks the right test type (unit/integration/E2E) based on context and applies Evoke's testing patterns automatically.

claude-code

View skill

Recommended MCP configs

Wire these tools into Claude Code first

MCP servers give Claude Code direct access to external systems (Jira, browsers, databases). Configure once.

MCP config· MCP config 5 min setup

Filesystem MCP for Evoke

Pre-configured filesystem MCP server for Claude Code — safe, scoped read/write access to project files.

claude-codemcp

View config

When you're done

Verify these in your own work before moving on

This is a checklist for you to mentally tick off in your repo and IDE — the site doesn't track it, you do.

Parity test framework at /tests/parity/ with record + verify modes
30-50 test cases covering slice 1 capabilities
Golden responses captured from legacy and committed to git
Tests run in CI on every PR
Quirks (legacy bugs users depend on) explicitly documented as expected behavior

Common pitfalls

What goes wrong at this step

Skipping parity tests — "it's a rewrite, we'll fix bugs along the way". Users will notice every change
Pixel-perfect screenshot diffs — too brittle. Prefer behavioral assertions
Treating quirks as bugs to fix during migration — fix them AFTER, with explicit user comms
Not committing golden files to git — they're the migration contract

← Previous step