reversa-screen-translator

Translate legacy UI screens into token-driven migration specifications with human-approved modes.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/afsjr/secretaria_escola_csm --skill reversa-screen-translator-afsjr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reversa-screen-translator
Source: https://github.com/afsjr/secretaria_escola_csm/tree/main/.agents/skills/reversa-screen-translator
Command: npx skills add https://github.com/afsjr/secretaria_escola_csm --skill reversa-screen-translator-afsjr

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents coders from improvising during migration by translating each legacy UI screen into an executable, token-based specification—after forcing a human decision on the modernization mode.

Core Features & Use Cases

  • Two-phase screen translation: first detects source/target platforms and captures a human-approved translation mode, then generates per-screen specs and optional golden files for parity testing.
  • Human-in-the-loop modernization mode: requires explicit selection of literal, modernized, or hybrid to avoid silent redesign decisions.
  • Deterministic parity support (when available): emits golden files and a manifest.yaml so the Inspector can run constructive parity tests when the legacy “oracle” can be executed.

Quick Start

Run reversa-screen-translator via /reversa-screen-translator (typically invoked by /reversa-migrate) and choose the translation mode when prompted, then proceed only after the mode decision is approved.

Frequently Asked Questions about reversa-screen-translator

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

FAQPage Schema
How do I translate legacy UI screens into executable migration specs?

Legacy UI screens are translated into executable, token-driven migration specifications by enforcing a two-phase workflow that first captures a human-approved translation mode, then generates per-screen specs.

What is golden file parity testing for legacy migrations?

Golden file parity testing validates migration accuracy by emitting golden files and a manifest.yaml, allowing the Inspector to run constructive parity tests when the legacy system can be executed as an oracle.

How do design-system tokens work during legacy screen translation?

Design-system tokens resolve UI elements during screen translation, logging any deviations between the legacy source and the target design system to ensure strict textual preservation by default.

Can I enforce a human-in-the-loop modernization mode for TUI migrations?

Yes, a human-in-the-loop modernization mode is required, forcing an explicit selection of literal, modernized, or hybrid translation modes to prevent silent redesign decisions during TUI to modern UI migrations.

Does legacy screen translation support platform origin and target detection?

Yes, screen translation detects source and target platforms across supported adapter pairs, capturing a human-approved translation mode before generating per-screen specifications for the migration.

When should I not use automated screen translation for legacy migration?

Automated screen translation should not be used without an initial human decision on the modernization mode, as the workflow strictly requires explicit selection of literal, modernized, or hybrid options to proceed.