opencode-conductor-cdd-plugin 1.0.0-beta.13

package/dist/templates/code_styleguides/go.md

@@ -0,0 +1,48 @@
+# Effective Go Style Guide Summary
+
+This document summarizes key rules and best practices from the official "Effective Go" guide for writing idiomatic Go code.
+
+## 1. Formatting
+- **`gofmt`:** All Go code **must** be formatted with `gofmt` (or `go fmt`). This is a non-negotiable, automated standard.
+- **Indentation:** Use tabs for indentation (`gofmt` handles this).
+- **Line Length:** Go has no strict line length limit. Let `gofmt` handle line wrapping.
+
+## 2. Naming
+- **`MixedCaps`:** Use `MixedCaps` or `mixedCaps` for multi-word names. Do not use underscores.
+- **Exported vs. Unexported:** Names starting with an uppercase letter are exported (public). Names starting with a lowercase letter are not exported (private).
+- **Package Names:** Short, concise, single-word, lowercase names.
+- **Getters:** Do not name getters with a `Get` prefix. A getter for a field named `owner` should be named `Owner()`.
+- **Interface Names:** One-method interfaces are named by the method name plus an `-er` suffix (e.g., `Reader`, `Writer`).
+
+## 3. Control Structures
+- **`if`:** No parentheses around the condition. Braces are mandatory. Can include an initialization statement (e.g., `if err := file.Chmod(0664); err != nil`).
+- **`for`:** Go's only looping construct. Unifies `for` and `while`. Use `for...range` to iterate over slices, maps, strings, and channels.
+- **`switch`:** More general than in C. Cases do not fall through by default (use `fallthrough` explicitly). Can be used without an expression to function as a cleaner `if-else-if` chain.
+
+## 4. Functions
+- **Multiple Returns:** Functions can return multiple values. This is the standard way to return a result and an error (e.g., `value, err`).
+- **Named Result Parameters:** Return parameters can be named. This can make code clearer and more concise.
+- **`defer`:** Schedules a function call to be run immediately before the function executing `defer` returns. Use it for cleanup tasks like closing files.
+
+## 5. Data
+- **`new` vs. `make`:**
+  - `new(T)`: Allocates memory for a new item of type `T`, zeroes it, and returns a pointer (`*T`).
+  - `make(T, ...)`: Creates and initializes slices, maps, and channels only. Returns an initialized value of type `T` (not a pointer).
+- **Slices:** The preferred way to work with sequences. They are more flexible than arrays.
+- **Maps:** Use the "comma ok" idiom to check for the existence of a key: `value, ok := myMap[key]`.
+
+## 6. Interfaces
+- **Implicit Implementation:** A type implements an interface by implementing its methods. No `implements` keyword is needed.
+- **Small Interfaces:** Prefer many small interfaces over one large one. The standard library is full of single-method interfaces (e.g., `io.Reader`).
+
+## 7. Concurrency
+- **Share Memory By Communicating:** This is the core philosophy. Do not communicate by sharing memory; instead, share memory by communicating.
+- **Goroutines:** Lightweight, concurrently executing functions. Start one with the `go` keyword.
+- **Channels:** Typed conduits for communication between goroutines. Use `make` to create them.
+
+## 8. Errors
+- **`error` type:** The built-in `error` interface is the standard way to handle errors.
+- **Explicit Error Handling:** Do not discard errors with the blank identifier (`_`). Check for errors explicitly.
+- **`panic`:** Reserved for truly exceptional, unrecoverable situations. Generally, libraries should not panic.
+
+*Source: [Effective Go](https://go.dev/doc/effective_go)*

package/dist/templates/code_styleguides/html-css.md

@@ -0,0 +1,49 @@
+# Google HTML/CSS Style Guide Summary
+
+This document summarizes key rules and best practices from the Google HTML/CSS Style Guide.
+
+## 1. General Rules
+- **Protocol:** Use HTTPS for all embedded resources.
+- **Indentation:** Indent by 2 spaces. Do not use tabs.
+- **Capitalization:** Use only lowercase for all code (element names, attributes, selectors, properties).
+- **Trailing Whitespace:** Remove all trailing whitespace.
+- **Encoding:** Use UTF-8 (without a BOM). Specify `<meta charset="utf-8">` in HTML.
+
+## 2. HTML Style Rules
+- **Document Type:** Use `<!doctype html>`.
+- **HTML Validity:** Use valid HTML.
+- **Semantics:** Use HTML elements according to their intended purpose (e.g., use `<p>` for paragraphs, not for spacing).
+- **Multimedia Fallback:** Provide `alt` text for images and transcripts/captions for audio/video.
+- **Separation of Concerns:** Strictly separate structure (HTML), presentation (CSS), and behavior (JavaScript). Link to CSS and JS from external files.
+- **`type` Attributes:** Omit `type` attributes for stylesheets (`<link>`) and scripts (`<script>`).
+
+## 3. HTML Formatting Rules
+- **General:** Use a new line for every block, list, or table element, and indent its children.
+- **Quotation Marks:** Use double quotation marks (`""`) for attribute values.
+
+## 4. CSS Style Rules
+- **CSS Validity:** Use valid CSS.
+- **Class Naming:** Use meaningful, generic names. Separate words with a hyphen (`-`).
+  - **Good:** `.video-player`, `.site-navigation`
+  - **Bad:** `.vid`, `.red-text`
+- **ID Selectors:** Avoid using ID selectors for styling. Prefer class selectors.
+- **Shorthand Properties:** Use shorthand properties where possible (e.g., `padding`, `font`).
+- **`0` and Units:** Omit units for `0` values (e.g., `margin: 0;`).
+- **Leading `0`s:** Always include leading `0`s for decimal values (e.g., `font-size: 0.8em;`).
+- **Hexadecimal Notation:** Use 3-character hex notation where possible (e.g., `#fff`).
+- **`!important`:** Avoid using `!important`.
+
+## 5. CSS Formatting Rules
+- **Declaration Order:** Alphabetize declarations within a rule.
+- **Indentation:** Indent all block content.
+- **Semicolons:** Use a semicolon after every declaration.
+- **Spacing:**
+  - Use a space after a property name's colon (`font-weight: bold;`).
+  - Use a space between the last selector and the opening brace (`.foo {`).
+  - Start a new line for each selector and declaration.
+- **Rule Separation:** Separate rules with a new line.
+- **Quotation Marks:** Use single quotes (`''`) for attribute selectors and property values (e.g., `[type='text']`).
+
+**BE CONSISTENT.** When editing code, match the existing style.
+
+*Source: [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)*

package/dist/templates/code_styleguides/java.md

@@ -0,0 +1,39 @@
+# Google Java Style Guide Summary
+
+This document summarizes key rules and best practices from the Google Java Style Guide.
+
+## 1. Source File Organization
+- **Filename**: The source file name is the case-sensitive name of the top-level class it contains, plus the `.java` extension.
+- **File Encoding**: UTF-8.
+- **Structure**:
+  1. License or copyright information (if any)
+  2. Package statement
+  3. Import statements
+  4. Exactly one top-level class
+
+## 2. Formatting
+- **Indentation**: 2 spaces (Google style).
+- **Column limit**: 100 characters.
+- **Braces**: Use Egyptian brackets (opening brace on the same line).
+- **Empty blocks**: Can be concise `{}` if they contain no code.
+
+## 3. Naming Conventions
+- **Packages**: `lower.case.with.dots` (e.g., `com.google.common.base`).
+- **Classes**: `UpperCamelCase` (e.g., `HttpRequest`).
+- **Methods**: `lowerCamelCase` (e.g., `sendMessage`).
+- **Variables**: `lowerCamelCase` (e.g., `userId`).
+- **Constants**: `CONSTANT_CASE` (e.g., `MAX_RETRY_COUNT`).
+- **Type Variables**: Single capital letter or `UpperCamelCase` followed by a capital letter (e.g., `T`, `RequestT`).
+
+## 4. Programming Practices
+- **Overrides**: Always use the `@Override` annotation.
+- **Exceptions**: Never ignore exceptions. At least log them or explain why they are ignored in a comment.
+- **Static Members**: Access static members via the class name, not an instance (e.g., `MyClass.staticMethod()`).
+- **Finalizers**: Do not use `Object.finalize()`.
+
+## 5. Javadoc
+- **Formatting**: Use standard Javadoc format `/** ... */`.
+- **At-clauses**: Use `@param`, `@return`, `@throws`, `@deprecated` in that order.
+- **Summary**: The first sentence of each Javadoc block should be a concise summary.
+
+*Source: [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html)*

package/dist/templates/code_styleguides/javascript.md

@@ -0,0 +1,51 @@
+# Google JavaScript Style Guide Summary
+
+This document summarizes key rules and best practices from the Google JavaScript Style Guide.
+
+## 1. Source File Basics
+- **File Naming:** All lowercase, with underscores (`_`) or dashes (`-`). Extension must be `.js`.
+- **File Encoding:** UTF-8.
+- **Whitespace:** Use only ASCII horizontal spaces (0x20). Tabs are forbidden for indentation.
+
+## 2. Source File Structure
+- New files should be ES modules (`import`/`export`).
+- **Exports:** Use named exports (`export {MyClass};`). **Do not use default exports.**
+- **Imports:** Do not use line-wrapped imports. The `.js` extension in import paths is mandatory.
+
+## 3. Formatting
+- **Braces:** Required for all control structures (`if`, `for`, `while`, etc.), even single-line blocks. Use K&R style ("Egyptian brackets").
+- **Indentation:** +2 spaces for each new block.
+- **Semicolons:** Every statement must be terminated with a semicolon.
+- **Column Limit:** 80 characters.
+- **Line-wrapping:** Indent continuation lines at least +4 spaces.
+- **Whitespace:** Use single blank lines between methods. No trailing whitespace.
+
+## 4. Language Features
+- **Variable Declarations:** Use `const` by default, `let` if reassignment is needed. **`var` is forbidden.**
+- **Array Literals:** Use trailing commas. Do not use the `Array` constructor.
+- **Object Literals:** Use trailing commas and shorthand properties. Do not use the `Object` constructor.
+- **Classes:** Do not use JavaScript getter/setter properties (`get name()`). Provide ordinary methods instead.
+- **Functions:** Prefer arrow functions for nested functions to preserve `this` context.
+- **String Literals:** Use single quotes (`'`). Use template literals (`` ` ``) for multi-line strings or complex interpolation.
+- **Control Structures:** Prefer `for-of` loops. `for-in` loops should only be used on dict-style objects.
+- **`this`:** Only use `this` in class constructors, methods, or in arrow functions defined within them.
+- **Equality Checks:** Always use identity operators (`===` / `!==`).
+
+## 5. Disallowed Features
+- `with` keyword.
+- `eval()` or `Function(...string)`.
+- Automatic Semicolon Insertion.
+- Modifying builtin objects (`Array.prototype.foo = ...`).
+
+## 6. Naming
+- **Classes:** `UpperCamelCase`.
+- **Methods & Functions:** `lowerCamelCase`.
+- **Constants:** `CONSTANT_CASE` (all uppercase with underscores).
+- **Non-constant Fields & Variables:** `lowerCamelCase`.
+
+## 7. JSDoc
+- JSDoc is used on all classes, fields, and methods.
+- Use `@param`, `@return`, `@override`, `@deprecated`.
+- Type annotations are enclosed in braces (e.g., `/** @param {string} userName */`).
+
+*Source: [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)*

package/dist/templates/code_styleguides/julia.md

@@ -0,0 +1,27 @@
+# Julia Style Guide Summary
+
+This document summarizes key rules and best practices for Julia development, based on the official Julia Style Guide and common community patterns.
+
+## 1. Naming Conventions
+- **Variables**: `snake_case` (e.g., `user_id`).
+- **Functions**: `snake_case` (e.g., `calculate_sum`).
+- **Types (Modules, Types)**: `PascalCase` (e.g., `MemoryManager`).
+- **Files**: `snake_case.jl` (e.g., `data_processing.jl`).
+- **Mutating Functions**: Functions that modify their arguments should end with an exclamation mark (e.g., `sort!`).
+
+## 2. Formatting
+- **Indentation**: 4 spaces.
+- **Line Length**: 92 characters limit is often recommended.
+- **Braces**: Opening brace on the same line.
+
+## 3. Idiomatic Julia
+- **Type Annotations**: Avoid over-specifying types in function signatures unless needed for multiple dispatch.
+- **Global Variables**: Avoid global variables where possible. Use `const` if globals are necessary.
+- **Performance**: Use type-stable functions and avoid type-unstable constructs (like `Any` in performance-critical sections).
+- **Arrays**: Indexing is 1-based. Use `eachindex(A)` for efficient iteration.
+
+## 4. Documentation
+- Use `""" ... """` for docstrings before function/type definitions.
+- Document arguments, return values, and include examples.
+
+*Source: [Official Julia Documentation - Style Guide](https://docs.julialang.org/en/v1/manual/style-guide/)*

package/dist/templates/code_styleguides/kotlin.md

@@ -0,0 +1,41 @@
+# Kotlin Style Guide Summary
+
+This document summarizes key rules and best practices for Kotlin development, based on the official Kotlin coding conventions and Google's Android Kotlin style guide.
+
+## 1. Source File Organization
+- **Encoding**: UTF-8.
+- **Indentation**: 4 spaces.
+- **Structure**:
+  1. Package header
+  2. Imports
+  3. Top-level declarations (classes, functions, etc.)
+
+## 2. Naming Conventions
+- **Classes/Interfaces**: `UpperCamelCase`.
+- **Functions/Properties**: `lowerCamelCase`.
+- **Constants**: `SCREAMING_SNAKE_CASE` (only for `const val`).
+- **Packages**: `lower.case.without.underscores`.
+
+## 3. Formatting
+- Use 100 character line limit.
+- Prefer expression bodies for simple one-line functions (e.g., `fun foo() = bar()`).
+- Omit the unit return type explicitly (e.g., `fun foo(): Unit` \u2192 `fun foo()`).
+
+## 4. Idiomatic Kotlin
+- **Immutability**: Prefer `val` over `var` whenever possible.
+- **Null Safety**:
+  - Use `?.` and `?:` (Elvis operator) instead of explicit null checks.
+  - Avoid `!!` (non-null assertion) unless absolutely certain.
+- **Data Classes**: Use `data class` for simple data-holding classes.
+- **Scope Functions**: Use `let`, `run`, `apply`, `also`, and `with` where they improve readability.
+- **String Templates**: Prefer `"$foo"` over concatenation.
+
+## 5. Collections
+- Prefer read-only collection interfaces (`List`, `Map`, `Set`) over mutable ones.
+- Use collection transformation methods (`map`, `filter`, etc.) instead of manual loops.
+
+## 6. Documentation (KDoc)
+- Use `/** ... */` for documentation comments.
+- Use `[` and `]` to reference symbols within doc comments.
+
+*Source: [Official Kotlin Coding Conventions](https://kotlinlang.org/docs/coding-conventions.html)*

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/)*