reversa-designer

Generate migration design specifications from legacy system topology.

1|Updated Dec 20, 2025
One-click install
npx skills add https://github.com/Rdinda/FMA_Pontos --skill reversa-designer-rdinda
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reversa-designer
Source: https://github.com/Rdinda/FMA_Pontos/tree/main/.agents/skills/reversa-designer
Command: npx skills add https://github.com/Rdinda/FMA_Pontos --skill reversa-designer-rdinda

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It turns legacy system findings into a complete, traceable target design so a migration team can move forward without losing accountability to the original data and rules.

Core Features & Use Cases

  • Two-phase migration design: first produces a topology decision that waits for human approval, then generates architecture, domain model, data model, and a migration plan aligned to that decision.
  • Total traceability to the legacy: every new element links back to specific legacy origins or is explicitly discarded and logged.
  • Paradigm-honoring modeling: explicitly materializes the chosen target paradigm (event-driven, OO with DI, functional, actor model, or dataflow) into the architecture and models.

Quick Start

Use the reversa-designer skill by invoking /reversa-designer to generate a topology decision first, then approve it so it can produce the target architecture, domain model, data model, and data migration plan.

Frequently Asked Questions about reversa-designer

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

FAQPage Schema
How do I design a target architecture for a legacy system migration?

To design a target architecture for legacy system migration, generate a topology decision first, then approve it to produce target architecture, domain model, data model, and a data migration plan with full traceability to legacy origins.

How does traceability work in domain modeling for system migration?

Traceability in domain modeling ensures every new architectural element links back to specific legacy origins or is explicitly discarded and logged, maintaining accountability to original data and rules during system migration.

Can I model event-driven or actor model paradigms during data migration planning?

Yes, you can model event-driven, OO with DI, functional, actor model, or dataflow paradigms. The chosen target paradigm is explicitly materialized into the architecture and domain models during migration planning.

What's the best way to plan ETL for a staged system migration?

The best way to plan ETL for staged migration is to confirm topology and paradigm decisions first, then generate a deterministic data migration plan aligned with the target data model and domain architecture.

What do I need to produce bounded contexts before architecture modeling?

To produce bounded contexts before architecture modeling, you need to provide multiple migration briefs and artifacts so the system can detect legacy topology and enforce traceability rules across the domain model.

Why does my migration design require a topology approval before generating models?

Migration design requires topology approval because the staged workflow enforces human confirmation of topology and paradigm decisions before proceeding to generate architecture, domain models, and data models.