Brilliant CV: a Typst package for CVs you can retarget

A template that is a real Typst package

Brilliant CV is described as a modern, modular, and feature-rich CV template for Typst, and the repository description is blunter about the genre: another CV template for your job application, yet powered by Typst and more.

The important structural fact is that it is a package, not a folder of files. It is published on Typst Universe, and the site listed as the homepage is the package page on typst.app/universe/package/brilliant-cv. That means the project is consumed the way other Typst packages are consumed, with the template manager scaffolding a project around it rather than a person copying a directory and editing it.

The primary language is Typst, the licence is Apache 2.0, the default branch is main, and the last push was on 2026-10-19. The releases are v4.0.1 on 2026-05-01, v4.1.0 on 2026-07-19 and v4.1.1 on 2026-09-26, so the project is being maintained on a regular cadence, and the version numbers sit in a 4.x line that has been running since May 2026.

For a reader deciding whether to look further, the design question is simple. Typst is a typesetting system with a template system on top, so a CV template written in it is a program rather than a set of macros to fight with, and the entire document is compiled rather than assembled in a word processor. That is a real difference in how you maintain a CV, and the rest of the README is about how this particular template uses that.

Profiles are the unit of variation

The first key feature is the one that decides whether the template is useful to you, and it is called one profile, one complete CV, bind it to anything.

Each profile_<name>/ directory is a self-contained variant you can target at a specific job, audience or language, and it is switched with --input profile=<name> at compile time. The interesting claim in the same bullet is that profiles are fully decoupled from language: any script, CJK, Arabic, Hebrew and the rest, works through the [layout.fonts] settings.

That decoupling is the design decision. A naive template would make a profile a translation, and a French profile would be the English one with a different font. Here, a profile is a target, and the script is a property of the layout configuration, so a Chinese CV aimed at a domestic employer and a Chinese CV aimed at an international one are two profiles rather than one profile in two languages.

The second key feature is the composition model. You build each CV from reusable blocks, experience, education, projects, publications and skills, and you keep as many tailored variants as you need, a long academic version, a one-page industry cut, or one per application, from the same building blocks. The third is that it is polished by default, with clean, modern typography, Font Awesome icons and a matching cover letter.

The practical instruction in the README is short: to add a new variant, copy the directory and tweak the fields that differ. That is the whole extension story, and it is a deliberately small one.

The compile loop, and the keyword layer you probably should leave off

Getting started is a scaffolding command and a compile:

typst init @preview/brilliant-cv   # scaffolds a project directory with the template
cd brilliant-cv

Then, once you have edited the profile, the document is compiled the same way for every variant, with the difference carried in the input argument:

typst compile cv.typ                    # default profile
typst compile cv.typ --input profile=fr # switch profile at compile time

The second line is the whole point of the design in one command. The French CV is not a different document, it is the same document compiled with a different profile, which means the blocks stay in sync and only the fields that differ need editing.

Two practical notes from the README. If you are using Typst Web, you have to upload the Font Awesome 7 Free desktop OTF files, the Regular, Solid and Brands ones, to your project so the contact icons render, which is a browser sandbox constraint rather than a template limitation. And you edit profile_en/metadata.toml and the content modules in profile_en/*.typ, with profile_en described as the most heavily annotated profile, so it is the one to read first.

Then there is the feature worth reading twice. It is optional to embed a hidden, ATS-friendly keyword layer for automated screeners, and it is opt-in and off by default. The same keywords are also written openly to the PDF Keywords metadata field, and the README asks you to read the notes in profile_en/metadata.toml before enabling it, and to keep keywords truthful.

That is a careful piece of design. A hidden keyword layer is the sort of thing that drifts into keyword stuffing, so the template makes it opt-in, makes the same terms visible in the PDF metadata, and asks for truthfulness. Whether to enable it at all is your decision, and the default is no.

Version 4 breaks loudly, on purpose

The README opens with a warning that v4 is a breaking change, and it points to a migration guide for the v3 fields that now panic with a migration message, naming them: language, non_latin_font, the [lang.<code>] form, inject_ai_prompt, and others, together with their v4 replacements.

Panicking is a deliberate choice and it is the right one for a template. The old field names were not going to keep working, and a template that silently ignored a field the user had set would produce a document missing a language setting or a font, with no explanation. A panic with a migration message tells the author exactly what they have to change, and it fails at compile time rather than producing a wrong PDF.

The rename of language to the layout fonts configuration is the visible shape of the change, and it is the same decoupling the profiles section describes: the script is now a layout property rather than a per-profile field, which is what makes a profile usable across languages.

For anyone arriving at the project from version 3, the migration guide is a required reading rather than an optional one. The template keeps a dedicated documentation site for it, and the guide is linked from the top of the README rather than buried, which is the right place for something that breaks builds.

The repository is a package with its own development loop

The top-level listing shows a package project rather than a document repository.

There is typst.toml, which is the package manifest, a src/ directory for the library code, a template/ directory with the actual CV template, docs/ for the documentation site, scripts/, tests/ with a .pre-commit-config.yaml, a justfile, an AGENTS.md and a CLAUDE.md, a CONTRIBUTING.md, and a thumbnail.png that the README uses as its preview image.

The justfile is the most interesting file, because it is the project's own description of how the package is developed. The default recipe lists the available commands, and the dev recipe describes a complete development lifecycle with automatic cleanup: it links the workspace, starts a watch mode with typst watch on the template, and installs a trap on interrupt so that when you stop the watcher it builds the final version and cleans up. The internal cleanup recipe builds the final PDF, unlinks the local package and removes the temporary files.

The link recipe is where the Typst package tooling shows through. It runs utpm prj link --force --no-copy against the preview package, and it is careful: it captures the output, checks for ERROR or Operation not permitted in it and fails loudly with a message if the linking failed, and it then reads the package version out of typst.toml with python3 and tomllib before evaluating the imported value to check that its type is the expected function.

The gallery section adds one more detail about the process. The preview images for English, French and Chinese are generated in CI from the live template with just previews, so the screenshots in the README cannot drift away from what the template actually produces.

What to check before you build your CV on it

Three things, in the order in which they will bite you.

The version. If you are moving from version 3, the old field names now panic with a migration message, and the guide linked at the top of the README lists them and their replacements. If you are starting fresh, the only question is whether the 4.x line is the one you want, and the release history suggests it is, with three releases between May and September 2026 and a push on 2026-10-19.

The environment. In Typst Web the Font Awesome files have to be uploaded to the project, and the icons in the contact block are part of the design rather than a decoration you can drop. If you compile locally, they are handled by the package.

The keyword layer. It is off by default, it is opt-in, it writes the same terms into the PDF Keywords metadata so they are not hidden, and the documentation asks you to keep them truthful. The sensible thing is to read the notes in profile_en/metadata.toml, and then to decide whether you need it at all.

Beyond that, the project is in good shape for what it is. The documentation site carries the full guide, a component gallery, recipes and a configuration reference, the previews are generated from the live template in CI, the licence is Apache 2.0, and the sponsor list is short and human, which is a good sign about how the project is run.

Editorial conclusion

Adopt Brilliant CV if you write CVs in Typst and want one content source with several tailored outputs, a long academic version and a one-page industry cut built from the same blocks, because that is exactly what the profile mechanism is for. Do not adopt it without reading the v4 migration guide, since the old field names now panic with a migration message rather than being ignored, and check what the template asks of you in the web environment, where the Font Awesome files have to be uploaded to the project. Before you compile, decide about the keyword layer, because it is off by default on purpose and the documentation asks you to keep any keywords you do enable truthful.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. yunanwg/brilliant-CV on GitHub