zrb 1.21.29__py3-none-any.whl → 2.0.0a4__py3-none-any.whl

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

@@ -1,128 +0,0 @@
----
-description: "A workflow for developing with Go, including project analysis and best practices."
----
-Follow this workflow to deliver high-quality, idiomatic Go code that respects project conventions.
-
-# Core Mandates
-
-- **Simplicity First:** Write clear, simple, and readable code
-- **Idiomatic Go:** Follow Go conventions and community standards
-- **Tool Integration:** Leverage Go's excellent tooling ecosystem
-- **Safety and Reliability:** Write robust, well-tested code
-
-# Tool Usage Guideline
-- Use `read_from_file` to analyze Go modules and configuration
-- Use `search_files` to find Go patterns and conventions
-- Use `run_shell_command` for Go toolchain operations
-- Use `list_files` to understand project structure
-
-# Step 1: Project Analysis
-
-1. **Module Information:** Examine `go.mod` for module path and dependencies
-2. **Workspace:** Check for `go.work` for multi-module workspace configuration
-3. **Tooling:** Look for `Makefile` with build, test, and lint commands
-4. **CI/CD Configuration:** Check `.github/workflows/go.yml` for verification commands
-5. **Linting Config:** Examine `.golangci.yml` for linting rules
-6. **Package Structure:** Analyze `pkg/`, `internal/`, and `cmd/` directories
-
-# Step 2: Understand Conventions
-
-1. **Formatting:** `go fmt` is mandatory for all code
-2. **Linting:** Adhere to project's `golangci-lint` configuration
-3. **Package Naming:** Use short, concise, all-lowercase package names
-4. **Error Handling:** Match existing error handling patterns
-5. **Testing:** Follow established test structure and patterns
-
-# Step 3: Implementation Planning
-
-1. **File Structure:** Plan where new code should be placed based on project conventions
-2. **Dependencies:** Identify if new dependencies are needed and verify they're appropriate
-3. **API Design:** Consider how new code integrates with existing APIs
-4. **Testing Strategy:** Plan comprehensive tests for new functionality
-
-# Step 4: Write Code
-
-## Code Quality Standards
-- **Formatting:** All code must be `go fmt` compliant
-- **Linting:** Address all `golangci-lint` warnings
-- **Naming:** Follow Go naming conventions (camelCase for variables, PascalCase for exports)
-- **Documentation:** Add godoc comments for exported functions and types
-
-## Implementation Patterns
-- **Error Handling:** Use appropriate error wrapping based on project patterns
-- **Concurrency:** Follow existing goroutine and channel usage patterns
-- **Interfaces:** Define small, focused interfaces
-- **Composition:** Prefer composition over inheritance
-
-# Step 5: Testing and Verification
-
-1. **Write Tests:** Create comprehensive tests for all new functionality
-2. **Run Tests:** Execute `go test ./...` to verify functionality
-3. **Format Code:** Run `go fmt ./...` to ensure proper formatting
-4. **Lint Code:** Run `golangci-lint run` to catch issues
-5. **Build Verification:** Run `go build ./...` to ensure code compiles
-
-# Step 6: Quality Assurance
-
-## Testing Standards
-- **Table-Driven Tests:** Use for comprehensive test coverage
-- **Test Files:** Place tests in `_test.go` files within the same package
-- **Benchmarks:** Add benchmarks for performance-critical code
-- **Examples:** Include example code in documentation
-
-## Code Review Checklist
-- [ ] Code follows project formatting standards
-- [ ] All tests pass
-- [ ] No linting warnings
-- [ ] Error handling is appropriate
-- [ ] Documentation is complete
-- [ ] Performance considerations addressed
-
-# Step 7: Finalize and Deliver
-
-1. **Verify Dependencies:** Run `go mod tidy` to clean up dependencies
-2. **Run Full Test Suite:** Ensure all existing tests still pass
-3. **Document Changes:** Update relevant documentation
-4. **Prepare for Review:** Ensure code is ready for team review
-
-# Common Commands Reference
-
-## Development
-- `go fmt ./...`: Format all Go code
-- `go vet ./...`: Report suspicious constructs
-- `go build ./...`: Build all packages
-- `go run ./cmd/my-app`: Run a specific application
-
-## Testing
-- `go test ./...`: Run all tests
-- `go test -v ./...`: Run tests with verbose output
-- `go test -race ./...`: Run tests with race detector
-- `go test -bench=. ./...`: Run benchmarks
-
-## Dependency Management
-- `go mod tidy`: Add missing and remove unused modules
-- `go mod download`: Download modules to local cache
-- `go list -m all`: List all dependencies
-- `go get package@version`: Add or update a dependency
-
-## Debugging
-- `dlv debug`: Debug with Delve
-- `go tool pprof`: Performance profiling
-- `go tool trace`: Execution tracing
-
-# Risk Assessment Guidelines
-
-## Low Risk (Proceed Directly)
-- Reading configuration files
-- Running tests and linters
-- Adding tests to existing packages
-
-## Moderate Risk (Explain and Confirm)
-- Adding new dependencies
-- Modifying core business logic
-- Changing public API interfaces
-
-## High Risk (Refuse and Explain)
-- Modifying critical system paths
-- Operations that could break the build
-- Changes that affect multiple teams

zrb/task/llm/default_workflow/html-css/workflow.md

@@ -1,135 +0,0 @@
----
-description: "A workflow for developing with HTML and CSS, including project analysis and best practices."
----
-Follow this workflow to create accessible, responsive, and maintainable web interfaces.
-
-# Core Mandates
-
-- **Semantic HTML:** Use HTML elements for their intended purpose
-- **Accessibility First:** Ensure content is accessible to all users
-- **Responsive Design:** Create interfaces that work across all devices
-- **Performance:** Optimize for fast loading and smooth interactions
-
-# Tool Usage Guideline
-- Use `read_from_file` to analyze HTML/CSS structure and patterns
-- Use `search_files` to find specific styles or markup patterns
-- Use `run_shell_command` for linting and formatting tools
-- Use `list_files` to understand project structure
-
-# Step 1: Project Analysis
-
-1. **HTML Files:** Examine `*.html` for structure, doctype, and meta tags
-2. **CSS Files:** Analyze `*.css` for architecture (BEM, SMACSS) and frameworks
-3. **Preprocessors:** Check for Sass (`*.scss`), Less (`*.less`), or other preprocessors
-4. **Frameworks:** Identify usage of Bootstrap, Tailwind CSS, or other CSS frameworks
-5. **Configuration:** Look for `.stylelintrc`, `.prettierrc`, and other config files
-6. **Build Tools:** Check for Webpack, Vite, or other build configurations
-
-# Step 2: Understand Conventions
-
-1. **HTML Standards:** Follow semantic HTML5 elements and attributes
-2. **CSS Methodology:** Adhere to project's CSS architecture (BEM, SMACSS, etc.)
-3. **Accessibility:** Implement WCAG guidelines and ARIA attributes
-4. **Responsive Patterns:** Follow established breakpoints and grid systems
-5. **Performance:** Optimize images, minimize CSS, and leverage browser caching
-
-# Step 3: Implementation Planning
-
-1. **Component Structure:** Plan HTML structure based on project patterns
-2. **Styling Approach:** Determine CSS organization and naming conventions
-3. **Responsive Strategy:** Plan breakpoints and adaptive layouts
-4. **Accessibility:** Identify required ARIA attributes and keyboard navigation
-5. **Browser Compatibility:** Consider cross-browser testing requirements
-
-# Step 4: Write Markup and Styles
-
-## HTML Best Practices
-- **Semantic Structure:** Use appropriate elements (`<nav>`, `<main>`, `<article>`, etc.)
-- **Accessibility:** Include `alt` attributes, proper headings, and ARIA labels
-- **SEO Optimization:** Use proper meta tags and semantic markup
-- **Performance:** Minimize DOM depth and avoid unnecessary elements
-
-## CSS Best Practices
-- **Methodology:** Follow established naming conventions (BEM, etc.)
-- **Organization:** Use logical grouping and consistent ordering
-- **Responsive Design:** Implement mobile-first media queries
-- **Performance:** Minimize specificity and avoid expensive selectors
-- **Maintainability:** Use variables and modular organization
-
-# Step 5: Testing and Verification
-
-1. **HTML Validation:** Validate markup using W3C validator
-2. **Accessibility Testing:** Test with screen readers and accessibility tools
-3. **Cross-Browser Testing:** Verify rendering across target browsers
-4. **Responsive Testing:** Test on different screen sizes and devices
-5. **Performance Testing:** Check load times and rendering performance
-
-# Step 6: Quality Assurance
-
-## Linting and Formatting
-- **HTML Linting:** Use tools like HTMLHint or validator
-- **CSS Linting:** Run `stylelint` with project configuration
-- **Formatting:** Use Prettier or project-specific formatters
-- **Code Quality:** Ensure consistent indentation and organization
-
-## Browser Compatibility
-- **Progressive Enhancement:** Ensure core functionality works everywhere
-- **Feature Detection:** Use modern features with fallbacks
-- **Vendor Prefixing:** Use Autoprefixer for cross-browser compatibility
-
-# Step 7: Optimization
-
-## Performance Optimization
-- **CSS Minification:** Use tools like cssnano for production
-- **Image Optimization:** Compress and use appropriate formats
-- **Critical CSS:** Inline above-the-fold styles for faster rendering
-- **Lazy Loading:** Defer non-critical resources
-
-## Accessibility Optimization
-- **Keyboard Navigation:** Ensure all interactive elements are keyboard accessible
-- **Screen Reader Compatibility:** Test with NVDA, VoiceOver, or JAWS
-- **Color Contrast:** Verify sufficient contrast ratios
-- **Focus Management:** Implement proper focus indicators and order
-
-# Step 8: Finalize and Deliver
-
-1. **Final Validation:** Run comprehensive validation and testing
-2. **Documentation:** Update style guides or component documentation
-3. **Performance Review:** Verify optimization targets are met
-4. **Accessibility Audit:** Complete final accessibility checks
-
-# Common Commands Reference
-
-## Development Tools
-- `stylelint "**/*.css"`: Lint CSS files
-- `prettier --check "**/*.html"`: Check HTML formatting
-- `prettier --write "**/*.{html,css}"`: Format HTML and CSS files
-- `npx htmlhint "**/*.html"`: Lint HTML files
-
-## Build and Optimization
-- `npm run build`: Build project (if using build tools)
-- `npm run dev`: Start development server
-- `npm run lint`: Run all linting
-- `npm run format`: Format all code
-
-## Testing
-- `npm test`: Run tests (if test framework configured)
-- Browser developer tools for manual testing
-- Lighthouse for performance and accessibility audits
-
-# Risk Assessment Guidelines
-
-## Low Risk (Proceed Directly)
-- Adding new CSS classes following established patterns
-- Creating new HTML components with semantic markup
-- Running linters and validators
-
-## Moderate Risk (Explain and Confirm)
-- Modifying core layout or grid systems
-- Changing established CSS architecture
-- Adding new dependencies or frameworks
-
-## High Risk (Refuse and Explain)
-- Breaking existing responsive layouts
-- Removing accessibility features
-- Changes that affect multiple pages or components

zrb/task/llm/default_workflow/java/workflow.md

@@ -1,146 +0,0 @@
----
-description: "A workflow for developing with Java, including project analysis and best practices."
----
-Follow this workflow to deliver robust, maintainable Java code that follows project conventions.
-
-# Core Mandates
-
-- **Object-Oriented Excellence:** Follow SOLID principles and design patterns
-- **Type Safety:** Leverage Java's strong typing system
-- **Tool Integration:** Use Maven/Gradle and IDE tools effectively
-- **Enterprise Standards:** Follow established Java enterprise patterns
-
-# Tool Usage Guideline
-- Use `read_from_file` to analyze build configurations and source code
-- Use `search_files` to find Java patterns and conventions
-- Use `run_shell_command` for build and test operations
-- Use `list_files` to understand project structure
-
-# Step 1: Project Analysis
-
-1. **Build System:** Examine `pom.xml` (Maven) or `build.gradle` (Gradle)
-2. **Java Version:** Check `.java-version` or build configuration
-3. **Style Configuration:** Look for `.checkstyle.xml`, `.pmd.xml`, `.editorconfig`
-4. **Testing Framework:** Analyze `src/test/java` and test dependencies
-5. **Project Structure:** Understand package organization and module boundaries
-6. **Dependencies:** Review dependency management and versioning
-
-# Step 2: Understand Conventions
-
-1. **Code Style:** Adhere to project's configured linter (Checkstyle, PMD)
-2. **Package Organization:** Follow established package naming and structure
-3. **Class Design:** Use appropriate design patterns and principles
-4. **Exception Handling:** Follow project's exception handling strategy
-5. **Testing Patterns:** Use established test frameworks and patterns
-
-# Step 3: Implementation Planning
-
-1. **Class Structure:** Plan new classes and interfaces based on project patterns
-2. **Package Placement:** Determine appropriate package for new code
-3. **Dependencies:** Identify required dependencies and verify compatibility
-4. **API Design:** Consider public interfaces and backward compatibility
-5. **Testing Strategy:** Plan comprehensive unit and integration tests
-
-# Step 4: Write Code
-
-## Code Quality Standards
-- **Formatting:** Follow project's code style configuration
-- **Documentation:** Add Javadoc for public APIs and complex logic
-- **Naming:** Use clear, descriptive names following Java conventions
-- **Immutability:** Prefer immutable objects where appropriate
-- **Composition:** Favor composition over inheritance
-
-## Implementation Patterns
-- **Exception Handling:** Use checked exceptions for recoverable errors, unchecked for programming errors
-- **Collections:** Use appropriate collection types and avoid raw types
-- **Streams:** Leverage Java Streams for functional-style operations
-- **Optional:** Use `Optional` for nullable return values
-- **Records:** Use records for data carrier classes (Java 14+)
-
-# Step 5: Testing and Verification
-
-1. **Write Unit Tests:** Create comprehensive tests for all new functionality
-2. **Run Tests:** Execute `mvn test` or `gradle test` to verify functionality
-3. **Static Analysis:** Run Checkstyle, PMD, or other configured linters
-4. **Build Verification:** Ensure code compiles without warnings
-5. **Integration Tests:** Add integration tests for cross-component functionality
-
-# Step 6: Quality Assurance
-
-## Testing Standards
-- **Test Structure:** Follow project's test organization patterns
-- **Mocking:** Use appropriate mocking frameworks (Mockito, etc.)
-- **Assertions:** Use fluent assertion libraries (AssertJ, Hamcrest)
-- **Coverage:** Aim for high test coverage of business logic
-
-## Code Review Checklist
-- [ ] Code follows project formatting standards
-- [ ] All tests pass with good coverage
-- [ ] No static analysis warnings
-- [ ] Exception handling is appropriate
-- [ ] Javadoc is complete for public APIs
-- [ ] Performance considerations addressed
-- [ ] Thread safety considered where needed
-
-# Step 7: Build and Deployment
-
-## Maven Commands
-- `mvn clean`: Clean build artifacts
-- `mvn compile`: Compile source code
-- `mvn test`: Run unit tests
-- `mvn package`: Create deployable package
-- `mvn install`: Install to local repository
-- `mvn verify`: Run integration tests
-
-## Gradle Commands
-- `./gradlew clean`: Clean build artifacts
-- `./gradlew build`: Build and test
-- `./gradlew test`: Run unit tests
-- `./gradlew check`: Run all checks
-
-# Step 8: Finalize and Deliver
-
-1. **Verify Dependencies:** Ensure dependency versions are consistent
-2. **Run Full Test Suite:** Verify all existing tests still pass
-3. **Static Analysis:** Address any remaining linting issues
-4. **Documentation:** Update relevant documentation and Javadoc
-5. **Performance Testing:** Verify performance characteristics
-
-# Advanced Java Features
-
-## Modern Java (8+)
-- **Lambdas:** Use for concise functional programming
-- **Streams:** Process collections efficiently
-- **Optional:** Handle null values safely
-- **Modules:** Use Java Platform Module System (JPMS) if configured
-
-## Concurrency
-- **CompletableFuture:** For asynchronous programming
-- **Executors:** Manage thread pools effectively
-- **Concurrent Collections:** Use thread-safe collections
-- **Synchronization:** Prefer higher-level concurrency utilities
-
-## Enterprise Patterns
-- **Dependency Injection:** Use Spring, CDI, or other DI frameworks
-- **AOP:** Implement cross-cutting concerns appropriately
-- **Persistence:** Follow established ORM patterns (JPA, Hibernate)
-- **REST APIs:** Use JAX-RS or Spring MVC consistently
-
-# Risk Assessment Guidelines
-
-## Low Risk (Proceed Directly)
-- Adding tests to existing test suites
-- Implementing utility methods in existing classes
-- Following established patterns in new classes
-
-## Moderate Risk (Explain and Confirm)
-- Modifying core business logic
-- Changing public API interfaces
-- Adding new dependencies
-- Modifying build configuration
-
-## High Risk (Refuse and Explain)
-- Breaking backward compatibility
-- Modifying critical security components
-- Changes affecting multiple modules
-- Operations that could break the build system

zrb/task/llm/default_workflow/javascript/workflow.md

@@ -1,158 +0,0 @@
----
-description: "A workflow for developing with JavaScript and TypeScript, including project analysis and best practices."
----
-Follow this workflow to deliver robust, maintainable JavaScript/TypeScript code that follows project conventions.
-
-# Core Mandates
-
-- **Type Safety First:** Use TypeScript when available, proper typing in JavaScript
-- **Modern Standards:** Follow ES6+ features and best practices
-- **Framework Consistency:** Adhere to project's framework conventions
-- **Tool Integration:** Leverage comprehensive JavaScript tooling ecosystem
-
-# Tool Usage Guideline
-- Use `read_from_file` to analyze package.json and configuration files
-- Use `search_files` to find JavaScript/TypeScript patterns
-- Use `run_shell_command` for npm/yarn/pnpm operations
-- Use `list_files` to understand project structure
-
-# Step 1: Project Analysis
-
-1. **Package Management:** Examine `package.json` and lock files (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`)
-2. **TypeScript Configuration:** Check for `tsconfig.json` and TypeScript usage
-3. **Linting Configuration:** Look for `.eslintrc.js`, `.prettierrc`, ESLint config in `package.json`
-4. **Build Configuration:** Analyze `webpack.config.js`, `vite.config.ts`, `rollup.config.js`
-5. **Testing Framework:** Check for `jest.config.js`, `vitest.config.ts`, test directories
-6. **Framework Usage:** Identify React, Vue, Angular, or other framework usage
-
-# Step 2: Understand Conventions
-
-1. **Module System:** Determine ES Modules (`import/export`) vs CommonJS (`require/module.exports`)
-2. **TypeScript Strictness:** Adhere to project's TypeScript configuration
-3. **Framework Patterns:** Follow established component, state management, and routing patterns
-4. **Styling Approach:** Understand CSS-in-JS, CSS modules, or traditional CSS usage
-5. **Testing Strategy:** Follow established test patterns and mocking approaches
-
-# Step 3: Implementation Planning
-
-1. **File Structure:** Plan where new code should be placed based on project conventions
-2. **Type Definitions:** Plan TypeScript interfaces and types for new functionality
-3. **Component Design:** Design React/Vue/Angular components following established patterns
-4. **State Management:** Determine appropriate state management approach
-5. **Testing Strategy:** Plan comprehensive unit, integration, and end-to-end tests
-
-# Step 4: Write Code
-
-## Code Quality Standards
-- **Formatting:** Use Prettier with project configuration
-- **Linting:** Follow ESLint rules and address all warnings
-- **Type Safety:** Use TypeScript strictly when available
-- **Naming:** Use clear, descriptive names following project conventions
-- **Documentation:** Add JSDoc/TSDoc for complex functions and public APIs
-
-## Framework-Specific Patterns
-
-### React
-- **Functional Components:** Use hooks-based functional components
-- **State Management:** Follow established patterns (useState, useReducer, Redux, etc.)
-- **Performance:** Use React.memo, useMemo, useCallback appropriately
-- **Testing:** Use React Testing Library and established testing patterns
-
-### Vue
-- **Composition API:** Prefer Composition API over Options API
-- **State Management:** Use Pinia or Vuex following project patterns
-- **Component Structure:** Follow single-file component conventions
-- **Testing:** Use Vue Test Utils and established testing patterns
-
-### Angular
-- **Component Structure:** Follow Angular module and component conventions
-- **Dependency Injection:** Use Angular's DI system appropriately
-- **RxJS:** Follow established reactive programming patterns
-- **Testing:** Use Angular Testing utilities and established patterns
-
-# Step 5: Testing and Verification
-
-1. **Write Tests:** Create comprehensive tests for all new functionality
-2. **Run Tests:** Execute `npm test` or framework-specific test commands
-3. **Type Checking:** Run `npm run typecheck` or `tsc --noEmit`
-4. **Linting:** Run `npm run lint` to catch code quality issues
-5. **Build Verification:** Run `npm run build` to ensure code compiles correctly
-
-# Step 6: Quality Assurance
-
-## Testing Standards
-- **Unit Tests:** Test individual functions and components in isolation
-- **Integration Tests:** Test component interactions and API integrations
-- **End-to-End Tests:** Test complete user workflows (if configured)
-- **Mocking:** Use appropriate mocking libraries and patterns
-- **Coverage:** Aim for high test coverage of business logic
-
-## Code Review Checklist
-- [ ] Code follows project formatting and linting standards
-- [ ] All tests pass with good coverage
-- [ ] TypeScript compiles without errors (if applicable)
-- [ ] No ESLint warnings
-- [ ] Documentation is complete for complex logic
-- [ ] Performance considerations addressed
-- [ ] Accessibility requirements met
-
-# Step 7: Package Management
-
-## Dependency Management
-- **npm:** Use `npm install <package>` for new dependencies
-- **yarn:** Use `yarn add <package>` for new dependencies
-- **pnpm:** Use `pnpm add <package>` for new dependencies
-- **Version Management:** Follow project's versioning strategy
-
-## Script Execution
-- `npm install` / `yarn install` / `pnpm install`: Install dependencies
-- `npm run dev` / `yarn dev` / `pnpm dev`: Start development server
-- `npm run build` / `yarn build` / `pnpm build`: Build for production
-- `npm run lint` / `yarn lint` / `pnpm lint`: Run linting
-
-# Step 8: Finalize and Deliver
-
-1. **Verify Dependencies:** Ensure dependency versions are consistent
-2. **Run Full Test Suite:** Verify all existing tests still pass
-3. **Type Checking:** Ensure TypeScript compilation succeeds
-4. **Build Verification:** Confirm production build works correctly
-5. **Documentation:** Update relevant documentation and comments
-
-# Common Commands Reference
-
-## Development
-- `npm run dev`: Start development server
-- `npm run build`: Build for production
-- `npm run typecheck`: Type check TypeScript code
-- `npm run lint`: Run ESLint
-- `npm run format`: Format code with Prettier
-
-## Testing
-- `npm test`: Run tests
-- `npm run test:watch`: Run tests in watch mode
-- `npm run test:coverage`: Run tests with coverage
-- `npm run test:e2e`: Run end-to-end tests (if configured)
-
-## Debugging
-- Browser developer tools for frontend debugging
-- `node --inspect` for Node.js debugging
-- Framework-specific debugging tools
-
-# Risk Assessment Guidelines
-
-## Low Risk (Proceed Directly)
-- Adding tests to existing test suites
-- Implementing utility functions following established patterns
-- Creating new components in established patterns
-
-## Moderate Risk (Explain and Confirm)
-- Modifying core application state
-- Changing public API interfaces
-- Adding new dependencies
-- Modifying build configuration
-
-## High Risk (Refuse and Explain)
-- Breaking TypeScript strict mode compliance
-- Modifying critical security components
-- Changes affecting multiple applications
-- Operations that could break the build system