ara-cli 0.1.10.7__tar.gz → 0.1.10.8__tar.gz

{ara_cli-0.1.10.7 → ara_cli-0.1.10.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ara_cli
-Version: 0.1.10.7
+Version: 0.1.10.8
 Summary: Powerful, open source command-line tool for managing, structuring and automating software development artifacts in line with Business-Driven Development (BDD) and AI-assisted processes
 Description-Content-Type: text/markdown
 Requires-Dist: langfuse

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/empty.commands.md

@@ -0,0 +1,4 @@
+### COMMANDS FOR ...
+Your job is now:
+* <main list for mandotory commands>
+* ...

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/extract_general.commands.md

@@ -0,0 +1,12 @@
+# general file generation and file extract instructions
+* return only full copy pastable file content using this markdown codeblock format with 5 backticks:
+`````
+# [ ] extract
+# filename: <absolute filepath>/<filename>.<file_extension>
+{valid file content depending on the given file_extension}
+`````
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/extract_markdown.commands.md

@@ -0,0 +1,11 @@
+# general markdown file generation and file extract instructions
+* return full copy pastable file content using a markdown code block with 5-backticks:
+`````
+# [ ] extract
+# filename: <filepath>/<filename>.md
+{markdown formatted text}
+`````
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/extract_python.commands.md

@@ -0,0 +1,13 @@
+# general python code file generation and file extract instructions
+* return only full copy pastable file content using this markdown codeblock format:
+
+```python
+# [ ] extract
+# filename: src/{filename}.py
+{python code}
+
+```
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/feature_add_or_modifiy_specified_behavior.commands.md

@@ -0,0 +1,36 @@
+# COMMANDS FOR ADDING OR MODIFYING EXISTING SPECIFIED BEHAVIOR
+
+**At first**: 
+
+Check if a set of feature files is given
+
+* In case no feature files are given:
+  * Stop immediately and respond with: "Error in prompt context: no feature files are given as already specified application behavior"
+
+* Else:
+  * Continue following the given instructions
+
+# Instructions
+Your job is now:
+* Silently analyze the given feature files and the specified behavior.
+* Silently analyze the additionally given information about new wanted behavior or changes of existing behavior
+* Develop adaptation strategies that minimize feature file changes with respect to any given already existing feature files, prefer reusing and adapting existing formulations/scenarios and steps over completely new formulations
+* Now formulate to fully cover the new or changed behavior (one, two or many changed or new feature files)
+
+Follow these feature file quality rules:
+* Each feature file should not consist of more than max 3 scenarios, each feature file should follow the single responsibility principle as well as the feature file formulations should follow the separation of concerns of feature files that fully cover the human user observable behavior described in the specification notes. Consider in your formulation of the Gherkin feature files that, when implementing the graphical user interfaces, the full functionality of the Python package Streamlit can be utilized.
+* Follow strictly the given feature file format in order to structure your feature files. 
+* You are allowed to use scenario outlines where useful. But in case they are not helpful in order to increase the readability you can just use standard scenario formulations.
+
+* Wrap and return the formulated feature files as full copy pastable file content in the following format as markdown code block:
+
+```artefact
+# [ ] extract 
+# filename: ara/features/{filename}.feature
+{formulation, with the valid feature file structure following the given feature files as reference}
+```
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/feature_generate_initial_specified_bevahior.commands.md

@@ -0,0 +1,53 @@
+# COMMANDS FOR INITIALLY SPECIFYING APPLICATION BEHAVIOR USING FEATURE FILES
+
+* Given a description of the wanted application behavior as bullet point list, specification document, ...
+
+* And given this feature template with placeholders in <...>
+
+```
+@creator_Egermeier
+Feature: <descriptive title>
+
+  As a <user>
+  I want to <do something | need something>
+  So that <I can achieve something>
+
+  Contributes to <here comes your parent artefact> <here comes your classifier of the parent artefact>  
+
+  Description: <further optional description to understand
+  the rule, no format defined, the example artefact is only a placeholder>
+
+  Scenario: <descriptive scenario title>
+    Given <precondition>
+    When <action>
+    Then <expected result>
+
+  Scenario Outline: <descriptive scenario title>
+    Given <precondition>
+    When <action>
+    Then <expected result>
+
+    Examples:
+      | descriptive scenario title | precondition         | action             | expected result    |
+      | <example title 1>          | <example precond. 1> | <example action 1> | <example result 1> |
+      | <example title 2>          | <example precond. 2> | <example action 2> | <example result 2> |
+```
+
+# Instructions
+* Now formulate a set (one, two or many, each feature file should not consist of more than max 3 scenarios
+* Each feature file should follow the single responsibility principle as well as the feature file formulations should follow the separation of concerns) of feature files that fully cover the human user observable behavior described in the specification notes. 
+* Consider in your formulation of the Gherkin feature files when specifying the behavior of graphical user interfaces: Describe the behavior of the graphical user interfaces so that I can clearly imagine both how they work and their visual look and feel.
+* Follow strictly the given template format in order to structure your feature files. You are allowed to use scenario outlines where useful. But in case they are not helpful in order to increase the readability you can just use standard scenario formulations.
+
+* Wrap and return the formulated feature files as full copy pastable file content in the following format as markdown code block:
+
+```artefact
+# [ ] extract 
+# filename: ara/features/{filename}.feature 
+{formulation, with the valid feature file structure as given by the feature gherkin template}
+```
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/prompt_template_tech_stack_transformer.commands.md

@@ -0,0 +1,95 @@
+# Tech Stack Prompt Template Transformer
+
+## PROMPT:
+You are a prompt template transformation specialist. Your task is to transform Python-specific prompt templates into equivalent templates for a different technology stack while maintaining the same structure, intent, and quality standards.
+
+### INPUT REQUIREMENTS:
+1. **Target Technology Stack** (MANDATORY): The technology stack to transform to (e.g., 'C#', 'Java', 'React', 'TypeScript', 'Go', 'Rust', etc.)
+2. **Source Prompt Templates** (MANDATORY): One or more Python prompt templates to transform
+
+### TRANSFORMATION RULES:
+1. **Preserve Structure and Intent**:
+   - Maintain the same logical flow and purpose of each prompt template
+   - Keep all sections and their hierarchical organization
+   - Preserve the extract/filename format for code generation
+
+2. **Technology-Specific Adaptations**:
+   - Replace Python-specific references with target technology equivalents
+   - Update file extensions (.py → appropriate extension for target stack)
+   - Adapt coding standards (PEP8 → target language conventions)
+   - Replace Python packages with target language equivalents
+   - Update testing frameworks (pytest/behave → target language testing tools)
+   - Adapt documentation styles (numpy docstrings → target language documentation)
+   - Update logging approaches to target language standards
+   - Adjust line/method/class length limits based on target language best practices. Prefer lower length limits.
+
+3. **Naming Convention**:
+   - Prefix each transformed template filename with the target technology
+   - Example: `python_bug_fixing_code.commands.md` → `csharp_bug_fixing_code.commands.md`
+
+4. **Output Format**:
+   - Return each transformed template as a complete, copy-pastable markdown file in 5-backticks
+   - The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+   - Use this format for each transformed template:
+
+`````markdown
+# [ ] extract
+# filename: ara/.araconfig/custom-prompt-modules/commands/{technology}_{original_template_name}
+{transformed template content}
+`````
+
+5. Markdown code block handling in prompt templates
+   The first and the second line of the Markdown code blocks used in the prompt templates serve as extraction control commands. the '#' tags in the first and second line of the code blocks must not be replaced by any other symbols, independent of the technology for which the markdown code block response is defined 
+
+6. **Technology Mapping Guidelines**:
+   **For C#/.NET:**
+   - PEP8 → C# Coding Conventions (Microsoft guidelines)
+   - pytest → NUnit/xUnit/MSTest
+   - behave → SpecFlow
+   - unittest.mock → Moq/NSubstitute
+   - numpy docstrings → XML documentation comments
+   - logging package → ILogger/Serilog/NLog
+
+   **For Java:**
+   - PEP8 → Java Code Conventions (Oracle/Google style)
+   - pytest → JUnit/TestNG
+   - behave → Cucumber-JVM
+   - unittest.mock → Mockito/EasyMock
+   - numpy docstrings → Javadoc
+   - logging package → SLF4J/Log4j
+
+   **For JavaScript/TypeScript:**
+   - PEP8 → ESLint/Prettier standards
+   - pytest → Jest/Mocha/Vitest
+   - behave → Cucumber.js, Selenium
+   - unittest.mock → Jest mocks/Sinon
+   - numpy docstrings → JSDoc/TSDoc
+   - logging package → Winston/Bunyan/Pino
+
+   **For React:**
+   - Include React-specific patterns (components, hooks, state management)
+   - pytest → Jest/React Testing Library
+   - behave → Selenium 
+   - Add component testing guidelines
+   - Include JSX/TSX specific rules
+
+7. **Preserve Key Constraints**:
+   - Maintain separation of concerns and single responsibility principles
+   - Keep modular/extensible design requirements
+   - Preserve testability requirements
+   - Maintain observability/logging requirements
+
+### VALIDATION:
+- Ensure all Python-specific references are properly transformed
+- Verify file paths and extensions match target technology conventions
+- Confirm testing and mocking frameworks are appropriate for target stack
+- Check that documentation styles match target language standards
+
+### OUTPUT SPECIFICATION:
+- Replace '# [ ] extract' with '# [x] extract' in all output blocks
+- Ensure each template is complete and ready for extraction
+- Include a summary of key transformations made for each template
+
+---
+
+**Begin transformation after receiving target technology stack and source templates.**

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/python_bug_fixing_code.commands.md

@@ -0,0 +1,34 @@
+### COMMANDS FOR FIXING BUGS
+
+Your job is now to fix the described error:
+
+* Silently analyze the given error description or error log files
+* Silently review the provided source files and if given the provided feature file (specified behavior) to understand the current faulty implementation and draft silently a potential solution to fix the error
+* Develop implementation strategies that minimize code changes, prefer reusing existing methods over new implementations. Also always prefer to use existing python packages over your own implementation.
+
+When you touch code or need to generate code for bug fixing:
+* The max function or method length should not exceed 40 lines.
+* The max class length should not exceed 150 lines.
+* The max file length should not exceed 150 lines.
+* Split implementation files or functions/methods/classes in case they exceed their defined length maximum.
+* Apply as coding and design principle the separation of concerns and single responsibility principle in general and specifically when you need to split.
+
+* Important: you are NOT allowed to do any further refactorings not related to the bug fixing implementation. Refactoring for enhancing the code quality is not allowed.
+* The fixed code must fully implement the specified behavior in an easy testable and modular/extensible way.
+* Follow PEP8 coding guidelines.
+* Use descriptive numpy style docstrings for inline method and class documentation.
+* Use the python logger logging package to implement logging for all application modules that enables a fine granular full observability of the program flow by the log file. Use ./logs/<module_name>.log as filepath for logging.
+
+* Only return full copy pastable file content.
+* Use for every single generated code block this markdown code block format:
+
+```python
+# [ ] extract
+# filename: src/{filename}.py
+{python code}
+```
+
+* The extract and filename statements are only allowed once per code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/python_generate_code.commands.md

@@ -0,0 +1,27 @@
+### COMMANDS FOR IMPLEMENTING ONE OR A SET OF NEW OR CHANGED FEATURE FILES
+
+Your job is now:
+* Silently analyze the given feature files and the specified behavior.
+* Develop implementation strategies that minimize code changes with respect to any given code and test files, prefer reusing existing methods over new implementations.
+* The max function length should not exceed 25 lines. The max file length should not exceed 120 lines.
+* Always prefer to use existing python packages over your own implementation.
+* In case additional implementation instructions are given as:
+  * Specified in files with extensions "*.technology.md" follow strictly the specified mandatory python packages and tech stack
+  * Explicitly specified as example reference implementation: use this reference information as starting point for your own implementation
+* Fully implement the specified behavior in an easy testable and modular/extensible way, fully implement unit tests for your production code (try to achieve at least 90% code coverage) and implement for all given feature files the corresponding step definitions. Follow PEP8 coding guidelines, use numpy style docstrings for inline function documentation, apply as coding and design principle the separation of concerns and single responsibility principle.
+* Generated or reworked python methods must not exceed 25 lines of code. In case methods exceed this length they need to be split according to the single responsibility principle and separation of concerns.
+* Generated or reworked python files must not exceed 120 lines of code. In case files exceed this length they need to be split according to the single responsibility principle and separation of concerns.
+* Use the python logger logging package to implement logging for all application modules that enable a full observability of the program flow over the log file. Use ./logs/<module_name>.log as filepath for logging.
+
+* Only return full copy pastable file content for production code, unit test files and step definition files. Use for every single generated code block this markdown code block format:
+
+```python
+# [ ] extract
+# filename: src/{filename}.py
+{python code}
+```
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/python_refactoring_code.commands.md

@@ -0,0 +1,39 @@
+### COMMANDS FOR REFACTORING
+
+Your job is now to refactor the code for enhancing the code quality and the design of the code according to the following guidelines:
+* Refactoring = Changing the internal structure of code
+* Without changing its external behavior
+* Goal = Improve readability, maintainability, and design
+-> "Refactoring is a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior."
+-> "Refactoring changes how code is written, not what it does."
+
+Now do:
+* Silently analyze the given code base
+* Silently analyze the given feature file (specified behavior) to fully understand the flow and logic of the current implementation. Remember: you are not allowed to change specified behavior.
+
+When you refactor the code remember:
+* The max function or method length should not exceed 40 lines.
+* The max class length should not exceed 150 lines.
+* The max file length should not exceed 150 lines.
+* Split implementation files or functions/methods/classes in case they exceed their defined length maximum.
+* Apply as coding and design principle the separation of concerns and single responsibility principle in general and specifically when you need to split.
+* Flatten nested code structures (e.g. if/while/for statements) to only one nesting level.
+* The refactored code must fully implement the specified behavior in an easy testable and modular/extensible way.
+* Follow PEP8 coding guidelines.
+* Use descriptive numpy style docstrings for inline method and class documentation.
+* Use the python logger logging package to implement logging for all application modules that enables a fine granular full observability of the program flow by the log file. Use ./logs/<module_name>.log as filepath for logging.
+
+Your output specification is:
+* Only return full copy pastable file content.
+* Use for every single generated code block this markdown code block format:
+
+```python
+# [ ] extract
+# filename: src/{filename}.py
+{python code}
+```
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/python_step_definitions_generation_and_fixing.commands.md

@@ -0,0 +1,40 @@
+### COMMANDS FOR CREATING AND CORRECTING STEP DEFINITIONS FOR FEATURE FILES
+
+**MANDATORY INPUT VALIDATION:**
+- Feature files (.feature) must be provided
+- Behave test report must be provided
+
+**PROMPT DEFINITION ERROR:** If mandatory input is missing, immediately stop and return: "ERROR: Missing mandatory input. Please provide both feature files (.feature) and behave test report before proceeding."
+
+**OPTIONAL INPUT:**
+- Already existing step definitions
+
+**PROMPT DEFINITION WARNING:** If optional input is missing: "WARNING: No existing step definitions provided. If step definitions already exist in your project, please include them as input context to avoid duplication and ensure consistency."
+
+### Your job is now:
+* Silently analyze the given feature files and behave test report to understand current test failures and missing step implementations.
+* Silently review any provided existing step definitions to avoid duplication and maintain consistency.
+* Develop step definition implementation strategies that minimize code changes with respect to existing step definitions, prefer reusing existing step patterns over new implementations.
+* The max function length should not exceed 25 lines. The max file length should not exceed 120 lines.
+* Always prefer to use existing python packages over your own implementation.
+* Use the behave testing framework for all step definition implementations.
+* Apply mocking extensively to isolate step definitions from external inputs and interfaces using unittest.mock or pytest-mock.
+* Fully implement all missing step definitions for the given feature files in an easy testable and modular/extensible way. Follow PEP8 coding guidelines, use numpy style docstrings for inline function documentation, apply as coding and design principle the separation of concerns and single responsibility principle.
+* Generated or reworked python methods must not exceed 25 lines of code. In case methods exceed this length they need to be split according to the single responsibility principle and separation of concerns.
+* Generated or reworked python files must not exceed 120 lines of code. In case files exceed this length they need to be split according to the single responsibility principle and separation of concerns.
+* Implement proper assertion methods that provide clear error messages when steps fail.
+* Use context.scenario, context.feature, and context.table appropriately for data sharing between steps.
+* Implement proper cleanup in @after_scenario and @after_feature hooks when necessary.
+
+* Only return full copy pastable file content for step definition files. Use for every single generated code block this markdown code block format:
+
+```python
+# [ ] extract
+# filename: ara/features/steps/{filename}_steps.py
+{python code}
+```
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

ara_cli-0.1.10.8/ara_cli/templates/prompt-modules/commands/python_unittest_generation_and_fixing.commands.md

@@ -0,0 +1,48 @@
+### COMMANDS FOR CREATING AND CORRECTING UNIT TESTS
+
+**MANDATORY INPUT VALIDATION:**
+- Feature files (.feature) must be provided
+- Code coverage report or pytest test report must be provided
+
+**PROMPT DEFINITION ERROR:** If mandatory input is missing, immediately stop and return: "ERROR: Missing mandatory input. Please provide both feature files (.feature) and code coverage/pytest test report before proceeding."
+
+**OPTIONAL INPUT:**
+- Already existing unit tests
+
+**PROMPT DEFINITION WARNING:** If optional input is missing: "WARNING: No existing unit tests provided. If unit tests already exist in your project, please include them as input context to avoid duplication and ensure consistency."
+
+#### Your job is now:
+* Silently analyze the given feature files and code coverage/pytest test report to understand current test gaps and implementation requirements.
+* Silently review any provided existing unit tests to avoid duplication and maintain consistency with existing test patterns.
+* Develop unit test implementation strategies that minimize code changes with respect to existing tests, prefer reusing existing test patterns and fixtures over new implementations.
+* The max function length should not exceed 25 lines. The max file length should not exceed 120 lines.
+* Always prefer to use existing python packages over your own implementation.
+* Use the pytest testing framework for all unit test implementations.
+* Apply mocking extensively to isolate unit tests from external inputs and interfaces using unittest.mock or pytest-mock. Mock all external dependencies, file I/O, network calls, and database interactions.
+* Fully implement comprehensive unit tests that achieve at least 90% code coverage for the specified behavior in an easy maintainable and modular/extensible way. Follow PEP8 coding guidelines, use numpy style docstrings for inline function documentation, apply as coding and design principle the separation of concerns and single responsibility principle.
+* Generated or reworked python methods must not exceed 25 lines of code. In case methods exceed this length they need to be split according to the single responsibility principle and separation of concerns.
+* Generated or reworked python files must not exceed 120 lines of code. In case files exceed this length they need to be split according to the single responsibility principle and separation of concerns.
+
+* Implement comprehensive test cases covering:
+  - Happy path scenarios
+  - Edge cases and boundary conditions
+  - Error handling and exception scenarios
+  - Input validation scenarios
+
+* Use pytest fixtures for test data setup and teardown to ensure test isolation.
+* Implement parametrized tests using @pytest.mark.parametrize for testing multiple input combinations efficiently.
+* Use descriptive test method names that clearly indicate what is being tested.
+* Include proper assertions with meaningful error messages.
+
+* Only return full copy pastable file content for unit test files. Use for every single generated code block this markdown code block format:
+
+```python
+# [ ] extract
+# filename: test/test_{filename}.py
+{python code}
+```
+
+* The extract and filename statements are only allowed once per markdown code block
+* The first character of the first line inside your code block must be '#' and the first character of the second line inside your code block must be '#'
+* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
+* in case of files get deprecated give me a list of files that can be safely deleted

{ara_cli-0.1.10.7 → ara_cli-0.1.10.8}/ara_cli/version.py

@@ -1,2 +1,2 @@
 # version.py
-__version__ = "0.1.10.7"   # fith parameter like .0 for local install test purposes only. official numbers should be 4 digit numbers
+__version__ = "0.1.10.8"   # fith parameter like .0 for local install test purposes only. official numbers should be 4 digit numbers

{ara_cli-0.1.10.7 → ara_cli-0.1.10.8}/ara_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ara_cli
-Version: 0.1.10.7
+Version: 0.1.10.8
 Summary: Powerful, open source command-line tool for managing, structuring and automating software development artifacts in line with Business-Driven Development (BDD) and AI-assisted processes
 Description-Content-Type: text/markdown
 Requires-Dist: langfuse

{ara_cli-0.1.10.7 → ara_cli-0.1.10.8}/ara_cli.egg-info/SOURCES.txt

@@ -116,30 +116,24 @@ ara_cli/templates/template.steps.prompt_log.md
 ara_cli/templates/template.task.prompt_log.md
 ara_cli/templates/template.userstory.prompt_log.md
 ara_cli/templates/template.vision.prompt_log.md
-ara_cli/templates/prompt-modules/blueprints/complete_pytest_unittest.blueprint.md
 ara_cli/templates/prompt-modules/blueprints/empty.blueprint.md
-ara_cli/templates/prompt-modules/blueprints/pytest_unittest_prompt.blueprint.md
 ara_cli/templates/prompt-modules/blueprints/task_todo_list_C4_architecture_analysis.blueprint.md
-ara_cli/templates/prompt-modules/blueprints/task_todo_list_implement_feature_BDD_way.blueprint.md
 ara_cli/templates/prompt-modules/commands/architecture_C4_analysis.commands.md
 ara_cli/templates/prompt-modules/commands/architecture_radon_cc_score.commands.md
 ara_cli/templates/prompt-modules/commands/architecture_radon_halstead_v.commands.md
 ara_cli/templates/prompt-modules/commands/architecture_radon_maintainability_score.commands.md
-ara_cli/templates/prompt-modules/commands/artefact_classification.commands.md
-ara_cli/templates/prompt-modules/commands/artefact_extension.commands.md
-ara_cli/templates/prompt-modules/commands/artefact_formulation.commands.md
-ara_cli/templates/prompt-modules/commands/behave_step_generation.commands.md
-ara_cli/templates/prompt-modules/commands/code_generation_complex.commands.md
-ara_cli/templates/prompt-modules/commands/code_generation_simple.commands.md
 ara_cli/templates/prompt-modules/commands/empty.commands.md
-ara_cli/templates/prompt-modules/commands/error_fixing.commands.md
-ara_cli/templates/prompt-modules/commands/feature_file_update.commands.md
-ara_cli/templates/prompt-modules/commands/feature_formulation.commands.md
-ara_cli/templates/prompt-modules/commands/js_code_generation_simple.commands.md
-ara_cli/templates/prompt-modules/commands/refactoring.commands.md
-ara_cli/templates/prompt-modules/commands/refactoring_analysis.commands.md
-ara_cli/templates/prompt-modules/commands/reverse_engineer_feature_file.commands.md
-ara_cli/templates/prompt-modules/commands/reverse_engineer_program_flow.commands.md
+ara_cli/templates/prompt-modules/commands/extract_general.commands.md
+ara_cli/templates/prompt-modules/commands/extract_markdown.commands.md
+ara_cli/templates/prompt-modules/commands/extract_python.commands.md
+ara_cli/templates/prompt-modules/commands/feature_add_or_modifiy_specified_behavior.commands.md
+ara_cli/templates/prompt-modules/commands/feature_generate_initial_specified_bevahior.commands.md
+ara_cli/templates/prompt-modules/commands/prompt_template_tech_stack_transformer.commands.md
+ara_cli/templates/prompt-modules/commands/python_bug_fixing_code.commands.md
+ara_cli/templates/prompt-modules/commands/python_generate_code.commands.md
+ara_cli/templates/prompt-modules/commands/python_refactoring_code.commands.md
+ara_cli/templates/prompt-modules/commands/python_step_definitions_generation_and_fixing.commands.md
+ara_cli/templates/prompt-modules/commands/python_unittest_generation_and_fixing.commands.md
 ara_cli/templates/prompt-modules/intentions/classify_task.intention.md
 ara_cli/templates/prompt-modules/intentions/empty.intention.md
 ara_cli/templates/prompt-modules/intentions/error_fixing.intention.md

ara_cli-0.1.10.7/ara_cli/templates/prompt-modules/blueprints/complete_pytest_unittest.blueprint.md

@@ -1,27 +0,0 @@
-# Usage: 
-# necessary input and adaption: 
-# replace text snippets in <> with specific context
-# ...
-# expected output: 
-# ...
-Do not use usage information as prompt instructions
-
-
-Given source code
-```python
-<source code for context, skip irrelevant for current task>
-```
-
-Given existing unit tests
-```python
-<existing unit tests>
-```
-
-Given pytest is available
-
-Modify and/or create unit tests so this is fully covered:
-```python
-<snippet you want to cover in the next step>
-```
-
-Give me only what is relevant to testing this snippet. Use parametrization where applicable. Split into multiple tests instead of using if-else blocks. Mock all dependencies of tested code.

ara_cli-0.1.10.7/ara_cli/templates/prompt-modules/blueprints/pytest_unittest_prompt.blueprint.md

@@ -1,32 +0,0 @@
-MODE: STRICT_GENERATION
-TASK: Produce one complete pytest file for a given Python module.
-
-REQUIREMENTS:
-- Output only valid Python code (no text, no markdown).
-- Target: full behavioral + branch coverage (100%).
-- Tests follow AAA pattern (# Arrange, # Act, # Assert).
-- Exactly ONE assert or ONE pytest.raises() per test.
-- Use tmp_path fixture for filesystem isolation.
-- Include an autouse=True fixture for global patching if needed.
-- No external I/O or network calls.
-- All tests independent, self-contained.
-
-STYLE:
-- File starts with module docstring describing AAA, single assert rule, autouse fixture.
-- Group tests with comment headers: 
-  # --- Success paths --- / # --- Error paths --- / # --- Edge cases ---
-- Function names: test_<function>_<expected_behavior>_<condition>
-- Variables descriptive (rel, path, new_content, etc.).
-- Use direct asserts (assert result is True, assert path.read_text() == "x").
-- For errors: 
-  with pytest.raises(ExceptionType, match=r"text"): function_call()
-
-COVERAGE:
-- Include success, failure, and rare edge branches (e.g., conditional exceptions).
-- Ensure 100% of conditional branches executed.
-
-OUTPUT:
-- Single .py file, runnable via: pytest -v --disable-warnings --maxfail=1 --cov=<target_module>
-- No explanations or prose, only the test code.
-
-END

ara_cli-0.1.10.7/ara_cli/templates/prompt-modules/blueprints/task_todo_list_implement_feature_BDD_way.blueprint.md

@@ -1,30 +0,0 @@
-### INTENTION and CONTEXT
-My intention is to setup a todo list in my given task that helps me to implement a feature in a BDD way
-
-Now do the following:
-Search for a line starting with `Task: ` defined in the `### GIVENS` section. Just repeat the task_name you have found as confirmation
-* Do not proceed if no task is defined. Return immediatly with the message: "No task defined as prompt control" 
-
-* Focus on the description in the `Description` section of the defined task. Ignore all other sections.
-* Analyze the content of the task description section and adapt your default recipe accordingly. You can add new "[@to-do]s ...", you can delete "[@to-do]s" that are not necessary anymore according to the existing task description content
-
-* the format and formulation of your default recipe implementing a feature in BDD style is
-```
-[@to-do] analyze and understand the given `user story`
-[@to-do] generate an example contributing to the rule `rule of userstory to implement` which should be turned into a scenario or feature description
-[@to-do] use the example and aditional relevant context `{context list}` to formulate the feature file
-[@to-do] use the formulated feature file, relevant existing step implementations and relevant existing production code to implement the new step implementations that will fail
-[@to-do] use the created step definitions, the relevant existing production code to modify existing code and to create new code implementing the requested behavior so that the step implementations will pass 
-```
-
-* append your recipe at the end of task
-* return the extended task in the following format 
-```artefact
-# [ ] extract 
-# filename: ara/tasks/{task_name}.task 
-{initial task content}
-{recipe}
-```
-* the extract and filename statements are only allowed once per code block
-
-* in case you think information is missing in order to generate a suffiently precise formulation, return a warning "WARNING: information is missing to formulate the new artefacts" and then explain what kind of information you think is missing and how I could easily retrieve it  

ara_cli-0.1.10.7/ara_cli/templates/prompt-modules/commands/artefact_classification.commands.md

@@ -1,9 +0,0 @@
-### COMMANDS FOR THE CORRECT CONTEXTUAL CLASSIFICATION OF ARTIFACTS
-Your job is now:
-* analyze the given files with respect to content and relationship
-* analyze the new artefact with respect to content and the relationship to the given files
-* give me a list of the top 5 artefacts to which the new artefact contributes the most
-* the output format must be a table with the columns
-  | artefact name | contribution rating from 0 (very low) - 1 (very high) | arguments for rating | path to artefact |
-
-* in case you think the relationship of the new artefact is to weak to any given files, return a warning "WARNING: new artefact is not directly related to already existing aretefacts" and then make a proposal with regard of the ara "work orchestration contribution hierarchy" and/or the "specification contribution hierarchy" 

ara_cli-0.1.10.7/ara_cli/templates/prompt-modules/commands/artefact_extension.commands.md

@@ -1,17 +0,0 @@
-### COMMANDS FOR EXTENDING EXISTING AGILE REQUIREMENTS ARTIFACTS
-Your job is now:
-* analyze the given files with respect to content and relationship
-* analyze the new or changed behavior with respect to content and the relationship to the existing artefacts
-* Develop formulation strategies that minimize formulation changes of existing changes.
-* generate a formulation proposal that adds the new context and or behavior for the specified documents
-* wrap and return the formulated  in the following format 
-```artefact
-# [ ] extract 
-# filename: {path/filename.filextension} 
-{formulation}
-```
-* the extract and filename statements are only allowed once per code block
-
-* Adhere strictly to established rules for AGILE PRODUCT OWNERS for high-quality specification artefacts.
-
-* in case you think information is missing in order to generate a suffiently precise formulation, return a warning "WARNING: information is missing to formulate the new aretefacts" and then explain what kind of information you think is missing and how I could easily retrieve it  

ara_cli-0.1.10.7/ara_cli/templates/prompt-modules/commands/artefact_formulation.commands.md

@@ -1,14 +0,0 @@
-### COMMANDS FOR FORMULATING AGILE REQUIREMENTS ARTIFACTS
-Your job is now:
-* analyze the given files with respect to content and relationship
-* analyze the new artefact with respect to content and the relationship to the given files
-* generate a formulation proposal for the specified documents
-* wrap and return the formulated  in the following format 
-```artefact
-# [ ] extract 
-# filename: {path/filename.filextension} 
-{formulation}
-```
-* the extract and filename statements are only allowed once per code block
-
-* in case you think information is missing in order to generate a suffiently precise formulation, return a warning "WARNING: information is missing to formulate the new artefacts" and then explain what kind of information you think is missing and how I could easily retrieve it