claude-code-everyone-course: a Nextra site built from course lessons

What the repository actually is

The README's title is Claude Code for Product Managers, and its first line says this is the Nextra-based documentation website for the Claude Code for Product Managers Course. The repository description is different again: Claude Code for Everyone, learn Claude Code in Claude Code.

That mismatch is worth flagging rather than smoothing over. The repository is named claude-code-everyone-course, the description says for Everyone, the README header says for Product Managers, and the deployment instructions tell you to import a repository called claude-code-pm-course. The releases make it clearer in part: v2.0.1 is Claude Code for Everyone, Complete Course, v2.0.2 is the same with a version number, and v2.0.3 removes Nimbalyst references. So the course appears to have been rebranded, with the documentation site, the repository names and the deployment instructions not all updated in step.

That is a small thing, and it is the kind of small thing that matters to somebody trying to reproduce a deployment from the README.

The primary language is recorded as MDX, which is accurate for a documentation site whose content is Markdown with JSX components. The licence is not a standard identifier. The default branch is main, the homepage is a Vercel deployment URL rather than a stable custom domain, and the recent releases are v2.0.3 from 2026-04-06, v2.0.2 from 2026-03-06 and v2.0.1 from 2026-02-03. The last push was on 2026-08-05 with the project not archived.

The site itself is a Next.js 14 application with Nextra 3 as the documentation theme, and the package manifest confirms the versions exactly: next at 14.2.5, nextra and nextra-theme-docs both at 3.2.3, react and react-dom at 18.2.0. The dev dependencies are @types/node at 24.8.1, next-sitemap at about 4.2.3 and pagefind at 1.1.0.

Development and build, which is three npm commands

The development section is short enough to quote in full:

# Install dependencies
npm install

# Run development server
npm run dev

# Open http://localhost:3000

That is npm install, npm run dev, and open localhost:3000. The build is equally short:

# Build static site
npm run build

# The build output will be in the `out/` directory
# Pagefind will automatically index the content after build

The comments in the build block are the informative part. The build output goes to the out/ directory, and Pagefind will automatically index the content after the build.

That static output directory is the whole reason the deployment instructions are what they are. A Next.js app with a build output directory of out is a static export, not a server deployment, so the site can be served from a CDN with no Node process running. The package manifest makes the same point in the scripts, where the build script is next build and the postbuild script runs next-sitemap with the sitemap config and then pagefind against the out directory.

So the pipeline is: Next builds the pages to a static directory, next-sitemap generates a sitemap from the exported site, and Pagefind builds a search index over the exported HTML. The search index is what makes the client-side search work, and generating it after the build is the only correct order, since it needs the finished HTML to crawl.

There is also a preview script, npx serve out -p 3000, which serves the exported directory locally. That is a small but genuinely useful detail, because it lets you check the static build, including the search index, without deploying anything.

Deploying to Vercel, and the two ways to do it

The deployment section offers a dashboard route and a CLI route, and both come down to the same set of settings.

The dashboard route is a numbered list: sign in at vercel.com, click Add New Project, import the GitHub repository, set the Root Directory to website, pick the Framework Preset of Next.js, set the Build Command to npm run build, set the Output Directory to out, and deploy.

The CLI route is:

# Install Vercel CLI
npm i -g vercel

# Deploy from the website directory
cd website
vercel

# For production
vercel --prod

The important thing in both is the Root Directory. This is a monorepo-style layout where the site lives in a website/ subdirectory, and if that setting is wrong the build will fail or deploy the wrong thing. The same warning applies to the repository name in step three, which names a different repository than the one this README lives in.

The Output Directory of out is the other setting that matters, because it is unusual for a Next.js project. Most Next deployments expect the .next directory and a running server, whereas this one is a static export. Getting that wrong produces a deployment that builds successfully and serves nothing useful.

The repository also has a DEPLOY.md, a VERCEL_SETTINGS.md and a vercel.json at the root, so the settings the README describes in prose are also captured in files you can copy. The presence of VERCEL_SETTINGS.md next to the step list is the pattern to follow if you are deploying a Nextra site yourself: keep the exact settings in a file, because the failure mode of a wrong output directory is confusing and the fix is one field.

The structure, and how content is generated

The project structure diagram is the most informative part of the README because it explains the two-directory model.

website/
├── pages/               # All content pages (MDX)
│   ├── company-context/ # TaskFlow company info
│   ├── getting-started/ # Modules 0.0-0.2
│   ├── fundamentals/    # Modules 1.1-1.7
│   ├── advanced/        # Modules 2.1-2.3
│   ├── _app.jsx         # Next.js app wrapper
│   ├── _meta.ts         # Navigation config
│   ├── index.mdx        # Homepage
│   └── search.mdx       # Search page with Pagefind
├── public/
│   └── images/          # Course images
├── next.config.mjs      # Next.js configuration
├── theme.config.tsx     # Nextra theme configuration
└── package.json         # Dependencies

The pages/ tree is organised by module rather than by topic. company-context/ holds the TaskFlow company information, which tells you the course runs against a fictional company that exercises are set in. getting-started/ covers modules 0.0 to 0.2, fundamentals/ covers modules 1.1 to 1.7, and advanced/ covers modules 2.1 to 2.3. The leading _ in _app.jsx and _meta.ts marks them as Nextra convention files: the app wrapper and the navigation configuration.

Nextra's meta file is what generates the sidebar, so the whole navigation structure of the course site is data in one TypeScript file rather than a hand-maintained list in every page.

Then there is index.mdx as the homepage and search.mdx as the search page with Pagefind. That separation matters, because Pagefind does not work as a build-time search across MDX source. It indexes the rendered HTML output, so a client-side search widget has to be a separate page that loads the generated index at runtime, which is exactly what search.mdx is for.

The content pipeline is described in the Content Updates section, and it is the part with the real design decision in it. Content is automatically converted from the main course lesson-modules/ directory, and the update procedure is three steps: edit the REFERENCE_GUIDE.md files in /lesson-modules/, run the conversion script ./convert-content.sh, then build and deploy.

So the source of truth is a directory called lesson-modules/ that lives outside this repository, or at least outside the website/ tree, and the site is a derived artefact. The repository listing supports that: there is a `course-materials/` directory, a course-structure.json, a convert-content.sh script, and two fix-frontmatter scripts, fix-frontmatter.py and fix-frontmatter-v2.py.

The two versions of the frontmatter fixer are a small but revealing detail. A v2 of a script usually means the first one did not fully solve the problem, and the fact that the script was written at all suggests the MDX frontmatter produced from the source lessons does not quite match what Nextra expects. That is the kind of friction that a conversion step between two content systems always has, and it is worth knowing about before you try to feed your own lessons through the same script.

The wider repository, and the parts you would not guess

The top-level listing is broader than a documentation site, and several entries are worth decoding.

There is an api/ directory, which on a static export means either serverless functions or, more probably here, content served as data files rather than a server. There are components/ for shared React pieces, styles/ for CSS, releases/ for release artefacts, and public/ for images.

The two Python scripts at the root, fix-frontmatter.py and fix-frontmatter-v2.py, we have covered. There is next-sitemap.config.js, a next.config.mjs, a theme.config.tsx for the Nextra theme, a next-env.d.ts, a tsconfig.json, a vercel.json and a package-lock.json.

The course-structure.json is the interesting one, because it suggests the module organisation is machine-readable rather than only expressed in the Nextra meta file. If the module boundaries and the order of the lessons live in a JSON file, then the conversion script and the navigation can both be derived from it, and the two cannot drift apart.

The `course-materials/` folder is the counterpart to the lesson-modules/ directory the README refers to, so the repository appears to hold the lessons in one form and the converted site content in another. The releases/ directory alongside the tagged releases suggests the site is versioned in step with the course, which is what you want for a course people work through module by module.

The tech stack section confirms the four choices: Next.js 14 for static site generation, Nextra 3 for the documentation theme, Pagefind for client-side search, and MDX for Markdown with JSX components. The links section points to a live site that is listed as to be determined and will be deployed to Vercel, the course repository, and the Nextra and Pagefind documentation.

How to evaluate it, and what to check first

There are four things to establish, and the first is whether the lessons here are what you actually want.

This repository is a website for a course about Claude Code, aimed at product managers according to the README header, with a fictional company called TaskFlow used as the running example. It is not a Claude Code distribution, not a plugin collection and not a set of prompting techniques. If you are looking for a way to use Claude Code well, the value here is a structured curriculum with exercises, and the website is the delivery format for it.

The second is the content pipeline, and this is the part that decides whether you can reuse the machinery. The site is generated from lesson modules by a conversion script, and the source of truth is a REFERENCE_GUIDE.md per module. If you want to publish your own course in the same shape, the pieces to reuse are the Nextra theme configuration, the directory layout, the conversion script and the Pagefind search page. The two frontmatter fixer scripts are a warning that the conversion is not entirely smooth, so budget time for that if you are adapting it.

The third is the deployment. Static export to Vercel with the Root Directory set to website and the Output Directory set to out. Those two settings are the whole deployment, and the presence of VERCEL_SETTINGS.md means you can copy them rather than retyping them.

The fourth is the state of the project, and here the dates are worth reading closely. The releases are v2.0.1 from February 2026, v2.0.2 from March and v2.0.3 from April, and the last push was on 2026-08-05, so the site is receiving commits several months after the last release tag. The live site link is listed as to be determined in the README, even though a Vercel URL exists as the homepage, which suggests the README is not fully maintained. Combined with the repository name drift between the course for Everyone and the course for Product Managers, the reasonable conclusion is that the site works but the documentation around it is behind.

The stack itself is dated in a way that is worth noting. Next.js 14.2.5 and Nextra 3.2.3 are both a couple of major versions behind what is current, and react 18.2.0 rather than 19. For a documentation site that is not a problem, since nothing about the content depends on the newest framework features, but if you are starting a new site today you would pick up a newer Nextra and the theme configuration would need adjusting rather than copying.

Editorial conclusion

Adopt the claude-code-everyone-course setup if you are publishing a course as a Nextra documentation site and want a working reference for a static export with a conversion script and Pagefind search, since the configuration, the directory layout and the deployment settings are all there to copy. Do not adopt it expecting a Claude Code tool, plugin or technique library, because what the repository contains is a website and a content pipeline for a course, and do not copy the repository naming as it stands, since the README, the repository description and the deployment instructions all point at different course names. Before you commit, set the Vercel Root Directory to website and the Output Directory to out, plan for the frontmatter conversion to need attention since there are two generations of the fixer script, and expect the Next.js 14 and Nextra 3 pins to need updating if you start a new site rather than maintaining this one.

Frequently asked questions

Official sources

1. carlvellotti/claude-code-everyone-course on GitHub
2. Issues
3. Project website
4. README
5. Releases