A Godot C#, GDScript curated subset of the everything-claude-code repository. Strips out public-use rules and heavy JavaScript/frontend context, focusing Godot specific developers, and some other front-end, back-end support.
- Focus
- Installation
- Repository Structure
- Using Agents
- Skills
- Using Rules
- Adding New Content
- Key Conventions
- Languages: Godot (GDScript + C#), C# (.NET / ASP.NET Core), Java (Spring Boot), Terraform (Azure Verified Modules), Go, Python
- Cloud: Azure
- Philosophy: No auto-pushing code at this level — override at project/user level if needed. Plugins are under review and not yet vetted.
./install.sh <language> [<language> ...]
# Examples
./install.sh golang
./install.sh golang java terraform
./install.sh --all.\install.ps1 <language> [<language> ...]
# Examples
.\install.ps1 golang
.\install.ps1 golang java terraform
.\install.ps1 -AllRun the installer with no arguments to see the list:
csharpgodotgolangjavaterraform
Use --all (Bash) or -All (PowerShell) to install every available language at once.
The installer copies the following into ~/.claude/:
| What | Source | Destination |
|---|---|---|
| Common rules | rules/common/ |
~/.claude/rules/common/ |
| Language rules | rules/<lang>/ |
~/.claude/rules/<lang>/ |
| Agents | agents/*.md |
~/.claude/agents/ |
| Skills | skills/*/SKILL.md |
~/.claude/skills/<name>/ |
Common rules and all agents/skills are always installed. Language rules are installed only for the languages you request (or all with --all).
rules/
common/ Language-agnostic rules (coding style, git, security, testing, etc.)
csharp/ C#/.NET-specific rules
godot/ Godot engine rules (GDScript + Godot C#)
golang/ Go-specific rules
java/ Java/Spring Boot-specific rules
terraform/ Terraform/Azure-specific rules
agents/ Agent definitions (planner, architect, tdd-guide, code-reviewer, etc.)
skills/ Skill definitions (Spring Boot, Go, Python, JPA, Terraform, etc.)
examples/ Example CLAUDE.md files for target projects
plugins/ Plugin marketplace docs (under review, not yet vetted)
install.sh Bash installer (Linux/macOS)
install.ps1 PowerShell installer (Windows)
Agents are specialized sub-agents that Claude Code delegates to for specific tasks. Each agent is defined as a Markdown file in agents/ with YAML frontmatter specifying its name, description, allowed tools, and model tier.
After installation, agents live in ~/.claude/agents/ and Claude Code discovers them automatically. You do not need to configure anything beyond running the installer.
Invoking agents manually:
> Can you run the code-reviewer agent on my latest changes?
> Use the planner agent to break down this feature.
> Run security-reviewer before I commit.
Automatic invocation: The rules in rules/common/agents.md instruct Claude Code to invoke agents proactively based on context — for example, running code-reviewer after code modifications or tdd-guide when writing new features. You do not need to ask explicitly; Claude Code will use them when appropriate.
Parallel execution: Independent agents run in parallel when possible. For example, security-reviewer and code-reviewer can analyze different aspects of the same change simultaneously.
| Agent | Model | Purpose | When to Use |
|---|---|---|---|
| planner | opus | Implementation planning | Complex features, architectural changes |
| architect | opus | System design and scalability | Architectural decisions, technical trade-offs |
| tdd-guide | sonnet | TDD enforcement | New features, bug fixes, refactoring |
| code-reviewer | sonnet | Code quality and security | Immediately after writing or modifying code |
| security-reviewer | sonnet | Vulnerability detection (OWASP Top 10) | Code handling user input, auth, secrets, APIs |
| build-error-resolver | sonnet | Fix build/type errors | When builds fail |
| refactor-cleaner | sonnet | Dead code cleanup | Code maintenance, consolidation |
| Trigger | Agent |
|---|---|
| User requests a complex feature or refactoring | planner |
| Architectural decision or trade-off discussion | architect |
| New feature, bug fix, or any code change | tdd-guide |
| Code has just been written or modified | code-reviewer |
| Code touches auth, user input, secrets, or APIs | security-reviewer |
| Build or compilation fails | build-error-resolver |
| Code maintenance or dead code cleanup | refactor-cleaner |
| Skill | Description |
|---|---|
| godot-patterns | File formats (.gd, .tscn, .tres), component architecture, signals, CLI, common pitfalls |
| godot-csharp-patterns | Godot 4 C# node lifecycle, signals, scenes, input, [GlobalClass], RefCounted, interop |
| godot-gdscript-patterns | GDScript static typing, annotations, signals, coroutines, style conventions |
| godot-testing | GUT/gdUnit4 for GDScript, NUnit for C#, headless execution, CI/CD, benchmarking |
| Skill | Description |
|---|---|
| csharp-coding-standards | Naming, immutability, nullable refs, modern C# features |
| csharp-patterns | ASP.NET Core architecture, DI, middleware, caching |
| csharp-testing | xUnit, Moq, NSubstitute, FluentAssertions, Testcontainers |
| aspnetcore-security | JWT auth, authorization, validation, CORS, rate limiting |
| efcore-patterns | Entity design, queries, N+1 prevention, migrations, auditing |
| Skill | Description |
|---|---|
| java-coding-standards | Naming, immutability, Optional, streams, exceptions |
| springboot-patterns | Architecture, REST API, layered services, caching |
| springboot-security | Auth, validation, CSRF, secrets, headers |
| springboot-tdd | JUnit 5, Mockito, MockMvc, Testcontainers, JaCoCo |
| springboot-verification | Build, static analysis, tests, security scans |
| jpa-patterns | Entity design, relationships, queries, transactions |
| Skill | Description |
|---|---|
| terraform-style-guide | HCL style conventions and best practices |
| terraform-patterns | Azure Verified Modules, resource patterns |
| Skill | Description |
|---|---|
| golang-patterns | Idioms, concurrency, error handling, packages |
| golang-testing | Table-driven tests, benchmarks, fuzzing, coverage |
| Skill | Description |
|---|---|
| python-patterns | PEP 8, type hints, idioms, best practices |
| python-testing | pytest, TDD, fixtures, mocking, parametrization |
| Skill | Description |
|---|---|
| api-design | REST resource naming, status codes, pagination, errors |
| security-review | Security checklist and patterns |
| tdd-workflow | TDD enforcement with 80%+ coverage |
| verification-loop | Comprehensive verification for Claude Code sessions |
| postgres-patterns | Query optimization, schema design, indexing |
| agent-harness-construction | AI agent action spaces, tool definitions |
| frontend-patterns | React, TypeScript, state management |
Rules are Markdown files that Claude Code loads automatically to guide its behavior. They define coding standards, security requirements, workflows, and conventions that Claude Code follows when working in your project.
After installation, rules live in ~/.claude/rules/. Claude Code loads them based on two mechanisms:
-
Common rules (
rules/common/) — always loaded for every session, regardless of what files you are editing. These define universal standards like git workflow, security checks, and testing requirements. -
Language-specific rules (
rules/<lang>/) — loaded conditionally based on thepaths:globs in their YAML frontmatter. For example, Java rules specify:--- paths: - "**/*.java" - "**/pom.xml" ---
These rules activate only when Claude Code is working with files matching those patterns. This keeps context focused — Terraform rules do not load when you are editing Java files, and vice versa.
You do not invoke rules manually. They are loaded automatically and shape how Claude Code writes code, reviews changes, handles errors, and interacts with your project. Think of them as persistent configuration, not commands.
Customizing rules: To override or extend rules for a specific project, add project-level rules in your project's .claude/rules/ directory or adjust behavior in your project's CLAUDE.md. Project-level settings take precedence.
Applied to all projects regardless of language:
| Rule | Purpose |
|---|---|
| coding-style | Immutability, file organization (200-400 lines typical, 800 max), error handling |
| git-workflow | Conventional commits (feat:, fix:, refactor:, etc.), PR workflow |
| development-workflow | Research/reuse first, plan, TDD, code review, commit pipeline |
| security | Mandatory pre-commit security checks, secret management |
| testing | TDD workflow, 80% minimum coverage, unit/integration/E2E tests |
| performance | Model selection strategy (Haiku/Sonnet/Opus), context window management |
| hooks | PreToolUse/PostToolUse hook patterns, TodoWrite best practices |
| agents | Agent orchestration, parallel execution, multi-perspective analysis |
Each language directory contains 5 rule files that extend the common rules with language-specific guidance:
| Rule | Purpose |
|---|---|
| coding-style | Language-specific formatting, naming conventions, idioms |
| patterns | Architecture and design patterns (e.g., Spring Boot layers, Go interfaces) |
| security | Language-specific security concerns (e.g., Spring Security, Go crypto) |
| testing | Frameworks, tools, coverage configuration (e.g., JUnit 5, go test) |
| hooks | Post-edit automation — formatters, compilers, linters |
Available language rule sets: csharp, godot, golang, java, terraform.
- Language rules — add a new directory under
rules/<language>/with.mdfiles. The installer picks it up automatically. - Skills — add
skills/<skill-name>/SKILL.md. - Agents — add
agents/<name>.md.
- Git: Conventional commits (
feat:,fix:,refactor:, etc.). No PRs created at this level. - Workflow: Research/reuse first, plan (planner agent), TDD (tdd-guide agent), code review (code-reviewer agent), commit.
- Code style: Immutability preferred. 200-400 lines typical, 800 max. Many small files over few large ones.
- Testing: TDD mandatory, 80% minimum coverage.
- Agents: Invoked proactively — planner for complex features, tdd-guide for new code, code-reviewer after writing. Parallel execution for independent tasks.