opencode-conductor-plugin 1.1.0

package/dist/templates/code_styleguides/php.md

@@ -0,0 +1,37 @@
+# PHP Style Guide Summary (PSR-12)
+
+This document summarizes key rules from the PSR-12 Extended Coding Style Guide, which is the current standard for the PHP community.
+
+## 1. Files and Basic Standards
+- **PHP Tag**: Use only `<?php` or `<?=`.
+- **Encoding**: UTF-8 without BOM.
+- **Side Effects**: A file should either declare symbols (classes, functions, constants, etc.) or cause side effects, but not both.
+- **Indentation**: 4 spaces.
+
+## 2. Naming Conventions
+- **Classes**: `UpperCamelCase` (e.g., `UserMapper`).
+- **Methods**: `lowerCamelCase` (e.g., `getUserData`).
+- **Constants**: `CONSTANT_CASE` (e.g., `MAX_RETRIES`).
+- **Properties**: `lowerCamelCase` (preferred) or `snake_case` (be consistent).
+
+## 3. Structure and Layout
+- **Namespaces**: One declaration per line.
+- **Imports**: Use `use` for imports. Group imports by type (classes, functions, constants).
+- **Visibility**: Always declare visibility (`public`, `protected`, `private`) for properties and methods.
+- **Strict Types**: Use `declare(strict_types=1);` at the top of every file.
+
+## 4. Control Structures
+- **Braces**: Opening brace on the same line for control structures, but on a new line for classes and methods (PSR style).
+- **Conditionals**: Always use curly braces, even for one-line blocks.
+- **Spaces**: One space after the control structure keyword, no space after the opening parenthesis.
+
+## 5. Functions and Methods
+- **Type Hinting**: Always use type hints for parameters and return types.
+- **Nullables**: Use `?Type` or `Type | null` for nullable types.
+- **Return Type**: The colon and type should follow the closing parenthesis with a space.
+
+## 6. Documentation (DocBlocks)
+- Use standard PHPDoc `/** ... */` for documenting classes, methods, and properties.
+- Include `@param` and `@return` tags with specific types.
+
+*Source: [PHP-FIG PSR-12](https://www.php-fig.org/psr/psr-12/)*

package/dist/templates/code_styleguides/python.md

@@ -0,0 +1,37 @@
+# Google Python Style Guide Summary
+
+This document summarizes key rules and best practices from the Google Python Style Guide.
+
+## 1. Python Language Rules
+- **Linting:** Run `pylint` on your code to catch bugs and style issues.
+- **Imports:** Use `import x` for packages/modules. Use `from x import y` only when `y` is a submodule.
+- **Exceptions:** Use built-in exception classes. Do not use bare `except:` clauses.
+- **Global State:** Avoid mutable global state. Module-level constants are okay and should be `ALL_CAPS_WITH_UNDERSCORES`.
+- **Comprehensions:** Use for simple cases. Avoid for complex logic where a full loop is more readable.
+- **Default Argument Values:** Do not use mutable objects (like `[]` or `{}`) as default values.
+- **True/False Evaluations:** Use implicit false (e.g., `if not my_list:`). Use `if foo is None:` to check for `None`.
+- **Type Annotations:** Strongly encouraged for all public APIs.
+
+## 2. Python Style Rules
+- **Line Length:** Maximum 80 characters.
+- **Indentation:** 4 spaces per indentation level. Never use tabs.
+- **Blank Lines:** Two blank lines between top-level definitions (classes, functions). One blank line between method definitions.
+- **Whitespace:** Avoid extraneous whitespace. Surround binary operators with single spaces.
+- **Docstrings:** Use `"""triple double quotes"""`. Every public module, function, class, and method must have a docstring.
+  - **Format:** Start with a one-line summary. Include `Args:`, `Returns:`, and `Raises:` sections.
+- **Strings:** Use f-strings for formatting. Be consistent with single (`'`) or double (`"`) quotes.
+- **`TODO` Comments:** Use `TODO(username): Fix this.` format.
+- **Imports Formatting:** Imports should be on separate lines and grouped: standard library, third-party, and your own application's imports.
+
+## 3. Naming
+- **General:** `snake_case` for modules, functions, methods, and variables.
+- **Classes:** `PascalCase`.
+- **Constants:** `ALL_CAPS_WITH_UNDERSCORES`.
+- **Internal Use:** Use a single leading underscore (`_internal_variable`) for internal module/class members.
+
+## 4. Main
+- All executable files should have a `main()` function that contains the main logic, called from a `if __name__ == '__main__':` block.
+
+**BE CONSISTENT.** When editing code, match the existing style.
+
+*Source: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)*

package/dist/templates/code_styleguides/react.md

@@ -0,0 +1,37 @@
+# React Best Practices & Style Guide
+
+This document outlines recommended patterns and styles for building React applications with functional components and hooks.
+
+## 1. Components
+- **Functional Components**: Prefer functional components with Hooks over class components.
+- **Naming**: Use `PascalCase` for component filenames and function names (e.g., `UserProfile.tsx`).
+- **One Component per File**: Each file should export exactly one primary component.
+- **Props**:
+  - Use TypeScript interfaces/types for prop definitions.
+  - Destructure props in the function signature for clarity.
+  - Provide default values using ES6 default parameters.
+
+## 2. Hooks
+- **Rules of Hooks**: Follow the official rules (only call at top level, only in React functions).
+- **Custom Hooks**: Extract complex logic into custom hooks (`useSomeLogic`). Name them with the `use` prefix.
+- **Dependencies**: Be exhaustive with dependency arrays in `useEffect`, `useMemo`, and `useCallback`.
+
+## 3. Styling
+- **CSS-in-JS / Modules**: Prefer CSS Modules or a utility-first framework like Tailwind CSS over global CSS.
+- **Conditional Classes**: Use a utility like `clsx` or `classnames` for managing conditional class strings.
+
+## 4. State Management
+- **Local State**: Use `useState` for simple, component-specific state.
+- **Complex State**: Use `useReducer` for more complex state logic or when state transitions depend on previous state.
+- **Context API**: Use `useContext` for sharing state that is "global" to a tree of components (e.g., theme, user session).
+
+## 5. Patterns
+- **Container/Presenter**: While less strict now, keep data fetching/logic separate from pure presentation components where it improves testability.
+- **Composition**: Prefer component composition (`children` prop) over deep prop drilling.
+- **Early Returns**: Use early returns for conditional rendering (e.g., loading or error states).
+
+## 6. Performance
+- **useMemo/useCallback**: Use sparingly. Only memoize when profiling shows a performance bottleneck or when passing objects/functions to memoized child components.
+- **Fragment**: Use `<React.Fragment>` or `<>` to avoid unnecessary DOM nodes.
+
+*Source: [Official React Documentation](https://react.dev/)*

package/dist/templates/code_styleguides/ruby.md

@@ -0,0 +1,39 @@
+# Ruby Style Guide Summary
+
+This document summarizes key rules and best practices for Ruby development, largely based on the community-driven Ruby Style Guide and RuboCop defaults.
+
+## 1. Source Code Layout
+- **Indentation**: 2 spaces per indentation level.
+- **Line Length**: Limit lines to 80 characters where possible.
+- **Spaces**: Use spaces around operators, after commas, colons, and semicolons.
+- **Newlines**: End each file with a single newline.
+
+## 2. Naming Conventions
+- **Classes and Modules**: `UpperCamelCase`.
+- **Methods and Variables**: `snake_case`.
+- **Constants**: `SCREAMING_SNAKE_CASE`.
+- **Predicate Methods**: Methods returning booleans should end with a question mark (e.g., `is_empty?`).
+- **Bang Methods**: Methods that modify the receiver or are "dangerous" should end with an exclamation mark (e.g., `save!`).
+
+## 3. Syntax and Style
+- **Quoting**: Prefer single quotes (`'`) for strings that don't require interpolation or special characters.
+- **Interpolation**: Use `#{expression}` for string interpolation.
+- **Arrays**: Prefer the literal syntax `[]`. Use `%w()` for arrays of words.
+- **Hashes**: Use the Ruby 1.9+ syntax `key: value` for symbol keys.
+- **Conditionals**: Avoid `then` in `if/unless` statements. Use `unless` instead of `if !condition`.
+- **Method Definitions**: Use parentheses when a method has parameters. Omit them when it doesn't.
+
+## 4. Collections
+- **Iteration**: Prefer `each` over `for`.
+- **Transformation**: Use `map`, `select`, `reduce` for collection operations.
+- **Selection**: Use `find` or `detect` to find a single element.
+
+## 5. Exceptions
+- **Control Flow**: Avoid using exceptions for control flow.
+- **Rescue**: Be specific about the exception classes you rescue. Never rescue `Exception` (rescue `StandardError` instead).
+
+## 6. Documentation
+- **Comments**: Use `#` for comments.
+- **Yard**: Use YARD-style documentation tags for methods and classes.
+
+*Source: [The Ruby Style Guide](https://rubystyle.guide/)*

package/dist/templates/code_styleguides/rust.md

@@ -0,0 +1,44 @@
+# Rust Style Guide Summary
+
+This document summarizes key rules and best practices for Rust development, based on the official Rust style guidelines and common idiomatic patterns.
+
+## 1. Naming Conventions
+- **`UpperCamelCase`**: Types (structs, enums, traits), type aliases, and enum variants.
+- **`snake_case`**: Crates, modules, functions, methods, variables, and arguments.
+- **`SCREAMING_SNAKE_CASE`**: Statics and constants.
+- **`T` (Single Letter)**: Type parameters (e.g., `<T>`, `<U>`).
+
+## 2. Formatting (Rustfmt)
+- Use 4-space indentation.
+- Maximum line width: 100 characters.
+- Use curly braces for all `if`, `else`, `while`, and `loop` blocks.
+- Place the opening brace on the same line as the declaration.
+
+## 3. Idiomatic Patterns
+- **Pattern Matching**: Prefer `match` or `if let` over complex nested `if` statements.
+- **Error Handling**: 
+  - Use `Result<T, E>` for recoverable errors and `Option<T>` for optional values.
+  - Use the `?` operator for concise error propagation.
+  - Avoid `unwrap()` and `expect()` in production code unless a panic is truly intended.
+- **Ownership and Borrowing**:
+  - Prefer immutable borrows (`&T`) by default.
+  - Use mutable borrows (`&mut T`) only when necessary.
+  - Avoid unnecessary cloning; prefer passing references.
+- **Iterators**: Use iterator methods (`map`, `filter`, `fold`, etc.) instead of manual loops where it improves clarity.
+
+## 4. Documentation
+- Use `///` for documentation comments on items (functions, structs, etc.).
+- Use `//!` for module-level or crate-level documentation.
+- Documentation should include an "Examples" section using markdown code blocks.
+- Markdown is supported and encouraged in doc comments.
+
+## 5. Attributes and Macros
+- Use `#[derive(...)]` for common traits like `Debug`, `Clone`, `PartialEq`, and `Serialize`.
+- Keep macros simple and well-documented. Avoid complex macro logic where regular functions suffice.
+
+## 6. Dependencies (Cargo.toml)
+- Be explicit with versioning.
+- Periodically run `cargo update` and `cargo audit` to manage security vulnerabilities.
+- Prefer small, focused crates over large "kitchen sink" dependencies.
+
+*Source: [Official Rust Style Guidelines](https://github.com/rust-lang/rust/tree/master/src/doc/style-guide)*

package/dist/templates/code_styleguides/shell.md

@@ -0,0 +1,35 @@
+# Shell Style Guide Summary (Bash)
+
+This document outlines best practices for writing clean, safe, and maintainable shell scripts, based on the Google Shell Style Guide and common idiomatic patterns.
+
+## 1. General Principles
+- **Shebang**: Use `#!/bin/bash` or `#!/usr/bin/env bash`.
+- **Portability**: If you don't need Bash-specific features, use `#!/bin/sh`.
+- **Fail Fast**: Use `set -euo pipefail` at the beginning of scripts to exit on errors, unset variables, and pipeline failures.
+
+## 2. Naming Conventions
+- **Files**: `snake_case` with `.sh` extension.
+- **Variables**: `snake_case` for local variables. `UPPERCASE` for constants and environment variables.
+- **Functions**: `snake_case`.
+
+## 3. Formatting
+- **Indentation**: 2 spaces.
+- **Line Length**: Limit to 80 characters where possible.
+- **Functions**: Use the standard `function_name() { ... }` syntax.
+
+## 4. Safety and Robustness
+- **Quoting**: Always quote variables that contain filenames or user input (e.g., `"$file"`) to prevent word splitting and globbing.
+- **Command Substitution**: Use `$(command)` instead of backticks.
+- **Conditionals**: Use `[[ ... ]]` instead of `[ ... ]` or `test` for Bash scripts.
+- **Local Variables**: Always use the `local` keyword inside functions.
+
+## 5. Idiomatic Patterns
+- **Main Function**: Put the script logic in a `main` function and call it at the bottom.
+- **Logging**: Use a dedicated `log` or `error` function for consistent output.
+- **Check for Existence**: Always check if a command exists before using it (e.g., `command -v git >/dev/null 2>&1`).
+
+## 6. Documentation
+- **Header**: Include a brief description, usage examples, and author information at the top of the script.
+- **Comments**: Use `#` to explain *why* complex commands are used.
+
+*Source: [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)*

package/dist/templates/code_styleguides/solidity.md

@@ -0,0 +1,60 @@
+# Solidity Style Guide Summary
+
+This document summarizes key rules and best practices for Solidity development, based on the official Solidity Style Guide and industry standards from OpenZeppelin and ConsenSys.
+
+## 1. Source File Organization
+- **License Identifier**: Every source file should start with a machine-readable SPDX license identifier (e.g., `// SPDX-License-Identifier: MIT`).
+- **Pragma**: Use a specific compiler version (e.g., `pragma solidity 0.8.20;`) rather than a floating pragma (`^0.8.20`) for deployed contracts to ensure deterministic builds.
+- **Layout Order**:
+  1. License Identifier
+  2. Pragma statements
+  3. Import statements
+  4. Interfaces
+  5. Libraries
+  6. Contracts
+
+## 2. Contract Layout
+Inside each contract, library, or interface, use the following order:
+1. Type declarations (enums, structs)
+2. State variables
+3. Events
+4. Modifiers
+5. Functions
+
+**Function Order**:
+- Constructor
+- Receive function (if exists)
+- Fallback function (if exists)
+- External
+- Public
+- Internal
+- Private
+
+## 3. Naming Conventions
+- **Contracts & Libraries**: `UpperCamelCase` (e.g., `SimpleToken`).
+- **Structs & Enums**: `UpperCamelCase` (e.g., `UserAccount`).
+- **Events**: `UpperCamelCase` (e.g., `Transfer`).
+- **Functions**: `lowerCamelCase` (e.g., `getBalance`).
+- **Function Arguments**: `lowerCamelCase` (e.g., `_address`).
+- **Local & State Variables**: `lowerCamelCase` (e.g., `accountBalance`).
+- **Constants**: `UPPER_CASE_WITH_UNDERSCORES` (e.g., `MAX_SUPPLY`).
+- **Modifiers**: `lowerCamelCase` (e.g., `onlyOwner`).
+- **Private/Internal**: It is common practice to prefix internal or private state variables and functions with an underscore (e.g., `_balances`).
+
+## 4. Security Best Practices
+- **Checks-Effects-Interactions**: Always follow this pattern to prevent reentrancy attacks.
+  1. **Checks**: Validate inputs and conditions (e.g., `require`).
+  2. **Effects**: Update the contract state (e.g., update balances).
+  3. **Interactions**: Interact with other contracts (e.g., `transfer` or external calls).
+- **Visibility**: Always explicitly define visibility for all functions (`external`, `public`, `internal`, or `private`).
+- **Error Handling**: Use `revert CustomError()` (Solidity 0.8.4+) for gas efficiency instead of string-based `require`.
+- **Overflow/Underflow**: Use Solidity 0.8.0+ which has built-in overflow checks, or `SafeMath` for older versions.
+
+## 5. Documentation (NatSpec)
+Use Ethereum Natural Language Specification (NatSpec) for all public and external interfaces:
+- `/// @notice`: Explain to an end user what this does.
+- `/// @dev`: Explain to a developer any extra details.
+- `/// @param`: Document a parameter.
+- `/// @return`: Document a return value.
+
+*Source: [Solidity Documentation - Style Guide](https://docs.soliditylang.org/en/latest/style-guide.html)*

package/dist/templates/code_styleguides/sql.md

@@ -0,0 +1,39 @@
+# SQL Style Guide Summary
+
+This document outlines best practices for writing clean, readable, and maintainable SQL queries and schema definitions.
+
+## 1. Keywords and Naming
+- **Keywords**: Use `UPPERCASE` for all SQL keywords (e.g., `SELECT`, `FROM`, `WHERE`).
+- **Identifiers**: Use `snake_case` for all table names, column names, and other identifiers.
+- **Singular vs Plural**: Prefer singular table names (e.g., `user` instead of `users`).
+- **Reserved Words**: Never use reserved SQL keywords as identifiers.
+
+## 2. Query Structure
+- **Formatting**:
+  - One major clause per line (`SELECT`, `FROM`, `JOIN`, `WHERE`, `GROUP BY`, `ORDER BY`).
+  - Indent subclauses (e.g., inside `WHERE` or `JOIN`) for clarity.
+- **Columns**: Explicitly list all columns in `SELECT` statements. Avoid `SELECT *` in production code.
+- **Joins**: 
+  - Use explicit `JOIN` syntax (e.g., `INNER JOIN`, `LEFT JOIN`).
+  - Use the `ON` clause for join conditions.
+- **Aliases**: Use descriptive aliases for tables, especially in multi-table joins.
+
+## 3. Data Types and Constraints
+- **Consistency**: Use consistent data types across the schema.
+- **Constraints**: 
+  - Always define a `PRIMARY KEY`.
+  - Use `FOREIGN KEY` constraints to enforce referential integrity.
+  - Use `NOT NULL` where appropriate.
+  - Use `DEFAULT` values instead of allowing `NULL` where a sensible default exists.
+
+## 4. Performance and Best Practices
+- **Indexing**: Create indexes on columns used in `WHERE`, `JOIN`, and `ORDER BY` clauses.
+- **Transactions**: Use transactions for multi-step operations to ensure atomicity.
+- **Comments**: Use `--` for single-line comments and `/* ... */` for block comments to explain complex logic.
+
+## 5. Migrations
+- **Incremental**: Apply schema changes through version-controlled migration files.
+- **Idempotent**: Ensure migrations are idempotent where possible (though typically managed by a tool).
+- **Rollback**: Always include a rollback path for schema changes.
+
+*Source: [SQL Style Guide (General Best Practices)](https://www.sqlstyle.guide/)*

package/dist/templates/code_styleguides/swift.md

@@ -0,0 +1,36 @@
+# Swift Style Guide Summary
+
+This document summarizes key rules and best practices for Swift development, based on the official Swift API Design Guidelines and common community standards.
+
+## 1. Naming Conventions
+- **Types (Structs, Classes, Enums, Protocols)**: `UpperCamelCase`.
+- **Functions, Variables, Arguments**: `lowerCamelCase`.
+- **Enum Variants**: `lowerCamelCase`.
+- **Clarity over Brevity**: Prefer descriptive names over short ones (e.g., `remove(at:)` instead of `delete()`).
+
+## 2. Formatting
+- **Indentation**: 4 spaces (standard for Xcode/Swift).
+- **Line Width**: Limit to 100-120 characters.
+- **Braces**: Opening brace on the same line as the declaration.
+
+## 3. Optionals and Control Flow
+- **Optional Binding**: Prefer `if let` or `guard let` over `!` (force unwrap).
+- **Early Exit**: Use `guard` statements to keep the main logic at the lowest indentation level.
+- **Switch Statements**: Always include a `default` case unless all cases are exhaustively covered.
+
+## 4. Idiomatic Swift
+- **Type Inference**: Rely on Swift's type inference for local variables.
+- **Structs vs Classes**: Prefer `struct` by default. Use `class` only when you need reference semantics or inheritance.
+- **Extensions**: Use `extension` to group related functionality or implement protocols.
+- **Trailing Closures**: Use trailing closure syntax when a function's last argument is a closure.
+
+## 5. Error Handling
+- Use `Error` protocol and `throw` for recoverable errors.
+- Use `Result` type for asynchronous error handling.
+- Avoid `try!` unless failure is genuinely impossible.
+
+## 6. Access Control
+- Use `private` or `fileprivate` by default for implementation details.
+- Be explicit about `public` or `internal` (though `internal` is the default).
+
+*Source: [Swift.org API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/)*

package/dist/templates/code_styleguides/typescript.md

@@ -0,0 +1,43 @@
+# Google TypeScript Style Guide Summary
+
+This document summarizes key rules and best practices from the Google TypeScript Style Guide, which is enforced by the `gts` tool.
+
+## 1. Language Features
+- **Variable Declarations:** Always use `const` or `let`. **`var` is forbidden.** Use `const` by default.
+- **Modules:** Use ES6 modules (`import`/`export`). **Do not use `namespace`.**
+- **Exports:** Use named exports (`export {MyClass};`). **Do not use default exports.**
+- **Classes:**
+  - **Do not use `#private` fields.** Use TypeScript's `private` visibility modifier.
+  - Mark properties never reassigned outside the constructor with `readonly`.
+  - **Never use the `public` modifier** (it's the default). Restrict visibility with `private` or `protected` where possible.
+- **Functions:** Prefer function declarations for named functions. Use arrow functions for anonymous functions/callbacks.
+- **String Literals:** Use single quotes (`'`). Use template literals (`` ` ``) for interpolation and multi-line strings.
+- **Equality Checks:** Always use triple equals (`===`) and not equals (`!==`).
+- **Type Assertions:** **Avoid type assertions (`x as SomeType`) and non-nullability assertions (`y!`)**. If you must use them, provide a clear justification.
+
+## 2. Disallowed Features
+- **`any` Type:** **Avoid `any`**. Prefer `unknown` or a more specific type.
+- **Wrapper Objects:** Do not instantiate `String`, `Boolean`, or `Number` wrapper classes.
+- **Automatic Semicolon Insertion (ASI):** Do not rely on it. **Explicitly end all statements with a semicolon.**
+- **`const enum`:** Do not use `const enum`. Use plain `enum` instead.
+- **`eval()` and `Function(...string)`:** Forbidden.
+
+## 3. Naming
+- **`UpperCamelCase`:** For classes, interfaces, types, enums, and decorators.
+- **`lowerCamelCase`:** For variables, parameters, functions, methods, and properties.
+- **`CONSTANT_CASE`:** For global constant values, including enum values.
+- **`_` Prefix/Suffix:** **Do not use `_` as a prefix or suffix** for identifiers, including for private properties.
+
+## 4. Type System
+- **Type Inference:** Rely on type inference for simple, obvious types. Be explicit for complex types.
+- **`undefined` and `null`:** Both are supported. Be consistent within your project.
+- **Optional vs. `|undefined`:** Prefer optional parameters and fields (`?`) over adding `|undefined` to the type.
+- **`Array<T>` Type:** Use `T[]` for simple types. Use `Array<T>` for more complex union types (e.g., `Array<string | number>`).
+- **`{}` Type:** **Do not use `{}`**. Prefer `unknown`, `Record<string, unknown>`, or `object`.
+
+## 5. Comments and Documentation
+- **JSDoc:** Use `/** JSDoc */` for documentation, `//` for implementation comments.
+- **Redundancy:** **Do not declare types in `@param` or `@return` blocks** (e.g., `/** @param {string} user */`). This is redundant in TypeScript.
+- **Add Information:** Comments must add information, not just restate the code.
+
+*Source: [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html)*

package/dist/templates/code_styleguides/vue.md

@@ -0,0 +1,38 @@
+# Vue.js Style Guide Summary
+
+This document summarizes key rules and best practices from the official Vue.js Style Guide, specifically for Vue 3 and the Composition API.
+
+## 1. Component Files
+- **Single File Components (SFC)**: Always use `.vue` files.
+- **Naming**: Use `PascalCase` for component filenames (e.g., `TodoList.vue`).
+- **Structure**: Follow the standard order: `<script setup>`, `<template>`, `<style>`.
+
+## 2. Component Data
+- **Composition API**: Prefer `<script setup>` and the Composition API over the Options API.
+- **Ref vs Reactive**: Use `ref()` for primitive values and `reactive()` for objects/arrays (or `ref()` consistently for both).
+- **Props**: 
+  - Use `defineProps` with TypeScript types.
+  - Props should be used for data passing only (unidirectional flow).
+
+## 3. Template Syntax
+- **Directives**: Use shorthand for `v-bind` (`:`) and `v-on` (`@`).
+- **Key Attribute**: Always use `:key` with `v-for`. Never use an index as a key if the list can change.
+- **Computed Properties**: Use `computed()` for complex logic in templates. Never use method calls for data derived from other reactive state in templates.
+
+## 4. Lifecycle Hooks
+- Use Composition API lifecycle hooks (e.g., `onMounted`, `onUnmounted`) within `setup`.
+- Ensure listeners and timers are cleaned up in `onUnmounted`.
+
+## 5. Global State
+- **Pinia**: Use Pinia for complex global state management.
+- **Provide/Inject**: Use `provide`/`inject` for dependency injection across deeply nested components.
+
+## 6. Styling
+- **Scoped Styles**: Use `<style scoped>` by default to prevent leaking styles.
+- **CSS Variables**: Use reactive CSS variables via `v-bind()` in `<style>` blocks where appropriate.
+
+## 7. Directives & Events
+- **Custom Directives**: Use sparingly. Prefer components for reusable logic.
+- **Emit**: Use `defineEmits` for documenting and typed-checking events.
+
+*Source: [Official Vue.js Style Guide](https://vuejs.org/style-guide/)*

package/dist/templates/code_styleguides/zig.md

@@ -0,0 +1,27 @@
+# Zig Style Guide Summary
+
+This document summarizes key rules and best practices for Zig development, based on the official Zig documentation and common community patterns.
+
+## 1. Naming Conventions
+- **Functions**: `camelCase` (e.g., `initStack`).
+- **Variables**: `camelCase` (e.g., `userCounter`).
+- **Types (Structs, Enums, Unions)**: `PascalCase` (e.g., `MemoryPool`).
+- **Files**: `snake_case.zig` (e.g., `array_list.zig`).
+- **Constants**: `Screaming_Snake_Case` is avoided; prefer `camelCase` or `PascalCase` depending on if it's a value or a type.
+
+## 2. Formatting
+- **Indentation**: 4 spaces.
+- **Line Length**: 100 characters limit.
+- **Braces**: Opening brace on the same line.
+
+## 3. Idiomatic Zig
+- **Error Handling**: Use `error` sets and the `!` operator. Prefer `try` and `catch` for explicit error handling.
+- **Memory Management**: Use `Allocator` explicitly. Avoid global allocators.
+- **Comptime**: Use `comptime` for generic programming and compile-time logic.
+- **Optionals**: Use `?T` for values that can be null. Use `if (maybe_value) |value|` to unwrap.
+
+## 4. Documentation
+- Use `///` for doc comments.
+- Use `//!` for top-level module documentation.
+
+*Source: [Zig Documentation](https://ziglang.org/documentation/master/)*