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

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

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

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