A homepage generator that names its own clichés before avoiding them

Naming the cliché before trying to avoid it

This is a skill and template gallery for coding agents that generates personal homepages, portfolios and sixteen-by-nine HTML presentations. What sets it apart from the many similar prompt packages is that the README opens not with a feature list but with a diagnosis of exactly what makes AI-generated personal pages look cheap.

The list is specific rather than generic: hero copy so vague it does not identify who the person is, purple gradients and random glowing orbs used as decoration in place of design, a skills section that is only a wall of logos, project cards missing the problem, the person's role, what they actually built and the result, invented metrics and fabricated testimonials, a visual reference the user supplied being ignored, and a page with no consistent visual system or content hierarchy.

Naming failure modes this precisely before offering a solution is a good sign, because it means the workflow that follows was built against observed problems rather than against an abstract idea of quality. Two items on that list deserve to be read twice: ignoring a user's supplied reference, and inventing metrics or testimonials. Both are trust failures rather than aesthetic ones, and the workflow that follows treats them accordingly.

Reference-first, and what it protects against

The stated workflow order is: understand the person and the content goal first, then follow any reference the user supplied, then organise the information architecture, and only at the end run a visual and content quality check.

Putting the user's reference ahead of the tool's own aesthetic preferences is the correct ordering for a generation tool, because the alternative, letting the model's default style dominate regardless of what the user actually wanted, is precisely the genericness the whole project opens by criticising. A skill that quietly overrides a supplied reference with its own house style has not really solved the problem it names.

The project backs this with a dedicated document on reference products and a copyright boundary, which is the detail that separates a considered reference-following workflow from a plagiarism risk. Following the layout logic or interaction pattern of an admired site is a legitimate design practice; copying its specific content, imagery or protected assets is not, and having a written boundary for that distinction, rather than leaving it to whatever the model infers in the moment, is meaningfully more careful than most projects in this category attempt.

Two independent tracks under one entry point

The skill's entry file is described as responsible only for recognising the task and loading what is needed, deliberately kept thin. Underneath it sit two genuinely separate tracks that happen to share editing and export code.

The personal homepage track has its own generation workflow and its own design-review checklist, covering continuous-page layout, responsive behaviour, portfolio display and scroll interaction. The HTML presentation track has its own workflow and its own visual quality-assurance document, built around a fixed sixteen-by-nine frame, page-by-page delivery, a clear point per page and a complete speaker script, with a documented standalone presenter mode.

Splitting these rather than treating a presentation as a homepage with different styling is the right structural call, because the two have almost nothing in common as reading experiences: one is scrolled continuously by a visitor at their own pace, the other is paged through in front of an audience with someone talking over it. A shared workflow would inevitably compromise one to accommodate the other. The README is specific about how it wants a full deck built in practice too: draft a handful of representative pages with real content first and look at how they actually render, then expand to the full set, rather than pausing partway to ask the user to confirm before continuing.

Eighteen previews, and the honesty about what they are

The template gallery lists eighteen named visual directions, from a science-fiction landing page and a collectible-figurine carousel to a dark editorial portfolio, a terminal-styled developer homepage and a case-study-driven portfolio, each with its own preview image.

The README includes a sentence that a lot of template libraries skip: eighteen style previews are not the same thing as eighteen complete, fully implemented websites or presentations. When a user names a specific template, the skill follows it directly; when no template is specified, the choice is made based on the person, the context and the assets available, drawing on a maintained index that maps template names, Chinese search terms, the actual preview and the implementation file.

Stating that distinction plainly is a form of honesty a generation tool benefits from having, because it sets the right expectation before someone picks a preview image and assumes the finished output will match it exactly. It also explains why the fully built-out example, a hero-style neural cinematic homepage with an embedded video background and a portable single-file export, is presented separately from the eighteen previews rather than folded into the same list, since it is a complete implementation rather than a direction.

A portable file you can hand to someone who has no server

One concrete deliverable is worth walking through because it solves an ordinary distribution problem well. Running one build command produces a self-contained version of the flagship hero template that opens by double-clicking the file, with no server or build step needed by the recipient:

npm run build:hero-portable

The output lands in a dedicated portable directory, and the README's instruction for sharing it is to zip the whole folder and send it, rather than relying on any particular hosting setup existing on the other end. That solves a real and common problem: sending someone a link to a homepage that needs a running server, or a repository they would need to clone and build, is friction that a lot of intended recipients, an employer, a client, a collaborator with no interest in your tooling, simply will not push through.

The template also handles missing material gracefully rather than breaking. If the user supplies a name, description, project or video, that content replaces the corresponding placeholder; whatever is not supplied keeps the original template asset rather than leaving a broken reference, which means a draft is always presentable even before every asset has been gathered.

Checking your own output, and what remains to check yourself

Beyond generation, the project ships tooling to verify its own output rather than trusting the generation step alone.

npm run check

That command runs documentation-reference, template-index and build checks. A further command adds browser and shared-runtime checks on top, which is the more meaningful of the two, since a static reference check can confirm files are wired together correctly without confirming the page actually renders or behaves as intended in a browser. Running both before delivering anything is the sound habit the README's own commands make easy to follow.

Licensing is the one thing to verify independently rather than take from any single signal. The README displays a licence badge, but the repository's own metadata reports no assertion of a recognised licence, and a licence file exists in the tree that should be read directly rather than trusted from the badge image alone. This is not legal advice.

The project reports 322 stars, 30 forks and two open issues, with the last push on 2026-09-17, so it is current. Before adopting it, three steps in order. Open the licence file directly and confirm what it actually permits. Provide your own visual reference up front if you have one, since the workflow is built to follow it rather than override it. And run both check commands after any generated output, treating a clean pass as confirmation the build is wired correctly rather than as confirmation the design itself is any good, which still needs a human's eye.

Editorial conclusion

This skill fits someone using a coding agent to build a personal homepage, portfolio or HTML deck who has watched AI-generated versions collapse into the same purple-gradient, fake-metric template, since the README's own diagnosis of that failure is unusually specific and the workflow is built directly against it. Its reference-first ordering and its written copyright boundary for admired sites are the details worth trusting most, and the portable single-file export solves the real problem of handing a finished page to someone with no server and no interest in your tooling. Open the licence file directly rather than the README's badge, provide your own visual reference before generating anything if you have one, and run both check commands afterward, understanding that a clean pass confirms the build is wired correctly rather than that the design itself is any good.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. shengjidaguai-china/personal-homepage-skill on GitHub