reversa-inspector

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

Updated Aug 14, 2026
One-click install
npx skills add https://github.com/Ruggery/OCR_Cartorio --skill reversa-inspector-ruggery
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: reversa-inspector
Source: https://github.com/Ruggery/OCR_Cartorio/tree/main/.agents/skills/reversa-inspector
Command: npx skills add https://github.com/Ruggery/OCR_Cartorio --skill reversa-inspector-ruggery

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When migrating a legacy system to a new architecture, teams struggle to prove the new system behaves equivalently to the old one, especially when the migration involves a paradigm shift (e.g., synchronous to event-driven). This Skill defines the validation strategy and produces parity specifications that make equivalence testable. ## 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, adding idempotency, ordering, immutability, or supervision scenarios where needed. - Gherkin Spec Generation: Produces one .feature file per critical flow with traceability to legacy analysis artifacts, plus visual parity scenarios when screen modernization is involved. - Use Case: A team migrating a procedural monolith to an event-driven system uses this Skill to generate parity specs requiring @idempotencia and @ordem scenarios for every critical flow, with a divergence metric below 0.01% over 30 days as the cutover gate. ## Quick Start Invoke /reversa-inspector after the migration strategy and target architecture are approved to generate parity_specs.md and Gherkin parity test files under _reversa_sdd/migration/.

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 is equivalent to 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 covering positive cases, edge cases, and paradigm-specific concerns.

What extra tests are needed when migrating from synchronous to event-driven architecture?▼

Event-driven migrations require scenarios for message ordering, idempotency, eventual consistency, and queue failure behavior such as retries and dead letter queues. Each critical flow should include at least parity, idempotency, and ordering scenarios.

Can characterization tests be reused during a system migration?▼

Yes, existing characterization specs serve as the base for parity features. Adapt inputs and outputs to the new system, adjust acceptance criteria to the target paradigm, and keep explicit traceability to the original spec identifier.

How is visual parity validated when modernizing legacy screens?▼

In literal mode, golden file comparison requires byte-level or pixel-equivalent matching against captured screen outputs within declared normalization rules. In modernized mode, contract tests verify component hierarchy, declared events, textual content, and the four UI states instead.

What are the limitations of functional equivalence testing in migrations?▼

Naive input-output equivalence is insufficient when the paradigm changes, because it misses dimensions like state isolation, supervision recovery, or compositional equivalence. Coverage must be adapted to the specific transition, and pending screen deviations block the parity handoff entirely.