zrb 1.18.0__tar.gz → 1.18.2__tar.gz

{zrb-1.18.0 → zrb-1.18.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: zrb
-Version: 1.18.0
+Version: 1.18.2
 Summary: Your Automation Powerhouse
 License: AGPL-3.0-or-later
 Keywords: Automation,Task Runner,Code Generator,Monorepo,Low Code

{zrb-1.18.0 → zrb-1.18.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "zrb"
-version = "1.18.0"
+version = "1.18.2"
 description = "Your Automation Powerhouse"
 authors = ["Go Frendi Gunawan <gofrendiasgard@gmail.com>"]
 license = "AGPL-3.0-or-later"

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/cpp.md

@@ -0,0 +1,33 @@
+# C++ Development Guide
+
+This guide provides the baseline for C++ development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Build System:** `CMakeLists.txt` (CMake), `Makefile` (Make), or a Visual Studio solution file (`*.sln`).
+- **C++ Standard:** Look for flags like `-std=c++11`, `-std=c++14`, `-std=c++17`, or `-std=c++20` in the build files.
+- **Style & Linting Config:** `.clang-format`, `.clang-tidy`. These define the coding standard.
+- **Testing Framework:** Look for a `tests/` directory and check the build files for dependencies like `gtest` or `catch2`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured formatter (e.g., clang-format) and linter (e.g., clang-tidy). If none exist, default to the Google C++ Style Guide.
+- **Modern C++:** Use modern C++ features, such as smart pointers, range-based for loops, and auto.
+- **RAII (Resource Acquisition Is Initialization):** Use RAII to manage resources like memory, files, and network connections.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for error handling. Use exceptions for errors that cannot be handled locally.
+- **Testing:** Use the project's existing test structure. Write unit tests for all new code.
+
+## 4. Common Commands
+
+- **CMake:**
+  - **Configure:** `cmake -B build`
+  - **Build:** `cmake --build build`
+  - **Test:** `cd build && ctest`
+- **Make:**
+  - **Build:** `make`
+  - **Test:** `make test`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/csharp.md

@@ -0,0 +1,35 @@
+# C# Development Guide
+
+This guide provides the baseline for C# development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Project File:** `*.csproj`. This defines the project structure, dependencies, and build settings.
+- **Solution File:** `*.sln`. This defines the solution that contains one or more projects.
+- **.NET Version:** Look for a `global.json` file, or check the `*.csproj` file.
+- **Style & Linting Config:** `.editorconfig`, `.stylecop.json`. These define the coding standard.
+- **Testing Framework:** Look for a `*Tests` directory and check the project file for dependencies like `xunit`, `nunit`, or `mstest`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (e.g., StyleCop). If none exists, default to the .NET coding conventions.
+- **Idiomatic C#:** Embrace C#'s core features:
+  - Use properties instead of public fields.
+  - Use LINQ for data manipulation.
+  - Use `async/await` for asynchronous programming.
+- **Object-Oriented Design:** Follow SOLID principles and use design patterns where appropriate.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for exceptions. Use `try-catch-finally` blocks for exception handling.
+- **Testing:** Use the project's existing test structure. Write unit tests for all new code.
+
+## 4. Common Commands
+
+- **Build:** `dotnet build`
+- **Run:** `dotnet run`
+- **Test:** `dotnet test`
+- **Clean:** `dotnet clean`
+- **Publish:** `dotnet publish`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/git.md

@@ -0,0 +1,58 @@
+# Git Workflow Guide
+
+This guide governs all version control operations. Adhere to it for safety and consistency.
+
+## 1. Core Principles & Safety
+
+- **Atomic Commits:** One logical change per commit. Use `git add -p` for precision.
+- **Descriptive Messages:** Explain the "why" in the imperative mood (e.g., "Add feature"). Follow the 50/72 format.
+- **Safety First:**
+  - Always run `git status` before operations.
+  - Use `git push --force-with-lease`, not `--force`.
+  - Ensure the working directory is clean before `git rebase`.
+
+## 2. Standard Workflow
+
+This is the primary development cycle.
+
+1. **Branch:** `git checkout -b <branch-name>`
+2. **Code & Verify:** Make changes, then run all tests, linters, and builds.
+3. **Stage:** `git add <file>` or, for more precision, `git add -p`.
+4. **Commit:** `git commit` with a descriptive message.
+    ```
+    feat: Add user authentication endpoint
+
+    Implement the /login endpoint using JWT for token-based auth.
+    This resolves issue #123 by providing a mechanism for users to
+    log in and receive an access token.
+    ```
+5. **Review/Amend:** Use `git log -1` to review. If needed, fix with `git commit --amend`.
+6. **Push:** `git push origin <branch-name>`
+
+## 3. Command Reference
+
+### Status & History
+- `git status`: Check working directory status.
+- `git diff`: See uncommitted changes to tracked files.
+- `git diff --staged`: See staged changes.
+- `git log --oneline --graph -10`: View recent commit history.
+- `git blame <file>`: See who changed what in a file.
+
+### Branching & Merging
+- `git checkout -b <name>`: Create and switch to a new branch.
+- `git switch <name>`: Switch to an existing branch.
+- `git rebase main`: Update the current branch from `main`. **(Use with care)**.
+- `git merge --no-ff <branch>`: Merge a branch without fast-forwarding.
+
+### Stashing
+- `git stash push -m "msg"`: Save uncommitted changes temporarily.
+- `git stash list`: List all stashes.
+- `git stash pop`: Apply and remove the last stash.
+
+### Remote Operations
+- `git fetch origin`: Fetch updates from the remote repository.
+- `git push origin <branch>`: Push a branch to the remote.
+- `git push origin --delete <branch>`: Delete a remote branch.
+
+### Advanced
+- `git cherry-pick <commit-hash>`: Apply a specific commit from another branch. **(Use with caution to avoid duplicate commits)**.

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/golang.md

@@ -0,0 +1,43 @@
+# Go Development Guide
+
+This guide provides the baseline for Go development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Module Information:** `go.mod` to identify the module path and dependencies. `go.sum` for dependency checksums.
+- **Workspace:** `go.work` to see if the project is part of a multi-module workspace.
+- **Tooling:** A `Makefile` is common for defining build, test, and lint commands.
+- **CI/CD Configuration:** Files like `.github/workflows/go.yml` can reveal the exact commands used for verification.
+- **Linting Config:** `.golangci.yml` defines the linting rules for `golangci-lint`.
+- **Package Structure:** Analyze the `pkg/` and `internal/` directories to understand the project's layout.
+
+## 2. Core Principles
+
+- **Formatting:** `go fmt` is mandatory. All code must be formatted before committing.
+- **Linting:** Adhere to the project's `golangci-lint` configuration. If none exists, use a sensible default.
+- **Package Naming:** Use short, concise, all-lowercase package names.
+- **Simplicity:** Write clear, simple, and readable code. Avoid unnecessary complexity or "clever" tricks.
+
+## 3. Project Structure
+
+- **`cmd/`:** Main applications for the project. Each subdirectory is a separate command.
+- **`pkg/`:** Library code that's okay to be used by external applications.
+- **`internal/`:** Private application and library code. It's not importable by other projects.
+
+## 4. Implementation Patterns
+
+- **Error Handling:** Match the existing error handling strategy. Check if the project uses a library like `pkg/errors` for wrapping or if it relies on the standard library's `fmt.Errorf` with `%w`.
+- **Testing:** Replicate the existing test structure. Use table-driven tests if they are prevalent in the codebase. Place tests in `_test.go` files within the same package.
+- **Concurrency:** Follow existing concurrency patterns. Pay close attention to how goroutines, channels, and mutexes are used.
+- **Debugging:** Use the `delve` debugger for debugging Go applications.
+
+## 5. Common Commands
+
+- **Tidy Dependencies:** `go mod tidy`
+- **Formatting:** `go fmt ./...`
+- **Linting:** `golangci-lint run`
+- **Testing:** `go test ./...`
+- **Building:** `go build ./...`
+- **Run:** `go run ./cmd/my-app`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/html-css.md

@@ -0,0 +1,34 @@
+# HTML/CSS Development Guide
+
+This guide provides the baseline for HTML and CSS development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **HTML Files:** `*.html`. Look for the overall structure, doctype, and meta tags.
+- **CSS Files:** `*.css`. Look for the CSS architecture (e.g., BEM, SMACSS), preprocessors (e.g., Sass, Less), and frameworks (e.g., Bootstrap, Tailwind CSS).
+- **Style & Linting Config:** `.stylelintrc`, `.prettierrc`. These define the coding standard.
+
+## 2. Core Principles
+
+- **HTML:**
+  - **Semantic HTML:** Use HTML elements for their intended purpose. For example, use `<nav>` for navigation, `<main>` for the main content, and `<article>` for articles.
+  - **Accessibility:** Follow accessibility best practices, such as using `alt` attributes for images and `aria-*` attributes for dynamic content.
+- **CSS:**
+  - **Separation of Concerns:** Keep your CSS separate from your HTML. Use external stylesheets instead of inline styles.
+  - **Responsive Design:** Use media queries to create a responsive design that works on all screen sizes.
+  - **CSS Methodologies:** If the project uses a CSS methodology like BEM or SMACSS, follow it.
+
+## 3. Implementation Patterns
+
+- **HTML:**
+  - **Validation:** Validate your HTML using the W3C Markup Validation Service.
+- **CSS:**
+  - **Prefixing:** Use a tool like Autoprefixer to add vendor prefixes to your CSS.
+  - **Minification:** Use a tool like cssnano to minify your CSS for production.
+
+## 4. Common Commands
+
+- **Linting:** `stylelint "**/*.css"`, `prettier --check "**/*.html"`
+- **Formatting:** `prettier --write "**/*.{html,css}"`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/java.md

@@ -0,0 +1,37 @@
+# Java Development Guide
+
+This guide provides the baseline for Java development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Build System:** `pom.xml` (Maven) or `build.gradle` (Gradle). Note the dependencies, plugins, and build lifecycle.
+- **Java Version:** Look for a `.java-version` file, or check the `pom.xml` or `build.gradle` file.
+- **Style & Linting Config:** `.checkstyle.xml`, `.pmd.xml`. These define the coding standard.
+- **Testing Framework:** Look for a `src/test/java` directory and check the build file for dependencies like `junit` or `testng`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (e.g., Checkstyle, PMD). If none exist, default to the Google Java Style Guide.
+- **Object-Oriented Design:** Follow SOLID principles and use design patterns where appropriate.
+- **API Design:** Follow the principles of good API design, such as keeping APIs small and focused.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for exceptions. Use checked exceptions for recoverable errors and unchecked exceptions for programming errors.
+- **Testing:** Use the project's existing test structure. Write unit tests for all new code.
+- **Concurrency:** Follow existing concurrency patterns. Use the `java.util.concurrent` package for high-level concurrency abstractions.
+
+## 4. Common Commands
+
+- **Maven:**
+  - **Clean:** `mvn clean`
+  - **Compile:** `mvn compile`
+  - **Test:** `mvn test`
+  - **Package:** `mvn package`
+  - **Install:** `mvn install`
+- **Gradle:**
+  - **Clean:** `./gradlew clean`
+  - **Build:** `./gradlew build`
+  - **Test:** `./gradlew test`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/javascript.md

@@ -0,0 +1,45 @@
+# JavaScript/TypeScript Development Guide
+
+This guide provides the baseline for JS/TS development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Package Manager:** `package.json` (and `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`). Note the `scripts` and `dependencies`.
+- **TypeScript/JavaScript Config:** `tsconfig.json` or `jsconfig.json`. This defines module system, strictness, and paths.
+- **Style & Linting Config:** `.eslintrc.js`, `.prettierrc`, `package.json` (for `eslintConfig`, `prettier`). These define the coding standard.
+- **Build/Vite Config:** `webpack.config.js`, `vite.config.ts`, `rollup.config.js`.
+- **Testing Framework:** Look for a `tests/` or `__tests__/` directory, and config files like `jest.config.js` or `vitest.config.ts`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (`ESLint`) and formatter (`Prettier`).
+- **TypeScript:** If the project uses TypeScript (`tsconfig.json` exists), you MUST use it for all new code. Adhere to the configured strictness level.
+- **Module System:** Match the project's module system (e.g., ES Modules `import/export` or CommonJS `require/module.exports`). This is usually defined in `package.json` (`"type": "module"`) or `tsconfig.json`.
+
+## 3. Package Management
+
+- **`npm`:** If the project uses `package-lock.json`, add new dependencies using `npm install <package-name>`.
+- **`yarn`:** If the project uses `yarn.lock`, add new dependencies using `yarn add <package-name>`.
+- **`pnpm`:** If the project uses `pnpm-lock.yaml`, add new dependencies using `pnpm add <package-name>`.
+
+## 4. Framework Conventions
+
+- **React:** If the project uses React, follow its component structure (e.g., functional components with hooks), state management (e.g., `useState`, `useReducer`, Redux), and JSX syntax.
+- **Vue:** If the project uses Vue, follow its single-file component structure, `v-` directives, and state management patterns (e.g., Pinia).
+- **Angular:** If the project uses Angular, follow its module and component structure, dependency injection, and RxJS-based patterns.
+
+## 5. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for `try/catch`, Promises (`.catch()`), and async/await error handling.
+- **Testing:** Use the project's existing test runner (`Jest`, `Vitest`, `Mocha`), assertion library, and mocking patterns. Add tests for all new code.
+- **Debugging:** Use the browser's developer tools for front-end code and the Node.js debugger (`node --inspect`) for back-end code.
+
+## 6. Common Commands
+
+- **Install Dependencies:** `npm install`, `yarn install`, `pnpm install`
+- **Linting/Formatting:** `npm run lint`, `npm run format`
+- **Type Checking:** `npm run typecheck`, `tsc --noEmit`
+- **Testing:** `npm test`, `npm run test`
+- **Building:** `npm run build`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/kotlin.md

@@ -0,0 +1,41 @@
+# Kotlin Development Guide
+
+This guide provides the baseline for Kotlin development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Build System:** `build.gradle.kts` (Gradle with Kotlin DSL) or `pom.xml` (Maven). Note the dependencies, plugins, and build lifecycle.
+- **Kotlin Version:** Look for a `.kotlin-version` file, or check the `build.gradle.kts` or `pom.xml` file.
+- **Style & Linting Config:** `.editorconfig`, `.ktlint.ruleset.json`. These define the coding standard.
+- **Testing Framework:** Look for a `src/test/kotlin` directory and check the build file for dependencies like `junit` or `kotest`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (e.g., `ktlint`). If none exists, default to the official Kotlin coding conventions.
+- **Idiomatic Kotlin:** Embrace Kotlin's core features:
+  - Use `val` and `var` correctly.
+  - Use null safety features (`?`, `!!`, `let`).
+  - Use data classes for immutable data.
+  - Use extension functions to add functionality to existing classes.
+- **Functional Programming:** Use higher-order functions, lambdas, and collections API where it improves clarity.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for exceptions. Use `try-catch` expressions and the `Result` type.
+- **Testing:** Use the project's existing test structure. Write unit tests for all new code.
+- **Coroutines:** Follow existing concurrency patterns. Use coroutines for asynchronous programming.
+
+## 4. Common Commands
+
+- **Gradle:**
+    - **Clean:** `./gradlew clean`
+    - **Build:** `./gradlew build`
+    - **Test:** `./gradlew test`
+- **Maven:**
+    - **Clean:** `mvn clean`
+    - **Compile:** `mvn compile`
+    - **Test:** `mvn test`
+    - **Package:** `mvn package`
+    - **Install:** `mvn install`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/php.md

@@ -0,0 +1,30 @@
+# PHP Development Guide
+
+This guide provides the baseline for PHP development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Dependency Management:** `composer.json` and `composer.lock`. Note the dependencies and scripts.
+- **PHP Version:** Look for a `.php-version` file or check `composer.json`.
+- **Style & Linting Config:** `.php-cs-fixer.php`, `phpcs.xml`. These define the coding standard.
+- **Testing Framework:** Look for a `tests/` directory and check `composer.json` for dependencies like `phpunit`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (e.g., PHP-CS-Fixer, PHP_CodeSniffer). If none exists, default to PSR-12.
+- **Modern PHP:** Use modern PHP features, such as type declarations, strict types, and the null coalescing operator.
+- **Frameworks:** If the project uses a framework like Laravel or Symfony, follow its conventions.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for exceptions. Use `try-catch` blocks for exception handling.
+- **Testing:** Use the project's existing test structure. Write unit tests for all new code.
+
+## 4. Common Commands
+
+- **Install Dependencies:** `composer install`
+- **Update Dependencies:** `composer update`
+- **Linting:** `vendor/bin/php-cs-fixer fix`, `vendor/bin/phpcs`
+- **Testing:** `vendor/bin/phpunit`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/python.md

@@ -0,0 +1,44 @@
+# Python Development Guide
+
+This guide provides the baseline for Python development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Dependency Management:** `pyproject.toml` (and `poetry.lock` or `pdm.lock`), `requirements.txt`, `setup.py`. Note the exact libraries and versions used.
+- **Virtual Environment:** Check for a `.venv` or `venv` directory. If it exists, activate it using `source .venv/bin/activate`. If not, create one using `python -m venv .venv` and then activate it.
+- **Python Version:** Look for a `.python-version` file or check `pyproject.toml`.
+- **Style & Linting Config:** `ruff.toml`, `pyproject.toml` (for `black`, `isort`, `ruff`), `.flake8`, `.pylintrc`. These define the coding standard.
+- **Type Checking Config:** `mypy.ini`, `pyrightconfig.json`.
+- **Testing Framework:** Look for a `tests/` directory, `pytest.ini`, or `tox.ini` to identify `pytest`, `unittest`, etc.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (e.g., `ruff`, `flake8`) and formatter (e.g., `black`, `autopep8`). If none exist, default to PEP 8.
+- **Type Hints:** If the project uses type hints, you MUST use them for all new code. Match the existing style.
+- **Imports:** Follow the project's import organization (e.g., stdlib, third-party, local). Use the configured import sorter (like `isort`).
+- **Docstrings:** Match the existing docstring format (e.g., Google, NumPy, reStructuredText).
+
+## 3. Dependency Management
+
+- **`pip`:** If the project uses `requirements.txt`, add new dependencies to the file and then run `pip install -r requirements.txt`.
+- **`poetry`:** If the project uses `pyproject.toml` with poetry, add new dependencies using `poetry add <package-name>` and install them with `poetry install`.
+
+## 4. Implementation Patterns
+
+- **Error Handling:** Replicate the existing patterns for exceptions, logging, and error wrapping.
+- **Testing:** Use the project's existing test structure, fixtures, and mocking libraries. Add tests for all new code.
+- **Debugging:** Use the built-in `pdb` for debugging, or `ipdb` if it's available in the project.
+
+## 5. Project Structure
+
+- **Simple scripts:** For single-file scripts, keep them in the root of the project.
+- **Larger projects:** For larger projects, use a `src` layout, where the main source code resides in a `src` directory. Tests should be in a separate `tests` directory.
+
+## 6. Common Commands
+
+- **Formatting:** `black .`, `autopep8 .`
+- **Linting:** `ruff check .`, `flake8 .`, `pylint .`
+- **Type Checking:** `mypy .`, `pyright .`
+- **Testing:** `pytest`, `python -m unittest discover`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/ruby-on-rails.md

@@ -0,0 +1,34 @@
+# Ruby on Rails Development Guide
+
+This guide provides the baseline for Ruby on Rails development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Gemfile:** This file contains all the gems used in the project.
+- **config/routes.rb:** This file defines the application's routes.
+- **app/models/:** This directory contains the application's models.
+- **app/views/:** This directory contains the application's views.
+- **app/controllers/:** This directory contains the application's controllers.
+- **db/schema.rb:** This file defines the database schema.
+
+## 2. Core Principles
+
+- **Convention over Configuration:** Follow the Rails conventions for file and class naming.
+- **Fat Model, Skinny Controller:** Keep your controllers thin and your models fat.
+- **RESTful Design:** Use RESTful principles for your application's design.
+
+## 3. Implementation Patterns
+
+- **Active Record:** Use Active Record for database interaction.
+- **Action View:** Use Action View for creating views.
+- **Action Controller:** Use Action Controller for handling requests and responses.
+
+## 4. Common Commands
+
+- **Start the server:** `bin/rails server`
+- **Run the console:** `bin/rails console`
+- **Run the tests:** `bin/rails test`
+- **Generate code:** `bin/rails generate`
+- **Run database migrations:** `bin/rails db:migrate`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/ruby.md

@@ -0,0 +1,33 @@
+# Ruby Development Guide
+
+This guide provides the baseline for Ruby development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Dependency Management:** `Gemfile` and `Gemfile.lock`. Note the gems and their versions.
+- **Ruby Version:** Look for a `.ruby-version` file.
+- **Style & Linting Config:** `.rubocop.yml`. This defines the coding standard.
+- **Testing Framework:** Look for a `test/` or `spec/` directory and check the `Gemfile` for dependencies like `minitest` or `rspec`.
+
+## 2. Core Principles
+
+- **Style:** Strictly adhere to the project's configured linter (e.g., RuboCop). If none exists, default to the Ruby Style Guide.
+- **Idiomatic Ruby:** Embrace Ruby's core features:
+  - Use blocks and iterators.
+  - Use symbols for identifiers and strings for data.
+  - Use metaprogramming responsibly.
+- **Frameworks:** If the project uses a framework like Ruby on Rails, follow its conventions.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Replicate existing patterns for exceptions. Use `begin-rescue-end` blocks for exception handling.
+- **Testing:** Use the project's existing test structure. Write unit tests for all new code.
+
+## 4. Common Commands
+
+- **Install Dependencies:** `bundle install`
+- **Update Dependencies:** `bundle update`
+- **Linting:** `bundle exec rubocop`
+- **Testing:** `bundle exec rake test`, `bundle exec rspec`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/rust.md

@@ -0,0 +1,38 @@
+# Rust Development Guide
+
+This guide provides the baseline for Rust development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Crate & Dependency Info:** `Cargo.toml` is the source of truth for dependencies, features, and workspace members. `Cargo.lock` pins dependency versions.
+- **Toolchain Version:** A `rust-toolchain.toml` file specifies the exact Rust version and components.
+- **Formatting Config:** `rustfmt.toml` or ` .rustfmt.toml` defines the formatting rules.
+- **Linting Config:** `clippy.toml` or the `[lints]` section in `Cargo.toml` defines Clippy rules.
+- **Module Structure:** Analyze `src/lib.rs`, `src/main.rs`, and the `src/bin` directory to understand the crate structure and module hierarchy.
+
+## 2. Core Principles
+
+- **Formatting:** `cargo fmt` is mandatory. All code must be formatted.
+- **Linting:** `cargo clippy` is mandatory. All warnings must be addressed. Strictly adhere to the project's Clippy configuration.
+- **Safety:** Write safe Rust. `unsafe` blocks are forbidden unless you have an extremely compelling, documented reason and receive explicit approval.
+- **Idiomatic Rust:** Embrace Rust's core features:
+  - Use `Result` and `Option` for error and optional value handling.
+  - Leverage ownership, borrowing, and lifetimes correctly.
+  - Use iterators and closures over manual loops where it improves clarity.
+
+## 3. Implementation Patterns
+
+- **Error Handling:** Match the existing error handling strategy. If the project uses a specific error library (e.g., `anyhow`, `thiserror`), you must use it.
+- **Testing:** Place unit tests in a `#[cfg(test)]` module at the bottom of the file they are testing. Integration tests go in the `tests/` directory. Follow existing patterns for test setup.
+- **API Design:** Follow the Rust API Guidelines. Pay attention to how public APIs are structured and documented.
+
+## 4. Common Commands
+
+- **Formatting:** `cargo fmt`
+- **Linting:** `cargo clippy -- -D warnings` (Treat all warnings as errors)
+- **Testing:** `cargo test`
+- **Building:** `cargo build`
+- **Run:** `cargo run`
+- **Check for Errors:** `cargo check` (Faster than a full build)

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/shell.md

@@ -0,0 +1,49 @@
+# Shell Scripting Guide
+
+This guide is for writing robust, safe, and maintainable shell scripts.
+
+## 1. The Non-Negotiable Boilerplate
+
+Every script you write MUST start with this. No exceptions.
+
+```bash
+#!/usr/bin/env bash
+
+# Exit on error, exit on unset variables, and exit on pipe fails.
+set -euo pipefail
+```
+
+## 2. Core Principles
+
+- **Safety First:** Always quote your variables (`"$VAR"`). Use `[[` instead of `[`. Check command success.
+- **Readability:** Use clear variable names (`snake_case`). Add comments for anything complex. Use functions to structure your code.
+- **Portability:** Prefer POSIX-compliant features when possible, but assume `bash` as a safe default unless otherwise specified.
+- **Error Handling:** If a command can fail, you MUST check its exit code and handle the failure appropriately.
+
+## 3. Best Practices
+
+### Variable Safety
+- **Quote Everything:** `rm "$file"` instead of `rm $file`.
+- **Use Local Variables in Functions:** `local my_var="value"` to avoid polluting the global scope.
+- **Use Arrays for Lists:** `args=("-a" "-b" "$file")` and `command "${args[@]}"` is safer than a single string.
+- **Use `readonly` for Constants:** `readonly TIMEOUT=30`.
+
+### Robust Commands
+- **Check for Command Existence:** `if ! command -v jq &> /dev/null; then ...`
+- **Handle Command Failures:** `my_command || { echo "my_command failed" >&2; exit 1; }`
+- **Use `mktemp` for Temporary Files/Dirs:** `tmp_file=$(mktemp)` and `trap 'rm -f "$tmp_file"' EXIT`.
+
+### Script Structure
+- **`main` function:** Put your core logic in a `main()` function and call it at the end with `main "$@"`.
+- **Logging Functions:** Create simple `log` and `error` functions to standardize output.
+- **Usage/Help Function:** Every script should have a `usage()` function that explains what it does and what arguments it expects.
+
+## 4. Linting
+
+- All scripts MUST be checked with `shellcheck`. There should be no warnings.
+
+## 5. Common Commands
+
+- **Linting:** `shellcheck your_script.sh`
+- **Executing:** `bash your_script.sh`
+- **Debugging:** `bash -x your_script.sh`

zrb-1.18.2/src/zrb/task/llm/default_workflow/coding/sql.md

@@ -0,0 +1,38 @@
+# SQL Development Guide
+
+This guide provides the baseline for SQL development. It is superseded by project-specific conventions.
+
+## 1. Project Analysis Checklist
+
+Before coding, inspect the project for these files to determine its conventions:
+
+- **Schema Definitions:** `*.sql` files that define the database schema.
+- **Migrations:** A directory containing migration files (e.g., `db/migrations`).
+- **Database Client:** The database client used in the project (e.g., `psql`, `mysql`, `sqlcmd`).
+
+## 2. Core Principles
+
+- **Style:**
+  - **Keywords:** Use uppercase for SQL keywords (e.g., `SELECT`, `FROM`, `WHERE`).
+  - **Identifiers:** Use snake_case for table and column names.
+  - **Indentation:** Use consistent indentation to make your queries readable.
+- **Data Types:** Use the most appropriate data types for your columns.
+- **Normalization:** Normalize your database to reduce data redundancy and improve data integrity.
+- **Indexes:** Use indexes to improve the performance of your queries.
+
+## 3. Implementation Patterns
+
+- **Transactions:** Use transactions to ensure data consistency.
+- **Stored Procedures:** Use stored procedures to encapsulate complex business logic.
+- **Views:** Use views to simplify complex queries and to enforce security.
+
+## 4. Common Commands
+
+- **Connect to database:**
+  - **PostgreSQL:** `psql -h <host> -U <user> -d <database>`
+  - **MySQL:** `mysql -h <host> -u <user> -p <database>`
+  - **SQL Server:** `sqlcmd -S <server> -U <user> -P <password> -d <database>`
+- **Run a script:**
+  - **PostgreSQL:** `psql -h <host> -U <user> -d <database> -f <script.sql>`
+  - **MySQL:** `mysql -h <host> -u <user> -p <database> < <script.sql>`
+  - **SQL Server:** `sqlcmd -S <server> -U <user> -P <password> -d <database> -i <script.sql>`