TL;DR: The markdown file your AI coding assistant reads, a CLAUDE.md, an AGENTS.md, a Cursor rules file, was never guaranteed to match what your enforcement platform actually checked. Guidelines as Code closes that gap. Point Pandorian at a directory in your repo, and every properly tagged markdown file becomes a live, enforced guideline the moment it’s merged to main, no manual re-entry, no second source of truth.

What’s in this post

• One Directory, Every Guideline, No Copy-Paste
• One Source of Truth, Versioned Like the Code It Governs
• The File Your AI Reads Is the File Pandorian Enforces
• The Rules Were Never the Problem. Having Two Sets of Them Was.
• Common Questions

Your AI coding assistant reads a markdown file to know how your team writes code. Your enforcement platform reads something else: whatever got typed into a settings screen at some point, by someone who may not still be on the team.

Guidelines as Code closes that gap by making the repository itself the source of truth. Point Pandorian at a directory, and any markdown file with the right metadata becomes a live guideline the moment it lands on main.

The question was never whether your standards were written down. It’s whether the file instructing your AI and the file enforcing your code were ever the same file.

One Directory, Every Guideline, No Copy-Paste

Guidelines as code means pointing Pandorian at a repository directory instead of re-entering standards in a separate dashboard. Designate a base directory, /docs/guidelines is a common choice, in the Integrations tab, and Pandorian starts monitoring it for markdown files.

Each file carries a small YAML frontmatter block: an ID, the target language, a title, whether violations block a build or just get monitored, a category, and tags. Merge a change to that directory into main, and the update is live. The guideline is immediately enforced across every repository it applies to.

There’s no export, no manual sync, no quarterly reconciliation between what the docs say and what Pandorian actually checks. The directory is the guideline catalog, and it covers more ground than the pre-built catalog alone: any of Pandorian’s 20+ supported languages can be targeted directly from your repo.

One Source of Truth, Versioned Like the Code It Governs

Versioning guidelines as code means every change goes through the same pull request review, commit history, and rollback your team already trusts for the codebase itself. A guideline update isn’t a form submitted into a settings screen somewhere. It’s a commit, reviewed the same way a change to production code would be, with a clear record of who changed it, when, and why.

That version history feeds directly into the enforcement layer. Merge a change to the guidelines directory on main, and Pandorian picks it up and starts enforcing the new version immediately, across every repository the guideline applies to. There’s no separate publish step and no second place where the “real” guideline lives. We’ve made the case before for why guidelines belong in version control in the first place. Guidelines as Code is that idea made literal: the repository isn’t a mirror of your standards, it is your standards, a single source of truth with git as the audit trail.

If a guideline change turns out to be wrong, too strict, or targeting the wrong language, revert the commit. Enforcement reverts with it, the same rollback your team already uses for a bad code change, not a support ticket to a vendor.

The File Your AI Reads Is the File Pandorian Enforces

If your team already writes markdown instruction files for AI coding assistants, guidelines as code lets those same files define what Pandorian enforces. Every major coding assistant reads its own version of this file: Claude Code looks for CLAUDE.md, Codex CLI reads AGENTS.md, Cursor uses a rules directory, GitHub Copilot reads copilot-instructions.md. These files already describe your team’s real conventions, because they’re the files developers actually maintain to keep AI output usable.

That matters more than it used to. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI coding tools, yet only 29% said they trust the code those tools produce without review. Two different, drifting documents, one guiding the AI and one supposedly validating its output, is exactly the gap that erodes that trust.

With guidelines as code, a rule like requiring IO over blocking calls in Scala, or banning null in favor of Option, lives in the same markdown file your AI assistant already reads before it writes a line. Update the file once. The AI writes to it, and Pandorian enforces it.

The Rules Were Never the Problem. Having Two Sets of Them Was.

Every team already writes down what good code looks like, somewhere: a Confluence page, a CLAUDE.md file, a senior engineer’s comments in code review. The failure was never a lack of documentation. It was maintaining two versions of the truth, one that guided the AI and one that maybe got enforced. Guidelines as Code collapses that into one file, versioned, reviewed, and enforced the same way the rest of your code already is.

Common Questions

Written by Amit Kochman, GTM Operations Director at Pandorian

Related Reading

• New Feature: Turn Your Agent Skills Files into Powerful CI Enforcement Rules
• Why You Should Be Versioning Guidelines Like Code
• New Feature: Turn Confluence and Docs Into Live Code-Wide Guardrails
• Explore the Pandorian Platform