Content Wind: a Nuxt theme where the content directory is the whole site

Pages are files in content/, and everything else follows

Content Wind describes itself as a personal website theme powered by Nuxt Content, TailwindCSS, Iconify and Vue components, and the theme's site lives at content-wind.nuxt.space.

The whole content model is one directory. You create pages in Markdown in the content/ directory, and the theme does the rest.

That is the decision that separates this from a starter kit with a blog module bolted on. There is no separate blog route, no collection configuration to wire up, no schema to declare before a file is recognised. A Markdown file is a page, and the filesystem is the routing table.

The rest of the feature list builds outward from that. You can use Nuxt layouts in your Markdown pages, so a page can opt into a different shell without a special directory or a route change. Meta tags are generated from the Markdown files themselves, meaning the frontmatter is the single source for titles and descriptions. Navigation is generated based on your pages rather than maintained by hand in a config file.

For a site of a dozen or twenty pages, that is exactly the right amount of machinery. The pages are readable in a text editor, diffable in git, and portable to any other static site generator if the theme is abandoned later. The cost is that the site is only as good as the conventions you keep, and a personal site with forty pages and a hand-maintained sidebar would be better served by something with an explicit navigation model.

Nuxt layouts inside a Markdown file

The layouts feature is the one that deserves more attention than it gets in a feature list, because it is what makes Markdown a page format rather than just a blog format.

In most Markdown-driven sites, the Markdown file is the body and the surrounding chrome is fixed by the route. Content Wind lets you use Nuxt layouts in your Markdown pages, which means a page can declare which layout wraps it. A post, a changelog and a landing page can each sit in a different shell, and the choice travels with the file rather than living in a separate mapping.

The same principle shows up in the components feature. You can create Vue components and use them in Markdown, so when a piece of prose needs something a Markdown file cannot express, an interactive demo or a computed widget, you drop in a component instead of abandoning the content directory for a hand-written page. The theme advertises Vue components as one of its four foundations alongside Nuxt Content, TailwindCSS and Iconify, and this is where the Vue part earns its place.

That combination also defines the failure mode. A site built this way can drift toward being a Vue app with Markdown files in it, at which point the theme's value has thinned out, because you are now maintaining both a component tree and a content tree. The theme works best when the balance stays mostly on the Markdown side.

The theme also offers live editing on Nuxt Studio, which lets you edit content in a browser interface rather than in a text editor. For someone who writes but does not want to open a terminal to fix a typo, that removes the main friction of a filesystem-based site.

Icons, syntax highlighting and the typography layer

Three presentation concerns are handled by the theme, and each is a small decision that would otherwise become your own dependency.

Icons come from Iconify through the Nuxt Icon module, with access to 200,000 icons from 100+ icon sets using the Icon component. The package manifest shows the theme itself depends on two specific icon sets, @iconify-json/lucide and @iconify-json/simple-icons, so those are pre-installed and the rest are fetched on demand.

Code blocks are highlighted with Shiki, which is the highlighter Nuxt Content itself uses, so the theme's output matches the ecosystem default rather than introducing a second highlighter with different token classes.

Prose components are configurable through Nuxt Typography, which is the @tailwindcss/typography plugin. That plugin is what gives a long Markdown document sensible defaults for headings, lists, tables and blockquotes without you writing any prose CSS. Making it configurable is the important part: the theme does not lock you into one look, you can restyle headings and links inside a Markdown file with the typography plugin's own modifiers.

There is also a light and dark mode switch, implemented with @nuxtjs/color-mode, which is in the dependency list.

The Tailwind side is worth noting for anyone upgrading. The manifest lists both tailwindcss at 4.1.3 and @tailwindcss/vite at 4.1.3, and also @tailwindcss/typography at 0.5.16. The Tailwind v4 vite plugin is how v4 integrates with a bundler, and the fact that both the v3-era typography plugin and the v4 core are present tells you the theme spans the CSS framework's major version change. Customising the theme means working with Tailwind classes, and knowing which Tailwind generation you are on matters when you read the documentation.

One command to a new site, and where you can host it

Starting a project is a single command that scaffolds from the GitHub template.

npx nuxi@latest init -t github:atinux/content-wind my-website

Then you follow the instructions and you are ready to go. The command uses the Nuxt init tooling with the github template source, so it clones the theme rather than installing a package and configuring it, which is why the result is a directory you own with the theme's source in it, not a dependency in a package.json.

The deployment story is wide open. The theme deploys on any Node or static hosting, with GH Pages, Vercel, Netlify and Heroku named. That list maps onto two different builds, and the package.json scripts show both. nuxi dev for development, nuxi build for a server build, nuxi generate for a static build, nuxi preview to serve the output locally, and eslint for linting.

npm run generate

The generate script is the one that matters for a static host like GH Pages, and the fact that both exist is the practical point: if you want a server with a runtime, build; if you want a bucket of HTML, generate. Nothing in the theme requires a server, which is why the static option is a first class path rather than a workaround.

The repository itself carries a pnpm-lock.yaml and declares pnpm 10.7.1 as the package manager, plus a pnpm onlyBuiltDependencies list for @parcel/watcher, better-sqlite3, esbuild and vue-demi, which are the packages allowed to run install scripts. The .npmrc file is present, which typically holds the package manager configuration.

There is also a renovate.json for dependency updates and an eslint.config.mjs with @nuxt/eslint, plus a .vscode/ directory and a tsconfig.json. The presence of TypeScript configuration and a Nuxt-aware ESLint setup means the theme is written for a typed Vue codebase even though your content is Markdown.

Version numbers that do not agree, and what that tells you

There is a version mismatch in this repository that an adopter should notice before pinning anything.

The listed GitHub releases are v1.1.0 on 2023-10-25, v1.1.1 on 2023-12-12 and v1.1.2 on 2024-01-23. The package manifest, on the other hand, declares version 2.0.0 with the main entry point at nuxt.config.ts.

So the newest tag in the release list is from January 2024, while the source tree describes itself as 2.0.0. The likely explanation is that releases are tagged or published separately from the manifest version, or that the 2.0.0 work was never cut as a GitHub release. Either way, the practical consequence is that the GitHub release list is not a reliable way to find the current version, and the manifest is the better guide to what the source tree contains.

The dependency set points the same way. Nuxt is at ^3.15.4, @nuxt/content at ^3.4.0, Tailwind at 4.1.3 and @nuxt/icon at 1.11.0. Those are recent enough versions that this tree is being kept current against Nuxt 3 and Nuxt Content 3, not frozen on the 2024 stack.

On maintenance timing, the last push was on 2026-04-23. That is the date to quote rather than any characterisation of how actively the project is developed, because the documentation does not state a support policy or a roadmap, and the release list is stale enough that it says little either way. For a theme you fork and own, that matters less than it would for a library, because you are not waiting on upstream for bug fixes, you are merging the repository and changing it.

Where Content Wind is the wrong choice

Three situations rule it out, and all of them come from the same root: the content model is a directory of Markdown files.

The first is a site that needs an editorial workflow with non-technical writers. If the people writing the site will not use a text editor and a git repository, a filesystem-based theme asks them to learn one, or you build a CMS on top, and the theme gives you nothing for that.

The second is a site whose content is dynamic. Anything that has to be fetched at request time, personalised per user, or sourced from another system does not fit a build-time content directory. Nuxt can do all of that, but then you are building a Nuxt app and using the theme for its layouts and prose components, which is a legitimate but much smaller use of it.

The third is a team that wants a shared component library across several sites. The theme is a single site scaffold, not a design system package. Its components live in the app/ directory of the cloned repository, so sharing them means extracting them into your own package, which is work the theme does not do for you.

The alternative approach depends on what you are building. For a personal site, a plain Nuxt Content setup with your own components is smaller and gives you the same content model, and the theme's value is precisely the pre-built shell, typography defaults and icon set. For a team that wants an editorial platform, a headless CMS with a rendering frontend separates the authoring experience from the site, which is a bigger architecture but the one that actually supports non-technical writers. Content Wind optimises for the first case and makes no attempt at the second.

Editorial conclusion

Content Wind suits someone who wants a personal or documentation site in Vue and is happy to write Markdown with a small amount of Vue where Markdown is not enough, and the one command init makes the first deployment a few minutes away. It does not suit a project that needs a CMS, an API-driven site or an editor other than the filesystem, because the content model is a directory of Markdown files and the theme does not offer an alternative. Before adopting it, check the version you actually get, since the newest tagged release is v1.1.2 from 2024-01-23 while the package manifest declares 2.0.0, and read the documentation on the demo site rather than assuming the readme covers the current API.

Frequently asked questions

Official sources

1. atinux/content-wind on GitHub
2. License: MIT
3. Project website
4. README
5. Releases