CSharpGuidelines keeps a style guide as a website and a buildable PDF

The site is the source, and the PDF is a build product

The repository describes itself as a set of coding guidelines for C# up to v14, design principles, layout rules and Agent Skills, and the landing page is csharpcodingguidelines.com. What is interesting about the layout is where the authority sits. The rules are not in a single document, they live as individual files under a _rules/ directory, and the site itself is a Jekyll site with the usual pieces, _config.yml, _data/, _includes/, _layouts/, _pages/, _sass/ and assets/. The site is therefore the readable form, and it is also the source from which the PDFs are produced, which means the two cannot drift. The rule set is compiled into a full guidelines document and into a two page cheat sheet, both generated into an Artifacts folder, and the difference between the two is the point. A document you can read end to end and a document you can pin above a desk are different products, and generating both from one source is the part most style guides get wrong.

Two PDF artefacts, and Chrome plus Pandoc to make them

Building the PDFs is a single command from the repository root, and there is a script per platform.

.\build.ps1        # Windows
./build.sh         # macOS / Linux

The output is two files in the Artifacts folder, CSharpCodingGuidelines.pdf for the full guidelines document and CSharpCodingGuidelinesCheatsheet.pdf for the two page cheat sheet. The toolchain is deliberately boring, since Pandoc is downloaded automatically on first run and Google Chrome must be installed for PDF rendering. Using a browser as the PDF engine is a common choice because it means the PDF is rendered by the same engine that renders the site, so a rule that renders correctly on the page renders correctly in the document. The cost is that Chrome is a hard prerequisite on every machine that produces the artefacts, including the CI runner, and the repository lists it as a prerequisite alongside the .NET 10 SDK.

Previewing the site needs Ruby, and the theme comes with npm scripts

Running the site locally has its own script, and it installs a Ruby toolchain for you if it is not there.

.\launch-website.ps1        # Windows
./build.sh LaunchWebsite    # macOS / Linux

That installs Ruby 3.3 if not already present, runs bundle install, and starts the Jekyll development server at http://localhost:4000, and the server monitors for changes when the incremental flag is used. The repository carries a Gemfile and a Gemfile.lock for the Ruby side, which is the Jekyll dependency set. On the JavaScript side there is a package.json, and it is worth noticing what it contains, because the name is minimal-mistakes and the description is the Minimal Mistakes Jekyll theme npm build scripts. The theme is the upstream project by Michael Rose under the MIT licence, and the scripts in it uglify the jQuery and plugin assets, add a banner and run bundle exec jekyll serve with the incremental and watch flags. So the JavaScript in this repository is the theme's, not the guidelines', and the guidelines content is the part you would fork.

The rule set is data, which is what makes it reviewable

The repository structure is the argument for the design. A _rules/ directory with one file per rule means a rule can be discussed, changed and versioned as a unit, which a single 300 page document cannot do. The _data/ directory holds structured site data, and the _pages/ and _includes/ directories carry the presentation, so the content and the rendering stay separate in the usual Jekyll way. The other notable files are the ones that show the project has an audience beyond the page itself. There is a Skills/ directory, and the project description mentions Agent Skills for improving the overall quality of your code development, so the guidelines are being packaged for tools that read them rather than only for humans. There is a staticman.yml, which is the configuration for a comment system for static sites, an ads.txt for the advertising side, a CNAME for the domain, and a .nuke/ directory plus build.cmd, build.ps1 and build.sh for the build, with a CSharpGuidelines.slnx and a global.json for the .NET side. A repository that carries both a solution file and a Ruby Gemfile is telling you it is more than one thing.

Maintenance has picked up, and the version numbering is unusual

The release history is unusual for a document. The tags are 6.0.0 from 2026-05-16, 5.7.0 from 2024-01-27 and 5.6.0 from 2022-03-10, so the version is a major number that moves with the content, and the two-year gap between 5.7.0 and 6.0.0 tells you the bulk of the change was large. The last push was on 2026-07-21, and the project covers C# up to v14, so the guideline set is being kept in step with the language, which is a recurring obligation rather than a one-off. The licence is listed as a custom one that GitHub cannot classify, with the terms in the LICENSE.md file, and for a document that people are invited to adopt as a house style that file is the one to read, since the MIT licence the theme's package.json declares applies to the theme's own files and not to the guideline content. The troubleshooting section in the README is also short and specific, with a pointer to a known pages-gem issue around jekyll-remote-theme and libcurl, and a pointer to a Jekyll issue for the SSL certificate verification error, which are the two failures a new contributor is most likely to hit.

Where a written style guide is the wrong instrument

The main limitation is that this is advice, not enforcement. Nothing in the repository runs as a check on your code, so every rule remains a thing a human has to notice and mention, and a style guide without a corresponding formatter or analyzer configuration is a document that slowly stops matching what the codebase does. That is not a criticism of the project, which is explicit that it is a set of guidelines, but it changes who should reach for it. The second limit is scope, because the guidelines cover C# up to v14 with design principles and layout rules, which means they are written for a mainstream .NET shop and will describe a default position on questions where teams legitimately differ, and adopting them wholesale is adopting someone else's defaults rather than your own. The third is the delivery format. The site is the primary artefact and the PDFs are generated, so if your organisation needs the rules inside a wiki, an internal docs site or a lint configuration, you will be converting them by hand. The fourth is the tooling chain, where producing a change means Ruby, Jekyll, a bundler, Pandoc and Chrome, and the .NET SDK is listed as a prerequisite even though the documentation itself is not a .NET project.

Editorial conclusion

CSharpGuidelines suits a C# team that wants a written style guide it can point at in review comments, and it suits anyone who wants the rules as a document rather than as a linter configuration, since the same rules are what a reviewer would quote. It is the wrong tool for enforcing anything automatically, because nothing here runs as a check on your build, and it is the wrong tool for a team whose conventions already come from a formatter with opinions baked in, where a second document describing the same style is a maintenance liability rather than an asset. Before adopting it, read the rules against your existing style rather than against your aspirations, and treat the cheat sheet as the starting point for a conversation rather than as a mandate. The last push was on 2026-07-21 and the current release is 6.0.0 from 2026-05-16.

Frequently asked questions

Official sources

1. dennisdoomen/CSharpGuidelines on GitHub
2. Issues
3. Project website
4. README
5. Releases