IFQ Design Delivery

Problem

Visual delivery work often stalls not because the request is ambiguous, but because execution is fragmented: a landing page, app prototype, deck, infographic, or motion demo needs fact-checking, brand assets, a stable template, layout decisions, export planning, and verification. If a model starts from a blank HTML file, the result can be structurally loose, typography-unstable, generically branded, and hard to verify. When the request involves a product, company, release date, version, person, or spec, unverified claims can become embedded in the artifact. IFQ Design Skills targets this class of HTML-first visual delivery by turning the task into a routable, verifiable workflow.

How It Works

The skill uses a short root instruction layer to confirm that the request is a visual HTML deliverable, then routes through references/modes.md and assets/templates/INDEX.json instead of generating from scratch. The core path includes:

• Template-driven output: fork a listed template into the workspace, preserving structure and interaction affordances.
• Brand layer: inline assets/ifq-brand/ifq-tokens.css and weave in at least three IFQ ambient marks for consistent visual rhythm.
• Facts before assumptions: verify product, company, technology, date, version, person, or specification claims against authoritative sources when available; otherwise ask for sources and mark the fact unresolved.
• Asset protocol: handle logos, product images, UI screenshots, color, and typography before layout or hero imagery decisions.
• Verification: preview with host browser or screenshot tools when available; click through at least one primary path, one tab or screen switch, and one detail action for app prototypes; check slide count, aspect ratio, and format for decks.

Boundaries

It is well suited to interactive prototypes, hi-fi mockups, clickable app flows, dashboards, landing pages, whitepapers, reports, infographics, slide decks, brand systems, and motion demos that also need MP4/GIF export planning. It is not intended for production frontend engineering, backend work, SEO-critical site implementation, CSS bug fixing inside an existing app, copy-only editing, or deliverables that must round-trip through Word, Google Docs, or locked corporate templates. The bundled workflow stays local-first, avoiding unrelated secrets, dynamic eval, child_process, runtime network calls, and hidden installs; optional export automation is expected to live in the full repository rather than the lightweight bundle.