zrb 1.13.1__py3-none-any.whl → 1.21.17__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- zrb/__init__.py +2 -6
- zrb/attr/type.py +8 -8
- zrb/builtin/__init__.py +2 -0
- zrb/builtin/group.py +31 -15
- zrb/builtin/http.py +7 -8
- zrb/builtin/llm/attachment.py +40 -0
- zrb/builtin/llm/chat_session.py +130 -144
- zrb/builtin/llm/chat_session_cmd.py +226 -0
- zrb/builtin/llm/chat_trigger.py +73 -0
- zrb/builtin/llm/history.py +4 -4
- zrb/builtin/llm/llm_ask.py +218 -110
- zrb/builtin/llm/tool/api.py +74 -62
- zrb/builtin/llm/tool/cli.py +35 -16
- zrb/builtin/llm/tool/code.py +49 -47
- zrb/builtin/llm/tool/file.py +262 -251
- zrb/builtin/llm/tool/note.py +84 -0
- zrb/builtin/llm/tool/rag.py +25 -18
- zrb/builtin/llm/tool/sub_agent.py +29 -22
- zrb/builtin/llm/tool/web.py +135 -143
- zrb/builtin/project/add/fastapp/fastapp_template/my_app_name/_zrb/entity/add_entity_util.py +7 -7
- zrb/builtin/project/add/fastapp/fastapp_template/my_app_name/_zrb/module/add_module_util.py +5 -5
- zrb/builtin/project/add/fastapp/fastapp_util.py +1 -1
- zrb/builtin/searxng/config/settings.yml +5671 -0
- zrb/builtin/searxng/start.py +21 -0
- zrb/builtin/setup/latex/ubuntu.py +1 -0
- zrb/builtin/setup/ubuntu.py +1 -1
- zrb/builtin/shell/autocomplete/bash.py +4 -3
- zrb/builtin/shell/autocomplete/zsh.py +4 -3
- zrb/config/config.py +255 -78
- zrb/config/default_prompt/file_extractor_system_prompt.md +109 -9
- zrb/config/default_prompt/interactive_system_prompt.md +24 -30
- zrb/config/default_prompt/persona.md +1 -1
- zrb/config/default_prompt/repo_extractor_system_prompt.md +31 -31
- zrb/config/default_prompt/repo_summarizer_system_prompt.md +27 -8
- zrb/config/default_prompt/summarization_prompt.md +8 -13
- zrb/config/default_prompt/system_prompt.md +36 -30
- zrb/config/llm_config.py +129 -24
- zrb/config/llm_context/config.py +127 -90
- zrb/config/llm_context/config_parser.py +1 -7
- zrb/config/llm_context/workflow.py +81 -0
- zrb/config/llm_rate_limitter.py +89 -45
- zrb/context/any_shared_context.py +7 -1
- zrb/context/context.py +8 -2
- zrb/context/shared_context.py +6 -8
- zrb/group/any_group.py +12 -5
- zrb/group/group.py +67 -3
- zrb/input/any_input.py +5 -1
- zrb/input/base_input.py +18 -6
- zrb/input/text_input.py +7 -24
- zrb/runner/cli.py +21 -20
- zrb/runner/common_util.py +24 -19
- zrb/runner/web_route/task_input_api_route.py +5 -5
- zrb/runner/web_route/task_session_api_route.py +1 -4
- zrb/runner/web_util/user.py +7 -3
- zrb/session/any_session.py +12 -6
- zrb/session/session.py +39 -18
- zrb/task/any_task.py +24 -3
- zrb/task/base/context.py +17 -9
- zrb/task/base/execution.py +15 -8
- zrb/task/base/lifecycle.py +8 -4
- zrb/task/base/monitoring.py +12 -7
- zrb/task/base_task.py +69 -5
- zrb/task/base_trigger.py +12 -5
- zrb/task/llm/agent.py +138 -52
- zrb/task/llm/config.py +45 -13
- zrb/task/llm/conversation_history.py +76 -6
- zrb/task/llm/conversation_history_model.py +0 -168
- zrb/task/llm/default_workflow/coding/workflow.md +41 -0
- zrb/task/llm/default_workflow/copywriting/workflow.md +68 -0
- zrb/task/llm/default_workflow/git/workflow.md +118 -0
- zrb/task/llm/default_workflow/golang/workflow.md +128 -0
- zrb/task/llm/default_workflow/html-css/workflow.md +135 -0
- zrb/task/llm/default_workflow/java/workflow.md +146 -0
- zrb/task/llm/default_workflow/javascript/workflow.md +158 -0
- zrb/task/llm/default_workflow/python/workflow.md +160 -0
- zrb/task/llm/default_workflow/researching/workflow.md +153 -0
- zrb/task/llm/default_workflow/rust/workflow.md +162 -0
- zrb/task/llm/default_workflow/shell/workflow.md +299 -0
- zrb/task/llm/file_replacement.py +206 -0
- zrb/task/llm/file_tool_model.py +57 -0
- zrb/task/llm/history_summarization.py +22 -35
- zrb/task/llm/history_summarization_tool.py +24 -0
- zrb/task/llm/print_node.py +182 -63
- zrb/task/llm/prompt.py +213 -153
- zrb/task/llm/tool_wrapper.py +210 -53
- zrb/task/llm/workflow.py +76 -0
- zrb/task/llm_task.py +98 -47
- zrb/task/make_task.py +2 -3
- zrb/task/rsync_task.py +25 -10
- zrb/task/scheduler.py +4 -4
- zrb/util/attr.py +50 -40
- zrb/util/cli/markdown.py +12 -0
- zrb/util/cli/text.py +30 -0
- zrb/util/file.py +27 -11
- zrb/util/{llm/prompt.py → markdown.py} +2 -3
- zrb/util/string/conversion.py +1 -1
- zrb/util/truncate.py +23 -0
- zrb/util/yaml.py +204 -0
- {zrb-1.13.1.dist-info → zrb-1.21.17.dist-info}/METADATA +40 -20
- {zrb-1.13.1.dist-info → zrb-1.21.17.dist-info}/RECORD +102 -79
- {zrb-1.13.1.dist-info → zrb-1.21.17.dist-info}/WHEEL +1 -1
- zrb/task/llm/default_workflow/coding.md +0 -24
- zrb/task/llm/default_workflow/copywriting.md +0 -17
- zrb/task/llm/default_workflow/researching.md +0 -18
- {zrb-1.13.1.dist-info → zrb-1.21.17.dist-info}/entry_points.txt +0 -0
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "A workflow for developing with HTML and CSS, including project analysis and best practices."
|
|
3
|
+
---
|
|
4
|
+
Follow this workflow to create accessible, responsive, and maintainable web interfaces.
|
|
5
|
+
|
|
6
|
+
# Core Mandates
|
|
7
|
+
|
|
8
|
+
- **Semantic HTML:** Use HTML elements for their intended purpose
|
|
9
|
+
- **Accessibility First:** Ensure content is accessible to all users
|
|
10
|
+
- **Responsive Design:** Create interfaces that work across all devices
|
|
11
|
+
- **Performance:** Optimize for fast loading and smooth interactions
|
|
12
|
+
|
|
13
|
+
# Tool Usage Guideline
|
|
14
|
+
- Use `read_from_file` to analyze HTML/CSS structure and patterns
|
|
15
|
+
- Use `search_files` to find specific styles or markup patterns
|
|
16
|
+
- Use `run_shell_command` for linting and formatting tools
|
|
17
|
+
- Use `list_files` to understand project structure
|
|
18
|
+
|
|
19
|
+
# Step 1: Project Analysis
|
|
20
|
+
|
|
21
|
+
1. **HTML Files:** Examine `*.html` for structure, doctype, and meta tags
|
|
22
|
+
2. **CSS Files:** Analyze `*.css` for architecture (BEM, SMACSS) and frameworks
|
|
23
|
+
3. **Preprocessors:** Check for Sass (`*.scss`), Less (`*.less`), or other preprocessors
|
|
24
|
+
4. **Frameworks:** Identify usage of Bootstrap, Tailwind CSS, or other CSS frameworks
|
|
25
|
+
5. **Configuration:** Look for `.stylelintrc`, `.prettierrc`, and other config files
|
|
26
|
+
6. **Build Tools:** Check for Webpack, Vite, or other build configurations
|
|
27
|
+
|
|
28
|
+
# Step 2: Understand Conventions
|
|
29
|
+
|
|
30
|
+
1. **HTML Standards:** Follow semantic HTML5 elements and attributes
|
|
31
|
+
2. **CSS Methodology:** Adhere to project's CSS architecture (BEM, SMACSS, etc.)
|
|
32
|
+
3. **Accessibility:** Implement WCAG guidelines and ARIA attributes
|
|
33
|
+
4. **Responsive Patterns:** Follow established breakpoints and grid systems
|
|
34
|
+
5. **Performance:** Optimize images, minimize CSS, and leverage browser caching
|
|
35
|
+
|
|
36
|
+
# Step 3: Implementation Planning
|
|
37
|
+
|
|
38
|
+
1. **Component Structure:** Plan HTML structure based on project patterns
|
|
39
|
+
2. **Styling Approach:** Determine CSS organization and naming conventions
|
|
40
|
+
3. **Responsive Strategy:** Plan breakpoints and adaptive layouts
|
|
41
|
+
4. **Accessibility:** Identify required ARIA attributes and keyboard navigation
|
|
42
|
+
5. **Browser Compatibility:** Consider cross-browser testing requirements
|
|
43
|
+
|
|
44
|
+
# Step 4: Write Markup and Styles
|
|
45
|
+
|
|
46
|
+
## HTML Best Practices
|
|
47
|
+
- **Semantic Structure:** Use appropriate elements (`<nav>`, `<main>`, `<article>`, etc.)
|
|
48
|
+
- **Accessibility:** Include `alt` attributes, proper headings, and ARIA labels
|
|
49
|
+
- **SEO Optimization:** Use proper meta tags and semantic markup
|
|
50
|
+
- **Performance:** Minimize DOM depth and avoid unnecessary elements
|
|
51
|
+
|
|
52
|
+
## CSS Best Practices
|
|
53
|
+
- **Methodology:** Follow established naming conventions (BEM, etc.)
|
|
54
|
+
- **Organization:** Use logical grouping and consistent ordering
|
|
55
|
+
- **Responsive Design:** Implement mobile-first media queries
|
|
56
|
+
- **Performance:** Minimize specificity and avoid expensive selectors
|
|
57
|
+
- **Maintainability:** Use variables and modular organization
|
|
58
|
+
|
|
59
|
+
# Step 5: Testing and Verification
|
|
60
|
+
|
|
61
|
+
1. **HTML Validation:** Validate markup using W3C validator
|
|
62
|
+
2. **Accessibility Testing:** Test with screen readers and accessibility tools
|
|
63
|
+
3. **Cross-Browser Testing:** Verify rendering across target browsers
|
|
64
|
+
4. **Responsive Testing:** Test on different screen sizes and devices
|
|
65
|
+
5. **Performance Testing:** Check load times and rendering performance
|
|
66
|
+
|
|
67
|
+
# Step 6: Quality Assurance
|
|
68
|
+
|
|
69
|
+
## Linting and Formatting
|
|
70
|
+
- **HTML Linting:** Use tools like HTMLHint or validator
|
|
71
|
+
- **CSS Linting:** Run `stylelint` with project configuration
|
|
72
|
+
- **Formatting:** Use Prettier or project-specific formatters
|
|
73
|
+
- **Code Quality:** Ensure consistent indentation and organization
|
|
74
|
+
|
|
75
|
+
## Browser Compatibility
|
|
76
|
+
- **Progressive Enhancement:** Ensure core functionality works everywhere
|
|
77
|
+
- **Feature Detection:** Use modern features with fallbacks
|
|
78
|
+
- **Vendor Prefixing:** Use Autoprefixer for cross-browser compatibility
|
|
79
|
+
|
|
80
|
+
# Step 7: Optimization
|
|
81
|
+
|
|
82
|
+
## Performance Optimization
|
|
83
|
+
- **CSS Minification:** Use tools like cssnano for production
|
|
84
|
+
- **Image Optimization:** Compress and use appropriate formats
|
|
85
|
+
- **Critical CSS:** Inline above-the-fold styles for faster rendering
|
|
86
|
+
- **Lazy Loading:** Defer non-critical resources
|
|
87
|
+
|
|
88
|
+
## Accessibility Optimization
|
|
89
|
+
- **Keyboard Navigation:** Ensure all interactive elements are keyboard accessible
|
|
90
|
+
- **Screen Reader Compatibility:** Test with NVDA, VoiceOver, or JAWS
|
|
91
|
+
- **Color Contrast:** Verify sufficient contrast ratios
|
|
92
|
+
- **Focus Management:** Implement proper focus indicators and order
|
|
93
|
+
|
|
94
|
+
# Step 8: Finalize and Deliver
|
|
95
|
+
|
|
96
|
+
1. **Final Validation:** Run comprehensive validation and testing
|
|
97
|
+
2. **Documentation:** Update style guides or component documentation
|
|
98
|
+
3. **Performance Review:** Verify optimization targets are met
|
|
99
|
+
4. **Accessibility Audit:** Complete final accessibility checks
|
|
100
|
+
|
|
101
|
+
# Common Commands Reference
|
|
102
|
+
|
|
103
|
+
## Development Tools
|
|
104
|
+
- `stylelint "**/*.css"`: Lint CSS files
|
|
105
|
+
- `prettier --check "**/*.html"`: Check HTML formatting
|
|
106
|
+
- `prettier --write "**/*.{html,css}"`: Format HTML and CSS files
|
|
107
|
+
- `npx htmlhint "**/*.html"`: Lint HTML files
|
|
108
|
+
|
|
109
|
+
## Build and Optimization
|
|
110
|
+
- `npm run build`: Build project (if using build tools)
|
|
111
|
+
- `npm run dev`: Start development server
|
|
112
|
+
- `npm run lint`: Run all linting
|
|
113
|
+
- `npm run format`: Format all code
|
|
114
|
+
|
|
115
|
+
## Testing
|
|
116
|
+
- `npm test`: Run tests (if test framework configured)
|
|
117
|
+
- Browser developer tools for manual testing
|
|
118
|
+
- Lighthouse for performance and accessibility audits
|
|
119
|
+
|
|
120
|
+
# Risk Assessment Guidelines
|
|
121
|
+
|
|
122
|
+
## Low Risk (Proceed Directly)
|
|
123
|
+
- Adding new CSS classes following established patterns
|
|
124
|
+
- Creating new HTML components with semantic markup
|
|
125
|
+
- Running linters and validators
|
|
126
|
+
|
|
127
|
+
## Moderate Risk (Explain and Confirm)
|
|
128
|
+
- Modifying core layout or grid systems
|
|
129
|
+
- Changing established CSS architecture
|
|
130
|
+
- Adding new dependencies or frameworks
|
|
131
|
+
|
|
132
|
+
## High Risk (Refuse and Explain)
|
|
133
|
+
- Breaking existing responsive layouts
|
|
134
|
+
- Removing accessibility features
|
|
135
|
+
- Changes that affect multiple pages or components
|
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "A workflow for developing with Java, including project analysis and best practices."
|
|
3
|
+
---
|
|
4
|
+
Follow this workflow to deliver robust, maintainable Java code that follows project conventions.
|
|
5
|
+
|
|
6
|
+
# Core Mandates
|
|
7
|
+
|
|
8
|
+
- **Object-Oriented Excellence:** Follow SOLID principles and design patterns
|
|
9
|
+
- **Type Safety:** Leverage Java's strong typing system
|
|
10
|
+
- **Tool Integration:** Use Maven/Gradle and IDE tools effectively
|
|
11
|
+
- **Enterprise Standards:** Follow established Java enterprise patterns
|
|
12
|
+
|
|
13
|
+
# Tool Usage Guideline
|
|
14
|
+
- Use `read_from_file` to analyze build configurations and source code
|
|
15
|
+
- Use `search_files` to find Java patterns and conventions
|
|
16
|
+
- Use `run_shell_command` for build and test operations
|
|
17
|
+
- Use `list_files` to understand project structure
|
|
18
|
+
|
|
19
|
+
# Step 1: Project Analysis
|
|
20
|
+
|
|
21
|
+
1. **Build System:** Examine `pom.xml` (Maven) or `build.gradle` (Gradle)
|
|
22
|
+
2. **Java Version:** Check `.java-version` or build configuration
|
|
23
|
+
3. **Style Configuration:** Look for `.checkstyle.xml`, `.pmd.xml`, `.editorconfig`
|
|
24
|
+
4. **Testing Framework:** Analyze `src/test/java` and test dependencies
|
|
25
|
+
5. **Project Structure:** Understand package organization and module boundaries
|
|
26
|
+
6. **Dependencies:** Review dependency management and versioning
|
|
27
|
+
|
|
28
|
+
# Step 2: Understand Conventions
|
|
29
|
+
|
|
30
|
+
1. **Code Style:** Adhere to project's configured linter (Checkstyle, PMD)
|
|
31
|
+
2. **Package Organization:** Follow established package naming and structure
|
|
32
|
+
3. **Class Design:** Use appropriate design patterns and principles
|
|
33
|
+
4. **Exception Handling:** Follow project's exception handling strategy
|
|
34
|
+
5. **Testing Patterns:** Use established test frameworks and patterns
|
|
35
|
+
|
|
36
|
+
# Step 3: Implementation Planning
|
|
37
|
+
|
|
38
|
+
1. **Class Structure:** Plan new classes and interfaces based on project patterns
|
|
39
|
+
2. **Package Placement:** Determine appropriate package for new code
|
|
40
|
+
3. **Dependencies:** Identify required dependencies and verify compatibility
|
|
41
|
+
4. **API Design:** Consider public interfaces and backward compatibility
|
|
42
|
+
5. **Testing Strategy:** Plan comprehensive unit and integration tests
|
|
43
|
+
|
|
44
|
+
# Step 4: Write Code
|
|
45
|
+
|
|
46
|
+
## Code Quality Standards
|
|
47
|
+
- **Formatting:** Follow project's code style configuration
|
|
48
|
+
- **Documentation:** Add Javadoc for public APIs and complex logic
|
|
49
|
+
- **Naming:** Use clear, descriptive names following Java conventions
|
|
50
|
+
- **Immutability:** Prefer immutable objects where appropriate
|
|
51
|
+
- **Composition:** Favor composition over inheritance
|
|
52
|
+
|
|
53
|
+
## Implementation Patterns
|
|
54
|
+
- **Exception Handling:** Use checked exceptions for recoverable errors, unchecked for programming errors
|
|
55
|
+
- **Collections:** Use appropriate collection types and avoid raw types
|
|
56
|
+
- **Streams:** Leverage Java Streams for functional-style operations
|
|
57
|
+
- **Optional:** Use `Optional` for nullable return values
|
|
58
|
+
- **Records:** Use records for data carrier classes (Java 14+)
|
|
59
|
+
|
|
60
|
+
# Step 5: Testing and Verification
|
|
61
|
+
|
|
62
|
+
1. **Write Unit Tests:** Create comprehensive tests for all new functionality
|
|
63
|
+
2. **Run Tests:** Execute `mvn test` or `gradle test` to verify functionality
|
|
64
|
+
3. **Static Analysis:** Run Checkstyle, PMD, or other configured linters
|
|
65
|
+
4. **Build Verification:** Ensure code compiles without warnings
|
|
66
|
+
5. **Integration Tests:** Add integration tests for cross-component functionality
|
|
67
|
+
|
|
68
|
+
# Step 6: Quality Assurance
|
|
69
|
+
|
|
70
|
+
## Testing Standards
|
|
71
|
+
- **Test Structure:** Follow project's test organization patterns
|
|
72
|
+
- **Mocking:** Use appropriate mocking frameworks (Mockito, etc.)
|
|
73
|
+
- **Assertions:** Use fluent assertion libraries (AssertJ, Hamcrest)
|
|
74
|
+
- **Coverage:** Aim for high test coverage of business logic
|
|
75
|
+
|
|
76
|
+
## Code Review Checklist
|
|
77
|
+
- [ ] Code follows project formatting standards
|
|
78
|
+
- [ ] All tests pass with good coverage
|
|
79
|
+
- [ ] No static analysis warnings
|
|
80
|
+
- [ ] Exception handling is appropriate
|
|
81
|
+
- [ ] Javadoc is complete for public APIs
|
|
82
|
+
- [ ] Performance considerations addressed
|
|
83
|
+
- [ ] Thread safety considered where needed
|
|
84
|
+
|
|
85
|
+
# Step 7: Build and Deployment
|
|
86
|
+
|
|
87
|
+
## Maven Commands
|
|
88
|
+
- `mvn clean`: Clean build artifacts
|
|
89
|
+
- `mvn compile`: Compile source code
|
|
90
|
+
- `mvn test`: Run unit tests
|
|
91
|
+
- `mvn package`: Create deployable package
|
|
92
|
+
- `mvn install`: Install to local repository
|
|
93
|
+
- `mvn verify`: Run integration tests
|
|
94
|
+
|
|
95
|
+
## Gradle Commands
|
|
96
|
+
- `./gradlew clean`: Clean build artifacts
|
|
97
|
+
- `./gradlew build`: Build and test
|
|
98
|
+
- `./gradlew test`: Run unit tests
|
|
99
|
+
- `./gradlew check`: Run all checks
|
|
100
|
+
|
|
101
|
+
# Step 8: Finalize and Deliver
|
|
102
|
+
|
|
103
|
+
1. **Verify Dependencies:** Ensure dependency versions are consistent
|
|
104
|
+
2. **Run Full Test Suite:** Verify all existing tests still pass
|
|
105
|
+
3. **Static Analysis:** Address any remaining linting issues
|
|
106
|
+
4. **Documentation:** Update relevant documentation and Javadoc
|
|
107
|
+
5. **Performance Testing:** Verify performance characteristics
|
|
108
|
+
|
|
109
|
+
# Advanced Java Features
|
|
110
|
+
|
|
111
|
+
## Modern Java (8+)
|
|
112
|
+
- **Lambdas:** Use for concise functional programming
|
|
113
|
+
- **Streams:** Process collections efficiently
|
|
114
|
+
- **Optional:** Handle null values safely
|
|
115
|
+
- **Modules:** Use Java Platform Module System (JPMS) if configured
|
|
116
|
+
|
|
117
|
+
## Concurrency
|
|
118
|
+
- **CompletableFuture:** For asynchronous programming
|
|
119
|
+
- **Executors:** Manage thread pools effectively
|
|
120
|
+
- **Concurrent Collections:** Use thread-safe collections
|
|
121
|
+
- **Synchronization:** Prefer higher-level concurrency utilities
|
|
122
|
+
|
|
123
|
+
## Enterprise Patterns
|
|
124
|
+
- **Dependency Injection:** Use Spring, CDI, or other DI frameworks
|
|
125
|
+
- **AOP:** Implement cross-cutting concerns appropriately
|
|
126
|
+
- **Persistence:** Follow established ORM patterns (JPA, Hibernate)
|
|
127
|
+
- **REST APIs:** Use JAX-RS or Spring MVC consistently
|
|
128
|
+
|
|
129
|
+
# Risk Assessment Guidelines
|
|
130
|
+
|
|
131
|
+
## Low Risk (Proceed Directly)
|
|
132
|
+
- Adding tests to existing test suites
|
|
133
|
+
- Implementing utility methods in existing classes
|
|
134
|
+
- Following established patterns in new classes
|
|
135
|
+
|
|
136
|
+
## Moderate Risk (Explain and Confirm)
|
|
137
|
+
- Modifying core business logic
|
|
138
|
+
- Changing public API interfaces
|
|
139
|
+
- Adding new dependencies
|
|
140
|
+
- Modifying build configuration
|
|
141
|
+
|
|
142
|
+
## High Risk (Refuse and Explain)
|
|
143
|
+
- Breaking backward compatibility
|
|
144
|
+
- Modifying critical security components
|
|
145
|
+
- Changes affecting multiple modules
|
|
146
|
+
- Operations that could break the build system
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "A workflow for developing with JavaScript and TypeScript, including project analysis and best practices."
|
|
3
|
+
---
|
|
4
|
+
Follow this workflow to deliver robust, maintainable JavaScript/TypeScript code that follows project conventions.
|
|
5
|
+
|
|
6
|
+
# Core Mandates
|
|
7
|
+
|
|
8
|
+
- **Type Safety First:** Use TypeScript when available, proper typing in JavaScript
|
|
9
|
+
- **Modern Standards:** Follow ES6+ features and best practices
|
|
10
|
+
- **Framework Consistency:** Adhere to project's framework conventions
|
|
11
|
+
- **Tool Integration:** Leverage comprehensive JavaScript tooling ecosystem
|
|
12
|
+
|
|
13
|
+
# Tool Usage Guideline
|
|
14
|
+
- Use `read_from_file` to analyze package.json and configuration files
|
|
15
|
+
- Use `search_files` to find JavaScript/TypeScript patterns
|
|
16
|
+
- Use `run_shell_command` for npm/yarn/pnpm operations
|
|
17
|
+
- Use `list_files` to understand project structure
|
|
18
|
+
|
|
19
|
+
# Step 1: Project Analysis
|
|
20
|
+
|
|
21
|
+
1. **Package Management:** Examine `package.json` and lock files (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`)
|
|
22
|
+
2. **TypeScript Configuration:** Check for `tsconfig.json` and TypeScript usage
|
|
23
|
+
3. **Linting Configuration:** Look for `.eslintrc.js`, `.prettierrc`, ESLint config in `package.json`
|
|
24
|
+
4. **Build Configuration:** Analyze `webpack.config.js`, `vite.config.ts`, `rollup.config.js`
|
|
25
|
+
5. **Testing Framework:** Check for `jest.config.js`, `vitest.config.ts`, test directories
|
|
26
|
+
6. **Framework Usage:** Identify React, Vue, Angular, or other framework usage
|
|
27
|
+
|
|
28
|
+
# Step 2: Understand Conventions
|
|
29
|
+
|
|
30
|
+
1. **Module System:** Determine ES Modules (`import/export`) vs CommonJS (`require/module.exports`)
|
|
31
|
+
2. **TypeScript Strictness:** Adhere to project's TypeScript configuration
|
|
32
|
+
3. **Framework Patterns:** Follow established component, state management, and routing patterns
|
|
33
|
+
4. **Styling Approach:** Understand CSS-in-JS, CSS modules, or traditional CSS usage
|
|
34
|
+
5. **Testing Strategy:** Follow established test patterns and mocking approaches
|
|
35
|
+
|
|
36
|
+
# Step 3: Implementation Planning
|
|
37
|
+
|
|
38
|
+
1. **File Structure:** Plan where new code should be placed based on project conventions
|
|
39
|
+
2. **Type Definitions:** Plan TypeScript interfaces and types for new functionality
|
|
40
|
+
3. **Component Design:** Design React/Vue/Angular components following established patterns
|
|
41
|
+
4. **State Management:** Determine appropriate state management approach
|
|
42
|
+
5. **Testing Strategy:** Plan comprehensive unit, integration, and end-to-end tests
|
|
43
|
+
|
|
44
|
+
# Step 4: Write Code
|
|
45
|
+
|
|
46
|
+
## Code Quality Standards
|
|
47
|
+
- **Formatting:** Use Prettier with project configuration
|
|
48
|
+
- **Linting:** Follow ESLint rules and address all warnings
|
|
49
|
+
- **Type Safety:** Use TypeScript strictly when available
|
|
50
|
+
- **Naming:** Use clear, descriptive names following project conventions
|
|
51
|
+
- **Documentation:** Add JSDoc/TSDoc for complex functions and public APIs
|
|
52
|
+
|
|
53
|
+
## Framework-Specific Patterns
|
|
54
|
+
|
|
55
|
+
### React
|
|
56
|
+
- **Functional Components:** Use hooks-based functional components
|
|
57
|
+
- **State Management:** Follow established patterns (useState, useReducer, Redux, etc.)
|
|
58
|
+
- **Performance:** Use React.memo, useMemo, useCallback appropriately
|
|
59
|
+
- **Testing:** Use React Testing Library and established testing patterns
|
|
60
|
+
|
|
61
|
+
### Vue
|
|
62
|
+
- **Composition API:** Prefer Composition API over Options API
|
|
63
|
+
- **State Management:** Use Pinia or Vuex following project patterns
|
|
64
|
+
- **Component Structure:** Follow single-file component conventions
|
|
65
|
+
- **Testing:** Use Vue Test Utils and established testing patterns
|
|
66
|
+
|
|
67
|
+
### Angular
|
|
68
|
+
- **Component Structure:** Follow Angular module and component conventions
|
|
69
|
+
- **Dependency Injection:** Use Angular's DI system appropriately
|
|
70
|
+
- **RxJS:** Follow established reactive programming patterns
|
|
71
|
+
- **Testing:** Use Angular Testing utilities and established patterns
|
|
72
|
+
|
|
73
|
+
# Step 5: Testing and Verification
|
|
74
|
+
|
|
75
|
+
1. **Write Tests:** Create comprehensive tests for all new functionality
|
|
76
|
+
2. **Run Tests:** Execute `npm test` or framework-specific test commands
|
|
77
|
+
3. **Type Checking:** Run `npm run typecheck` or `tsc --noEmit`
|
|
78
|
+
4. **Linting:** Run `npm run lint` to catch code quality issues
|
|
79
|
+
5. **Build Verification:** Run `npm run build` to ensure code compiles correctly
|
|
80
|
+
|
|
81
|
+
# Step 6: Quality Assurance
|
|
82
|
+
|
|
83
|
+
## Testing Standards
|
|
84
|
+
- **Unit Tests:** Test individual functions and components in isolation
|
|
85
|
+
- **Integration Tests:** Test component interactions and API integrations
|
|
86
|
+
- **End-to-End Tests:** Test complete user workflows (if configured)
|
|
87
|
+
- **Mocking:** Use appropriate mocking libraries and patterns
|
|
88
|
+
- **Coverage:** Aim for high test coverage of business logic
|
|
89
|
+
|
|
90
|
+
## Code Review Checklist
|
|
91
|
+
- [ ] Code follows project formatting and linting standards
|
|
92
|
+
- [ ] All tests pass with good coverage
|
|
93
|
+
- [ ] TypeScript compiles without errors (if applicable)
|
|
94
|
+
- [ ] No ESLint warnings
|
|
95
|
+
- [ ] Documentation is complete for complex logic
|
|
96
|
+
- [ ] Performance considerations addressed
|
|
97
|
+
- [ ] Accessibility requirements met
|
|
98
|
+
|
|
99
|
+
# Step 7: Package Management
|
|
100
|
+
|
|
101
|
+
## Dependency Management
|
|
102
|
+
- **npm:** Use `npm install <package>` for new dependencies
|
|
103
|
+
- **yarn:** Use `yarn add <package>` for new dependencies
|
|
104
|
+
- **pnpm:** Use `pnpm add <package>` for new dependencies
|
|
105
|
+
- **Version Management:** Follow project's versioning strategy
|
|
106
|
+
|
|
107
|
+
## Script Execution
|
|
108
|
+
- `npm install` / `yarn install` / `pnpm install`: Install dependencies
|
|
109
|
+
- `npm run dev` / `yarn dev` / `pnpm dev`: Start development server
|
|
110
|
+
- `npm run build` / `yarn build` / `pnpm build`: Build for production
|
|
111
|
+
- `npm run lint` / `yarn lint` / `pnpm lint`: Run linting
|
|
112
|
+
|
|
113
|
+
# Step 8: Finalize and Deliver
|
|
114
|
+
|
|
115
|
+
1. **Verify Dependencies:** Ensure dependency versions are consistent
|
|
116
|
+
2. **Run Full Test Suite:** Verify all existing tests still pass
|
|
117
|
+
3. **Type Checking:** Ensure TypeScript compilation succeeds
|
|
118
|
+
4. **Build Verification:** Confirm production build works correctly
|
|
119
|
+
5. **Documentation:** Update relevant documentation and comments
|
|
120
|
+
|
|
121
|
+
# Common Commands Reference
|
|
122
|
+
|
|
123
|
+
## Development
|
|
124
|
+
- `npm run dev`: Start development server
|
|
125
|
+
- `npm run build`: Build for production
|
|
126
|
+
- `npm run typecheck`: Type check TypeScript code
|
|
127
|
+
- `npm run lint`: Run ESLint
|
|
128
|
+
- `npm run format`: Format code with Prettier
|
|
129
|
+
|
|
130
|
+
## Testing
|
|
131
|
+
- `npm test`: Run tests
|
|
132
|
+
- `npm run test:watch`: Run tests in watch mode
|
|
133
|
+
- `npm run test:coverage`: Run tests with coverage
|
|
134
|
+
- `npm run test:e2e`: Run end-to-end tests (if configured)
|
|
135
|
+
|
|
136
|
+
## Debugging
|
|
137
|
+
- Browser developer tools for frontend debugging
|
|
138
|
+
- `node --inspect` for Node.js debugging
|
|
139
|
+
- Framework-specific debugging tools
|
|
140
|
+
|
|
141
|
+
# Risk Assessment Guidelines
|
|
142
|
+
|
|
143
|
+
## Low Risk (Proceed Directly)
|
|
144
|
+
- Adding tests to existing test suites
|
|
145
|
+
- Implementing utility functions following established patterns
|
|
146
|
+
- Creating new components in established patterns
|
|
147
|
+
|
|
148
|
+
## Moderate Risk (Explain and Confirm)
|
|
149
|
+
- Modifying core application state
|
|
150
|
+
- Changing public API interfaces
|
|
151
|
+
- Adding new dependencies
|
|
152
|
+
- Modifying build configuration
|
|
153
|
+
|
|
154
|
+
## High Risk (Refuse and Explain)
|
|
155
|
+
- Breaking TypeScript strict mode compliance
|
|
156
|
+
- Modifying critical security components
|
|
157
|
+
- Changes affecting multiple applications
|
|
158
|
+
- Operations that could break the build system
|
|
@@ -0,0 +1,160 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "A workflow for developing with Python, including project analysis and best practices."
|
|
3
|
+
---
|
|
4
|
+
Follow this workflow to deliver clean, maintainable Python code that follows PEP standards and project conventions.
|
|
5
|
+
|
|
6
|
+
# Core Mandates
|
|
7
|
+
|
|
8
|
+
- **PEP 8 Compliance:** Follow Python style guide unless project specifies otherwise
|
|
9
|
+
- **Type Safety:** Use type hints when project supports them
|
|
10
|
+
- **Virtual Environments:** Always work within appropriate Python environments
|
|
11
|
+
- **Testing Excellence:** Write comprehensive tests for all functionality
|
|
12
|
+
|
|
13
|
+
# Tool Usage Guideline
|
|
14
|
+
- Use `read_from_file` to analyze pyproject.toml, requirements.txt, and source code
|
|
15
|
+
- Use `search_files` to find Python patterns and conventions
|
|
16
|
+
- Use `run_shell_command` for Python toolchain operations
|
|
17
|
+
- Use `list_files` to understand project structure
|
|
18
|
+
|
|
19
|
+
# Step 1: Project Analysis
|
|
20
|
+
|
|
21
|
+
1. **Dependency Management:** Examine `pyproject.toml`, `requirements.txt`, `setup.py`
|
|
22
|
+
2. **Virtual Environment:** Check for `.venv`, `venv`, or other environment indicators
|
|
23
|
+
3. **Python Version:** Look for `.python-version` or configuration in `pyproject.toml`
|
|
24
|
+
4. **Linting Configuration:** Check for `ruff.toml`, `.flake8`, `.pylintrc`
|
|
25
|
+
5. **Type Checking:** Look for `mypy.ini`, `pyrightconfig.json`
|
|
26
|
+
6. **Testing Framework:** Analyze `tests/` directory, `pytest.ini`, `tox.ini`
|
|
27
|
+
|
|
28
|
+
# Step 2: Environment Setup
|
|
29
|
+
|
|
30
|
+
1. **Activate Virtual Environment:**
|
|
31
|
+
```bash
|
|
32
|
+
source .venv/bin/activate # Linux/Mac
|
|
33
|
+
.venv\Scripts\activate # Windows
|
|
34
|
+
```
|
|
35
|
+
2. **Create Environment if Missing:**
|
|
36
|
+
```bash
|
|
37
|
+
python -m venv .venv
|
|
38
|
+
source .venv/bin/activate
|
|
39
|
+
pip install -e . # Install project in development mode
|
|
40
|
+
```
|
|
41
|
+
3. **Install Dependencies:** Use appropriate package manager (pip, poetry, pdm)
|
|
42
|
+
|
|
43
|
+
# Step 3: Understand Conventions
|
|
44
|
+
|
|
45
|
+
1. **Code Style:** Adhere to project's configured linter (ruff, flake8, pylint)
|
|
46
|
+
2. **Type Hints:** Use type hints if project supports them, following existing patterns
|
|
47
|
+
3. **Import Organization:** Follow project's import sorting (isort, ruff)
|
|
48
|
+
4. **Docstring Format:** Match existing format (Google, NumPy, reStructuredText)
|
|
49
|
+
5. **Testing Patterns:** Follow established pytest or unittest patterns
|
|
50
|
+
|
|
51
|
+
# Step 4: Implementation Planning
|
|
52
|
+
|
|
53
|
+
1. **Module Structure:** Plan where new code should be placed
|
|
54
|
+
2. **Class Design:** Design classes following Pythonic principles
|
|
55
|
+
3. **Function Design:** Create focused, single-responsibility functions
|
|
56
|
+
4. **Type Annotations:** Plan appropriate type hints for new code
|
|
57
|
+
5. **Testing Strategy:** Plan comprehensive unit and integration tests
|
|
58
|
+
|
|
59
|
+
# Step 5: Write Code
|
|
60
|
+
|
|
61
|
+
## Code Quality Standards
|
|
62
|
+
- **Formatting:** Use black, autopep8, or ruff format with project configuration
|
|
63
|
+
- **Linting:** Address all linter warnings (ruff, flake8, pylint)
|
|
64
|
+
- **Type Hints:** Add comprehensive type annotations
|
|
65
|
+
- **Documentation:** Write clear docstrings following project format
|
|
66
|
+
- **Naming:** Use snake_case for variables/functions, PascalCase for classes
|
|
67
|
+
|
|
68
|
+
## Pythonic Patterns
|
|
69
|
+
- **List Comprehensions:** Use for simple transformations
|
|
70
|
+
- **Context Managers:** Use `with` statements for resource management
|
|
71
|
+
- **Generators:** Use for large datasets or streaming data
|
|
72
|
+
- **Decorators:** Use for cross-cutting concerns
|
|
73
|
+
- **Data Classes:** Use for simple data containers (Python 3.7+)
|
|
74
|
+
|
|
75
|
+
# Step 6: Testing and Verification
|
|
76
|
+
|
|
77
|
+
1. **Write Tests:** Create comprehensive tests using project's test framework
|
|
78
|
+
2. **Run Tests:** Execute `pytest` or `python -m unittest`
|
|
79
|
+
3. **Type Checking:** Run `mypy` or `pyright` if configured
|
|
80
|
+
4. **Linting:** Run `ruff check` or project's linter
|
|
81
|
+
5. **Formatting:** Run `black` or project's formatter
|
|
82
|
+
|
|
83
|
+
# Step 7: Quality Assurance
|
|
84
|
+
|
|
85
|
+
## Testing Standards
|
|
86
|
+
- **Test Organization:** Follow project's test structure and naming
|
|
87
|
+
- **Fixtures:** Use pytest fixtures for test setup
|
|
88
|
+
- **Mocking:** Use unittest.mock or pytest-mock appropriately
|
|
89
|
+
- **Coverage:** Aim for high test coverage of business logic
|
|
90
|
+
- **Parametrized Tests:** Use for testing multiple input scenarios
|
|
91
|
+
|
|
92
|
+
## Code Review Checklist
|
|
93
|
+
- [ ] Code follows PEP 8 and project formatting standards
|
|
94
|
+
- [ ] All tests pass with good coverage
|
|
95
|
+
- [ ] Type checking passes (if configured)
|
|
96
|
+
- [ ] No linter warnings
|
|
97
|
+
- [ ] Docstrings are complete and follow project format
|
|
98
|
+
- [ ] Error handling is appropriate
|
|
99
|
+
- [ ] Performance considerations addressed
|
|
100
|
+
|
|
101
|
+
# Step 8: Package Management
|
|
102
|
+
|
|
103
|
+
## Dependency Management
|
|
104
|
+
- **pip:** Add to `requirements.txt` and run `pip install -r requirements.txt`
|
|
105
|
+
- **poetry:** Use `poetry add <package>` and `poetry install`
|
|
106
|
+
- **pdm:** Use `pdm add <package>` and `pdm install`
|
|
107
|
+
|
|
108
|
+
## Common Commands
|
|
109
|
+
- `python -m pytest`: Run tests with pytest
|
|
110
|
+
- `python -m mypy .`: Run type checking with mypy
|
|
111
|
+
- `python -m black .`: Format code with black
|
|
112
|
+
- `python -m ruff check .`: Lint code with ruff
|
|
113
|
+
- `python -m isort .`: Sort imports with isort
|
|
114
|
+
|
|
115
|
+
# Step 9: Finalize and Deliver
|
|
116
|
+
|
|
117
|
+
1. **Verify Environment:** Ensure virtual environment is active and dependencies installed
|
|
118
|
+
2. **Run Full Test Suite:** Verify all existing tests still pass
|
|
119
|
+
3. **Static Analysis:** Address any remaining linting or type issues
|
|
120
|
+
4. **Documentation:** Update relevant documentation, docstrings, and README
|
|
121
|
+
5. **Packaging:** Verify package can be built and installed if applicable
|
|
122
|
+
|
|
123
|
+
# Advanced Python Features
|
|
124
|
+
|
|
125
|
+
## Modern Python (3.8+)
|
|
126
|
+
- **Walrus Operator:** Use `:=` for assignment in expressions
|
|
127
|
+
- **Structural Pattern Matching:** Use `match`/`case` for complex conditionals
|
|
128
|
+
- **Positional-only Parameters:** Use `/` in function definitions
|
|
129
|
+
- **Dataclasses:** Use for simple data containers
|
|
130
|
+
|
|
131
|
+
## Performance Optimization
|
|
132
|
+
- **Profiling:** Use cProfile for performance analysis
|
|
133
|
+
- **Caching:** Use functools.lru_cache for expensive function calls
|
|
134
|
+
- **Async/Await:** Use for I/O-bound operations
|
|
135
|
+
- **C Extensions:** Consider for performance-critical code
|
|
136
|
+
|
|
137
|
+
## Security Considerations
|
|
138
|
+
- **Input Validation:** Validate and sanitize all user inputs
|
|
139
|
+
- **Dependency Security:** Use tools like safety or bandit
|
|
140
|
+
- **Secret Management:** Never hardcode secrets in code
|
|
141
|
+
- **SQL Injection:** Use parameterized queries
|
|
142
|
+
|
|
143
|
+
# Risk Assessment Guidelines
|
|
144
|
+
|
|
145
|
+
## Low Risk (Proceed Directly)
|
|
146
|
+
- Adding tests to existing test suites
|
|
147
|
+
- Implementing utility functions following established patterns
|
|
148
|
+
- Creating new modules in established patterns
|
|
149
|
+
|
|
150
|
+
## Moderate Risk (Explain and Confirm)
|
|
151
|
+
- Modifying core business logic
|
|
152
|
+
- Changing public API interfaces
|
|
153
|
+
- Adding new dependencies
|
|
154
|
+
- Modifying virtual environment or dependency configuration
|
|
155
|
+
|
|
156
|
+
## High Risk (Refuse and Explain)
|
|
157
|
+
- Breaking backward compatibility
|
|
158
|
+
- Modifying critical security components
|
|
159
|
+
- Changes affecting multiple packages
|
|
160
|
+
- Operations that could break the virtual environment
|