mcp-subagents-opencode 1.0.0

package/build/templates/overlays/coder-csharp.mdx

@@ -0,0 +1,58 @@
+## C#-SPECIFIC GUIDELINES
+
+You are working in a **C#** codebase. Apply these principles with zero exceptions.
+
+### LINQ — Use It Everywhere
+- Use LINQ for collection operations — it's more readable than manual loops
+- Prefer method syntax (`.Where().Select()`) over query syntax (`from x in ...`) — follow project convention
+- Use `FirstOrDefault()`, `SingleOrDefault()` — know the difference (Single throws if >1)
+- Avoid `ToList()` / `ToArray()` unless you need materialization — keep queries lazy with `IEnumerable<T>`
+- Use `Any()` instead of `Count() > 0` for existence checks
+
+### Async/Await — The Right Way
+- Make async methods return `Task` or `Task<T>` — never `async void` except event handlers
+- Use `await` all the way — never mix `.Result` or `.Wait()` with async (deadlock risk)
+- Use `ConfigureAwait(false)` in library code (not in UI/ASP.NET controller code)
+- Use `CancellationToken` as the last parameter on async methods — propagate it through
+- Use `ValueTask<T>` for hot-path methods that frequently complete synchronously
+
+### Nullable Reference Types
+- Enable `<Nullable>enable</Nullable>` — if the project has it, respect it fully
+- Use `?` suffix for nullable: `string?` means "might be null"
+- Use `!` (null-forgiving) only when you've verified non-null through logic the compiler can't see — add a comment
+- Use `[NotNull]`, `[MaybeNull]`, `[NotNullWhen]` attributes for nuanced nullability
+- Prefer `is not null` over `!= null` in pattern matching contexts
+
+### Record Types & Immutability
+- Use `record` types for immutable data transfer objects: `record UserDto(string Name, string Email);`
+- Use `record struct` for value-type records (stack-allocated, no GC pressure)
+- Use `with` expressions for non-destructive mutation: `var updated = user with { Name = "New" };`
+- Use `init` properties for immutable-after-construction objects
+- Use `required` keyword (C# 11+) for mandatory init properties
+
+### Pattern Matching
+- Use pattern matching in `switch` expressions — cleaner than if/else chains
+- Use `is` patterns: `if (obj is string s)`, `if (value is > 0 and < 100)`
+- Use `switch` expressions for exhaustive matching: `var result = status switch { ... }`
+- Use property patterns: `if (user is { Name: "admin", IsActive: true })`
+- Use discard `_` for cases you don't handle: `_ => throw new InvalidOperationException()`
+
+### Entity Framework Core (if applicable)
+- Use `AsNoTracking()` for read-only queries — significant performance improvement
+- Use `Include()` for eager loading — avoid N+1 queries
+- Use `AsSplitQuery()` for queries with multiple includes
+- Keep DbContext lifetime short — scoped per request in ASP.NET
+- Use migrations — never modify the database schema manually
+
+### Naming Conventions
+- `PascalCase` for classes, methods, properties, events, namespaces
+- `camelCase` for local variables, parameters
+- `_camelCase` for private fields (with underscore prefix)
+- `I` prefix for interfaces: `IUserRepository`
+- `Async` suffix for async methods: `GetUserAsync()`
+- Boolean properties: `Is*`, `Has*`, `Can*`
+
+### Testing Considerations
+- Use constructor injection for testability — all dependencies through constructor
+- Use interfaces for external dependencies — mockable with Moq, NSubstitute, etc.
+- Follow project's test framework conventions (xUnit, NUnit, MSTest)

package/build/templates/overlays/coder-go.mdx

@@ -0,0 +1,53 @@
+## GO-SPECIFIC GUIDELINES
+
+You are working in a **Go** codebase. Apply these principles with zero exceptions.
+
+### Error Handling — The Go Way
+- **Always check errors:** `if err != nil { return fmt.Errorf("context: %w", err) }`
+- Use `%w` for error wrapping (enables `errors.Is()` and `errors.As()`) — not `%v`
+- Create sentinel errors with `var ErrNotFound = errors.New("not found")` for expected conditions
+- Create custom error types only when callers need to inspect error details
+- Never ignore errors — if you truly don't need it, assign to `_` with a comment explaining why
+- Return errors, don't panic — `panic` is for unrecoverable programming errors only
+
+### Interfaces — Accept Interfaces, Return Structs
+- Define interfaces at the **consumer** site, not the implementation site
+- Keep interfaces small — 1-3 methods. Compose larger behaviors from small interfaces
+- Use `io.Reader`, `io.Writer`, `fmt.Stringer`, `error` — don't reinvent standard interfaces
+- Never export interfaces for concrete types unless multiple implementations exist
+
+### Goroutine Lifecycle
+- **Always ensure goroutines can be stopped** — use `context.Context` for cancellation
+- Pass `context.Context` as the first parameter to functions that do I/O or may block
+- Use `sync.WaitGroup` to wait for goroutine completion
+- Use `errgroup.Group` for parallel tasks that can fail
+- Never launch a goroutine without a clear shutdown path — leaked goroutines are resource leaks
+- Use channels for communication, mutexes for state — prefer channels when both work
+
+### Code Structure
+- Follow **standard Go project layout** — respect the existing project conventions
+- Exported names (`PascalCase`) are public API — unexported (`camelCase`) are internal
+- One package per directory — package name matches directory name (lowercase, no underscores)
+- Group imports: stdlib → external → internal (separated by blank lines)
+- Use `internal/` for packages that should not be imported outside the module
+
+### Patterns
+- Use **functional options** for configurable constructors: `func NewServer(opts ...Option) *Server`
+- Use **table-driven tests** as the default test pattern
+- Use `struct embedding` for composition — not inheritance
+- Use `defer` for cleanup — but understand it runs at function exit, not block exit
+- Prefer `strings.Builder` for string concatenation in loops
+- Use `context.WithValue` sparingly — prefer explicit parameters
+
+### Naming Conventions
+- `PascalCase` for exported, `camelCase` for unexported
+- Receivers: short (1-2 letters), consistent within type: `func (s *Server) Start()`
+- Acronyms are all-caps: `userID`, `httpClient`, `URL`
+- Getters don't use `Get` prefix: `Name()` not `GetName()`
+- Package names are lowercase, single word when possible
+
+### Testing Considerations
+- Use table-driven tests with `t.Run()` for subtests
+- Use `t.Helper()` in test helper functions for better error reporting
+- Use `t.Parallel()` when tests are independent
+- Prefer `testify/assert` or standard `if got != want` — follow project convention

package/build/templates/overlays/coder-java.mdx

@@ -0,0 +1,54 @@
+## JAVA-SPECIFIC GUIDELINES
+
+You are working in a **Java** codebase. Apply these principles with zero exceptions.
+
+### Exception Handling
+- Use **checked exceptions** for recoverable conditions, **unchecked** for programming errors
+- Create a base application exception: `AppException extends RuntimeException`
+- Domain exceptions extend the base: `UserNotFoundException extends AppException`
+- Never catch `Exception` or `Throwable` broadly — catch specific types
+- Always include the original cause: `throw new AppException("context", originalException)`
+- Use try-with-resources for all `AutoCloseable` resources — never manual `finally` for cleanup
+
+### Immutability — Default to Final
+- Make fields `final` by default — mutable only when mutation is required
+- Use `Collections.unmodifiableList()` or `List.of()` for immutable collections
+- Prefer **record types** (Java 16+) for data carriers: `record User(String name, String email) {}`
+- Use builder pattern for objects with many optional fields
+
+### Modern Java Patterns
+- Use **Stream API** for collection processing — but keep pipelines short and readable
+- Use `Optional<T>` for return types that may not have a value — never for parameters or fields
+- Use `var` for local variables when the type is obvious from context
+- Use **switch expressions** (Java 14+) with pattern matching when available
+- Use **sealed classes** (Java 17+) for restricted type hierarchies
+- Use **text blocks** (`"""`) for multi-line strings
+
+### Annotations
+- `@Override` on all overridden methods — non-negotiable
+- `@Nullable` / `@NonNull` (from JSR-305 or JetBrains) on public API parameters and return types
+- `@Deprecated(forRemoval = true)` with `@deprecated` Javadoc tag — never deprecate without replacement guidance
+- Use Lombok sparingly — `@Getter`, `@Builder`, `@RequiredArgsConstructor` are fine; `@Data` hides mutation
+
+### Package Conventions
+- Follow the project's existing package structure — don't introduce new conventions
+- Organize by feature, not by layer (unless the project already uses layers)
+- One public class per file — file name matches class name
+- Keep packages focused — if a package has >15 classes, it probably needs splitting
+
+### Dependency Injection
+- Use constructor injection — not field injection (`@Autowired` on fields is an anti-pattern)
+- Prefer interface types in constructor parameters for testability
+- Keep constructors focused — if >5 parameters, the class may have too many responsibilities
+
+### Naming Conventions
+- `PascalCase` for classes, interfaces, enums, records
+- `camelCase` for methods, fields, parameters, local variables
+- `UPPER_SNAKE_CASE` for constants (`static final`)
+- Interfaces: no `I` prefix — `UserRepository` not `IUserRepository`
+- Boolean methods: `is*`, `has*`, `can*`, `should*`
+
+### Testing Considerations
+- Write code with dependency injection for testability
+- Prefer composition over inheritance — easier to mock
+- Use `@VisibleForTesting` (Guava) to annotate package-private methods exposed for testing

package/build/templates/overlays/coder-kotlin.mdx

@@ -0,0 +1,56 @@
+## KOTLIN-SPECIFIC GUIDELINES
+
+You are working in a **Kotlin** codebase. Apply these principles with zero exceptions.
+
+### Coroutines — Structured Concurrency
+- Use `suspend` functions for async operations — never use callbacks when coroutines are available
+- Use `CoroutineScope` properly — never use `GlobalScope` in production code
+- Use `viewModelScope` (Android) or `CoroutineScope(SupervisorJob())` for scoped work
+- Use `withContext(Dispatchers.IO)` for I/O operations, `Dispatchers.Default` for CPU-intensive work
+- Use `async/await` for parallel decomposition, `launch` for fire-and-forget
+- Handle cancellation: check `isActive` in long-running loops, catch `CancellationException` only to rethrow
+
+### Sealed Classes & Exhaustive When
+- Use **sealed classes/interfaces** for restricted type hierarchies (state machines, results, events)
+- Use `when` expressions with sealed types — the compiler enforces exhaustive matching
+- Use sealed classes for Result types: `sealed class Result<T> { data class Success<T>(val data: T) : Result<T>(); ... }`
+- Prefer sealed interfaces (Kotlin 1.5+) over sealed classes when state doesn't need to be stored
+
+### Null Safety — The Kotlin Advantage
+- Use `?` for nullable types, non-nullable is the default — respect the type system
+- Use `?.` (safe call), `?:` (Elvis), `?.let {}` for null handling
+- **Never use `!!`** (not-null assertion) in production code — it's a crash waiting to happen
+- Use `requireNotNull()` or `checkNotNull()` with descriptive messages for preconditions
+- Use `filterNotNull()` and `mapNotNull()` for collections
+
+### Extension Functions
+- Use extension functions for adding behavior to types you don't own
+- Keep extensions close to their usage — don't create a giant `Extensions.kt` dump file
+- Use extension properties for computed values: `val String.isEmail: Boolean get() = ...`
+- Scope extensions: define them in the file/class where they're used, not globally
+
+### Data Classes & Value Objects
+- Use `data class` for all DTOs and value objects — automatic `equals()`, `hashCode()`, `copy()`, `toString()`
+- Use `copy()` for non-destructive updates: `val updated = user.copy(name = "New")`
+- Use `value class` (inline class) for type-safe wrappers: `value class UserId(val value: String)`
+- Destructuring: `val (name, email) = user`
+
+### Code Style
+- Use expression bodies for simple functions: `fun double(x: Int) = x * 2`
+- Use `apply`, `also`, `let`, `run`, `with` scope functions — but don't nest them
+- Use `object` for singletons and companion factories
+- Use `typealias` for complex generic types: `typealias UserMap = Map<UserId, User>`
+- Use `require()` and `check()` for preconditions and state validation
+
+### Naming Conventions
+- `camelCase` for functions, properties, variables
+- `PascalCase` for classes, interfaces, objects, enums
+- `UPPER_SNAKE_CASE` for constants (`const val` or `@JvmField val`)
+- Boolean properties: `is*`, `has*`, `can*`
+- Factory functions: `PascalCase` matching the return type: `fun User(name: String) = User(name, ...)`
+
+### Testing Considerations
+- Use constructor injection for testability
+- Use `runTest` (coroutine test) for testing suspend functions
+- Use `MockK` or project's mocking framework conventions
+- Prefer deterministic code — accept `Clock` parameter instead of `Instant.now()`

package/build/templates/overlays/coder-nextjs.mdx

@@ -0,0 +1,65 @@
+## NEXT.JS-SPECIFIC GUIDELINES
+
+You are working in a **Next.js** codebase. Apply these principles with zero exceptions.
+
+### App Router — The Default (Next.js 13+)
+- Use the **App Router** (`app/` directory) — not Pages Router, unless the project explicitly uses it
+- Understand the file conventions: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `not-found.tsx`
+- Use `route.ts` for API routes in the App Router
+- Layouts persist across navigations — put shared UI (nav, sidebar) in layouts
+- Use `template.tsx` only when you need re-mounting on navigation (rare)
+
+### Server Components — Default Rendering
+- **All components are Server Components by default** — only add `'use client'` when you NEED client interactivity
+- Server Components can: fetch data directly, access backend, read fs, use async/await at component level
+- Client Components need `'use client'` directive when using: hooks, event handlers, browser APIs, state
+- **Minimize `'use client'`** — push it as far down the tree as possible
+- Never add `'use client'` to a layout unless absolutely necessary — it makes all children client components
+
+### Data Fetching
+- Use `async` Server Components for data fetching — direct `await` in the component body
+- Use **Server Actions** (`'use server'`) for mutations — form submissions, data writes
+- Use `fetch()` in Server Components with Next.js caching: `fetch(url, { cache: 'force-cache' })` or `{ next: { revalidate: 3600 } }`
+- Use `unstable_cache` or `cache()` from React for caching expensive operations
+- Never use `getServerSideProps` / `getStaticProps` in App Router — those are Pages Router patterns
+
+### Rendering Strategies
+- **Static (SSG):** Default for pages without dynamic data. Use `generateStaticParams()` for dynamic routes
+- **Dynamic (SSR):** Add `export const dynamic = 'force-dynamic'` or use `cookies()`, `headers()`, `searchParams`
+- **ISR:** Use `{ next: { revalidate: N } }` in fetch or `export const revalidate = N` in page/layout
+- Choose the least dynamic option that works — static > ISR > SSR
+
+### Routing & Navigation
+- Use `next/link` for client-side navigation — never `<a>` for internal links
+- Use `next/navigation` hooks: `useRouter()`, `usePathname()`, `useSearchParams()` — not `next/router`
+- Use dynamic routes: `app/users/[id]/page.tsx` — access via `params` prop
+- Use route groups `(group)` for organizing without affecting URL structure
+- Use parallel routes `@slot` and intercepting routes `(.)` for advanced patterns
+
+### Image & Asset Optimization
+- Use `next/image` for all images — automatic optimization, lazy loading, responsive sizing
+- Use `next/font` for fonts — automatic self-hosting, no layout shift
+- Set `width` and `height` or use `fill` with a sized container — prevent layout shift
+- Use `priority` prop for above-the-fold images (LCP optimization)
+
+### Middleware
+- Use `middleware.ts` at the project root for: auth guards, redirects, geolocation, A/B testing
+- Keep middleware fast — it runs on every request. No heavy computation or database queries
+- Use `matcher` config to limit which routes trigger middleware
+
+### Environment Variables
+- `NEXT_PUBLIC_*` — exposed to the browser (public). Use for: API URLs, feature flags
+- Variables without prefix — server-only. Use for: secrets, database URLs, API keys
+- Access in Server Components directly from `process.env`
+- Access in Client Components only via `process.env.NEXT_PUBLIC_*`
+
+### Naming Conventions
+- File-based routing: `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`
+- Components: `PascalCase` — `UserProfile.tsx`
+- Server Actions: `camelCase` with descriptive names — `createUser`, `deletePost`
+- API routes: `route.ts` with exported HTTP method handlers: `GET`, `POST`, `PUT`, `DELETE`
+
+### Testing Considerations
+- Separate server and client component logic for testability
+- Use server actions as the boundary for testing mutations
+- Mock `next/navigation` hooks in component tests

package/build/templates/overlays/coder-python.mdx

@@ -0,0 +1,53 @@
+## PYTHON-SPECIFIC GUIDELINES
+
+You are working in a **Python** codebase. Apply these principles with zero exceptions.
+
+### Code Style — PEP 8 Strictly
+- Follow **PEP 8** without exception — use the project's formatter config if present (black, ruff, autopep8)
+- **Type hints on ALL function signatures** (PEP 484) — parameters AND return types
+- Use `from __future__ import annotations` at the top of every file for modern type hint syntax
+- **Google-style docstrings** on all public functions — include Args, Returns, Raises sections
+- Max line length: follow project config, default to 88 (black) or 79 (PEP 8)
+
+### Type Safety
+- Use `TypedDict` for structured dictionaries instead of `Dict[str, Any]`
+- Use `Protocol` for structural typing (duck typing with type safety)
+- Use `Optional[X]` explicitly — never rely on implicit `None` default
+- Use `Literal` types for fixed string/int values
+- Use `@overload` decorator for functions with multiple signatures
+- Prefer `dataclasses` or **Pydantic** for data structures over raw dicts or tuples
+- Use `Final` for constants: `MAX_RETRIES: Final = 3`
+
+### Error Handling
+- **Custom exception classes** for domain-specific errors — inherit from a base app exception
+- Use `contextlib.contextmanager` or `contextlib.asynccontextmanager` for resource management
+- **Never bare `except:`** — always specify the exception type
+- Use `except Exception as e:` at minimum, prefer specific exceptions
+- Chain exceptions with `raise NewError(...) from original_error`
+- Use `logging` module, never `print()` for error reporting
+
+### Imports & Structure
+- Import grouping: **stdlib → third-party → local** (separated by blank lines)
+- Use **absolute imports** — never relative imports unless in a package's `__init__.py`
+- Use `__all__` to define the public API of modules
+- Never use `from module import *` — always import specific names
+
+### Patterns
+- Prefer **pathlib.Path** over `os.path` for file operations
+- Use **f-strings** over `.format()` or `%` formatting
+- Use **generators** and `yield` for large sequences — avoid loading everything into memory
+- Use `enumerate()` instead of manual index tracking
+- Use `collections.defaultdict`, `collections.Counter` when appropriate
+- Use `functools.lru_cache` or `functools.cache` for expensive pure function calls
+- Prefer list/dict/set **comprehensions** over `map()`/`filter()` for readability
+
+### Async Code (if applicable)
+- Use `async/await` consistently — never mix sync and async in the same function
+- Use `asyncio.gather()` for concurrent operations
+- Use `aiofiles` for async file I/O if the project uses it
+- Always handle `asyncio.CancelledError` properly
+
+### Testing Considerations
+- Write code that is **easily testable** — pure functions, dependency injection
+- Use `pytest` fixtures and parametrize for clean test setup
+- Prefer deterministic code — accept `datetime` params instead of calling `datetime.now()` directly

package/build/templates/overlays/coder-react.mdx

@@ -0,0 +1,55 @@
+## REACT-SPECIFIC GUIDELINES
+
+You are working in a **React** codebase. Apply these principles with zero exceptions.
+
+### Component Patterns — Functional Only
+- **Always use functional components** — never class components for new code
+- Keep components focused — if >150 lines, extract subcomponents
+- Use composition over prop drilling: split into Container + Presentation components when logic is complex
+- Export components as named exports: `export function UserCard() {}` — not default exports
+- Co-locate related files: component, styles, tests, types in the same directory
+
+### Hooks Rules — NON-NEGOTIABLE
+- Hooks only at the **top level** — never inside conditions, loops, or nested functions
+- Hooks only in **function components** or **custom hooks** — never in regular functions
+- Custom hooks start with `use`: `useAuth()`, `useFetchUser()`
+- Keep custom hooks focused on one responsibility — compose hooks, don't create mega-hooks
+- Always provide proper dependency arrays for `useEffect`, `useMemo`, `useCallback`
+
+### State Management
+- Use `useState` for simple local state
+- Use `useReducer` for complex state with multiple related updates
+- Use **React Context** for truly global state (theme, auth, locale) — not for all shared state
+- Avoid prop drilling >2 levels — extract to context or composition pattern
+- State should live as close to where it's used as possible — lift only when necessary
+- Never derive state from props in `useState` — compute it directly or use `useMemo`
+
+### Performance — When to Optimize
+- **Don't wrap everything in `memo`/`useMemo`/`useCallback`** — only optimize when there's a measured problem
+- Use `React.memo()` when: component renders often with same props, rendering is expensive
+- Use `useMemo()` when: computation is expensive AND dependencies change infrequently
+- Use `useCallback()` when: passing callbacks to memoized child components
+- Use `key` prop correctly — stable, unique IDs from data (never array index for dynamic lists)
+
+### Error Boundaries
+- Wrap major sections in error boundaries — prevent one component crash from taking down the page
+- Use `react-error-boundary` or create a class-based boundary (the one exception to "no classes")
+- Show meaningful fallback UI — not a blank page
+
+### React 19+ Patterns (if applicable)
+- Use `use()` hook for reading resources (promises, contexts)
+- Use `useActionState()` for form actions with pending state
+- Use `useOptimistic()` for optimistic UI updates
+- Use `<form action={}>` with server actions where available
+
+### Naming Conventions
+- `PascalCase` for components: `UserProfile`, `LoginForm`
+- `camelCase` for hooks: `useAuth`, `useFetchData`
+- `camelCase` for event handlers with `handle` prefix: `handleClick`, `handleSubmit`
+- `on` prefix for callback props: `onClick`, `onSubmit`, `onChange`
+- Boolean props: `is*`, `has*`, `should*`: `isLoading`, `hasError`
+
+### Testing Considerations
+- Write components that are testable — props in, rendered output out
+- Use data-testid attributes for test selectors (not CSS classes or element structure)
+- Prefer composition and dependency injection over hard-coded dependencies

package/build/templates/overlays/coder-ruby.mdx

@@ -0,0 +1,59 @@
+## RUBY-SPECIFIC GUIDELINES
+
+You are working in a **Ruby** codebase. Apply these principles with zero exceptions.
+
+### Ruby Idioms
+- Write **idiomatic Ruby** — use the language's expressiveness, not Java-in-Ruby
+- Use `attr_reader`, `attr_writer`, `attr_accessor` — don't write manual getters/setters
+- Use **guard clauses** for early returns: `return unless valid?` instead of wrapping in `if`
+- Prefer `unless` for single negative conditions — but never `unless...else` (use `if` instead)
+- Use **string interpolation** `"Hello #{name}"` over concatenation
+- Use `freeze` on string constants: `DEFAULT_NAME = "guest".freeze`
+
+### Blocks, Procs & Lambdas
+- Use `&block` parameter when you need to store or pass the block
+- Use `yield` when you just need to call the block inline
+- Prefer **lambdas** over procs — lambdas check arity and use `return` predictably
+- Use `Proc.new` / `proc {}` only when you need proc-specific behavior
+- Use `.map`, `.select`, `.reject`, `.reduce` — avoid manual iteration with `each` + accumulator
+
+### Gem Conventions
+- Follow the project's Gemfile conventions — respect existing gem choices
+- Use `bundler` — never install gems globally for project dependencies
+- Pin gem versions in production: `gem 'rails', '~> 7.1'`
+- Prefer well-maintained gems with active communities — check GitHub activity
+
+### Duck Typing & Protocols
+- Ruby uses **duck typing** — respond to methods, don't check types
+- Use `respond_to?(:method)` instead of `is_a?(ClassName)` when possible
+- Define clear method interfaces — document expected duck type in comments
+- Use modules for shared behavior: `include Enumerable` with `each` defined
+
+### Error Handling
+- Rescue specific exceptions, not bare `rescue` (catches `StandardError`)
+- Create custom exception classes inheriting from `StandardError`
+- Use `begin/rescue/ensure` blocks — `ensure` for cleanup
+- Use `raise` with message: `raise ArgumentError, "name cannot be blank"`
+- Never rescue `Exception` — it catches `SystemExit`, `SignalException`, etc.
+
+### Code Structure
+- Follow existing project conventions (Rails, Sinatra, plain Ruby)
+- Use modules for namespacing: `module MyApp::Services`
+- Keep methods short — if >15 lines, consider extracting
+- Use `frozen_string_literal: true` magic comment at top of files
+- Follow project's Ruby version and style guide (rubocop config)
+
+### Naming Conventions
+- `snake_case` for methods, variables, file names
+- `PascalCase` for classes and modules
+- `UPPER_SNAKE_CASE` for constants
+- Predicate methods end with `?`: `valid?`, `empty?`, `admin?`
+- Dangerous methods end with `!`: `save!`, `destroy!`, `sort!`
+- Setter methods end with `=`: `name=`
+
+### RSpec Patterns (if project uses RSpec)
+- Use `describe`/`context`/`it` hierarchy for clear test structure
+- Use `let` (lazy) and `let!` (eager) for test data — not instance variables
+- Use `subject` for the object under test
+- Use `shared_examples` for reusable test patterns
+- Prefer `expect(x).to eq(y)` over `assert_equal y, x`

package/build/templates/overlays/coder-rust.mdx

@@ -0,0 +1,48 @@
+## RUST-SPECIFIC GUIDELINES
+
+You are working in a **Rust** codebase. Apply these principles with zero exceptions.
+
+### Ownership & Borrowing — THE CORE RULES
+- Prefer **borrowing** (`&T`, `&mut T`) over taking ownership when the function doesn't need to own the data
+- Use `Clone` sparingly — it's a code smell if you're cloning to satisfy the borrow checker. Restructure instead
+- Prefer `&str` over `String` in function parameters — accept the most general form
+- Use `Cow<'_, str>` when a function might or might not need to allocate
+- Understand and respect lifetimes — don't sprinkle `'static` to make errors go away
+
+### Error Handling — Result/Option Everywhere
+- Use `Result<T, E>` for fallible operations — **never panic** in library code
+- Use `thiserror` for library error types, `anyhow` for application error types
+- Use the `?` operator for error propagation — avoid manual `match` on `Result` when `?` suffices
+- Create domain-specific error enums with `#[derive(thiserror::Error)]`
+- Use `Option<T>` for values that may not exist — never use sentinel values
+- Chain with `.map()`, `.and_then()`, `.unwrap_or_default()` — avoid nested `match` blocks
+
+### Unsafe Isolation
+- **Minimize `unsafe` blocks** — wrap unsafe operations in safe abstractions
+- Document every `unsafe` block with a `// SAFETY:` comment explaining why it's sound
+- Never expose raw pointers in public APIs — wrap in safe types
+
+### Code Quality
+- Run `cargo clippy` — treat all warnings as errors
+- Run `cargo fmt` — never deviate from project formatting
+- Use `#[derive(Debug, Clone, PartialEq)]` on all data types unless there's a reason not to
+- Prefer `impl Trait` in argument position over generic constraints when there's only one trait bound
+- Use `#[must_use]` on functions that return values that shouldn't be ignored
+
+### Patterns
+- Use **builder pattern** for complex struct construction
+- Use `enum` with variants for state machines — not boolean flags
+- Prefer iterators and combinators (`.iter().map().filter().collect()`) over manual loops
+- Use `Default` trait for structs with sensible defaults
+- Use `From`/`Into` traits for type conversions — avoid custom conversion functions
+
+### Naming Conventions
+- `snake_case` for functions, methods, variables, modules
+- `PascalCase` for types, traits, enums
+- `UPPER_SNAKE_CASE` for constants and statics
+- Prefix boolean methods with `is_`, `has_`, `can_`
+
+### Testing Considerations
+- Write code that is testable — use trait objects or generics for dependency injection
+- Use `#[cfg(test)]` module for unit tests within the same file
+- Prefer deterministic code — accept timestamps/randomness as parameters