opencode-conductor-plugin 1.1.0

package/dist/templates/code_styleguides/csharp.md

@@ -0,0 +1,115 @@
+# Google C# Style Guide Summary
+
+This document summarizes key rules and best practices from the Google C# Style Guide.
+
+## 1. Naming Conventions
+- **PascalCase:** For class names, method names, constants, properties, namespaces, and public fields.
+  - Example: `MyClass`, `GetValue()`, `MaxValue`
+- **_camelCase:** For private, internal, and protected fields (with leading underscore).
+  - Example: `_myField`, `_internalState`
+- **camelCase:** For local variables and parameters.
+  - Example: `localVariable`, `methodParameter`
+- **Interfaces:** Prefix with `I` (e.g., `IMyInterface`).
+- **Type Parameters:** Use descriptive names prefixed with `T` (e.g., `TValue`, `TKey`), or just `T` for simple cases.
+
+## 2. Formatting Rules
+- **Indentation:** Use 2 spaces (never tabs).
+- **Braces:** K&R style—no line break before the opening brace; keep `} else` on one line; braces required even when optional.
+  ```csharp
+  if (condition) {
+    DoSomething();
+  } else {
+    DoSomethingElse();
+  }
+  ```
+- **Line Length:** Column limit 100.
+- **One Statement Per Line:** Each statement on its own line.
+
+## 3. Declaration Order
+Class member ordering:
+- Group members in this order:
+  1. Nested classes, enums, delegates, and events
+  2. Static, const, and readonly fields
+  3. Fields and properties
+  4. Constructors and finalizers
+  5. Methods
+- Within each group, order by accessibility:
+  1. Public
+  2. Internal
+  3. Protected internal
+  4. Protected
+  5. Private
+- Where possible, group interface implementations together.
+
+## 4. Language Features
+- **var:** Use of `var` is encouraged if it aids readability by avoiding type names that are noisy, obvious, or unimportant. Prefer explicit types when it improves clarity.
+  ```csharp
+  var apple = new Apple();  // Good - type is obvious
+  bool success = true;  // Preferred over var for basic types
+  ```
+- **Expression-bodied Members:** Use sparingly for simple properties and lambdas; don't use on method definitions.
+  ```csharp
+  public int Age => _age;
+  // Methods: prefer block bodies.
+  ```
+- **String Interpolation:** In general, use whatever is easiest to read, particularly for logging and assert messages.
+  - Be aware that chained `operator+` concatenations can be slower and cause memory churn.
+  - If performance is a concern, `StringBuilder` can be faster for multiple concatenations.
+  ```csharp
+  var message = $"Hello, {name}!";
+  ```
+- **Collection Initializers:** Use collection and object initializers when appropriate.
+  ```csharp
+  var list = new List<int> { 1, 2, 3 };
+  ```
+- **Null-conditional Operators:** Use `?.` and `??` to simplify null checks.
+  ```csharp
+  var length = text?.Length ?? 0;
+  ```
+- **Pattern Matching:** Use pattern matching for type checks and casts.
+  ```csharp
+  if (obj is string str) { /* use str */ }
+  ```
+
+## 5. Best Practices
+- **Structs vs Classes**:
+  - Almost always use a class.
+  - Consider structs only for small, value-like types that are short-lived or frequently embedded.
+  - Performance considerations may justify deviations from this guidance.
+- **Access Modifiers:** Always explicitly declare access modifiers (don't rely on defaults).
+- **Ordering Modifiers:** Use standard order: `public protected internal private new abstract virtual override sealed static readonly extern unsafe volatile async`.
+- **Namespace Imports:** Place `using` directives at the top of the file (outside namespaces); `System` first, then alphabetical.
+- **Constants:** Always make variables `const` when possible; if not, use `readonly`. Prefer named constants over magic numbers.
+- **IEnumerable vs IList vs IReadOnlyList:** When method inputs are intended to be immutable, prefer the most restrictive collection type possible (e.g., IEnumerable, IReadOnlyList); for return values, prefer IList when transferring ownership of a mutable collection, and otherwise prefer the most restrictive option.
+- **Array vs List:** Prefer `List<>` for public variables, properties, and return types. Use arrays when size is fixed and known at construction time, or for multidimensional arrays.
+- **Extension Methods:** Only use when the source is unavailable or changing it is infeasible. Only for core, general features. Be aware they obfuscate code.
+- **LINQ:** Use LINQ for readability, but be mindful of performance in hot paths.
+
+## 6. File Organization
+- **One Class Per File:** Typically one class, interface, enum, or struct per file.
+- **File Name:** Prefer the file name to match the name of the primary type it contains.
+- **Folders and File Locations:**
+  - Be consistent within the project.
+  - Prefer a flat folder structure where possible.
+  - Don’t force file/folder layout to match namespaces.
+- **Namespaces:**
+  - In general, namespaces should be no more than 2 levels deep.
+  - For shared library/module code, use namespaces.
+  - For leaf application code, namespaces are not necessary.
+  - New top-level namespace names must be globally unique and recognizable.
+
+## 7. Parameters and Returns
+- **out Parameters:** Permitted for output-only values; place `out` parameters after all other parameters. Prefer tuples or return types when they improve clarity.
+- **Argument Clarity:** When argument meaning is nonobvious, use named constants, replace `bool` with `enum`, use named arguments, or create a configuration class/struct.
+  ```csharp
+  // Bad
+  DecimalNumber product = CalculateProduct(values, 7, false, null);
+  
+  // Good
+  var options = new ProductOptions { PrecisionDecimals = 7, UseCache = CacheUsage.DontUseCache };
+  DecimalNumber product = CalculateProduct(values, options, completionDelegate: null);
+  ```
+
+**BE CONSISTENT.** When editing code, follow the existing style in the codebase.
+
+*Source: [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html)*

package/dist/templates/code_styleguides/dart.md

@@ -0,0 +1,238 @@
+# Dart Code Style Guide
+
+This guide summarizes key recommendations from the official Effective Dart documentation, covering style, documentation, language usage, and API design principles. Adhering to these guidelines promotes consistent, readable, and maintainable Dart code.
+
+## 1. Style
+
+### 1.1. Identifiers
+
+- **DO** name types, extensions, and enum types using `UpperCamelCase`.
+- **DO** name packages, directories, and source files using `lowercase_with_underscores`.
+- **DO** name import prefixes using `lowercase_with_underscores`.
+- **DO** name other identifiers (class members, top-level definitions, variables, parameters) using `lowerCamelCase`.
+- **PREFER** using `lowerCamelCase` for constant names.
+- **DO** capitalize acronyms and abbreviations longer than two letters like words (e.g., `Http`, `Nasa`, `Uri`). Two-letter acronyms (e.g., `ID`, `TV`, `UI`) should remain capitalized.
+- **PREFER** using wildcards (`_`) for unused callback parameters in anonymous and local functions.
+- **DON'T** use a leading underscore for identifiers that aren't private.
+- **DON'T** use prefix letters (e.g., `kDefaultTimeout`).
+- **DON'T** explicitly name libraries using the `library` directive.
+
+### 1.2. Ordering
+
+- **DO** place `dart:` imports before other imports.
+- **DO** place `package:` imports before relative imports.
+- **DO** specify exports in a separate section after all imports.
+- **DO** sort sections alphabetically.
+
+### 1.3. Formatting
+
+- **DO** format your code using `dart format`.
+- **CONSIDER** changing your code to make it more formatter-friendly (e.g., shortening long identifiers, simplifying nested expressions).
+- **PREFER** lines 80 characters or fewer.
+- **DO** use curly braces for all flow control statements (`if`, `for`, `while`, `do`, `try`, `catch`, `finally`).
+
+## 2. Documentation
+
+### 2.1. Comments
+
+- **DO** format comments like sentences (capitalize the first word, end with a period).
+- **DON'T** use block comments (`/* ... */`) for documentation; use `//` for regular comments.
+
+### 2.2. Doc Comments
+
+- **DO** use `///` doc comments to document members and types.
+- **PREFER** writing doc comments for public APIs.
+- **CONSIDER** writing a library-level doc comment.
+- **CONSIDER** writing doc comments for private APIs.
+- **DO** start doc comments with a single-sentence summary.
+- **DO** separate the first sentence of a doc comment into its own paragraph.
+- **AVOID** redundancy with the surrounding context (e.g., don't repeat the class name in its doc comment).
+- **PREFER** starting comments of a function or method with third-person verbs if its main purpose is a side effect (e.g., "Connects to...").
+- **PREFER** starting a non-boolean variable or property comment with a noun phrase (e.g., "The current day...").
+- **PREFER** starting a boolean variable or property comment with "Whether" followed by a noun or gerund phrase (e.g., "Whether the modal is...").
+- **PREFER** a noun phrase or non-imperative verb phrase for a function or method if returning a value is its primary purpose.
+- **DON'T** write documentation for both the getter and setter of a property.
+- **PREFER** starting library or type comments with noun phrases.
+- **CONSIDER** including code samples in doc comments using triple backticks.
+- **DO** use square brackets (`[]`) in doc comments to refer to in-scope identifiers (e.g., `[StateError]`, `[anotherMethod()]`, `[Duration.inDays]`, `[Point.new]`).
+- **DO** use prose to explain parameters, return values, and exceptions.
+- **DO** put doc comments before metadata annotations.
+
+### 2.3. Markdown
+
+- **AVOID** using markdown excessively.
+- **AVOID** using HTML for formatting.
+- **PREFER** backtick fences (```) for code blocks.
+
+### 2.4. Writing
+
+- **PREFER** brevity.
+- **AVOID** abbreviations and acronyms unless they are obvious.
+- **PREFER** using "this" instead of "the" to refer to a member's instance.
+
+## 3. Usage
+
+### 3.1. Libraries
+
+- **DO** use strings in `part of` directives.
+- **DON'T** import libraries that are inside the `src` directory of another package.
+- **DON'T** allow an import path to reach into or out of `lib`.
+- **PREFER** relative import paths when not crossing the `lib` boundary.
+
+### 3.2. Null Safety
+
+- **DON'T** explicitly initialize variables to `null`.
+- **DON'T** use an explicit default value of `null`.
+- **DON'T** use `true` or `false` in equality operations (e.g., `if (nonNullableBool == true)`).
+- **AVOID** `late` variables if you need to check whether they are initialized; prefer nullable types.
+- **CONSIDER** type promotion or null-check patterns for using nullable types.
+
+### 3.3. Strings
+
+- **DO** use adjacent strings to concatenate string literals.
+- **PREFER** using interpolation (`$variable`, `${expression}`) to compose strings and values.
+- **AVOID** using curly braces in interpolation when not needed (e.g., `'$name'` instead of `'${name}'`).
+
+### 3.4. Collections
+
+- **DO** use collection literals (`[]`, `{}`, `<type>{}`) when possible.
+- **DON'T** use `.length` to check if a collection is empty; use `.isEmpty` or `.isNotEmpty`.
+- **AVOID** using `Iterable.forEach()` with a function literal; prefer `for-in` loops.
+- **DON'T** use `List.from()` unless you intend to change the type of the result; prefer `.toList()`.
+- **DO** use `whereType()` to filter a collection by type.
+- **AVOID** using `cast()` when a nearby operation (like `List<T>.from()` or `map<T>()`) will do.
+
+### 3.5. Functions
+
+- **DO** use a function declaration to bind a function to a name.
+- **DON'T** create a lambda when a tear-off will do (e.g., `list.forEach(print)` instead of `list.forEach((e) => print(e))`).
+
+### 3.6. Variables
+
+- **DO** follow a consistent rule for `var` and `final` on local variables (either `final` for non-reassigned and `var` for reassigned, or `var` for all locals).
+- **AVOID** storing what you can calculate (e.g., don't store `area` if you have `radius`).
+
+### 3.7. Members
+
+- **DON'T** wrap a field in a getter and setter unnecessarily.
+- **PREFER** using a `final` field to make a read-only property.
+- **CONSIDER** using `=>` for simple members (getters, setters, single-expression methods).
+- **DON'T** use `this.` except to redirect to a named constructor or to avoid shadowing.
+- **DO** initialize fields at their declaration when possible.
+
+### 3.8. Constructors
+
+- **DO** use initializing formals (`this.field`) when possible.
+- **DON'T** use `late` when a constructor initializer list will do.
+- **DO** use `;` instead of `{}` for empty constructor bodies.
+- **DON'T** use `new`.
+- **DON'T** use `const` redundantly in constant contexts.
+
+### 3.9. Error Handling
+
+- **AVOID** `catch` clauses without `on` clauses.
+- **DON'T** discard errors from `catch` clauses without `on` clauses.
+- **DO** throw objects that implement `Error` only for programmatic errors.
+- **DON'T** explicitly catch `Error` or types that implement it.
+- **DO** use `rethrow` to rethrow a caught exception to preserve the original stack trace.
+
+### 3.10. Asynchrony
+
+- **PREFER** `async`/`await` over using raw `Future`s.
+- **DON'T** use `async` when it has no useful effect.
+- **CONSIDER** using higher-order methods to transform a stream.
+- **AVOID** using `Completer` directly.
+
+## 4. API Design
+
+### 4.1. Names
+
+- **DO** use terms consistently.
+- **AVOID** abbreviations unless more common than the unabbreviated term.
+- **PREFER** putting the most descriptive noun last (e.g., `pageCount`).
+- **CONSIDER** making the code read like a sentence when using the API.
+- **PREFER** a noun phrase for a non-boolean property or variable.
+- **PREFER** a non-imperative verb phrase for a boolean property or variable (e.g., `isEnabled`, `canClose`).
+- **CONSIDER** omitting the verb for a named boolean parameter (e.g., `growable: true`).
+- **PREFER** the "positive" name for a boolean property or variable (e.g., `isConnected` over `isDisconnected`).
+- **PREFER** an imperative verb phrase for a function or method whose main purpose is a side effect (e.g., `list.add()`, `window.refresh()`).
+- **PREFER** a noun phrase or non-imperative verb phrase for a function or method if returning a value is its primary purpose (e.g., `list.elementAt(3)`).
+- **CONSIDER** an imperative verb phrase for a function or method if you want to draw attention to the work it performs (e.g., `database.downloadData()`).
+- **AVOID** starting a method name with `get`.
+- **PREFER** naming a method `to___()` if it copies the object's state to a new object (e.g., `toList()`).
+- **PREFER** naming a method `as___()` if it returns a different representation backed by the original object (e.g., `asMap()`).
+- **AVOID** describing the parameters in the function's or method's name.
+- **DO** follow existing mnemonic conventions when naming type parameters (e.g., `E` for elements, `K`, `V` for map keys/values, `T`, `S`, `U` for general types).
+
+### 4.2. Libraries
+
+- **PREFER** making declarations private (`_`).
+- **CONSIDER** declaring multiple classes in the same library if they logically belong together.
+
+### 4.3. Classes and Mixins
+
+- **AVOID** defining a one-member abstract class when a simple function (`typedef`) will do.
+- **AVOID** defining a class that contains only static members; prefer top-level functions/variables or a library.
+- **AVOID** extending a class that isn't intended to be subclassed.
+- **DO** use class modifiers (e.g., `final`, `interface`, `sealed`) to control if your class can be extended.
+- **AVOID** implementing a class that isn't intended to be an interface.
+- **DO** use class modifiers to control if your class can be an interface.
+- **PREFER** defining a pure mixin or pure class to a `mixin class`.
+
+### 4.4. Constructors
+
+- **CONSIDER** making your constructor `const` if the class supports it (all fields are `final` and initialized in the constructor).
+
+### 4.5. Members
+
+- **PREFER** making fields and top-level variables `final`.
+- **DO** use getters for operations that conceptually access properties (no arguments, returns a result, no user-visible side effects, idempotent).
+- **DO** use setters for operations that conceptually change properties (single argument, no result, changes state, idempotent).
+- **DON'T** define a setter without a corresponding getter.
+- **AVOID** using runtime type tests to fake overloading.
+- **AVOID** public `late final` fields without initializers.
+- **AVOID** returning nullable `Future`, `Stream`, and collection types; prefer empty containers or non-nullable futures of nullable types.
+- **AVOID** returning `this` from methods just to enable a fluent interface; prefer method cascades.
+
+### 4.6. Types
+
+- **DO** type annotate variables without initializers.
+- **DO** type annotate fields and top-level variables if the type isn't obvious.
+- **DON'T** redundantly type annotate initialized local variables.
+- **DO** annotate return types on function declarations.
+- **DO** annotate parameter types on function declarations.
+- **DON'T** annotate inferred parameter types on function expressions.
+- **DON'T** type annotate initializing formals.
+- **DO** write type arguments on generic invocations that aren't inferred.
+- **DON'T** write type arguments on generic invocations that are inferred.
+- **AVOID** writing incomplete generic types.
+- **DO** annotate with `dynamic` instead of letting inference fail silently.
+- **PREFER** signatures in function type annotations.
+- **DON'T** specify a return type for a setter.
+- **DON'T** use the legacy `typedef` syntax.
+- **PREFER** inline function types over `typedef`s.
+- **PREFER** using function type syntax for parameters.
+- **AVOID** using `dynamic` unless you want to disable static checking.
+- **DO** use `Future<void>` as the return type of asynchronous members that do not produce values.
+- **AVOID** using `FutureOr<T>` as a return type.
+
+### 4.7. Parameters
+
+- **AVOID** positional boolean parameters.
+- **AVOID** optional positional parameters if the user may want to omit earlier parameters.
+- **AVOID** mandatory parameters that accept a special "no argument" value.
+- **DO** use inclusive start and exclusive end parameters to accept a range.
+
+### 4.8. Equality
+
+- **DO** override `hashCode` if you override `==`.
+- **DO** make your `==` operator obey the mathematical rules of equality (reflexive, symmetric, transitive, consistent).
+- **AVOID** defining custom equality for mutable classes.
+- **DON'T** make the parameter to `==` nullable.
+
+_Sources:_
+
+- [Effective Dart: Style](https://dart.dev/effective-dart/style)
+- [Effective Dart: Documentation](https://dart.dev/effective-dart/documentation)
+- [Effective Dart: Usage](https://dart.dev/effective-dart/usage)
+- [Effective Dart: Design](https://dart.dev/effective-dart/design)

package/dist/templates/code_styleguides/general.md

@@ -0,0 +1,23 @@
+# General Code Style Principles
+
+This document outlines general coding principles that apply across all languages and frameworks used in this project.
+
+## Readability
+- Code should be easy to read and understand by humans.
+- Avoid overly clever or obscure constructs.
+
+## Consistency
+- Follow existing patterns in the codebase.
+- Maintain consistent formatting, naming, and structure.
+
+## Simplicity
+- Prefer simple solutions over complex ones.
+- Break down complex problems into smaller, manageable parts.
+
+## Maintainability
+- Write code that is easy to modify and extend.
+- Minimize dependencies and coupling.
+
+## Documentation
+- Document *why* something is done, not just *what*.
+- Keep documentation up-to-date with code changes.

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