Claude Code Governance Templates

Ready-to-use governance templates for Claude Code, organized by tech stack. Rules load automatically on every session: no prompting required.

If this saves you time, consider giving it a ⭐: it helps others find the project.

Why this exists

Without structure, Claude Code generates inconsistent code, ignores your conventions, and repeats the same mistakes across sessions. This project fixes that with a hierarchy of CLAUDE.md files that load automatically: no prompting required.

What you get:

• Consistent code that respects your architecture and naming conventions
• Security rules enforced by default (no IDOR, no raw SQL, no hardcoded secrets)
• Cost control: precise diffs instead of full rewrites, right model for the right task
• Behavior adapted to the developer's experience level (Junior → Tech Lead)

Installation

Via plugin marketplace (recommended):

/plugin marketplace add datallmhub/claude-governance
/plugin install claude-governance

Then run /setup in any project: select your stack, governance files are copied automatically, and rules inject at every session start.

Local / development:

git clone https://github.com/datallmhub/claude-governance.git
claude --plugin-dir /path/to/claude-governance

Manual (no plugin):

1. Copy the stack folder into your project root
2. Update CLAUDE.md with your project name and stack versions
3. Copy CLAUDE.local.md.example → CLAUDE.local.md (do not commit)
4. Set your experience level in dev-level.md

Available stacks

Java

JavaScript / TypeScript

Python

.NET / Go / PHP

What's inside each template

<stack>/
├── CLAUDE.md                    # Project context: always loaded
├── CLAUDE.local.md.example      # Personal overrides (copy locally, never commit)
├── .claude/
│   ├── settings.json            # SessionStart hook: injects rules at session start
│   ├── rules/
│   │   ├── backend.md           # Backend rules: scoped to backend files only
│   │   ├── frontend.md          # Frontend rules: scoped to frontend files only
│   │   ├── database.md          # DB / migration rules
│   │   ├── testing.md           # Testing standards
│   │   ├── security.md          # Security rules: loaded on every file
│   │   ├── governance.md        # Git, PR, versioning, release process
│   │   └── dev-level.md         # Behavior by experience level
│   └── architecture/
│       ├── overview.md          # System architecture + key decisions
│       ├── api.md               # REST API contract
│       └── data-model.md        # Database schema
└── samples/                     # Code examples applying all the rules

Load order

~/.claude/CLAUDE.md       ← personal preferences (your machine)
./CLAUDE.md               ← project rules (committed, shared)
./CLAUDE.local.md         ← personal overrides (gitignored)
.claude/rules/*.md        ← scoped rules (loaded per file path)

Security

security.md loads on every file automatically. It enforces:

• No IDOR: public_id UUID in all URLs, never internal sequential IDs
• No hardcoded secrets: all credentials via environment variables
• Safe tokens: JWT in memory, refresh token in HttpOnly; Secure cookie
• Injection prevention: parameterized queries, input validated at system boundary
• CORS locked down: explicit origin whitelist, never allowedOrigins("*")

Developer Experience Levels

One setting in dev-level.md: Claude adapts its verbosity automatically.

GovEval: Validate your governance

GovEval is to governance rules what unit tests are to code.

It does not test Claude in isolation. It tests Claude as configured by this repo — CLAUDE.md + .claude/rules/ + dev-level + everything else loaded automatically.

The developer prompt never repeats the rules:

Developer request → Claude Code runtime (rules loaded silently) → Generated code → Judge → PASS / FAIL

Example — SEC-01:

The judge (Mistral Large) is a different model family than the generator (Claude), so it isn't grading its own work.

/gov-eval                          # all scenarios
/gov-eval --category security      # one category
/gov-eval --scenario SEC-01        # one scenario

Requires MISTRAL_API_KEY. See java-react/tests/ for full details.

Run it on a schedule, not just once. A rule that passes today can silently break after a model update, even with no changes to CLAUDE.md. Re-run GovEval on every PR touching .claude/rules/, and periodically (e.g. every 2 weeks) to catch drift from model updates.

Contributing

See CONTRIBUTING.md for the full guide.

Pick an open new-stack issue: each one is a self-contained task with clear acceptance criteria.