Claude Code Plugin

Installation

If you haven't installed Claude Code yet, see the complete setup guide. Once Claude Code is running, install the Nette plugin:

/plugin marketplace add nette/claude-code
/plugin install nette@nette

For automatic validation of your PHP, Latte, NEON, JSON and JavaScript files after each edit, add the companion linter plugin:

/plugin install nette-lint@nette

The full family of plugins:

How Skills Work

You don't need to activate skills manually. They turn on automatically based on what you're talking about.

• Ask about “presenter structure” → the nette-architecture skill activates
• Ask about “form validation” → the nette-forms skill activates
• Ask about “Latte filters” → the latte-templates skill activates
• Ask about a “BlueScreen error” → the tracy-debugging skill activates

This means you get relevant, context-aware help without having to think about which skill you need.

Available Skills

Here's what each skill covers:

nette-architecture

When you're designing your application structure, this skill guides you through:

• Directory organization – Where to put presenters, services, entities, and components
• Module design – How to split your application into logical modules (Admin, Front, Api)
• Presenter patterns – When to use base presenters, how to handle authentication
• Evolution strategy – Start minimal, grow organically, refactor when needed

The key principle: Don't over-engineer. Create subdirectories when you have 5+ related files, not before.

nette-routing

URL masks and the router:

• Masks – Optional parts, regular-expression constraints, defaults
• Order – Why the first matching route also decides which URL gets generated
• Filters – Slug to id mapping, one-way routes for retired addresses
• Canonical URLs – When the redirect fires and how to switch it off

Example: Claude knows that a catch-all route placed first will quietly hijack every generated link.

nette-configuration

Everything about the DI container and NEON configuration:

• Service registration – How to define services in services.neon
• Autowiring – When it works automatically and when you need explicit configuration
• Parameters – How to use configuration parameters across your application
• Extensions – Working with DI extensions from Nette and third parties

nette-database

Covers both the raw SQL approach and the Database Explorer:

• Database Explorer – Using Selection for queries, ActiveRow for entities
• Entity conventions – The Row suffix pattern, type hints with @property-read
• Relationships – Navigating foreign keys with colon notation
• When to use what – Explorer for CRUD, raw SQL for complex analytics

Example: Claude knows that ->where('category.slug', $slug) automatically joins the category table.

nette-forms

Creating and handling forms the Nette way:

• Controls – All built-in controls from text inputs to file uploads
• Validation – Built-in rules, custom validators, conditional validation
• Rendering – Manual rendering, Bootstrap integration, custom renderers
• Patterns – Create/edit forms, form components, AJAX submissions

nette-components

Components, signals and AJAX:

• Factories – createComponent<Name>(), lazy creation, the component tree
• Signals – handle<Signal>(), where they run, links inside a component
• Snippets – redrawControl(), snippet areas, dynamic snippets
• Persistent parameters – The #[Persistent] attribute and persistent components

Example: Claude knows that inside a component template n:href always means a signal, and that reaching a presenter needs {plink}.

nette-security

Authentication and authorization:

• Login – The Authenticator interface, identities, error codes
• Passwords – Hashing as a service, rehashing on login
• Permissions – Roles, resources, and the Permission ACL
• Configuration – The security: section

Example: Claude knows that logout() keeps the identity unless you ask it not to, so “has an identity” is not the same as “is logged in”.

nette-http

The request, the response and sessions:

• Request – UrlScript, cookies, uploads, and the reverse-proxy trap
• Sessions – Sections with set() / get(), per-key expiration
• Same-origin protection – How CSRF defense works and how to allow a legitimate exception
• SSRF – Validating a URL that came from a user

Example: Claude knows that a link from an e-mail counts as direct navigation, so a signal reached that way needs to be marked explicitly.

nette-caching

Caching with nette/caching:

• Dependencies – Expiration, tags, files, and sliding expiration
• Invalidation – Cleaning by tag, and which storages need a journal for it
• Storages – File, Memcached, SQLite, memory, and the null one for tests

Example: Claude knows that tags silently need a journal, and that the constant is Cache::Expire.

nette-mail

Sending e-mail:

• Message – Recipients, HTML body with automatic image embedding, attachments
• Mailers – SMTP with OAuth 2.0, fallback, and writing to files in development
• DKIM – Signing outgoing mail

Example: Claude knows that setHtmlBody() embeds images referenced in the HTML by itself, so no manual cid: juggling is needed.

nette-schema

Data validation and normalization with the Schema component:

• Expect class – Building validation schemas for arrays and objects
• Configuration schemas – Validating NEON configuration in DI extensions
• Type coercion – Automatic conversion of strings to integers, dates, etc.
• Custom validators – Adding your own validation rules

Example: Claude knows how to create schemas like:

$schema = Expect::structure([
	'name' => Expect::string()->required(),
	'age' => Expect::int()->min(0)->max(120),
	'email' => Expect::string(),
	'roles' => Expect::listOf('string')->default([]),
]);

nette-tester

Writing tests with Nette Tester:

• Test structure – The .phpt format, @testCase annotation, file organization
• Assertions – All Assert::* methods: same(), equal(), exception(), match(), and more
• Fixtures – Setting up test data, mocking dependencies, database transactions
• Running tests – Command-line options, parallel execution, code coverage

Example: Claude can generate proper test files:

/** @testCase */
class UserServiceTest extends TestCase
{
	public function testCreateUser(): void
	{
		$service = new UserService($this->mockDatabase());
		$user = $service->create(['name' => 'John']);
		Assert::same('John', $user->name);
	}
}

tracy-debugging

Working with the Tracy debugger:

• BlueScreen – Reading exception details, stack traces, source highlights
• Tracy Bar – Interpreting embedded SQL query logs, timing, and memory usage at the bottom of every page
• dump() workflow – Inserting dump($variable) calls and reading the output back through curl or the browser
• Production logs – Investigating log/exception-*.html snapshots and log/error.log
• Chrome MCP integration – Pulling Tracy errors out of the browser console with list_console_messages() instead of taking screenshots

Especially useful for 500 errors, blank pages, N+1 query issues, or whenever Claude fetches a local PHP URL and needs to interpret what came back.

nette-utils

The utility classes that make PHP development easier:

• Arrays – Nette\Utils\Arrays with get(), getRef(), map(), flatten(), and more
• Strings – Unicode-safe operations: webalize(), truncate(), contains(), startsWith()
• Finder – File system traversal with filtering by name, size, date
• Image – Resize, crop, sharpen with automatic format detection
• Json – Safe JSON encoding/decoding with proper error handling
• Validators – Email, URL, numeric validation helpers
• DateTime – Immutable date/time with Czech locale support

frontend-development

Integrating frontend tools with Nette:

• Vite – Setting up Vite for modern JavaScript/TypeScript development, HMR configuration
• Nette Assets – Using the asset system for cache-busted URLs in production
• Tailwind CSS – Configuration for Tailwind with Latte templates, purging unused styles
• ESLint – Code quality integration via @nette/eslint-plugin
• Build scripts – npm/package.json scripts for development and production builds

Claude can help configure vite.config.js to work with Nette's directory structure and generate proper asset references in Latte templates.

latte-templates

Everything about the Latte templating engine:

• Syntax – Tags, filters, blocks, and inheritance
• Security – Auto-escaping, content-aware output
• Custom filters – Creating and registering your own filters
• Template classes – Using typed templates for better IDE support

neon-format

The NEON configuration format:

• Syntax – Mappings, sequences, entities, and multiline strings
• Common patterns – Service definitions, parameter references
• Debugging – Finding and fixing syntax errors

nette-upgrading

A lookup table of retired names:

• Renames – I-prefixed interfaces, UPPER_CASE constants, moved classes
• Silent survivals – Where the old name still works, so the mistake never surfaces
• Changed signatures – Arguments that disappeared or became named

Example: Claude knows that Nette\Database\Context still resolves as an alias, so code written from memory keeps running while quietly using a retired name.

Automatic Validation

One of the most useful features is automatic validation, provided by the separately installed nette-lint plugin. After every file edit it checks for errors:

If there's a syntax error in any of these files, Claude knows about it immediately and can suggest a fix. No more discovering errors in the browser.

The plugin looks for the project's tools and configs (latte-lint, vendor/bin/neon-lint, the ESLint config) upwards from the edited file, not just in the folder where Claude Code is running. So even if you keep several applications in one repository and run Claude Code from its root, each file is still checked with the right tool for its application. The search stops one level above the nearest .git folder, so tools from unrelated projects elsewhere on the disk are never picked up.

Sometimes you don't want a file checked – for example fixtures with intentionally broken templates or code used in tests. You can skip specific paths by creating a .nette-claude.json file in your project, where each key is a hook name with a list of paths to ignore:

{
	"lint-php": {
		"exclude": ["fixtures*"]
	},
	"lint-latte": {
		"exclude": ["tests/**/expected"]
	}
}

Patterns work like in .gitignore: a name without a slash (such as fixtures*) matches at any depth, while a pattern with a slash is anchored to the folder containing the config file.

Plugin for Framework Contributors

If you're contributing to Nette itself, there's an additional plugin with coding standards:

/plugin install nette-dev@nette

Automatic PHP Style Fixing

For automatic code style fixing after every PHP file edit, install the optional php-fixer plugin:

/plugin install php-fixer@nette
/install-php-fixer

The second command installs nette/coding-standard globally. After that, every PHP file you edit will be automatically formatted according to Nette coding standards.

Because the fixer rewrites your files, it's important to keep it away from code you don't want reformatted – typically fixtures with intentionally crafted formatting. Exclude such paths with a fix-php-style entry in .nette-claude.json:

{
	"fix-php-style": {
		"exclude": ["fixtures*"]
	}
}

The patterns follow the same gitignore-like rules as the validation hooks above.

By default the fixer runs a single preset, the one matching your project's PHP version. A presets list defines exactly which presets run and in what order, where the name php stands for that version-derived preset. This is how you add optimize-fn, which maintains grouped use function and use const imports for compiler-optimized functions:

{
	"fix-php-style": {
		"presets": ["php", "optimize-fn"]
	}
}

Each entry is a separate pass over the edited file, so drop php from the list only if you really want the standard preset gone.

The plugin also comes with the php-auto-fixer skill, which teaches Claude about one subtle pitfall: the fixer removes unused use statements, so a use added in a separate edit before the code that references it gets stripped. Claude knows to add imports together with the code that uses them.

MCP Inspector Integration

The plugin works even better with MCP Inspector – a tool that lets Claude see your actual application state. With MCP Inspector, Claude can:

• Query your real database schema instead of guessing
• List your registered DI services and their configuration
• Read Tracy error logs for debugging
• Match URLs to presenters using your actual routes

Install it with a single command:

/install-mcp-inspector

Then restart Claude Code. See the MCP Inspector documentation for all 21 available tools.