reversa-screen-translator

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

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

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 each legacy screen into an executable specification the coder can implement without inventing UI decisions. ## Core Features & Use Cases - Two-phase workflow with mandatory human decision: Phase 1 detects source/target platforms (COBOL TUI, Delphi VCL, VB6, ASP, JSP, Android XML, iOS XIB, and more) and forces an explicit choice between literal, modernized, or hybrid translation modes with concrete trade-offs. Phase 2 generates the specs only after approval. - Executable screen specs: Emits target_screens.md with per-screen YAML in adapter-specific formats (ansi-byte-stream, component-tree, route-component, composable), preserving textual content literally and referencing design-system tokens instead of raw values. - Golden files and deviation tracking: Captures deterministic golden files when a legacy oracle is executable, and logs every divergence in an append-only screen_deviation_log.md that blocks handoff to the Inspector until approved. - Use Case: Migrating a COBOL banking terminal to a Go CLI — the agent inventories each DISPLAY/ACCEPT screen, gets human approval for literal mode, then emits byte-exact ANSI stream specs plus a golden file manifest for parity testing. ## Quick Start Ask the agent to analyze the legacy repository, detect the source platform, and present the screen translation mode options for approval before generating 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 or Delphi screens to a modern web or CLI interface?▼

Run the Screen Translator after the migration Designer phase. It detects the source platform from code signatures, presents literal, modernized, and hybrid translation modes with trade-offs, and generates executable per-screen specs in target_screens.md once you approve a mode.

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 decide the screen modernization mode automatically?▼

No. The agent always presents the three modes with graded trade-offs and a recommendation, but never decides alone. Phase 2 spec generation is blocked until a human approves screen_modernization_decision.md, and hybrid mode is rejected if either screen list is empty.

What happens when the legacy system has no user interface?▼

For batch, API-only, or daemon systems, the agent emits a minimal decision file with mode set to skipped, a target_screens.md note stating no screens were detected, and an empty deviation log. The Inspector reads the skipped mode and bypasses 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 type, reason, and approval status. Pending deviations block handoff to the Inspector, while approved ones propagate to the parity specs exceptions section.