# Hodios paste pack: Conventions Everything in Conventions from Hodios, the open prompt library by Hermes IDE: 27 entries, catalog 2026.1004.3. Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed. Browse and search the library at https://hermes-ide.com/prompts ## How to use Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions. ## Contents - Conventions - [C# style rules](#csharp-style-rules) (rule) - [C++ style rules](#cpp-style-rules) (rule) - [Django rules](#django-rules) (rule) - [Embedded C rules](#embedded-c-rules) (rule) - [Error handling rules](#error-handling-rules) (rule) - [FastAPI rules](#fastapi-rules) (rule) - [Flutter rules](#flutter-rules) (rule) - [GDScript rules](#gdscript-rules) (rule) - [Go style rules](#go-style-rules) (rule) - [HTTP API design rules](#api-design-rules) (rule) - [Infrastructure as code style rules](#iac-style-rules) (rule) - [Java style rules](#java-style-rules) (rule) - [Kotlin style rules](#kotlin-style-rules) (rule) - [Laravel rules](#laravel-rules) (rule) - [Next.js rules](#nextjs-rules) (rule) - [Python style rules](#python-style-rules) (rule) - [React component rules](#react-component-rules) (rule) - [React Native rules](#react-native-rules) (rule) - [Ruby on Rails rules](#rails-rules) (rule) - [Rust style rules](#rust-style-rules) (rule) - [Shell script rules](#shell-script-rules) (rule) - [Spring Boot rules](#spring-boot-rules) (rule) - [SQL style rules](#sql-style-rules) (rule) - [Swift style rules](#swift-style-rules) (rule) - [Tailwind CSS rules](#tailwind-rules) (rule) - [TypeScript strict rules](#typescript-strict-rules) (rule) - [Vue and Nuxt rules](#vue-rules) (rule) --- ## C# style rules `csharp-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/csharp-style-rules Standing rules for C# an assistant writes, covering nullable reference types, async all the way with cancellation tokens, records and pattern matching, dependency injection and xUnit tests. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.cs`. When you write or change C# code in this project: **Tooling and version** - Use the target framework and `LangVersion` the project files declare, and only features they support. Do not change them on your own. - Follow the repository's `.editorconfig` and analyzers, and keep the build free of new warnings. Use file-scoped namespaces and the project's existing conventions for `using` directives. - Add NuGet packages only when the base class library cannot do the job in a few lines, through the project's central package management if it has it. **Nullable reference types** - Code assumes `enable`. Annotate every reference that can be null with `?` and handle it; never silence warnings with the null-forgiving operator unless a comment explains why the value cannot be null. - Validate public arguments with `ArgumentNullException.ThrowIfNull(arg)` and the related `ThrowIf` helpers. - Return empty collections, not `null`. Use the `Try` pattern (`bool TryGet(..., out T value)`) or a nullable return when absence is normal. **Async** - Async all the way: never block on tasks with `.Result`, `.Wait()` or `GetAwaiter().GetResult()`. Return `Task` or `Task`; use `async void` only for event handlers. - Every async method that does I/O takes a `CancellationToken cancellationToken` as its last parameter (optional with `= default` on public APIs, as the framework does) and passes it to every call that accepts one; analyzer CA2016 flags the calls where it is dropped. - Name async methods with the `Async` suffix. Use `ConfigureAwait(false)` in library code; it is not needed in ASP.NET Core application code. - Use `ValueTask` only where a measurement shows allocation matters. Use `IAsyncEnumerable` for streaming results, and `await using` for `IAsyncDisposable`. **Types and language features** - Use records (or `record struct`) for immutable data, `init` accessors and `required` members for object construction, and keep mutable state private. - Prefer switch expressions and pattern matching over `if`/`else` chains on types or values, with a discard arm that throws for unexpected cases. - Use `DateTimeOffset` for timestamps and inject `TimeProvider` (.NET 8 and later; otherwise the project's clock abstraction) where code needs the current time, never `DateTime.Now` in logic. Use `decimal` for money. - Always pass a `StringComparison` to string comparisons and `IndexOf`/`StartsWith` calls; use `StringComparer.OrdinalIgnoreCase` for case-insensitive keys. **Dependency injection and configuration** - Use constructor injection (primary constructors if the project uses them). No service locator calls to `IServiceProvider` inside business code. - Register lifetimes correctly: never inject a scoped service (such as a `DbContext`) into a singleton. Bind configuration to options classes with `IOptions` and validate them at startup. - Create HTTP clients through `IHttpClientFactory` or typed clients, never `new HttpClient()` per call. **Errors and resources** - Throw specific exceptions with useful messages. Rethrow with `throw;` to keep the stack trace, never `throw ex;`. Never catch `Exception` to ignore it; catch broadly only at a boundary that logs and translates. - Dispose `IDisposable` resources with `using` declarations. Do not use exceptions for normal control flow. **Data access and LINQ** - Keep LINQ readable; avoid enumerating the same `IEnumerable` twice (materialise once with `ToList()` when needed). - With Entity Framework Core, use async query methods with the cancellation token, `AsNoTracking()` for read-only queries, and projections or `Include` to avoid N+1 queries. **Logging** - Use `ILogger` with message templates and named placeholders: `logger.LogInformation("Order {OrderId} shipped", orderId)`. Never string interpolation in log calls, and never log secrets or personal data. Use the `LoggerMessage` source generator on hot paths if the project does. **Tests (xUnit)** - Use `[Fact]` for single cases and `[Theory]` with `[InlineData]` or `[MemberData]` for input tables. Name tests `Method_Scenario_ExpectedResult` or follow the project's existing scheme. - Put setup in the constructor and cleanup in `Dispose` or `IAsyncLifetime`; no shared static mutable state between tests. - Use the assertion library the project already uses, and `await Assert.ThrowsAsync(...)` for async failures, checking the exception type and message. - Mock only at boundaries (HTTP, storage, time) with the project's mocking library; use a fake `TimeProvider` for time. Never `Thread.Sleep` or `Task.Delay` to wait for work in tests. ```` --- ## C++ style rules `cpp-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/cpp-style-rules Standing rules for modern C++ an assistant writes, covering RAII, no raw new or delete, const by default, value semantics, span and string_view at boundaries, and sanitizer-clean code. ````markdown Follow these rules for the rest of this conversation. When you write or change C++ code in this project: **Standard and tooling** - Use the language standard set in the build (CMake `CMAKE_CXX_STANDARD` or the compiler flags); do not use features from a newer standard. - Code must compile without warnings under the project's flags (at least `-Wall -Wextra -Wpedantic` or `/W4`, treated as errors) and pass clang-tidy and the formatter configured in the repo. - Tests must pass under AddressSanitizer and UndefinedBehaviorSanitizer, and ThreadSanitizer for concurrent code, where the project has those builds. **Ownership and resources** - Every resource is owned by an object whose destructor releases it (RAII): memory, files, sockets, locks, handles. - No raw `new` or `delete` in application code. Use values first, then `std::make_unique`, then `std::make_shared` only when ownership is truly shared. - Raw pointers and references never own. Use `T&` for a required non-owning argument, `T*` for an optional one, and smart pointers in signatures only when the function takes or shares ownership. - Follow the rule of zero: let members manage resources so the class needs no custom copy, move or destructor. If you must write one, write or delete all five. - Lock mutexes with `std::scoped_lock` or `std::unique_lock`, never manual `lock()`/`unlock()`. **Interfaces and values** - Mark everything `const` that does not change: locals, member functions, references and pointers to data that is only read. Use `constexpr` for compile-time constants. - Pass cheap types by value, read-only larger types by `const&`, and sinks by value then `std::move`. Accept `std::string_view` and `std::span` for read-only views at function boundaries, and never store a view beyond the lifetime of what it points to. - Return values rather than out-parameters; use `std::optional` for "maybe a value" and the project's error type (`std::expected`, a result type or exceptions) consistently. - Make single-argument constructors `explicit`, and mark overrides with `override` and leaf classes `final` where it helps. - Use `enum class`, strong types for units and ids, and `[[nodiscard]]` on functions whose result must not be ignored. **Undefined behaviour** - Never read uninitialised memory: initialise every variable at declaration and every member with a default member initialiser. - Check bounds before indexing, or use `.at()` where the cost is acceptable; do not do pointer arithmetic outside an array. - Do not hold references, pointers or iterators into a container across operations that may reallocate or erase. - No signed integer overflow, no shifts by the width or more, no type punning through pointer casts (use `std::bit_cast` or `std::memcpy`), and no C-style casts; use `static_cast` and justify any `reinterpret_cast` or `const_cast` in a comment. - Do not return references to locals or capture locals by reference in a lambda that outlives them. **Errors and exceptions** - Follow the project's policy on exceptions. Where exceptions are used, throw by value and catch by `const&`, and keep destructors and move operations `noexcept`. Where they are disabled (games, embedded), return error values and check every one. **Style** - Prefer standard algorithms and range-based `for` over hand-written index loops when they read clearly. - Keep headers minimal: include what you use, forward-declare where it avoids heavy includes, no `using namespace` in headers. - Prefer `auto` when the type is obvious or verbose, and spell it out when it carries meaning. - Follow the C++ Core Guidelines where the project has no rule of its own. ```` --- ## Django rules `django-rules` · rule · Conventions · https://hermes-ide.com/prompts/django-rules Standing rules for Django code covering app layout, where business logic lives, querysets without N+1, safe migrations, forms and validation, settings per environment and security defaults. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.py`, `**/templates/**/*.html`. When you write or change code in this Django project: **Layout and where logic lives** - Follow the project's existing app structure. Put a new feature in the app that owns its models; create a new app only for a genuinely separate domain concept. - Keep views thin: parse the request, call the domain code, return a response. Put rules that belong to one model on the model or its custom manager or queryset. Put workflows that touch several models, external services or side effects in a plain function in a `services.py` (or the project's equivalent), and call it from views, commands and tasks alike. - Reference the user model through `settings.AUTH_USER_MODEL` in models and `get_user_model()` in code, never `django.contrib.auth.models.User` directly. **Queries** - Every list view or loop over a queryset that touches a related object uses `select_related` (foreign key, one-to-one) or `prefetch_related` (many-to-many, reverse foreign key). If you add a template or serializer field that follows a relation, update the queryset in the same change. - Never query inside a loop. Use `bulk_create`, `bulk_update`, `in_bulk`, `Subquery`, `annotate` or `aggregate` instead. - Use `F()` expressions or `select_for_update()` inside `transaction.atomic()` for counters and read-modify-write updates, so concurrent requests cannot lose writes. - Use `.exists()` rather than `len()` or truthiness to test for rows, `.count()` rather than `len(qs)` when you do not need the objects, and `.only()` or `.values()` for wide tables when you need a few fields. - Raw SQL is a last resort and always uses query parameters, never string formatting. **Migrations** - Generate migrations with `makemigrations`, read them, and commit them with the model change. Never edit a migration that has already been applied on a shared environment; add a new one. - Every data migration with `RunPython` has a reverse function (or `RunPython.noop` with a reason) and uses `apps.get_model`, never a direct model import. - On large or busy tables, make changes in deploy-safe steps: add a nullable column, backfill in batches, then add the constraint. Remove a field in two releases (stop using it, then drop it). Use the project's concurrent-index approach on PostgreSQL rather than locking the table. **Forms, serializers and validation** - Validate all input through forms, model forms or the API framework's serializers. Put cross-field rules in `clean()` or `validate()`, and model invariants in model constraints (`CheckConstraint`, `UniqueConstraint`), not only in Python. - Never trust hidden fields or client-side checks for permissions or prices. **Side effects and transactions** - Wrap multi-step writes in `transaction.atomic()`. Send email, enqueue tasks and call webhooks with `transaction.on_commit` so they never fire for a rolled-back write. - Pass primary keys to background tasks, not model instances, and re-fetch inside the task. **Settings** - Read secrets and per-environment values from environment variables (or the project's settings tool), never hard-code them. `SECRET_KEY`, database credentials and API keys never appear in the repository. - Production runs with `DEBUG = False`, an explicit `ALLOWED_HOSTS`, `SECURE_*` and `*_COOKIE_SECURE` settings enabled, and the security, CSRF, session and clickjacking middleware in place. Do not disable `CsrfViewMiddleware` or add `csrf_exempt` to a view used by browsers. **Templates and output** - Rely on auto-escaping. Never call `mark_safe`, `|safe` or `format_html` with untrusted content unescaped. - Use `{% url %}` and `reverse()` with named routes instead of hard-coded paths. **Tests and checks** - Add or update tests with the project's runner (Django's `TestCase` or pytest-django) for every behaviour change, including a test that asserts the query count (`assertNumQueries` or `django_assert_num_queries`) for list endpoints you touched. - Before finishing, run the tests, `python manage.py check`, and `makemigrations --check` to prove no migration is missing. ```` --- ## Embedded C rules `embedded-c-rules` · rule · Conventions · https://hermes-ide.com/prompts/embedded-c-rules Standing rules for embedded C an assistant writes, covering fixed-width types, no heap after init, volatile registers, short interrupt handlers, checked errors and MISRA-style restraint. ````markdown Follow these rules for the rest of this conversation. When you write or change C code for firmware in this project: **Types and arithmetic** - Use `` fixed-width types (`uint8_t`, `int32_t`) for data, registers and protocol fields; use `size_t` for sizes and `bool` from ``. Never assume the width of `int`. - Make every narrowing or sign-changing conversion an explicit cast, and only after checking the range. - Use unsigned types for bit manipulation and shifts; never shift by the type's width or more, and never left-shift a negative value. - Write constants with the right suffix (`1UL << 31`, `0xFFu`) so the expression does not overflow `int`. - Compare tick counters with unsigned subtraction (`(uint32_t)(now - start) >= timeout`) so wrap-around is handled. - No floating point in interrupt handlers, and none at all on cores without an FPU unless the project already accepts the cost. **Memory** - No `malloc`/`free` after initialisation. Use static allocation, fixed-size pools or the RTOS's static creation APIs. - No recursion and no variable-length arrays. Keep large buffers off the stack and note any function with a stack frame over a few hundred bytes. - Bounds-check every index and length that comes from outside the function (a peripheral, a packet, a register, a caller); use `sizeof` on the array, never a repeated literal. - Use `memcpy` for type punning and packed protocol data; do not cast byte pointers to wider types (unaligned access faults on many cores). **Hardware access** - Access memory-mapped registers through `volatile` pointers or the vendor's register definitions; never cache a register value across a wait. - Do read-modify-write on shared registers inside a critical section, or use the hardware's set/clear/toggle registers. - Do not use `volatile` as a synchronisation primitive. Data shared between an interrupt and other code uses atomics, a critical section, or a single-producer single-consumer structure with proper barriers. - Every wait on hardware has a timeout and returns an error when it expires. **Interrupts and concurrency** - Keep interrupt handlers short: acknowledge, capture, hand off (flag, queue or task notification), return. No blocking calls, `printf`, heap use or long loops in them. - Use the RTOS's ISR-safe API variants (for example the `FromISR` functions) inside handlers. - Keep critical sections as short as possible and never call blocking functions inside them. **Errors** - Check the return value of every function that can fail, including HAL and RTOS calls; do not discard it silently. Cast to `(void)` only with a comment saying why the result does not matter. - Return error codes from a project-wide enum; do not mix negative errno values, booleans and custom codes in one module. - Use `assert` or a project fault macro for programming errors, and handle runtime conditions (bus errors, timeouts, bad input) with error returns. **Style and structure** - Follow the project's existing standard (MISRA C, CERT C or an in-house guide). Where none exists, apply MISRA-style restraint: single exit points are optional, but no `goto` except forward to a cleanup label, no implicit fallthrough without a comment, every `switch` has a `default`, every `if`/`else if` chain ends with `else`. - Give file-local functions and data `static` linkage; keep globals few, named with a module prefix. - Mark hardware-specific code and magic addresses with a reference to the datasheet or reference manual section. - Build with warnings as errors (`-Wall -Wextra -Werror` or the project's equivalent) and keep static analysis clean; do not add warning suppressions without a comment. - Do not change clock trees, option bytes, fuses, linker scripts or bootloader settings unless asked, and say plainly when a change needs a hardware test. ```` --- ## Error handling rules `error-handling-rules` · rule · Conventions · https://hermes-ide.com/prompts/error-handling-rules Standing rules for error handling in code an assistant writes, covering no swallowed errors, added context, failing fast on bugs, retryable versus fatal, safe user messages and logging once. ````markdown Follow these rules for the rest of this conversation. When you write or change code that can fail: **Never lose an error** - Do not swallow errors: no empty catch blocks, no `catch` that only logs and continues as if nothing happened, no ignored return values or rejected promises, no `_ = err` without a comment explaining why it is safe. - Catch only what you can handle at that point. Let everything else propagate. - Every async call is awaited or has its failure handled; no fire-and-forget without an explicit error handler. **Add context, keep the cause** - When rethrowing or wrapping, add what was being attempted and the key identifiers (`"loading invoice 4821 for account 77"`), and keep the original error as the cause (`raise ... from err`, `fmt.Errorf("...: %w", err)`, `new Error(msg, { cause })`). - Use the project's existing error types and patterns before inventing new ones. Create a new type only when callers need to tell it apart. **Programmer errors versus operational errors** - Fail fast on programmer errors and broken invariants (null where it cannot be, impossible state, invalid arguments from internal callers): assert or throw immediately, do not try to limp on. - Handle operational errors (network failures, timeouts, missing files, invalid user input, conflicts) explicitly at the layer that can decide what to do. - Validate external input at the boundary and return a clear validation error; do not let it fail deep inside. **Retryable versus fatal** - Classify failures: retry only transient ones (timeouts, connection resets, rate limits, 5xx from idempotent calls), never validation errors, authorisation failures or other 4xx. - Retries use a bounded number of attempts, exponential backoff with jitter, and respect `Retry-After`. Only retry operations that are idempotent or protected by an idempotency key. - Set timeouts on every network and I/O call; no unbounded waits. **What users and callers see** - User-facing messages say what happened and what to do next, in plain words, without stack traces, SQL, file paths, internal hostnames or secrets. - APIs return a consistent error shape with a stable machine-readable code, using the project's format (for example problem details) and the correct status code. - Include a correlation or request ID in the response and the logs so support can find the details. **Logging** - Log an error once, at the boundary where it is handled (request handler, job runner, top-level loop), not at every layer it passes through. - Log with structured fields, the cause chain and the correlation ID, at the right level (expected operational failures as warning, unexpected failures as error). - Never log passwords, tokens, full request bodies or personal data. **Cleanup** - Release resources on every path with the language's construct (`finally`, `with`, `defer`, `using`, RAII) and leave partial work consistent: roll back transactions, delete temp files, do not leave half-written records. **Tests** - Add a test for each new failure path you handle, asserting the error type or code and the message the caller sees. ```` --- ## FastAPI rules `fastapi-rules` · rule · Conventions · https://hermes-ide.com/prompts/fastapi-rules Standing rules for FastAPI services covering typed request and response models, dependency injection, async correctness, error responses, settings, background work and tests. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.py`. When you write or change code in this FastAPI service: **Know the project first** - Check the installed FastAPI and Pydantic major versions before using their APIs, and follow the patterns already in the codebase (router layout, dependency style, ORM and session handling). Do not mix Pydantic v1 and v2 idioms. **Typed models at the edges** - Every endpoint declares a request model for its body and a response model (`response_model` or the return annotation). Never return ORM objects or raw dicts whose shape the schema does not describe. - Keep separate models for create, update and read when their fields differ, so clients cannot set server-owned fields such as `id`, `created_at` or `role`. Use `extra="forbid"` on input models where unknown fields should be rejected. - Put constraints in the model (`Field` limits, enums, validators) rather than ad hoc checks in the handler, so they appear in the OpenAPI schema. - Set an explicit `status_code` for non-200 success responses (201 for creation, 204 for no content), and give each route a `summary` or docstring and its tags. **Dependencies** - Use dependencies (preferably `Annotated[T, Depends(...)]`) for the database session, the current user, permissions, pagination and settings. Do not create database engines, HTTP clients or settings objects inside handlers. - Session and client dependencies use `yield` and close or roll back in `finally`. Create long-lived resources (engine, connection pools, HTTP clients) once in the app's lifespan handler, not per request and not with deprecated startup events. - Enforce authorisation in a dependency or in the service layer, not by trusting an id in the path. **Async correctness** - Use `async def` only when the handler awaits async libraries. A blocking call (a sync database driver, `requests`, file I/O, CPU-heavy work) inside `async def` stalls every request on the worker; write that handler as plain `def`, or move the call to a thread with the framework's threadpool helper. - Never call `asyncio.run` or create a new event loop inside the app. Do not share one async session across concurrent tasks. **Errors** - Raise `HTTPException` (or the project's domain exceptions mapped by registered exception handlers) with a consistent error body. Map domain errors to the right status: 404 not found, 409 conflict, 422 validation, 403 forbidden. - Never leak stack traces, SQL or internal messages in responses. Log them with a request id instead. **Settings and secrets** - Load configuration through one typed settings class (pydantic-settings or the project's equivalent) read from the environment, injected as a dependency so tests can override it. No secrets in code or default values. **Background work** - Use `BackgroundTasks` only for short, best-effort work after the response (sending one email, writing an audit row). Anything that must survive a restart, retry or take more than a few seconds goes to the project's task queue. **Tests** - Test through HTTP with the test client (or an async client for async apps), using `app.dependency_overrides` to swap the database, current user and external services. Clear overrides after each test. - Cover the happy path, validation failure (422), the not-found and forbidden paths for every endpoint you add or change. - Before finishing, run the tests and the type checker the project uses, and confirm the app still starts and serves `/openapi.json`. ```` --- ## Flutter rules `flutter-rules` · rule · Conventions · https://hermes-ide.com/prompts/flutter-rules Standing rules for Flutter code covering widget composition, const constructors, a single state management approach, async and BuildContext safety, theming, accessibility and widget tests. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `lib/**/*.dart`, `test/**/*.dart`, `integration_test/**/*.dart`. When you write or change code in this Flutter app: **Know the project first** - Check `pubspec.yaml` for the Flutter and Dart SDK constraints and the packages already in use (state management, routing, HTTP, code generation), and follow the patterns in existing features. Do not add a package for something the project already does another way. **Widget composition** - Split large `build` methods into small widget classes, not helper methods that return widgets. Separate classes rebuild independently and can be `const`. - Mark widget constructors and widget instances `const` whenever their inputs are compile-time constants, and keep the `prefer_const_constructors` lints passing. - Keep `build` pure and cheap: no network calls, no object creation that should persist, no side effects. Create controllers, streams and futures in `initState` (or the state management layer), never in `build`. - Give widgets in reorderable or dynamic lists stable `Key`s derived from the data. **State management** - Use the one state management approach the project already uses (for example Provider, Riverpod, Bloc or plain `ValueNotifier`). Do not introduce a second one. If the project has none and the feature needs shared state, ask before choosing. - Keep business logic and I/O out of widgets: widgets read state and dispatch intents; repositories and services talk to the network and storage. - Use `setState` only for state local to one widget, and call it only while the widget is mounted. **Async and BuildContext safety** - After any `await` in a widget or state method, check `if (!context.mounted) return;` (or `mounted` in a `State`) before using `context`, calling `setState` or navigating. - Dispose every `TextEditingController`, `AnimationController`, `ScrollController`, `FocusNode`, stream subscription and timer you create, in `dispose()`. - Show loading, error and empty states for every asynchronous view; never leave a spinner with no timeout or error path. **Lists and performance** - Use `ListView.builder`, `GridView.builder` or slivers for long or unbounded lists, never a `Column` inside a `SingleChildScrollView` with hundreds of children. - Size images to their display size and cache network images with the project's approach. Profile in profile mode, not debug, before claiming a performance fix. **Theming and layout** - Take colours, text styles and shapes from `Theme.of(context)` (`colorScheme`, `textTheme`) or the project's design tokens. Do not hard-code colours or font sizes in widgets, and support dark mode if the app does. - Build layouts that adapt to screen size and text scale with `LayoutBuilder`, `MediaQuery` or flexible widgets, not fixed pixel widths. Test with large text scaling. - Respect safe areas and the keyboard (`SafeArea`, scrollable forms). **Accessibility** - Give icon-only buttons a `tooltip` or semantic label, and images a `semanticLabel` (or exclude decorative ones from semantics). - Keep tap targets at least 48 by 48 logical pixels and colour contrast at WCAG AA. Do not convey meaning by colour alone. - Make custom controls expose their role and state through `Semantics`. **Strings** - Put user-facing text in the project's localisation files if it has them, never inline in widgets. **Tests** - Add widget tests with `testWidgets` and `pumpWidget` for new screens and components, finding widgets by key, text or semantics label, and covering loading, error and data states. Unit test the logic layer without widgets. - Before finishing, run `flutter analyze` and `flutter test`, and fix every analyzer warning you introduced. ```` --- ## GDScript rules `gdscript-rules` · rule · Conventions · https://hermes-ide.com/prompts/gdscript-rules Standing rules for Godot 4 GDScript an assistant writes, covering static typing, signals over hard references, scene composition, physics in the physics step and exported tuning values. ````markdown Follow these rules for the rest of this conversation. When you write or change GDScript in this Godot project: **Version and typing** - Write Godot 4 syntax (`@export`, `@onready`, `super()`, `Callable`, typed signals) unless the project is on Godot 3; check `project.godot` before assuming. - Type everything: variables, parameters, return values (`-> void` included), arrays (`Array[Enemy]`) and dictionaries where the project's version supports typed dictionaries. Use `:=` only when the type is obvious from the right-hand side. - Give reusable scripts a `class_name` and use it in type hints instead of `Node`. - Keep the project's typing warnings (untyped declaration, unsafe property access, unsafe call) enabled; do not silence them with `@warning_ignore` without a comment. **Scenes and nodes** - Compose behaviour from child nodes and small scenes rather than deep inheritance chains. - Get child nodes with `@onready var x: Type = $Path` or `%UniqueName`; never use long `get_node("../../..")` paths that reach up or across the tree. - Communicate upward and sideways with signals; call methods downward on children you own. A node must not assume who its parent is. - Connect signals in code with `signal_name.connect(_on_...)` or in the editor, consistently with the project, and name handlers `_on__`. - Use autoloads only for truly global services (save system, audio bus, settings), not as a shortcut for passing references. - Free nodes with `queue_free()`, and check `is_instance_valid()` before using a reference that might have been freed. **Frame loop and physics** - Move physics bodies and run gameplay that affects collisions in `_physics_process(delta)`; use `_process(delta)` for visuals and UI only. - Multiply movement and timers by `delta`; never assume a frame rate. - Use `CharacterBody2D/3D` with `move_and_slide()` for characters and set `velocity`; do not set the position of a `RigidBody` directly, use forces, impulses or `_integrate_forces`. - Read input actions from the Input Map (`Input.is_action_pressed("jump")`), not raw key codes, and handle one-shot input in `_unhandled_input` where UI should be able to consume it. **Performance** - Do not allocate in per-frame code: no new arrays, dictionaries, strings or nodes inside `_process` or `_physics_process` when they can be reused or pooled. - Cache node references and resources instead of calling `get_node`, `find_child` or `load` every frame; use `preload` for resources known at compile time. - Prefer groups, signals and areas over scanning the whole tree each frame. - Use timers or `await get_tree().create_timer(t).timeout` for delays instead of counting frames, and make sure the awaiting node can be freed safely. **Designer-facing values** - Expose tunable gameplay values with `@export` and a range hint (`@export_range(0, 1000, 10, "suffix:px/s")`), grouped with `@export_group`, instead of hard-coded numbers. - Put shared data (enemy stats, item definitions) in custom `Resource` classes rather than in scripts. **Style** - Follow the official GDScript style guide: `snake_case` for functions and variables, `PascalCase` for classes and nodes, `CONSTANT_CASE` for constants, private members prefixed with `_`, and the standard member order (signals, enums, constants, exports, vars, onready vars, built-in callbacks, public then private methods). - Keep scripts small and single-purpose; split one that handles several unrelated concerns. ```` --- ## Go style rules `go-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/go-style-rules Standing rules for Go an assistant writes, covering wrapped errors, context propagation, small consumer-side interfaces, table-driven tests and no goroutines without an owner. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.go`. When you write or change Go code in this project: **Tooling** - Code must be `gofmt`-formatted with imports grouped by `goimports`, and pass `go vet`. Follow the project's linter configuration (such as golangci-lint) if one exists. - Use the Go version in `go.mod`. Keep `go.mod` tidy, and do not add a dependency for something the standard library does in a few lines. **Errors** - Return errors as the last result and handle every one. Never discard an error with `_` unless a comment says why it is safe. - Add context once per layer with `fmt.Errorf("load config %q: %w", path, err)`. Use `%w` so callers can inspect the cause with `errors.Is` and `errors.As`; never compare error strings. - Either handle an error or return it. Do not log it and return it too. - Do not panic for expected failures. Reserve `panic` for programmer errors and impossible states, and do not let it cross a package's public API. - Error strings start lowercase and have no trailing punctuation. **Context** - Any function that does I/O, blocks or may be cancelled takes `ctx context.Context` as its first parameter and passes it on. - Never store a context in a struct, never pass `nil`, and create `context.Background()` only in `main`, initialisation and tests. - Respect cancellation in loops and blocking operations, and do not use context values for optional parameters. **Interfaces and types** - Define interfaces in the package that uses them, keep them small (one to three methods), and accept interfaces while returning concrete types. - Do not create an interface for a single implementation unless it is a deliberate seam for testing at a system boundary. - Make zero values useful where possible, and avoid package-level mutable state and `init()` side effects. **Concurrency** - Write sequential code first. Add a goroutine only for a measured need or a real requirement for parallelism. - Every goroutine has an owner who knows how it stops: it exits on context cancellation, and its errors reach the caller (prefer `errgroup`). - The sender closes a channel. Protect shared state with a mutex or confine it to one goroutine, and never copy a struct that contains a mutex. - Run tests with `-race` when concurrency is involved. **Tests** - Write table-driven tests with named `t.Run` subtests. Use `t.Helper()` in helpers and `t.Parallel()` where tests are independent. - Report failures as `got X, want Y`, and use `cmp.Diff` or similar for structs. - No `time.Sleep` for synchronisation. Wait on channels or conditions with a timeout. Put fixtures under `testdata/`. **Naming and docs** - Use MixedCaps, short receiver names that stay consistent, short lowercase package names, and no stutter (`http.Server`, not `http.HTTPServer`). - Every exported identifier has a doc comment that starts with its name. - Check the error from `Close` on anything you wrote to. ```` --- ## HTTP API design rules `api-design-rules` · rule · Conventions · https://hermes-ide.com/prompts/api-design-rules Rules for HTTP APIs covering resource naming, status codes, problem+json errors, cursor pagination, idempotency keys and versioning. Load when designing or changing HTTP endpoints. ````markdown Follow these rules for the rest of this conversation. When you design or change an HTTP API in this project, apply these rules. Where an existing API already follows a different convention, stay consistent with it and point out the difference instead of mixing styles. **Resources and methods** - Name resources with plural nouns in lowercase (`/orders`, `/orders/{order_id}/items`). Nest at most one level, and never put verbs in paths for create, read, update or delete. - Model actions that are not CRUD as a sub-resource or a clearly named action endpoint (`POST /orders/{id}/cancellation`), following the existing pattern. - `GET` is safe and has no body. `PUT` replaces and is idempotent. `PATCH` applies a partial update with a documented format (JSON Merge Patch unless the API already uses something else). `DELETE` is idempotent. - Use one field casing across the whole API, matching what exists. **Status codes** - `201` with a `Location` header for creation, `200` with a body or `204` without, `400` for malformed requests, `401` when unauthenticated, `403` when authenticated but not allowed, `404` when the resource does not exist or must not be revealed, `409` for state conflicts, `412` for failed preconditions, `422` for validation errors if the API already uses it, and `429` with `Retry-After` for rate limits. - Never return `200` with an error body, or a `5xx` for a client mistake. **Errors** - Return errors as `application/problem+json` (RFC 9457) with `type`, `title`, `status`, `detail` and `instance`. Add an `errors` array with a JSON pointer and message per invalid field for validation failures. - Make `type` a stable identifier clients can branch on. Never expose stack traces, SQL or internal hostnames. **Collections** - Paginate every collection that can grow. Use opaque cursors with a `limit` that has a documented maximum, and return the next cursor or link. Use offset pagination only for small, stable sets. - Sort deterministically, and keep filter and sort parameter names consistent across endpoints. **Idempotency and concurrency** - Accept an `Idempotency-Key` header on `POST` endpoints that create resources or move money. Store the key with a hash of the request and the response for a documented window. Replay the stored response for a repeated key, and reject the same key with a different body. - Support optimistic concurrency on updates with `ETag` and `If-Match` where lost updates matter. **Data formats** - Timestamps are RFC 3339 strings in UTC. Money is integer minor units or a decimal string, always with an ISO 4217 currency code. Identifiers are strings. - Document enums as extensible, and require clients to ignore unknown fields and values. **Versioning and change** - Within a version, make only additive changes: new endpoints, new optional fields, new enum values that clients were told to expect. - Any breaking change (removing or renaming a field, changing a type or meaning, tightening validation) goes into a new version using the API's existing scheme. Announce deprecations with `Deprecation` and `Sunset` headers and in the docs. **Security and documentation** - Authenticate every endpoint unless it is deliberately public, and check authorisation on every resource access, not just at login, so one user cannot read another's objects by changing an id. - Never put secrets or personal data in URLs. - Update the API description (such as the OpenAPI document) and its examples in the same change as the code. ```` --- ## Infrastructure as code style rules `iac-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/iac-style-rules Standing rules for Terraform, OpenTofu and similar IaC, covering pinned providers and modules, no hard-coded secrets or IDs, tags on every resource, validated variables, small state and plan review. ````markdown Follow these rules for the rest of this conversation. When you write or change infrastructure as code (Terraform, OpenTofu or a similar declarative tool): **Versions** - Pin the tool version in `required_version` and every provider in `required_providers` with a source and a pessimistic constraint (`~> 5.40`). Commit the dependency lock file (`.terraform.lock.hcl`). - Pin modules to a release tag or exact version, never a branch. Upgrade providers and modules in their own change, with the plan reviewed. - Match the versions and patterns the repository already uses; do not upgrade as a side effect. **No secrets or hard-coded identifiers** - Never write secrets, passwords, tokens or private keys in code, `.tfvars` committed to the repo, or outputs. Read them from a secret manager or generate them in the provider and store them there; mark sensitive variables and outputs `sensitive = true`. - Remember that state files contain secret values in plain text: state lives in a remote backend with encryption, locking and restricted access, never in the repository. - Do not hard-code account or project IDs, regions, ARNs, AMI or image IDs, IP addresses or domain names. Use variables, data sources or lookups. **Variables and outputs** - Give every variable a `type`, a `description`, and a `validation` block where values are constrained (allowed environments, CIDR format, name length). Use defaults only for values that are safe everywhere. - Prefer object types for related settings over many loose strings. Avoid `any`. - Give every output a description, and output only what callers need. **Resources** - Apply a standard set of tags or labels to every resource that supports them (for example owner, environment, service, cost centre, managed-by), through provider default tags where available, plus resource-specific tags. - Name resources consistently with the project's convention; use `snake_case` for Terraform identifiers. - Use `for_each` with stable keys rather than `count` for collections, so removing one item does not recreate the others. - Secure defaults: encryption at rest, no public access unless the variable says so, least-privilege IAM written as explicit policy documents with no wildcard actions on wildcard resources, logging enabled. - Use `lifecycle { prevent_destroy = true }` on stateful resources (databases, buckets with data, key material) and say so in a comment. **Structure and state** - Keep state small: one state per environment and per component (network, data, application), not one state for everything. Pass values between states through outputs and data sources, not copy-paste. - Keep environments in separate directories or workspaces with the same modules and different variables; do not branch logic on environment names inside modules. - Write reusable modules with a README, an example, and inputs and outputs only; no provider configuration inside modules. - Use `moved` and `import` blocks for refactors and adoptions instead of manual state commands, and explain each. **Changes and review** - Run the formatter and validator (`fmt`, `validate`) and the project's linters or policy checks before proposing a change. - Show the plan for every change and point out every destroy, replace and change to IAM, network exposure or data stores. Never suggest applying without a reviewed plan, and never suggest `-auto-approve` against production. - Never edit resources by hand in the console to "fix" drift; change the code, or import the change, and say which. - Ask before any change that destroys or replaces stateful resources, and give the backup or migration step first. ```` --- ## Java style rules `java-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/java-style-rules Standing rules for Java an assistant writes, covering modern language features, immutability, Optional and null handling, exceptions, restrained streams, records and JUnit 5 tests. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.java`. When you write or change Java code in this project: **Tooling and version** - Use the Java version the build declares (`maven.compiler.release`, the Gradle toolchain) and only language features it supports. Do not raise the version on your own. - Follow the project's formatter and static analysis (Spotless, google-java-format, Checkstyle, Error Prone, SpotBugs) and keep the build free of new warnings. - Do not add a dependency for something the JDK does in a few lines; when one is needed, add it through the build file with an explicit version or the project's version catalog or BOM. **Modern language features** - Use records for immutable data carriers, sealed interfaces for closed hierarchies, switch expressions and pattern matching (`instanceof` patterns, record patterns where available) instead of `instanceof`-and-cast chains, and text blocks for multi-line strings. - Use `var` only when the type is obvious from the right-hand side. Keep explicit types on fields, parameters and return types. - Use `java.time` for all dates and times (`Instant` for timestamps, `LocalDate` for calendar dates, a `Clock` injected where code needs "now"). Never `java.util.Date` or `Calendar` in new code. - Use `BigDecimal` for money with an explicit `RoundingMode`, and compare it with `compareTo`, not `equals`. **Immutability** - Make fields `final` by default and classes immutable where practical. Return `List.copyOf`, `Map.copyOf` or unmodifiable views, never internal mutable collections. - Prefer static factory methods or builders over constructors with many parameters of the same type. **Null handling and Optional** - Do not return `null` for collections or arrays; return empty ones. - Use `Optional` only as a return type for "may be absent". Never as a field, parameter or collection element, and never call `Optional.get()`; use `orElseThrow`, `orElse`, `map` or `ifPresent`. - Validate arguments at public boundaries with `Objects.requireNonNull(value, "name")`. Follow the project's nullness annotations (for example JSpecify `@Nullable` and `@NullMarked`) if it uses them. - Compare strings with `equals`, putting the constant or non-null side first, never with `==`. **Exceptions** - Throw specific exceptions with a message that includes the offending value. Use unchecked exceptions for programming errors and checked exceptions only where the caller can actually recover. - Never swallow an exception. When wrapping, pass the cause. Do not catch `Exception` or `Throwable` except at a top-level boundary that logs and translates. - Close resources with try-with-resources. Do not use exceptions for normal control flow. **Streams and collections** - Use streams for clear transformations (filter, map, collect). Use a plain loop when the stream would need nested lambdas, checked exceptions, index juggling or side effects. - No side effects inside stream operations except in `forEach` at the end. Do not use `parallelStream()` without a measurement showing it helps. - Implement `equals` and `hashCode` together (records do this for you), and never mutate an object while it is a key in a map or a member of a set. **Concurrency** - Prefer `java.util.concurrent` types and executors over raw threads, and shut executors down (try-with-resources on `ExecutorService` where the Java version allows). - Share only immutable state between threads, or guard it with a single, documented mechanism. Use virtual threads only if the project already does. Before Java 24, a blocking call inside `synchronized` pins the carrier thread, so guard such sections with a `ReentrantLock` instead; do not pool virtual threads, and limit concurrency to scarce resources with a `Semaphore`. **Logging** - Use the project's logging facade (usually SLF4J) with parameterised messages: `log.info("Order {} shipped", orderId)`. Never `System.out`, string concatenation in log calls, or logging secrets and personal data. **Tests (JUnit 5)** - Use JUnit Jupiter: `@Test`, `@ParameterizedTest` with `@CsvSource` or `@MethodSource` for input tables, `@Nested` to group cases, and `assertThrows` for expected exceptions, checking the message or type. - Use the project's assertion library (AssertJ or JUnit assertions) consistently. One behaviour per test, named for it. - Mock only at system boundaries (HTTP clients, repositories, clocks), never the class under test. Inject a fixed `Clock` instead of mocking static time. - No `Thread.sleep` to wait for asynchronous work; use the project's awaiting utility (such as Awaitility) or synchronise explicitly. ```` --- ## Kotlin style rules `kotlin-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/kotlin-style-rules Standing rules for Kotlin an assistant writes, covering null safety, immutability, coroutines with structured concurrency, and data and sealed classes. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.kt`, `**/*.kts`. When you write or change Kotlin code in this project: **Tooling** - Follow the Kotlin coding conventions and the project's formatter or linter (ktlint, detekt, or the IDE's settings in `.editorconfig`). Do not reformat code you are not changing. - Use the Kotlin version, JVM target and libraries already in the build. Do not add a dependency for what the standard library does. **Null safety** - No not-null assertions (the !! operator) in production code. Use `?.`, `?:` with a meaningful default or an early `return` or `throw`, `requireNotNull` or `checkNotNull` with a message, or a smart cast after a check. - Treat values from Java and platform APIs (platform types) as nullable unless their contract says otherwise, and convert them to Kotlin types at the boundary. - Do not use `lateinit` to dodge initialisation order. Reserve it for framework-injected fields and test setup. **Immutability and types** - Prefer `val` over `var`, and read-only collection types (`List`, `Map`) in signatures. Return copies or read-only views, never a backing mutable collection. - Use `data class` for values and update them with `copy`. Keep data classes free of behaviour that depends on identity. - Model closed sets of states and results with `sealed interface` or `sealed class` and handle them with exhaustive `when` expressions, without an `else` branch, so the compiler flags new cases. - Use `enum class` for simple fixed constants, and `@JvmInline value class` for domain identifiers and units (`UserId`, `Cents`) to avoid mixing them up. **Errors** - Throw exceptions for programmer errors and truly exceptional failures. For expected failures that callers must handle, return a sealed result type. - Never swallow exceptions. In coroutines, never catch `CancellationException` without rethrowing it; avoid broad `catch (e: Exception)` around suspend calls, or rethrow cancellation explicitly. Prefer `runCatching` only where cancellation cannot occur. **Coroutines and structured concurrency** - Launch coroutines only in a scope with a clear owner (`viewModelScope`, `lifecycleScope`, a scope tied to a component's lifecycle, or `coroutineScope` inside a suspend function). Never use `GlobalScope`. - Suspend functions must be main-safe: move blocking or CPU-heavy work with `withContext(Dispatchers.IO)` or `Dispatchers.Default` inside the function, not at the call site. Inject dispatchers so tests can replace them. - Use `coroutineScope` or `supervisorScope` for parallel work with `async`, and pick deliberately: one failure cancels siblings, or not. - Never call `runBlocking` in production code paths, especially on the main thread. - Expose streams as `Flow`. Expose UI state as `StateFlow` built with `stateIn` and an appropriate sharing strategy, and collect it in a lifecycle-aware way. **Functions and style** - Use expression bodies for short functions, named arguments for booleans and same-typed parameters, and default arguments instead of overload chains. - Use extension functions for helpers that read naturally on a type, kept close to their use. Do not add extensions on broad types (`Any`, `String`) for one call site. - Keep visibility as narrow as possible: `private` by default, `internal` for module-wide use, `public` only for real API. - Use scope functions (`let`, `apply`, `also`, `run`, `with`) when they make code clearer, not as a habit; never nest them. **Tests** - Use the project's test framework (JUnit 5, kotlin.test or Kotest) and test behaviour, one scenario per test, with descriptive names (backtick names are fine in tests). - Test coroutines with `kotlinx-coroutines-test` (`runTest` and a test dispatcher). No `Thread.sleep` or real delays. - Prefer fakes over mocks for your own interfaces; mock only at system boundaries. ```` --- ## Laravel rules `laravel-rules` · rule · Conventions · https://hermes-ide.com/prompts/laravel-rules Standing rules for Laravel code covering thin controllers, form requests, policies, Eloquent relations and eager loading, queues, config caching and feature tests. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `app/**/*.php`, `routes/**/*.php`, `config/**/*.php`, `database/**/*.php`, `tests/**/*.php`, `resources/views/**`. When you write or change code in this Laravel application: **Know the project first** - Check the Laravel version in `composer.lock` and follow that version's structure (for example where middleware and exception handling are registered) and the conventions already in this codebase. Use artisan generators (`make:model`, `make:request`, `make:policy`) so files land in the expected places. **Controllers** - Keep controllers thin: authorise, take validated input, call domain code, return a response or API resource. Move multi-step business logic into action or service classes (whichever the project already uses). - Return API responses through API resources, not raw models, so hidden and computed fields are controlled in one place. **Validation and authorisation** - Validate input in Form Request classes, and use `$request->validated()` (or `safe()`) to read it. Never pass `$request->all()` to `create` or `update`. - Authorise with policies and gates: in the Form Request's `authorize()`, with `$this->authorize()` or `can` middleware. Hiding a link is not authorisation. - Define `$fillable` (or the project's chosen guarding approach) on every model, and never make server-owned fields such as `is_admin`, `user_id` or `price` mass assignable from user input. - Scope lookups to the current user or tenant (`$request->user()->projects()->findOrFail($id)`), or rely on route model binding with scoped bindings, not a bare `find` on a user-supplied id. **Eloquent** - Define relations with return types and use them instead of manual foreign-key queries. - Eager load every relation a view, resource or loop touches (`with`, `load`, `withCount`). Keep `Model::preventLazyLoading()` enabled outside production if the project has it, and fix violations rather than disabling it. - Never query inside a loop. Use `whereIn`, `upsert`, `chunkById` or `lazyById` for large sets, and database aggregates instead of counting collections in PHP. - Wrap multi-step writes in `DB::transaction`. Use the query builder's bindings for all input; never concatenate user input into `DB::raw` or `whereRaw`. - Back uniqueness rules with unique indexes and relations with foreign keys in migrations. Migrations have a working `down` method or are explicitly irreversible. **Queues and side effects** - Put slow or failure-prone work (mail, notifications, third-party calls, exports) in queued jobs implementing `ShouldQueue`. Make jobs idempotent, set `tries`, `backoff` and `timeout`, and handle failure in `failed()`. - Dispatch jobs and events that depend on a database write after the transaction commits (`afterCommit`). **Configuration** - Call `env()` only inside `config/*.php` files. Everywhere else use `config('...')`; once config is cached in production, `env()` outside config returns null. - Add new settings to a config file with a sensible default and document them in `.env.example`. Never commit `.env` or real secrets. **Views and output** - Echo values with Blade's escaped double-brace syntax. Use the raw, unescaped echo only for trusted, already-sanitised HTML, and say why in a comment next to it. **Tests** - Write feature tests (Pest or PHPUnit, whichever the project uses) that hit routes, using `RefreshDatabase` and model factories. Fake external effects with `Http::fake`, `Queue::fake`, `Mail::fake` and `Storage::fake`. - Cover validation errors, the forbidden case for another user, and the happy path for every endpoint you add or change. - Before finishing, run the tests and the static analysis or formatter the project uses (for example Larastan or Pint). ```` --- ## Next.js rules `nextjs-rules` · rule · Conventions · https://hermes-ide.com/prompts/nextjs-rules Standing rules for Next.js code covering server and client components, data fetching and caching, route handlers, metadata, images and fonts, environment variables and where code runs. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `app/**`, `src/app/**`, `pages/**`, `src/pages/**`, `next.config.*`, `middleware.*`, `proxy.*`. When you write or change code in this Next.js project: **Know the project before you write** - Read `package.json` for the installed Next.js major version and `next.config.*` for enabled features before using version-specific APIs. Caching defaults, whether request APIs (`params`, `searchParams`, `cookies()`, `headers()`) are async, and the name of the request-interception file have all changed between major versions. Match what this version does; do not write code from an older or newer release. - Check whether the route lives under `app/` (App Router) or `pages/` (Pages Router) and use that router's APIs only. Do not mix `getServerSideProps` into `app/`, or `"use client"` conventions into `pages/`. **Server and client components (App Router)** - Components are server components by default. Add `"use client"` only to the smallest component that needs state, effects, browser APIs or event handlers, and keep it as a leaf. Never mark a layout or page as a client component just to use one hook. - Pass server-fetched data to client components as serialisable props. Do not pass functions, class instances or database objects across the boundary. - Never import server-only code (database clients, secrets, file system access) into a client component. Mark such modules with `import "server-only"` when the package is available. - Pass server components to client components as `children` or props instead of importing them inside the client file. **Data fetching and caching** - Fetch data in server components or server functions, close to where it is used, and run independent requests in parallel with `Promise.all` rather than in a waterfall. - State the caching intent of every fetch or cached function explicitly (static, revalidated on a timer, tagged for on-demand revalidation, or never cached) instead of relying on the version's default. Per-user data is never cached in a shared cache. - After a mutation, revalidate exactly what changed (`revalidatePath` or `revalidateTag`) in the server action or route handler that made the change. - Wrap slow sections in `` with a meaningful fallback, and add `loading` and `error` files for route segments that fetch. **Mutations, server actions and route handlers** - Treat every server action and route handler as a public HTTP endpoint: authenticate, authorise and validate input with a schema on the server, every time. Hiding a button is not authorisation. - Use server actions for form mutations from your own UI; use route handlers (`route.ts`) for webhooks, third-party callbacks and endpoints other clients call. - Return typed results or throw errors that the error boundary handles; never return raw exception messages or stack traces to the client. **Where code runs** - Keep the request-interception file (middleware or proxy, depending on version) thin: redirects, rewrites, header and cookie checks. No database queries or heavy libraries there. - Do not set a route to the edge runtime unless every dependency supports it; Node APIs and most database drivers do not. **Environment variables** - Only variables prefixed `NEXT_PUBLIC_` reach the browser, and they are inlined at build time. Never put a secret behind that prefix, and never read a non-public variable in a client component. - Validate required environment variables once at startup with a schema, and fail with a clear message when one is missing. **Metadata, images and fonts** - Set titles, descriptions and Open Graph data with the `metadata` export or `generateMetadata`, not hand-written `` tags. Give every page a unique title. - Use `next/image` with explicit `width` and `height` (or `fill` with a sized parent) and a real `alt`. Add `priority` only to the largest above-the-fold image. Allow remote image hosts by exact pattern, never a wildcard. - Load fonts with `next/font` so they are self-hosted and do not shift layout. Do not add font `` tags. **Before you finish** - Run the type check, lint and build (`next build`), and fix errors at their cause. A build that only passes in `next dev` is not done. ```` --- ## Python style rules `python-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/python-style-rules Standing rules for Python an assistant writes, covering type hints, pathlib, logging over print, explicit exceptions, safe subprocess calls, project layout and the project's own tooling. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.py`. When you write or change Python code in this project: **Version and tooling** - Target the Python version declared in `pyproject.toml` (`requires-python`). Do not use syntax or standard-library features newer than that. - Use the formatter, linter and type checker the project already configures (for example ruff, black, mypy or pyright) with its settings. Do not add new tools or reformat code you did not change. - Add or change dependencies only through the project's tool (uv, poetry, pip-tools or similar) so the lock file stays in sync. Never install packages globally. **Types** - Annotate every function and method signature, including return types. Use built-in generics (`list[str]`, `dict[str, int]`) and `X | None` where the target version allows. - Avoid `Any`. Model structured data with `dataclass`, `TypedDict`, `NamedTuple` or the project's validation library instead of loose dictionaries, and use `Protocol` for duck-typed interfaces. **Files, paths and resources** - Use `pathlib.Path`, not string concatenation or `os.path` joins. - Open text files with an explicit `encoding="utf-8"`, and manage files, locks and connections with `with` blocks. - Use timezone-aware datetimes (`datetime.now(tz=UTC)`); never mix naive and aware values. **Logging and output** - In library and service code, log through `logger = logging.getLogger(__name__)`, never `print`. Use `print` only for a command-line program's intended output. - Pass values as logging arguments (`logger.info("loaded %d rows", n)`) instead of formatting the string yourself, and never log secrets, tokens or personal data. **Errors** - Catch the narrowest exception that you can handle. Never write a bare `except:` or `except Exception: pass`. - Re-raise with context (`raise ConfigError("missing DB_URL") from err`) and give messages that say what failed and what to do. - Validate input at the boundaries (CLI arguments, HTTP handlers, file parsing), not deep inside the code. **Safety** - Call `subprocess.run` with a list of arguments and `check=True`. Never use `shell=True` with interpolated input. - Never use `eval`, `exec` or `pickle` on untrusted data. Build SQL with parameters, never with f-strings. - Never use mutable default arguments. Use `None` and create the value inside the function. **Layout and style** - Follow the existing package layout. For new projects, use a `src/` layout with `pyproject.toml` and tests under `tests/`. - Keep `__init__.py` to imports and exports. Guard script entry points with `if __name__ == "__main__":`. - Use f-strings for formatting. Keep comprehensions to one level of nesting; use a loop when the logic needs more. - Write docstrings for public modules, classes and functions that say what they do and what they raise, not how. ```` --- ## React component rules `react-component-rules` · rule · Conventions · https://hermes-ide.com/prompts/react-component-rules Standing rules for React code an assistant writes, covering function components, the rules of hooks, colocated state, stable list keys, accessible markup and no effect-driven derived state. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.tsx`, `**/*.jsx`. When you write or change React components in this project: **Components** - Write function components with hooks. Do not add class components. - Give each component one responsibility. Split it when it mixes data loading, state logic and layout, or grows hard to read in one screen. - Never define a component inside another component's body; it remounts on every render and loses its state. - Type props explicitly in TypeScript files. Do not spread unknown props onto DOM elements. - Follow the project's existing patterns for styling, file naming, exports and data fetching. **Hooks** - Call hooks only at the top level of components and custom hooks, never inside conditions, loops or callbacks. Name custom hooks `useSomething`. - Satisfy the exhaustive-deps lint rule by fixing the dependencies, not by disabling the rule. **State** - Keep state as close as possible to where it is used, and lift it only when siblings must share it. - Store the minimum. Compute anything derivable from props or state during render, and do not copy props into state (unless the prop is only an initial value, named like `initialCount`). - Reset a component's state by changing its `key`, not with an effect. - Use context for values that change rarely (theme, current user, locale), not for fast-changing state. - Never mutate state or props. Create new objects and arrays. **Effects** - Use `useEffect` only to synchronise with something outside React: subscriptions, timers, imperative DOM or third-party widgets. - Never use an effect to compute derived state or to react to an event. Put event logic in the event handler. - Clean up every subscription, listener and timer in the effect's cleanup function. - Fetch data with the project's data layer (framework loaders or a query library). If you must fetch in an effect, cancel stale requests with an `AbortController` or an ignore flag. **Lists** - Give list items a stable, unique `key` from the data, such as an id. Never use `Math.random()`, and use the array index only for static lists that are never reordered, filtered or inserted into. **Accessibility** - Use semantic elements: `button` for actions, `a` with `href` for navigation, headings in order, lists for lists. - Never attach `onClick` to a `div` or `span` for an action; use a `button`. - Every form control has an associated label, every meaningful image has `alt` text (decorative images get `alt=""`), and icon-only buttons have an accessible name. - Custom widgets must be operable by keyboard, with visible focus. Dialogs move focus in and return it when closed. - Add ARIA attributes only when no native element provides the semantics. **Performance and safety** - Do not wrap everything in `useMemo`, `useCallback` or `memo`. Use them when profiling shows a cost, or when a stable reference is needed by a memoised child or an effect dependency. If the project uses the React Compiler, do not add manual memoisation at all unless the compiler skips that component. - Never pass untrusted content to `dangerouslySetInnerHTML`. Sanitise it, or render it as text. ```` --- ## React Native rules `react-native-rules` · rule · Conventions · https://hermes-ide.com/prompts/react-native-rules Standing rules for React Native code covering platform-specific files, list performance, navigation, native module boundaries, permissions, secure storage and testing on real devices. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.tsx`, `**/*.ts`, `**/*.jsx`, `app.json`, `app.config.*`, `ios/**`, `android/**`. When you write or change code in this React Native app: **Know the project first** - Check `package.json` for the React Native version, whether the app uses Expo (managed or with prebuild) or bare React Native, and which navigation, state and storage libraries are installed. Use what is there. In an Expo project, prefer Expo modules and config plugins over editing `ios/` and `android/` by hand. **Platform differences** - Handle small differences with `Platform.select` or `Platform.OS`. When a component differs substantially, use platform files (`Button.ios.tsx`, `Button.android.tsx`) with the same exported props type. - Test every UI change on both iOS and Android; do not assume behaviour on one matches the other (shadows versus elevation, keyboard handling, back button, fonts). - Wrap screens in the safe-area handling the project uses and handle the keyboard on forms (`KeyboardAvoidingView` or the project's helper). - Handle the Android hardware back button deliberately on screens with unsaved changes or modals. **Lists and performance** - Render long or unbounded data with a virtualised list (`FlatList`, `SectionList` or the project's high-performance list), never `ScrollView` with `.map()`. - Provide `keyExtractor` from stable ids, keep `renderItem` and item components memoised, and give fixed-height rows a layout hint so the list can skip measurement. - Keep work off the JS thread during animations and gestures: use the native driver or the project's animation library's worklets. Do not run heavy computation in render. - Judge performance in a release build on a real low-end device, not in a debug build or simulator. **Navigation** - Type route params for every navigator and read them through typed hooks. Pass ids in params, not large objects or functions. - Configure deep links through the navigator's linking config and validate incoming params like any untrusted input. **Native module boundaries** - Keep native code behind a small, typed JavaScript interface in one module. Callers never touch `NativeModules` directly. - Do not add a native dependency for something achievable in JavaScript or already provided by an installed library. When you add one, state the native rebuild and any pod or Gradle step it needs. **Permissions and privacy** - Request a permission at the moment the user takes the action that needs it, explain why first, and handle denied and permanently denied states with a path to settings. - Add the matching usage descriptions (`Info.plist` keys or Expo config) and Android manifest entries in the same change, written in plain language. **Secure storage and data** - Store tokens, credentials and personal data only in the platform keychain or keystore (through the project's secure storage library). Never put them in AsyncStorage, MMKV without encryption, logs or Redux persistence. - Never embed API secrets in the bundle; anything in the JavaScript bundle can be extracted. Call your own backend instead. - Use HTTPS only and do not disable certificate checks or App Transport Security. **Accessibility** - Give touchables an `accessibilityRole` and an `accessibilityLabel` when the visible content is not descriptive, keep touch targets at least 44 by 44 points, and support dynamic font sizes without clipping. **Tests** - Test components with the project's testing library by role, label and text, not by implementation details. Mock native modules at the boundary module, not throughout. - Before finishing, run the type check, lint and tests, and say plainly which platforms you actually ran the change on. ```` --- ## Ruby on Rails rules `rails-rules` · rule · Conventions · https://hermes-ide.com/prompts/rails-rules Standing rules for Rails code covering conventions, strong parameters, restraint with callbacks, eager loading, deploy-safe migrations, background jobs and request specs. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `app/**/*.rb`, `config/**/*.rb`, `db/**/*.rb`, `lib/**/*.rb`, `spec/**/*.rb`, `test/**/*.rb`, `app/views/**`. When you write or change code in this Rails application: **Conventions first** - Check the Rails version in `Gemfile.lock` and follow the idioms of that version and of this codebase. Use Rails naming, RESTful resource routes and the standard directory layout before inventing structure. Add a custom route only when no resource action fits. - Keep controllers to the seven resource actions where possible; a new verb is usually a new resource (`resource :publication` instead of `post :publish`). - When logic spans several models or calls external services, put it in a plain Ruby object in the project's chosen place (service objects, `app/models` POROs, or concerns if that is the house style). Do not introduce a new architectural pattern the codebase does not already use. **Strong parameters** - Permit attributes explicitly with the version's strong-parameters API (`params.expect` on versions that have it, otherwise `params.require(...).permit(...)`). Never use the bang form of `permit` that allows every attribute, and never permit `role`, `admin`, `user_id`, prices or other server-owned fields from user input. - Scope lookups through the current user or tenant (`current_user.projects.find(params[:id])`), never a bare `Project.find` on a user-controlled id. **Callbacks** - Use model callbacks only for changes to the record itself (normalising a field, setting a default). Do not send email, enqueue jobs, call APIs or update other models from `before_*` or `after_save` callbacks; do it explicitly in the code path that owns the action. - When a side effect must follow a successful write, use `after_commit` (or the project's equivalent) so it never runs for a rolled-back transaction. **Queries** - Eager load every association a view, serializer or loop touches (`includes`, `preload` or `eager_load`). When you add a field that follows an association, update the query in the same change. Respect `strict_loading` where the project enables it. - Never query inside a loop. Use `where(id: ids)`, `pluck`, `exists?`, `insert_all`, `update_all` or counter caches, and `find_each` for large batches. - Use parameterised conditions (`where(name: value)` or placeholders); never interpolate user input into SQL strings or `order` clauses. - Back every uniqueness validation with a unique index, and every foreign key with a database constraint. **Migrations** - Write reversible migrations (`change` with reversible operations, or explicit `up` and `down`). - On large tables, keep deploys safe: add indexes concurrently with DDL transactions disabled (on PostgreSQL), add columns without volatile defaults, backfill in batches in a separate job or migration, and remove a column in two deploys (add it to `ignored_columns` first, then drop it). - Never reference application model classes in migrations that will outlive them; use SQL or a minimal model defined inside the migration. **Background jobs** - Make jobs idempotent and safe to retry. Pass ids or GlobalID-serialisable records, not large objects, and handle a record that no longer exists. - Enqueue jobs after the surrounding transaction commits, set a sensible retry and discard policy, and keep each job to one unit of work. **Views and security** - Rely on output escaping; never call `html_safe` or `raw` on user content. Use `sanitize` with an allow list when rich text is required. - Keep CSRF protection on for browser controllers. Store secrets in encrypted credentials or environment variables, never in the repository. **Tests** - Test behaviour through request specs (or integration tests in Minitest projects) rather than controller specs, plus model specs for validations and scopes. Use the project's factories or fixtures. - Cover authorisation: a user must not read or change another user's records. - Before finishing, run the test suite and the linter the project uses, and confirm `db/schema.rb` (or `structure.sql`) matches the migration you wrote. ```` --- ## Rust style rules `rust-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/rust-style-rules Standing rules for Rust an assistant writes, covering ownership-first APIs, Result over panic, clippy-clean code, typed errors, async hygiene and minimal, justified unsafe. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.rs`. When you write or change Rust code in this project: **Tooling** - Code must pass `cargo fmt` and `cargo clippy --all-targets` with no warnings under the project's lint settings. - Never silence a lint crate-wide. Allow a specific lint on the narrowest item, with a comment explaining why. - Use the edition and minimum Rust version in `Cargo.toml`. Add a dependency only when it earns its place, with the fewest features needed. **Ownership and APIs** - Borrow in parameters when the function does not keep the value: `&str`, `&[T]`, `&Path` or `impl AsRef`. Take ownership (`String`, `Vec`) when the value is stored. - Do not add `.clone()` just to satisfy the borrow checker. Restructure the code first, and when a clone is the right answer, make it visible and cheap or explain it. - Return owned values or iterators rather than references tied to temporary state. Use `Cow` when a value is only sometimes owned. - Model states with enums rather than booleans or sentinel values, and wrap ids and units in newtypes. - Implement standard traits (`From`, `TryFrom`, `Display`, `Default`, `Debug`) instead of ad hoc conversion methods, and mark results that must not be ignored with `#[must_use]`. **Errors** - Return `Result` for anything that can fail at runtime, and propagate with `?`. - Do not call `unwrap()` in library or request-handling code. Use `expect("reason this cannot fail")` only for real invariants. - Follow the project's error approach. Where there is none, use typed error enums (for example with `thiserror`) in libraries and contextual errors (for example `anyhow` with `.context(...)`) in binaries. - Never panic across an FFI boundary or in a `Drop` implementation. **Unsafe** - Avoid `unsafe`. If it is necessary, keep the block as small as possible, put a `// SAFETY:` comment on it that states the invariants that make it sound, and wrap it in a safe API. - Document every `unsafe fn` with a `# Safety` section, and test unsafe code under Miri where the project supports it. **Concurrency and async** - Prefer message passing or owned data over shared mutable state. When state is shared, use `Arc` with a `Mutex` or `RwLock` and keep critical sections short. - Never hold a `std::sync::Mutex` guard across `.await`. Use the runtime's async mutex or restructure. - Never block inside async code. Move blocking or CPU-heavy work to `spawn_blocking` or a dedicated thread. **Style** - Prefer iterator chains to index loops when they read clearly, and avoid collecting into a `Vec` only to iterate it again. - Keep items private by default, and use `pub(crate)` before `pub`. - Document public items with `///` comments, with an example for non-trivial APIs. - Put unit tests in a `#[cfg(test)] mod tests` beside the code, and integration tests in `tests/`. ```` --- ## Shell script rules `shell-script-rules` · rule · Conventions · https://hermes-ide.com/prompts/shell-script-rules Standing rules for Bash and POSIX shell an assistant writes, covering strict mode, quoting every expansion, no parsing of ls, mktemp with trap cleanup, ShellCheck-clean code and a usage message. ````markdown Follow these rules for the rest of this conversation. When you write or change a shell script: **Pick the shell on purpose** - Start every script with a shebang. Use `#!/usr/bin/env bash` when you use Bash features (arrays, `[[ ]]`, `local`, process substitution); use `#!/bin/sh` only if the script is strictly POSIX, and then use no Bash features at all. - Match the project's existing scripts and the shell available where the script runs (minimal containers often have only `sh`; macOS ships an old Bash 3.2). Say which shell and version you assume. - If the logic needs data structures, JSON handling or more than about 150 lines, say so and suggest the project's scripting language instead. **Fail loudly** - In Bash, start with `set -euo pipefail` and set `IFS` only if you need to. In POSIX sh, use `set -eu`. - Know where `set -e` does not help (commands in conditions, in `&&` chains, in subshells of command substitution) and check exit codes explicitly where it matters. - Send errors to standard error with a clear message and exit non-zero: `die() { printf '%s\n' "$*" >&2; exit 1; }`. **Quote everything** - Quote every variable and command substitution: `"$file"`, `"$(pwd)"`, `"${array[@]}"`. Leave something unquoted only when word splitting is the point, and comment why. - Use `"$@"` to pass arguments through, never `$*` unquoted. - Use `[[ ]]` in Bash and `[ ]` with quoted operands in sh. Use `$(...)`, not backticks. - Use `printf` rather than `echo` for anything that may start with `-` or contain backslashes. **Files and loops** - Never parse the output of `ls`. Use globs (`for f in ./*.log; do [ -e "$f" ] || continue; ...`) or `find ... -print0 | while IFS= read -r -d '' f`. - Read lines with `while IFS= read -r line`. Do not use `for line in $(cat file)`. - Prefix relative globs with `./` so filenames starting with `-` are not taken as options, and use `--` before file arguments where the command supports it. **Temporary files and cleanup** - Create temporary files and directories with `mktemp` (`tmp=$(mktemp -d)`), never fixed names in `/tmp`. - Register cleanup straight after creating them: `trap 'rm -rf -- "$tmp"' EXIT`. Keep the trap idempotent. - Guard destructive commands: never `rm -rf "$dir/"` when `dir` could be empty; use `${dir:?}` or check it first. **Dependencies and interface** - Check required commands at the start (`command -v jq >/dev/null || die "jq is required"`) and list them in the header comment. - Give every script that takes arguments a `usage` function, handle `-h` and `--help`, parse options with `getopts` or a simple `case` loop, and exit with code 2 on wrong usage. - Read configuration from arguments or environment variables with defaults (`: "${PORT:=8080}"`), not from edits inside the script. - Make scripts safe to re-run: check before creating, use `mkdir -p`, and avoid appending the same line twice. **Safety** - Never use `eval` on input. Never build commands by concatenating strings; use arrays in Bash. - Never put secrets in the script or echo them; read them from the environment or a secret store, and do not enable `set -x` around them. - Never download a script and pipe it straight into a shell. Download to a file, verify a checksum or signature, then run it. - Ask before writing scripts that delete data, change system configuration or run with `sudo`, and include a dry-run option for them. **Before you finish** - Make the script pass ShellCheck with no warnings, or disable a specific check on one line with a comment explaining why. - Format consistently (`shfmt` if the project uses it) and keep functions small with `local` variables in Bash. ```` --- ## Spring Boot rules `spring-boot-rules` · rule · Conventions · https://hermes-ide.com/prompts/spring-boot-rules Standing rules for Spring Boot services covering package structure, constructor injection, typed configuration, transaction boundaries, error responses, actuator and slice tests. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `src/main/**/*.java`, `src/main/**/*.kt`, `src/test/**/*.java`, `src/test/**/*.kt`, `src/main/resources/application*.yml`, `src/main/resources/application*.properties`. When you write or change code in this Spring Boot service: **Know the project first** - Check the Spring Boot and Java (or Kotlin) versions in the build file and use APIs that exist in those versions (for example the `jakarta.*` namespace, records, `RestClient`). Follow the existing package layout and naming. **Structure** - Organise by feature (`orders`, `billing`), each package holding its controller, service, repository and DTOs, unless the codebase is already layered by technical role. Keep classes package-private when nothing outside the feature uses them. - Controllers translate HTTP to calls on services and back. Business rules live in services or the domain model, never in controllers or repositories. - Expose DTOs (records are ideal) in the API, never JPA entities. Map explicitly at the boundary. **Dependency injection** - Use constructor injection with `final` fields (or Kotlin `val`s), one constructor, no `@Autowired` on fields or setters. A constructor with many parameters is a sign the class does too much; say so rather than hiding it. - Do not call `new` on Spring-managed collaborators or look beans up from the `ApplicationContext` in business code. **Configuration** - Bind settings with `@ConfigurationProperties` on a record or class, annotated `@Validated` with constraints, rather than scattered `@Value` strings. Give every property a documented default or make it required. - Keep secrets out of `application.yml` in the repository; read them from the environment or the project's secret store. Use profiles only for real environment differences. **Transactions and persistence** - Put `@Transactional` on public service methods that form one unit of work, with `readOnly = true` for queries. Remember that self-invocation and private methods bypass the proxy, so annotations there do nothing. - Do not call remote services, send messages or do slow I/O inside a database transaction; publish the side effect after commit (for example a transactional event listener with the after-commit phase). - Avoid N+1 queries: use fetch joins, entity graphs or projections for the associations a use case needs, and keep `spring.jpa.open-in-view` disabled so lazy loading cannot leak into the web layer. - Change the schema only through the project's migration tool (Flyway or Liquibase); never rely on `ddl-auto=update` outside throwaway local setups. **Errors** - Handle exceptions in one `@RestControllerAdvice` that returns `ProblemDetail` (RFC 9457) responses with the right status: 400 for validation, 404 not found, 409 conflicts. Validate request bodies with `@Valid` and Bean Validation constraints. - Never return stack traces or exception messages from internals to clients; log them with a correlation id. **Operations** - Expose only the actuator endpoints you need (health, info, metrics, readiness and liveness probes) and secure the rest. Never expose `env`, `heapdump` or `configprops` publicly. - Log through SLF4J with parameterised messages; never log secrets, tokens or full personal data. **Tests** - Prefer slice tests: `@WebMvcTest` (or the WebFlux slice) for controllers, `@DataJpaTest` for repositories, plain unit tests for services. Use `@SpringBootTest` sparingly for end-to-end wiring. - Test against the real database engine with Testcontainers when queries are database-specific, not an in-memory substitute that behaves differently. - Before finishing, run the build with tests (`./mvnw verify` or `./gradlew check`) and report the result. ```` --- ## SQL style rules `sql-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/sql-style-rules Standing rules for SQL an assistant writes, covering formatting, naming, explicit column lists, parameterised queries, NULL handling, data types and safe migrations. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.sql`, `**/migrations/**`, `**/migrate/**`. When you write or change SQL in this project: **Dialect and formatting** - Write for the project's database engine and version. Do not use features it lacks, and flag engine-specific syntax when portability matters. - Match the existing formatting. Where there is none: uppercase keywords, one major clause per line (`SELECT`, `FROM`, `JOIN`, `WHERE`, `GROUP BY`, `ORDER BY`), one column per line in long lists, and consistent indentation. - Prefer common table expressions to deeply nested subqueries, with names that say what each step contains. - Comment the reason for non-obvious logic, not what the SQL does. **Naming** - Use `snake_case` with no quoted identifiers, reserved words or unexplained abbreviations. Follow the existing singular or plural convention for table names. - Name foreign keys `_id`, booleans `is_` or `has_`, timestamps `_at` and dates `_on` or `_date`. - Name constraints and indexes explicitly (`orders_customer_id_fkey`, `orders_created_at_idx`) so migrations can refer to them. **Queries** - List columns explicitly in `SELECT` and `INSERT`. Use `SELECT *` only in ad hoc exploration, never in application code, views or models. - Use explicit `JOIN ... ON`, never comma joins, and qualify every column with a table alias when more than one table is involved. - Add `ORDER BY` whenever the order matters, and always with `LIMIT` or `OFFSET`. Make the ordering deterministic with a unique tie-breaker. - Check for fan-out before aggregating over joins, and aggregate before joining when that avoids it. **Parameters and safety** - Pass values as bound parameters, always. Never build SQL by concatenating or interpolating user input. - When an identifier such as a sort column must be dynamic, choose it from an allowlist in code. - Grant application roles only the privileges they need. **NULLs and types** - Compare with `IS NULL` or `IS DISTINCT FROM`, never `= NULL`. Prefer `NOT EXISTS` to `NOT IN` when the subquery can return NULL. - Store money as `NUMERIC`/`DECIMAL` or integer minor units, never floating point. Store timestamps with time zone, in UTC. - Enforce integrity in the schema with `NOT NULL`, `CHECK`, `UNIQUE` and foreign keys, not only in application code. **Migrations** - One logical change per migration. Never edit a migration that has already run anywhere shared; write a new one. - Separate schema changes from data backfills. Run backfills in batches with short transactions. - On large or busy tables, use lock-safe forms: build indexes concurrently or online, add constraints without validation and validate them separately, add columns as nullable first, and set a lock timeout. - Make destructive changes (drop, rename, type narrowing) only after a release in which no deployed code uses the old shape, and give every migration a tested rollback or an explicit note that it cannot be reversed. ```` --- ## Swift style rules `swift-style-rules` · rule · Conventions · https://hermes-ide.com/prompts/swift-style-rules Standing rules for Swift an assistant writes, covering value types, optionals without force unwraps, structured concurrency, access control and API Design Guidelines naming. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.swift`. When you write or change Swift code in this project: **Tooling and versions** - Use the Swift language version and concurrency checking level the project already sets (in `Package.swift` or the Xcode build settings). Do not raise or lower them as a side effect. - Follow the project's formatter and linter (swift-format or SwiftLint) if configured. Do not reformat code you are not changing. **Types and values** - Prefer `struct` and `enum` for models and values. Use a `class` only for identity, shared mutable state or framework requirements, and mark it `final` unless it is designed for subclassing. - Prefer `let` over `var`. Keep mutation local and explicit with `mutating` methods. - Model closed sets of states with enums with associated values instead of several optionals or boolean flags. - Use `Codable` with explicit `CodingKeys` when the wire format differs from Swift naming. Decode dates and numbers with explicit strategies. **Optionals and errors** - No force unwraps (postfix !), try! or forced casts (as!) in production code. Use `guard let`, `if let`, `??` with a meaningful default, or throw. The only exceptions are values that are guaranteed by construction (such as a URL literal), and they get a comment saying why. - Use `guard` for early exit and keep the happy path unindented. - Throw errors for recoverable failures with an error type that callers can match on. Do not return `nil` to signal an error the caller needs to understand. - Use `precondition` or `fatalError` only for programmer errors, never for bad input or network failures. **Concurrency** - Use `async`/`await` and structured concurrency (`async let`, task groups) for new asynchronous code. Wrap callback-based APIs with checked continuations rather than mixing styles. - Annotate UI-facing types and functions with `@MainActor`. Protect shared mutable state with an actor rather than locks or dispatch queues in new code. - Types crossing concurrency domains must be `Sendable`. Do not silence warnings with `@unchecked Sendable` or `nonisolated(unsafe)` unless you document the synchronisation that makes it safe. - Do not create unstructured `Task { }` without an owner. Store and cancel long-lived tasks, and check `Task.isCancelled` or call `try Task.checkCancellation()` in long loops. - In escaping closures that capture `self` in classes, use `[weak self]` when the closure can outlive the object. **Access control** - Default to `private`, then `fileprivate`, then `internal`. Make something `public` or `open` only when it is part of a module's intended API. - Keep properties `private(set)` when callers need to read but not write. **Naming (Swift API Design Guidelines)** - Aim for clarity at the point of use: `remove(at: index)`, `users.filter(isActive)`, not abbreviations. - Types and protocols in UpperCamelCase, everything else in lowerCamelCase. Booleans read as assertions (`isEmpty`, `hasAccess`). - Methods with side effects read as verbs (`sort()`), and non-mutating counterparts use the "ed" or "ing" form (`sorted()`). - Document public API with `///` comments that describe what it does, its parameters, what it throws and its complexity if not obvious. **SwiftUI (when used)** - Mark view-owned state `@State private`. Pass bindings down only when the child must write. - Keep views small and free of business logic. Put logic in an observable model (`@Observable` on the deployment targets that support it, otherwise `ObservableObject`) that can be tested without the view. - Do not start work in a view's `init`; use `.task` so it is tied to the view's lifetime and cancelled automatically. **Tests** - Use the test framework the project already uses (Swift Testing or XCTest). Write tests for behaviour, one scenario each, with clear names. - Test async code with `async` tests, not sleeps or expectations with long timeouts. - Inject dependencies (network, clock, storage) through protocols or closures so tests do not hit real services. ```` --- ## Tailwind CSS rules `tailwind-rules` · rule · Conventions · https://hermes-ide.com/prompts/tailwind-rules Standing rules for Tailwind CSS covering design tokens in the theme, class ordering, extracting components instead of repeated class strings, responsive and dark variants and visible focus states. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.html`, `**/*.jsx`, `**/*.tsx`, `**/*.vue`, `**/*.svelte`, `**/*.astro`, `**/*.css`, `tailwind.config.*`. When you write or change styling in this Tailwind project: **Know the setup first** - Check the installed Tailwind major version and where the theme is defined: a CSS-first `@theme` block in the main stylesheet, or a `tailwind.config.*` file in older setups. Use the syntax of that version only. - Read the theme before styling. Use the project's colours, spacing, font sizes, radii and shadows by their token names. **Design tokens** - Use theme tokens (`bg-brand-600`, `text-muted`, `rounded-card`) instead of arbitrary values (`bg-[#1f6feb]`, `p-[13px]`). If a value repeats and no token fits, add a token to the theme in the same change rather than repeating the arbitrary value. - Arbitrary values are acceptable for one-off layout needs with no design meaning (a specific grid template, an exact aspect ratio), not for brand colours or spacing scale. - Never use inline `style` attributes for things Tailwind can express. **Class names** - Write complete class names in source. Never build them by string concatenation or interpolation (`bg-${color}-500`): the build only generates classes it can find literally. Map variants to full class strings in an object instead. - Keep class order consistent. If the project uses the official Prettier plugin for Tailwind, let it sort; otherwise order layout, box model, typography, visual, then state and responsive variants. - Combine conditional classes with the project's helper (for example `clsx` with `tailwind-merge`, or a variants library) so conflicting utilities resolve predictably. **Reuse** - When the same long class list appears in three or more places, extract a component (or a partial in template languages) rather than copying it again. Prefer components to `@apply`; use `@apply` only for styling you cannot reach with markup, such as third-party HTML or prose content. - Keep variant logic (size, intent, state) in one place per component. **Responsive and dark mode** - Design mobile first: unprefixed utilities for small screens, then `sm:`, `md:`, `lg:` overrides. Do not use `max-*` variants to undo desktop styles unless that is the project's pattern. - If the project supports dark mode, every new colour on a surface, text or border gets its `dark:` counterpart (or uses semantic tokens that switch automatically). Check both themes. - Use container queries when a component's layout depends on its container rather than the viewport, if the project's version supports them. **Accessibility** - Never remove focus outlines without a replacement. Every interactive element gets a visible focus style such as `focus-visible:ring-2 focus-visible:ring-offset-2` with a token colour of sufficient contrast. - Keep text and background contrast at WCAG AA in both themes. Use `sr-only` for visually hidden labels, not `hidden`, which removes content from assistive technology. - Respect `motion-reduce:` for non-essential animation and transitions. **Before you finish** - Run the build and check the generated CSS contains the classes you used. Look at the change at mobile and desktop widths, in light and dark mode, and tab through it with the keyboard. ```` --- ## TypeScript strict rules `typescript-strict-rules` · rule · Conventions · https://hermes-ide.com/prompts/typescript-strict-rules Keeps TypeScript code fully type-safe under strict mode, with no any, no unchecked casts, validated external data and exhaustive unions. Use in any TypeScript project. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.ts`, `**/*.tsx`, `**/*.mts`, `**/*.cts`. When you write or change TypeScript: - Do not loosen the compiler settings. Never turn off `strict`, `noUncheckedIndexedAccess`, `exactOptionalPropertyTypes` or other checks in `tsconfig.json` to make an error go away; fix the code. - Do not use `any`. Use `unknown` for values of unknown shape and narrow them with type guards, `typeof`, `instanceof` or `in` checks. If a third-party type forces `any`, contain it in one small, typed wrapper. - Do not silence errors with `@ts-ignore` or `@ts-nocheck`. If an error cannot be fixed, use `@ts-expect-error` with a comment explaining why, so it fails when the cause goes away. - Avoid type assertions (`as Foo`) and non-null assertions (a postfix exclamation mark, as in `user!.name`). Prefer narrowing. Allow an assertion only where you can state the invariant that makes it safe, and write that invariant in a comment next to it. Never write `as unknown as Foo` to force a type. - Validate data that crosses a trust boundary before you type it: HTTP bodies, query strings, environment variables, files, `JSON.parse` results and third-party API responses. Use the schema library the project already uses, and derive the type from the schema instead of writing both by hand. - Model states that cannot coexist as discriminated unions rather than objects with many optional fields. Handle every member in a `switch`, and add a default branch that assigns the value to `never` so a new member becomes a compile error. - Use `satisfies` to check that a value matches a type without widening it, and `as const` for fixed lookup tables. - Mark data that should not change as `readonly` (`readonly T[]`, `Readonly`), especially function parameters. - Give exported functions explicit parameter and return types. Let inference handle local variables. - Use `import type` and `export type` for type-only imports and exports. - Prefer union types of string literals or `as const` objects over `enum` and `namespace`, unless the project already uses them, because they are not erasable syntax and break type stripping in runtimes that run TypeScript directly. - In `catch` blocks, treat the error as `unknown` and narrow it before reading properties. - Never leave a promise floating. `await` it, return it, or explicitly mark it as intentionally ignored with `void` and a comment. - Index access may return `undefined`. Handle that case instead of asserting it away. - Before you say the work is done, run the project's type check (for example `tsc --noEmit` or the repo's `typecheck` script) and report the result. ```` --- ## Vue and Nuxt rules `vue-rules` · rule · Conventions · https://hermes-ide.com/prompts/vue-rules Standing rules for Vue and Nuxt code covering the Composition API, typed props and emits, reactivity pitfalls, composables, stores and server versus client rendering in Nuxt. ````markdown Follow these rules for the rest of this conversation. Apply these rules to files matching: `**/*.vue`, `composables/**`, `stores/**`, `server/**`, `nuxt.config.*`, `src/**/*.ts`. When you write or change Vue or Nuxt code in this project: **Know the project first** - Check the Vue (and Nuxt, if present) version in `package.json` and follow the existing style. Some reactivity behaviour, such as whether destructured props stay reactive, depends on the version. **Components** - Write single-file components with `