reversa-inspector

Generates parity specs and Gherkin feature files proving legacy-to-new system behavioral equivalence.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/lacsousa/mediclaw-system --skill reversa-inspector-lacsousa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: reversa-inspector
Source: https://github.com/lacsousa/mediclaw-system/tree/main/.agents/skills/reversa-inspector
Command: npx skills add https://github.com/lacsousa/mediclaw-system --skill reversa-inspector-lacsousa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When migrating a legacy system to a new architecture, teams need a rigorous way to prove the new system behaves equivalently to the old one. This Skill defines parity validation strategies adapted to the target paradigm and produces traceable Gherkin specifications for critical flows. ## Core Features & Use Cases - Parity Strategy Definition: Selects validation modes (shadow mode, characterization tests, contract tests, data parity) and defines acceptance criteria such as divergence thresholds and observation windows. - Paradigm-Adapted Coverage: Adjusts required test dimensions based on the paradigm transition (e.g., synchronous to event-driven requires idempotency, ordering, and queue-failure scenarios). - Gherkin Spec Generation: Produces one .feature file per critical flow with traceability to process flows, target architecture, and business rules, including screen parity scenarios when a UI exists. - Use Case: After completing a migration design from a procedural legacy system to an event-driven architecture, invoke this Skill to generate parity_specs.md and Gherkin scenarios covering parity, idempotency, and message ordering for each critical flow. ## Quick Start Run /reversa-inspector after the migration strategy and target architecture are approved to generate parity specs and Gherkin feature files for all critical flows.

Frequently Asked Questions about reversa-inspector

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prove a migrated system behaves the same as the legacy system?▼

Define parity specs that select validation modes such as shadow mode, characterization tests, contract tests, and data parity, then set an acceptance metric like functional divergence below a threshold over an observation window. Generate Gherkin scenarios per critical flow with traceability to legacy analysis artifacts.

What test scenarios are needed when migrating from synchronous to event-driven architecture?▼

Each critical flow needs at least parity, idempotency, and message-ordering scenarios, plus behavior under queue failure such as retry, dead letter queue, and replay handling. Naive input-output equivalence is insufficient for paradigm changes.

Are the generated Gherkin feature files executable tests?▼

No, the .feature files are specifications, not executable tests. They contain no framework calls; a separate coding agent translates them into the appropriate test framework for the target stack.

What inputs does the parity inspection step require before running?▼

It requires the paradigm decision document, confirmed migration strategy, approved target architecture, and the screen modernization decision with no pending deviations. Characterization specs and legacy flow analyses are reused when available.

How is visual parity handled when the legacy system has a UI?▼

In literal mode, golden file comparison validates byte-level output against captured screens. In modernized mode, contract tests verify component hierarchy, events, content, and the four UI states instead of pixel comparison.