Nette Plugins for Claude Code and Codex

Installation

The plugins come as a family, so you install only what you need:

Claude Code

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

/plugin marketplace add nette/agent-plugins
/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

Codex

In Codex, add the same marketplace from the command line and install the main plugin:

codex plugin marketplace add nette/agent-plugins
codex plugin add nette@nette

The other plugins are installed the same way, for example codex plugin add nette-lint@nette. Then start a new session so Codex picks them up.

There is one extra step for the plugins that check or fix your files. Codex doesn't run a plugin's hooks just because you installed it; you have to approve them first. Open /hooks in Codex, review the hook definitions of the installed plugins and trust them. When a plugin update changes its hooks, you have to review them again.

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. The skills are identical in both clients, so whenever the examples below say Claude, the same applies to Codex.

Each skill comes with the complete Nette documentation of its topic, converted to Markdown and bundled with the plugin. The skill itself holds the essentials and the common pitfalls; when Claude needs the details, such as every option of a form control or the signature of a Latte filter, it reads the relevant page from your disk instead of fetching the website.

The plugin lives outside your project, so Claude Code asks for permission the first time it reads one of its files. To skip the prompt, allow reading the plugin directory in your settings:

{
	"permissions": {
		"allow": ["Read(~/.claude/plugins/cache/nette/**)"]
	}
}

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-command-line

Command-line scripts with nette/command-line 2.0:

• Parameters – Flags, options with required or optional values, arguments, defaults and normalizers
• Commands – Subcommands like git remote add, dispatched with match
• Help and errors – Help generated from the definition, messages the user understands
• Console – Colors that respect NO_COLOR, status lines, measuring text
• Upgrading from 1.x – A faithful rewrite of 1.x code, with a report of every place where 2.0 behaves differently

Example: Claude knows that the second argument of addOption() is the description, so the alias has to be passed as alias:.

nette-php-generator

Generating PHP code with nette/php-generator:

• Elements – Classes, interfaces, traits, enums, functions and closures
• Namespaces and files – Automatic shortening of class names by use clauses
• Bodies – Placeholders that export values as valid PHP
• Existing code – Loading classes and files and changing them

Example: Claude knows that in a body with placeholders, ?? and ?-> have to be escaped.

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, the agent knows about it immediately and can suggest a fix. No more discovering errors in the browser.

The checks run after the agent edits a file with its own editing tools. When it changes files through shell commands instead, no hook runs, so it's worth asking it to run your project's checks afterwards.

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 the agent is running. So even if you keep several applications in one repository and start the agent 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           # Claude Code
codex plugin add nette-dev@nette          # Codex

Automatic PHP Style Fixing

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

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

The second command installs DressCode globally together with PHPStan, from which DressCode takes the types of your code, or into the project when the project uses PHPStan itself, and offers to create a dresscode.neon for the project. In Codex, install the plugin with codex plugin add php-fixer@nette and then pick the install-php-fixer skill, which does the same. After that, every PHP file you edit will be automatically formatted: by your project's dresscode.neon (or dresscode.php) when there is one, so the same presets, rules and exceptions apply as in CI, and by the Nette coding standard otherwise. A project that has DressCode among its own dependencies is fixed with that copy, so its configuration may use extensions the global installation does not know.

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. The fixer is configured only by dresscode.neon, not by .nette-claude.json, so list such paths in its excludePaths:

presets:
	- nette

excludePaths:
	- fixtures*

Folders such as vendor, temp, log and hidden ones are left alone even without a configuration, and so is a file of no PHP project, one with neither composer.json nor dresscode.neon above it, such as a scratch script Claude writes into its temporary directory.

Claude learns from the hook what happened: when the file was rewritten, so it reads it again before the next edit, and which violations the fixer could not fix, so it fixes them by hand. The plugin also comes with the php-auto-fixer skill, which teaches Claude the one subtle pitfall of an automatic fixer: it 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.

Beyond the file just edited, the dresscode skill teaches Claude to work with DressCode itself: to check or fix the whole project, to read its report, to change dresscode.neon, to silence a rule or write a baseline, to set it up in CI, and to upgrade the code to a newer PHP version or library API. Claude asks the installed DressCode about its rules and your configuration instead of guessing, and leaves the decisions that are yours to you: a fix over the whole project, risky fixes that may change what the code does, switching a rule off, a baseline, and raising the PHP version in composer.json.

If you used version 1 of the plugin, which formatted with nette/coding-standard, nothing stops working after the upgrade: the fixer keeps using it until DressCode is installed, and Claude offers to migrate. With your consent it installs DressCode the same way, creates dresscode.neon and shows what the new standard would change.

MCP Inspector Integration

The plugins work even better with MCP Inspector – a tool that lets the agent 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 two commands:

composer require --dev nette/mcp-inspector:@dev
vendor/bin/mcp-inspector init

Then restart Claude Code. Codex isn't registered by init, so add the server to its configuration yourself as described in Other AI Tools. See the MCP Inspector documentation for all the available tools.

Privacy

The plugins collect no data. They run locally and have no servers, telemetry or analytics. See the privacy policy for details.