Using Code as Design Reference: 20 Open-Source HTML Pages for Reskinning Claude Projects

While building websites with Claude Code, a developer with years of experience in web development identified a recurring pain point: generating a functional interface was getting easier, but achieving a consistent, distinctive visual style still required endless iteration. So he did something about it — he packaged 20 landing pages as free, open-source single-file HTML files, designed specifically to serve as "visual reference samples" for Claude. The project is called InstaLanding.ai, and it requires no login to use.

Why Text Prompt Descriptions of Design Are Never Quite Enough

If you've used an AI coding assistant, you've probably experienced this frustration: you ask Claude to "make it look premium" or "give it a modern SaaS feel," but those instructions leave enormous room for interpretation. The word "premium" alone can produce completely different results every time.

The author's core insight is this: design is information that's extremely difficult to convey precisely through natural language. The subtle hierarchy of typography, the rhythm of spacing, the interplay of shadows and border radii, the timing of animations — describing these in words is both verbose and lossy. You might go through 20 rounds of prompting and still never accurately transfer the image in your head to the model.

His alternative approach is refreshingly direct: instead of describing a design to Claude, just give it a complete, runnable design to reference.

Single-File HTML: A Design Medium Optimized for Coding Agents

All 20 landing pages in this library are built with vanilla HTML, CSS, and JavaScript. Each page is self-contained in a single HTML file — no frameworks, no dependencies, no build steps.

This "against-the-grain" technical choice was deliberate. The author's goal was to make the designs as portable and legible as possible for coding agents. A single file means Claude can read the implementation directly:

• Typography, color palette, and spacing
• Layout structure and responsive behavior
• Component styles
• Animations and interactions
• The overall visual language

The key difference: no screenshots requiring guesswork, no dependency trees to traverse — just runnable code. For a model, parsing a self-contained HTML file is far more accurate than interpreting a PNG image or tracing through node_modules. This essentially encodes "design intent" into the format models are best at consuming — source code.

The underlying logic here relates to how LLMs handle different input modalities. When Claude receives a screenshot, it relies on visual understanding to "guess" the underlying CSS properties — an inverse inference process that inevitably introduces errors. It might perceive that "the button is rounded," but it can't precisely reconstruct the combination of border-radius: 12px and box-shadow: 0 2px 8px rgba(0,0,0,0.12). HTML/CSS source code, on the other hand, is a format that naturally aligns with the model's training data distribution: the model encountered massive amounts of code during pretraining, and its "understanding" of code is essentially pattern matching rather than inference. The single-file constraint further eliminates context fragmentation common in modular code — all design decisions are visible within the same file, so the model doesn't need to trace variable references or class inheritance across multiple files, allowing it to extract the complete visual system with minimal cognitive overhead.

The Most Interesting Use Case: Reskinning an Existing Claude Code Project

The real value of this library isn't in building new sites from scratch — it's in a reskinning scenario.

Imagine you've already built a dashboard or SaaS application with Claude Code. The functionality works great, but you're unhappy with the visual design. The conventional approach is to tear it down and rebuild, which is expensive. The author's approach: drop one of these HTML files into Claude and ask it to extract and apply the design system without touching your existing code architecture.

Here's the actual prompt he uses:

Analyze the attached HTML file and extract its visual design system, including typography, color palette, spacing, layout principles, components, borders, shadows, and animations. Apply this design language consistently to my existing project. Preserve all existing content, functionality, routing, and business logic. Treat this HTML as the single source of truth for visuals — not as a replacement for my application architecture.

What's clever about this prompt is how it deliberately separates two things that AI-assisted development often conflates: what your app does vs. what your app looks like. You preserve the functionality and architecture you've already built, while giving Claude a concrete visual anchor to align against.

The concept of "reskinning" has a long history in traditional software development — it refers to replacing the UI presentation layer without changing underlying logic. It depends on Separation of Concerns: business logic and visual presentation are properly decoupled. In modern frontend architecture, this is typically achieved through CSS Custom Properties, design tokens, or theming systems. The author's approach recreates similar thinking in the context of AI-assisted development: the prompt explicitly instructs Claude to operate only on the visual layer, leaving routing, data flow, and component interfaces untouched. This constraint is actually compensating for a common risk with AI coding tools — when you ask to "improve the UI," the model might refactor component structure to achieve a visual effect, causing functional regressions. Separating the visual reference from architectural instructions is a practical defense strategy for reducing these kinds of side effects.

The Core Insight: Code Itself Can Be a Design Reference

The biggest takeaway the author summarizes: code itself can serve as a design reference. Rather than spending 20 prompts describing an aesthetic, just give Claude a runnable sample that embodies it.

He's also honest about the limitations: this doesn't guarantee perfect results. You'll still need to review responsive layouts, component consistency, and places the agent may have inadvertently touched. But compared to pure text descriptions, this approach gives the model a far more concrete starting point.

For anyone doing frontend work with AI tools, this idea generalizes to a broader practice: feed high-quality reference implementations to the model as a "style dictionary," letting it generate within established visual constraints rather than improvising freely each time. This is fundamentally about using deterministic inputs to constrain the non-deterministic outputs of generative tools.

An Open Question Worth Discussing

The project is completely free, open-source, and requires no login (instalanding.ai). Anyone can take these HTML files and experiment with them or incorporate them into existing projects.

The question the author leaves open is actually the more valuable one — and it's worth every Claude Code user thinking about: Which approach conveys design intent most effectively — text descriptions, screenshots, or runnable code? From his experience, runnable code wins for being lossless and machine-friendly; but screenshots may be faster for conveying overall "atmosphere," while text wins on flexibility. The three aren't necessarily mutually exclusive — they may suit different stages of the design iteration process.

This also reflects a signal that AI-assisted development is maturing: when generating functionality is no longer the bottleneck, efficiently and controllably conveying "taste" and "style" is becoming the next workflow challenge worth refining.