FILED UNDER:

Themelets: Static Sites in a Tiny WordPress Hat

I made up a word and now it has a hat.

The word is themelet.

A themelet is a static HTML/CSS site that learned the WordPress handshake. It can stroll into Appearance > Themes, nod politely to plugins, show up with a screenshot, and still mostly be a pile of friendly files minding their own business.

Not a giant theme framework. Not a block theme. Not a page-builder cockpit with seventeen panels and a button labeled “Advanced” that means “good luck.” A themelet is GitHub Pages simplicity with a WordPress ID badge.

One page. One purpose. Tiny hat.

The Tiny Problem

I love GitHub Pages because the deal is so clean it feels like cheating:

  1. Make files.
  2. Publish files.
  3. Visit site.

WordPress is bigger. WordPress is a city with roads, permits, loading docks, theme districts, plugin elevators, admin hallways, and one mysterious screen nobody has opened since 2017.

Sometimes you want the city.

Sometimes you made a neat little static thing and somebody says, “Can this live on the WordPress site?”

That is when the tiny thing starts attracting machinery.

The Tiny Solution

A themelet gives WordPress the files it expects, then refuses to become a whole civilization:

my-themelet/
|-- style.css
|-- functions.php
|-- index.php
|-- site.css
|-- screenshot.png
`-- assets/
    |-- logo.png
    `-- hero.webp


style.css is the passport.

functions.php is the tiny translator.

index.php is the page, still mostly static, still recognizable, still not trying to found a committee.

The important WordPress handshakes stay in place: wp_head(), wp_footer(), body_class(), language_attributes(), enqueued assets, and a little helper for local images.

Visitors see the focused static site. WordPress sees a theme it can install, activate, screenshot, and introduce to plugins without spilling coffee on the carpet.

Everybody keeps their dignity. The hat stays on.

The Rules

Themelets are small on purpose:

  1. Keep the page static by default.
  2. Let WordPress load it like a theme.
  3. Preserve the hooks plugins expect.
  4. Enqueue assets the WordPress way.
  5. Stop before the tiny thing grows a settings page.


That last one is the sacred rule.

If the site needs archives, search, menus, comments, editable layouts, WooCommerce, or a serious publishing workflow, make a real theme. Give it the architecture. Let it wear a proper jacket.

But if the thing would be perfect on GitHub Pages except it needs to live inside WordPress, congratulations. You may have discovered a themelet.

The Example

I used this pattern for the Model Context Polytechnic site.

The plugin is the serious WordPress software: public MCP learning courses, anonymous learner progress, and WordPress plugin craft for LLMs.

The public campus page had a different job. It needed to look like an old technical school where language models enroll to stop writing suspicious plugin code. It did not need archives. It did not need a dashboard. It did not need to become a publishing empire with a marble lobby.

So it became a themelet.

WordPress sees a normal theme folder. Visitors see a focused HTML/CSS campus. The plugin stays separate from the public skin. The themelet is just the front door with brass lettering and a very small hat.

The Skill

I also turned the pattern into a Codex skill: build-themelet.

The skill converts static HTML/CSS into an installable WordPress themelet. It includes the starter structure, wrapper rules, asset helper pattern, quality checklist, and the most important instruction: stop before the tiny useful thing becomes a full theme by accident.

That is the whole pitch:

GitHub Pages simplicity, WordPress-shaped.

Tiny files. Big entrance. Excellent hat.