reversa-inspector

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

Updated May 22, 2026
One-click install
npx skills add https://github.com/GleisonOliveira/dockerpilot-mcp --skill reversa-inspector-gleisonoliveira
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: reversa-inspector
Source: https://github.com/GleisonOliveira/dockerpilot-mcp/tree/main/.agents/skills/reversa-inspector
Command: npx skills add https://github.com/GleisonOliveira/dockerpilot-mcp --skill reversa-inspector-gleisonoliveira

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When migrating a legacy system to a new architecture or paradigm, teams need a rigorous way to prove the new system behaves equivalently to the old one. This Skill defines the validation strategy and produces parity specifications adapted to the chosen paradigm transition. ## 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 parity_specs.md and one .feature file per critical flow with full traceability to process flows, target architecture, and business rules. - Use Case: After a migration team decides to move a procedural legacy system to an event-driven architecture, invoke this Skill to generate parity specs covering message ordering, idempotency, and DLQ behavior for every critical flow. ## Quick Start Run /reversa-inspector after the migration strategy and target architecture are approved to generate parity_specs.md and Gherkin parity test files in _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 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. Set a primary metric like functional divergence below a threshold over an observation window, then write Gherkin scenarios per critical flow.

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

Event-driven targets require scenarios for message ordering, idempotency, eventual consistency, and queue failure behavior such as retry, DLQ, and replay. 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-id.

What are typical acceptance criteria for parity in regulated systems?▼

Fiscal or regulatory systems typically require functional divergence below 0.01% over 60 days with zero divergence in regulated fields. Financial systems target monetary divergence below 0.001% with zero divergence in totalizers.

When should visual parity testing be skipped in a migration?▼

Visual parity is skipped when the legacy system has no UI, marked as skipped status in the screen modernization decision. In literal mode without captured golden files, scenarios are still emitted but validation is declared manual until capture runs.