Unified HTML Generator

Problem Solved

Between a design output and a runnable prototype, the usual pain is not just “does the page open,” but CSS variables, component tokens, icons, charts, and sidebar layout drifting out of alignment. This skill converts phase-design outputs such as DSL JSON or design specification documents into a single-file final.html, aiming to reproduce FTdesign-constrained pages without introducing a complex front-end engineering setup.

How It Works

• Input: prefers DSL JSON, and can also accept specification documents containing page lists, layout decisions, component-token summaries, and BEM container mappings;
• Output: a single HTML file with CSS variables, component styles, mock data, and responsive interactions;
• Icons and charts: uses Font Awesome 6.4.0 with multi-source CDN fallback, loads ECharts 5.4.3 on demand, and uses waitForECharts polling to avoid chart rendering races;
• Layout constraints: fixed 240px sidebar, main content with margin-left: 240px, and white content cards with 24px padding;
• Quality checks: CSS semicolons, var(--ft-xxx) format, tag closure, fa-solid fa-* icon classes, brand colors, and sidebar states.
  The skill also follows the L7-L10 layered structure, keeping design system, component assets, templates, and DSL Schema separate; design_engine.py can serve as a local CLI entry point for querying components, design-system data, and DSL.

Boundaries and Notes

Best suited to B-side admin pages, dashboards, permission/user management, list/form prototypes. If the page depends on login state, real APIs, complex routing, or backend permission models, it should be treated as a front-end visual prototype. This skill is closer to a design-to-frontend bridge than a general React/Vue scaffold. Confirm that upstream DSL is complete and that token prefixes such as GEN::, NAV::, and ENT:: cover the target components.