reversa-screen-translator

Translates legacy system screens into executable target-platform specifications with human-approved modernization modes.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

πŸ’‘ This Skill includes references (resource) components.

What problem does it solve? Legacy migration projects lack an owner for visual translation: architects cover structure, testers cover parity, and coders end up improvising layouts, colors, and messages. This Skill closes that gap by converting every legacy screen into an executable specification the coder can implement without inventing UI details. ## Core Features & Use Cases - Two-phase workflow with mandatory human decision: Phase 1 detects source/target platforms (COBOL TUI, Delphi VCL, VB6, WinForms, ASP, JSP, PHP, Android XML, iOS XIB) and forces an explicit choice between literal, modernized, or hybrid translation modes; Phase 2 generates the specs only after approval. - Executable screen specs: Produces target_screens.md with per-screen YAML specs in formats matched to the origin-target pair (ansi-byte-stream, component-tree, route-component, composable), plus a deviation log and optional golden files for parity testing. - Design-token enforcement: Maps every color, spacing, and typography value to design-system tokens, deriving new tokens when the legacy has no match and tracking each divergence as an approval-blocking deviation. - Use Case: Migrating a COBOL banking application to a Go CLI β€” the agent inventories each DISPLAY/ACCEPT screen, gets human approval for literal mode, and emits byte-exact ANSI specs with golden files so the Inspector can run constructive parity tests. ## Quick Start Ask the agent to analyze the legacy repository, detect the source UI platform, present the literal, modernized, and hybrid translation modes with trade-offs, and wait for your mode decision before generating the target screen specifications.

Frequently Asked Questions about reversa-screen-translator

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

FAQPage Schema
How do I migrate legacy COBOL screens to a modern CLI or web app?β–Ό

The agent detects the COBOL source platform, inventories each DISPLAY/ACCEPT screen, and presents literal, modernized, and hybrid translation modes with trade-offs. After you approve a mode, it generates executable specs such as ansi-byte-stream for Go CLI targets or component-tree for web SPAs.

What is the difference between literal, modernized, and hybrid screen translation modes?β–Ό

Literal mode preserves byte-a-byte or pixel-equivalent parity with the legacy UI. Modernized mode redesigns screens idiomatically for the target platform with explicit idle, loading, error, and success states. Hybrid mode applies literal to some screens and modernized to others, requiring explicit per-screen lists.

Which legacy platforms are supported for screen migration?β–Ό

Supported sources include COBOL ANSI TUI and Screen Section, ncurses C, Delphi VCL and FireMonkey, VB6, WinForms, WPF, Win32/MFC, classic ASP, ASP.NET WebForms, JSP, PHP server-rendered, jQuery HTML, Android XML, and iOS XIB/Storyboard. Unsupported pairs return error EC-01 with a raw prose template fallback.

Can the agent translate screens without human approval of the mode?β–Ό

No. Phase 2 spec generation is blocked until a human approves the screen_modernization_decision.md document and the orchestrator state marks screenModeApproved as true. The agent never applies modernization silently.

What happens when the legacy system has no user interface?β–Ό

For batch, API-only, or daemon systems, the agent emits a minimal decision document with mode set to skipped, a target_screens.md note stating no screens were detected, and an empty deviation log. The Inspector then skips visual parity checks.

How are visual differences between legacy and new screens tracked?β–Ό

Every divergence is recorded as a DEV-NNN entry in screen_deviation_log.md with a type (technical, modernization, platform, or correction) and an approval status. Pending deviations block handoff to the Inspector, and approved ones propagate to the parity specs exceptions section.