zrb 1.18.0__py3-none-any.whl → 1.18.1__py3-none-any.whl

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/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/task/llm/default_workflow/coding/git.md

@@ -1,142 +1,58 @@
-# Git Command Guidelines
+# Git Workflow Guide
 
-## Core Principles
+This guide governs all version control operations. Adhere to it for safety and consistency.
 
-- **Safety First:** Always verify current branch and status before destructive operations
-- **Atomic Commits:** Each commit should represent a single logical change
-- **Descriptive Messages:** Write clear, concise commit messages that explain "why" not just "what"
-- **Interactive Mode:** Use interactive rebase and staging for precise control
+## 1. Core Principles & Safety
 
-## Essential Commands
+- **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`.
 
-### Repository Status
-```bash
-# Check current status and branch
-git status
-git branch -v
+## 2. Standard Workflow
 
-# See uncommitted changes
-git diff
-git diff --staged
-```
+This is the primary development cycle.
 
-### Safe Branch Operations
-```bash
-# Create and switch to new branch
-git checkout -b feature/new-feature
+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
 
-# Switch branches safely
-git switch main
-git switch feature/branch-name
+    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>`
 
-# List all branches
-git branch -a
-```
+## 3. Command Reference
 
-### Staging and Committing
-```bash
-# Stage specific files
-git add path/to/file.py
-git add src/
+### 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.
 
-# Stage interactively
-git add -p
-
-# Commit with descriptive message
-git commit -m "feat: add user authentication
-
-- Implement JWT token generation
-- Add login/logout endpoints
-- Add password hashing"
-
-# Amend last commit (use carefully)
-git commit --amend
-```
-
-### History and Logs
-```bash
-# View commit history
-git log --oneline --graph -10
-git log --stat
-
-# See who changed what
-git blame file.py
-```
-
-## Advanced Operations
-
-### Rebasing and Merging
-```bash
-# Update feature branch from main
-git switch feature/branch
-git rebase main
-
-# Interactive rebase for cleanup
-git rebase -i HEAD~5
-
-# Safe merge
-git merge --no-ff feature/branch
-```
+### 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
-```bash
-# Save uncommitted changes temporarily
-git stash push -m "WIP: feature implementation"
-
-# List stashes
-git stash list
-
-# Apply and keep stash
-git stash apply stash@{0}
-
-# Apply and drop stash
-git stash pop
-```
+- `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
-```bash
-# Fetch and check before pulling
-git fetch origin
-git log origin/main..main
-
-# Push safely
-git push origin feature/branch
-git push --force-with-lease  # Safer than --force
-```
-
-## Safety Checklist
-
-1. **Before destructive operations:** Always run `git status` and `git branch -v`
-2. **Before force push:** Use `--force-with-lease` instead of `--force`
-3. **Before rebase:** Ensure working directory is clean
-4. **Before merge:** Resolve conflicts immediately
-5. **Regularly:** Fetch and integrate upstream changes
-
-## Common Patterns
-
-### Feature Development
-```bash
-git checkout -b feature/new-feature
-# ... make changes ...
-git add .
-git commit -m "feat: implement new feature"
-git push origin feature/new-feature
-```
-
-### Hotfix Workflow
-```bash
-git checkout -b hotfix/critical-bug main
-# ... fix the bug ...
-git add .
-git commit -m "fix: resolve critical issue"
-git push origin hotfix/critical-bug
-```
-
-### Cleanup
-```bash
-# Delete merged branches locally
-git branch --merged main | grep -v "main" | xargs git branch -d
+- `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.
 
-# Delete remote branches
-git push origin --delete old-branch
-```
+### Advanced
+- `git cherry-pick <commit-hash>`: Apply a specific commit from another branch. **(Use with caution to avoid duplicate commits)**.

zrb/task/llm/default_workflow/coding/golang.md

@@ -1,23 +1,43 @@
 # Go Development Guide
 
-## Core Principles
-- **Follow Go conventions** and effective Go patterns
-- **Use `go fmt`** for consistent formatting
-- **Follow project's package structure** and naming
-
-## Project Analysis
-- Check for: `go.mod`, `go.sum`, `Makefile`
-- Look for project-specific patterns in existing code
-- Identify testing approach: table tests, integration tests
-
-## Implementation Patterns
-- **Error Handling:** Follow project's error wrapping and handling style
-- **Package Organization:** Match existing package boundaries and dependencies
-- **Naming:** Follow Go conventions (camelCase, short names)
-- **Testing:** Use same test organization and helper patterns
-
-## Common Commands
-- Formatting: `go fmt`
-- Testing: `go test`
-- Linting: `golangci-lint`, `staticcheck`
-- Building: `go build`
+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/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/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/task/llm/default_workflow/coding/javascript.md

@@ -1,24 +1,45 @@
 # JavaScript/TypeScript Development Guide
 
-## Core Principles
-- **Follow project's style guide** (ESLint, Prettier, etc.)
-- **Use TypeScript** if the project uses it
-- **Match module system** (CommonJS, ES modules)
-
-## Project Analysis
-- Check for: `package.json`, `tsconfig.json`, `jsconfig.json`
-- Look for style guides: `.eslintrc`, `.prettierrc`, `.editorconfig`
-- Identify testing framework: `jest`, `mocha`, `vitest`
-- Check build tools: `webpack`, `vite`, `rollup`
-
-## Implementation Patterns
-- **Module System:** Follow project's import/export patterns
-- **Error Handling:** Match promise/async patterns and error types
-- **TypeScript:** Use same strictness level and type patterns
-- **Testing:** Use project's test utilities and mocking patterns
-
-## Common Commands
-- Package management: `npm`, `yarn`, `pnpm`
-- Testing: `npm test`, `npm run test`
-- Linting: `npm run lint`, `eslint`
-- Building: `npm run build`, `tsc`
+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/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/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/task/llm/default_workflow/coding/python.md

@@ -1,23 +1,44 @@
 # Python Development Guide
 
-## Core Principles
-- **Follow PEP 8** unless project has specific style guides
-- **Use type hints** if the project uses them
-- **Match existing patterns** for imports, docstrings, and error handling
-
-## Project Analysis
-- Check for: `pyproject.toml`, `requirements.txt`, `setup.py`, `.python-version`
-- Look for style guides: `.flake8`, `.pylintrc`, `ruff.toml`, `mypy.ini`
-- Identify testing framework: `pytest`, `unittest`, `nose`
-
-## Implementation Patterns
-- **Imports:** Follow project's import organization (stdlib, third-party, local)
-- **Error Handling:** Match existing exception patterns and logging
-- **Documentation:** Use same docstring format (Google, NumPy, reStructuredText)
-- **Testing:** Use project's test organization and fixtures
-
-## Common Commands
-- Formatting: `black`, `autopep8`, `yapf`
-- Linting: `flake8`, `pylint`, `ruff`
-- Testing: `pytest`, `python -m unittest`
-- Type checking: `mypy`, `pyright`
+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/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`