zrb 1.15.3__py3-none-any.whl → 1.21.29__py3-none-any.whl

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

@@ -0,0 +1,41 @@
+---
+description: "A comprehensive workflow for software engineering tasks, including writing, modifying, and debugging code, as well as creating new applications. ALWAYS activate this workflow whenever you need to deal with software engineering tasks."
+---
+
+This workflow provides a structured approach to software engineering tasks. Adhere to these guidelines to deliver high-quality, idiomatic code that respects the project's existing patterns and conventions.
+
+# Workflow Loading Strategy
+
+This is a general-purpose coding workflow. For tasks involving specific languages or tools, you **MUST** load the relevant specialized workflows.
+
+- **If the task involves Python:** Load the `python` workflow.
+- **If the task involves Git:** Load the `git` workflow.
+- **If the task involves shell scripting:** Load the `shell` workflow.
+- **If the task involves Go:** Load the `golang` workflow.
+- **If the task involves Java:** Load the `java` workflow.
+- **If the task involves Javascript/Typescript:** Load the `javascript` workflow.
+- **If the task involves HTML/CSS:** Load the `html-css` workflow.
+- **If the task involves Rust:** Load the `rust` workflow.
+
+Always consider if a more specific workflow is available and appropriate for the task at hand.
+
+# Core Mandates
+
+- **Conventions:** Rigorously adhere to existing project conventions when reading or modifying code. Analyze surrounding code, tests, and configuration first.
+- **Libraries/Frameworks:** NEVER assume a library/framework is available or appropriate. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', 'build.gradle', etc., or observe neighboring files) before employing it.
+- **Style & Structure:** Mimic the style (formatting, naming), structure, framework choices, typing, and architectural patterns of existing code in the project.
+- **Idiomatic Changes:** When editing, understand the local context (imports, functions/classes) to ensure your changes integrate naturally and idiomatically.
+- **Comments:** Add code comments sparingly. Focus on *why* something is done, especially for complex logic, rather than *what* is done. Only add high-value comments if necessary for clarity or if requested by the user. Do not edit comments that are separate from the code you are changing. *NEVER* talk to the user or describe your changes through comments.
+- **Proactiveness:** Fulfill the user's request thoroughly. When adding features or fixing bugs, this includes adding tests to ensure quality. Consider all created files, especially tests, to be permanent artifacts unless the user says otherwise.
+- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If asked *how* to do something, explain first, don't just do it.
+- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
+- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
+
+# Software Engineering Tasks
+When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
+1. **Understand & Strategize:** Think about the user's request and the relevant codebase context. When the task involves **complex refactoring, codebase exploration or system-wide analysis**, your **first and primary tool** must be 'codebase_investigator'. Use it to build a comprehensive understanding of the code, its structure, and dependencies. For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), you should use 'search_file_content' or 'glob' directly.
+2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
+3. **Implement:** Use the available tools (e.g., 'replace_in_file', 'write_to_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
+4. **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.
+5. **Verify (Standards):** VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.
+6. **Finalize:** After all verification passes, consider the task complete. Do not remove or revert any changes or created files (like tests). Await the user's next instruction.

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

@@ -0,0 +1,68 @@
+---
+description: "A workflow for creating, refining, and organizing textual content."
+---
+Follow this workflow to produce content that is not just correct, but compelling, clear, and perfectly suited to its purpose.
+
+# Core Mandates
+
+- **Audience-First:** Always understand who you're writing for and what they need to know
+- **Purpose-Driven:** Every piece of content must serve a clear objective
+- **Quality Standards:** Deliver polished, professional content that meets the highest standards
+- **Iterative Refinement:** Content improves through multiple rounds of review and editing
+
+# Tool Usage Guideline
+- Use `read_from_file` to analyze existing content and style guides
+- Use `write_to_file` for creating new content drafts
+- Use `replace_in_file` for targeted edits and refinements
+
+# Step 1: Understand Intent and Audience
+
+1. **Define the Goal:** What is this text supposed to achieve? (e.g., persuade, inform, entertain, sell). If the user is vague, ask for clarification.
+2. **Identify the Audience:** Who are you writing for? (e.g., experts, beginners, customers). This dictates your tone, vocabulary, and level of detail.
+3. **Determine the Tone:** Choose a voice that serves the goal and resonates with the audience (e.g., formal, witty, technical, urgent).
+4. **Analyze Existing Content:** Review any provided examples, style guides, or reference materials to understand established patterns.
+
+# Step 2: Plan and Outline
+
+1. **Create Logical Structure:** Develop an outline that flows naturally from introduction to conclusion
+2. **Key Sections:** Identify main talking points and supporting arguments
+3. **Call-to-Action:** Define what you want the reader to do or think after reading
+4. **Get Approval:** Present the outline to the user for confirmation before proceeding
+
+# Step 3: Draft with Purpose
+
+1. **Hook the Reader:** Start with a strong opening that grabs attention
+2. **Use Active Voice:** Make your writing direct and energetic
+3. **Show, Don't Just Tell:** Use examples, stories, and data to illustrate your points
+4. **Maintain Consistency:** Stick to the established tone and style throughout
+
+# Step 4: Refine and Polish
+
+1. **Read Aloud:** Catch awkward phrasing and grammatical errors
+2. **Cut Mercilessly:** Remove anything that doesn't serve the goal
+3. **Enhance Readability:** Use short paragraphs, headings, bullet points, and bold text
+4. **Verify Accuracy:** Ensure all facts, figures, and claims are correct
+
+# Step 5: Task-Specific Execution
+
+## Summarization
+- Distill the essence while preserving key information
+- Be objective and ruthless in cutting fluff
+- Maintain the original meaning and context
+
+## Proofreading
+- Correct grammar, spelling, and punctuation
+- Improve sentence flow and clarity
+- Preserve the original meaning and voice
+
+## Refining/Editing
+- Sharpen the author's message
+- Strengthen arguments and improve clarity
+- Ensure consistent tone while respecting the original voice
+
+# Step 6: Finalize and Deliver
+
+- Present the final content to the user
+- Be prepared to make additional refinements based on feedback
+- Ensure the content meets all stated objectives
+- Confirm the content is ready for its intended use

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

@@ -0,0 +1,118 @@
+---
+description: "A workflow for managing version control with git."
+---
+Follow this workflow for safe, consistent, and effective version control operations.
+
+# Core Mandates
+
+- **Safety First:** Never force operations that could lose data
+- **Atomic Commits:** One logical change per commit
+- **Descriptive Messages:** Explain the "why" in imperative mood
+- **Clean History:** Maintain a readable and useful commit history
+
+# Tool Usage Guideline
+- Use `run_shell_command` for all git operations
+- Use `read_from_file` to examine git configuration files
+- Use `search_files` to find specific commit messages or patterns
+
+# Step 1: Pre-Operation Safety Check
+
+1. **Check Status:** Always run `git status` before operations
+2. **Verify Working Directory:** Ensure the working directory is clean before destructive operations
+3. **Review Changes:** Use `git diff` and `git diff --staged` to understand what will be committed
+4. **Backup Important Changes:** Consider stashing or creating a backup branch for risky operations
+
+# Step 2: Standard Development Workflow
+
+1. **Create Feature Branch:** `git checkout -b <branch-name>`
+2. **Make Changes:** Implement features or fixes
+3. **Stage Changes:** Use `git add -p` for precision staging
+4. **Commit with Description:** Write clear, descriptive commit messages
+5. **Review and Amend:** Use `git log -1` to review, amend if needed
+6. **Push to Remote:** `git push origin <branch-name>`
+
+# Step 3: Commit Message Standards
+
+```
+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.
+```
+
+- **Type Prefix:** feat, fix, docs, style, refactor, test, chore
+- **Imperative Mood:** "Add feature" not "Added feature"
+- **50/72 Rule:** 50 character subject, 72 character body lines
+
+# Step 4: Branch Management
+
+## Safe Branch Operations
+- **Create:** `git checkout -b <name>` or `git switch -c <name>`
+- **Switch:** `git switch <name>`
+- **Update:** `git rebase main` (use with care)
+- **Merge:** `git merge --no-ff <branch>` for explicit merge commits
+
+## Remote Branch Operations
+- **Fetch Updates:** `git fetch origin`
+- **Push:** `git push origin <branch>`
+- **Delete Remote:** `git push origin --delete <branch>`
+
+# Step 5: Advanced Operations (Use with Caution)
+
+## Rebasing
+- **Update Branch:** `git rebase main`
+- **Interactive:** `git rebase -i <commit>` for history editing
+- **Safety:** Never rebase shared/public branches
+
+## Stashing
+- **Save Changes:** `git stash push -m "message"`
+- **List Stashes:** `git stash list`
+- **Apply:** `git stash pop` or `git stash apply`
+
+## Cherry-picking
+- **Apply Specific Commit:** `git cherry-pick <commit-hash>`
+- **Use Case:** Only when absolutely necessary to avoid duplicate commits
+
+# Step 6: Verification and Cleanup
+
+1. **Verify Operations:** Check `git status` and `git log` after operations
+2. **Run Tests:** Ensure all tests pass after changes
+3. **Clean Up:** Remove temporary branches and stashes when no longer needed
+4. **Document:** Update documentation if workflow changes affect team processes
+
+# Risk Assessment Guidelines
+
+## Low Risk (Proceed Directly)
+- `git status`, `git log`, `git diff`
+- Creating new branches
+- Stashing changes
+
+## Moderate Risk (Explain and Confirm)
+- `git rebase` operations
+- `git push --force-with-lease`
+- Deleting branches
+
+## High Risk (Refuse and Explain)
+- `git push --force` (use --force-with-lease instead)
+- Operations that could lose commit history
+- Modifying shared/public branches
+
+# Common Commands 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
+
+## Branch Operations
+- `git branch -a`: List all branches (local and remote)
+- `git branch -d <branch>`: Delete a local branch
+- `git remote prune origin`: Clean up remote tracking branches
+
+## Configuration
+- `git config --list`: View current configuration
+- `git config user.name "Your Name"`: Set user name
+- `git config user.email "your.email@example.com"`: Set user email

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

@@ -0,0 +1,128 @@
+---
+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

@@ -0,0 +1,135 @@
+---
+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

@@ -0,0 +1,146 @@
+---
+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