ara-cli 0.1.10.0__py3-none-any.whl → 0.1.13.3__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.
- ara_cli/__init__.py +51 -6
- ara_cli/__main__.py +270 -103
- ara_cli/ara_command_action.py +106 -63
- ara_cli/ara_config.py +187 -128
- ara_cli/ara_subcommands/__init__.py +0 -0
- ara_cli/ara_subcommands/autofix.py +26 -0
- ara_cli/ara_subcommands/chat.py +27 -0
- ara_cli/ara_subcommands/classifier_directory.py +16 -0
- ara_cli/ara_subcommands/common.py +100 -0
- ara_cli/ara_subcommands/config.py +221 -0
- ara_cli/ara_subcommands/convert.py +43 -0
- ara_cli/ara_subcommands/create.py +75 -0
- ara_cli/ara_subcommands/delete.py +22 -0
- ara_cli/ara_subcommands/extract.py +22 -0
- ara_cli/ara_subcommands/fetch.py +41 -0
- ara_cli/ara_subcommands/fetch_agents.py +22 -0
- ara_cli/ara_subcommands/fetch_scripts.py +19 -0
- ara_cli/ara_subcommands/fetch_templates.py +19 -0
- ara_cli/ara_subcommands/list.py +139 -0
- ara_cli/ara_subcommands/list_tags.py +25 -0
- ara_cli/ara_subcommands/load.py +48 -0
- ara_cli/ara_subcommands/prompt.py +136 -0
- ara_cli/ara_subcommands/read.py +47 -0
- ara_cli/ara_subcommands/read_status.py +20 -0
- ara_cli/ara_subcommands/read_user.py +20 -0
- ara_cli/ara_subcommands/reconnect.py +27 -0
- ara_cli/ara_subcommands/rename.py +22 -0
- ara_cli/ara_subcommands/scan.py +14 -0
- ara_cli/ara_subcommands/set_status.py +22 -0
- ara_cli/ara_subcommands/set_user.py +22 -0
- ara_cli/ara_subcommands/template.py +16 -0
- ara_cli/artefact_autofix.py +154 -63
- ara_cli/artefact_converter.py +256 -0
- ara_cli/artefact_models/artefact_model.py +106 -25
- ara_cli/artefact_models/artefact_templates.py +20 -10
- ara_cli/artefact_models/epic_artefact_model.py +11 -2
- ara_cli/artefact_models/feature_artefact_model.py +31 -1
- ara_cli/artefact_models/userstory_artefact_model.py +15 -3
- ara_cli/artefact_scan.py +2 -2
- ara_cli/chat.py +283 -80
- ara_cli/chat_agent/__init__.py +0 -0
- ara_cli/chat_agent/agent_process_manager.py +155 -0
- ara_cli/chat_script_runner/__init__.py +0 -0
- ara_cli/chat_script_runner/script_completer.py +23 -0
- ara_cli/chat_script_runner/script_finder.py +41 -0
- ara_cli/chat_script_runner/script_lister.py +36 -0
- ara_cli/chat_script_runner/script_runner.py +36 -0
- ara_cli/chat_web_search/__init__.py +0 -0
- ara_cli/chat_web_search/web_search.py +263 -0
- ara_cli/commands/agent_run_command.py +98 -0
- ara_cli/commands/fetch_agents_command.py +106 -0
- ara_cli/commands/fetch_scripts_command.py +43 -0
- ara_cli/commands/fetch_templates_command.py +39 -0
- ara_cli/commands/fetch_templates_commands.py +39 -0
- ara_cli/commands/list_agents_command.py +39 -0
- ara_cli/commands/read_command.py +17 -4
- ara_cli/completers.py +180 -0
- ara_cli/constants.py +2 -0
- ara_cli/directory_navigator.py +37 -4
- ara_cli/file_loaders/text_file_loader.py +2 -2
- ara_cli/global_file_lister.py +5 -15
- ara_cli/llm_utils.py +58 -0
- ara_cli/prompt_chat.py +20 -4
- ara_cli/prompt_extractor.py +199 -76
- ara_cli/prompt_handler.py +160 -59
- ara_cli/tag_extractor.py +38 -18
- ara_cli/template_loader.py +3 -2
- ara_cli/template_manager.py +52 -21
- ara_cli/templates/global-scripts/hello_global.py +1 -0
- ara_cli/templates/prompt-modules/commands/add_scenarios_for_new_behaviour.feature_creation_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/align_feature_with_implementation_changes.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/analyze_codebase_and_plan_tasks.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/choose_best_parent_artefact.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/create_tasks_from_artefact_content.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/create_tests_for_uncovered_modules.test_generation_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/derive_features_from_video_description.feature_creation_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/describe_agent_capabilities.agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/empty.commands.md +2 -12
- ara_cli/templates/prompt-modules/commands/execute_scoped_todos_in_task.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/explain_single_file_purpose.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/extract_file_information_bullets.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/extract_general.commands.md +12 -0
- ara_cli/templates/prompt-modules/commands/extract_markdown.commands.md +11 -0
- ara_cli/templates/prompt-modules/commands/extract_python.commands.md +13 -0
- ara_cli/templates/prompt-modules/commands/feature_add_or_modifiy_specified_behavior.commands.md +36 -0
- ara_cli/templates/prompt-modules/commands/feature_generate_initial_specified_bevahior.commands.md +53 -0
- ara_cli/templates/prompt-modules/commands/fix_failing_behave_step_definitions.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/fix_failing_pytest_tests.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/general_instruction_policy.commands.md +47 -0
- ara_cli/templates/prompt-modules/commands/generate_and_fix_pytest_tests.test_generation_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/prompt_template_tech_stack_transformer.commands.md +95 -0
- ara_cli/templates/prompt-modules/commands/python_bug_fixing_code.commands.md +34 -0
- ara_cli/templates/prompt-modules/commands/python_generate_code.commands.md +27 -0
- ara_cli/templates/prompt-modules/commands/python_refactoring_code.commands.md +39 -0
- ara_cli/templates/prompt-modules/commands/python_step_definitions_generation_and_fixing.commands.md +40 -0
- ara_cli/templates/prompt-modules/commands/python_unittest_generation_and_fixing.commands.md +48 -0
- ara_cli/templates/prompt-modules/commands/suggest_next_story_child_tasks.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/summarize_or_transcribe_media.interview_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/update_feature_to_match_implementation.feature_creation_agent.commands.md +1 -0
- ara_cli/templates/prompt-modules/commands/update_user_story_with_requirements.interview_agent.commands.md +1 -0
- ara_cli/version.py +1 -1
- {ara_cli-0.1.10.0.dist-info → ara_cli-0.1.13.3.dist-info}/METADATA +34 -1
- {ara_cli-0.1.10.0.dist-info → ara_cli-0.1.13.3.dist-info}/RECORD +123 -54
- tests/test_ara_command_action.py +31 -19
- tests/test_ara_config.py +177 -90
- tests/test_artefact_autofix.py +170 -97
- tests/test_artefact_autofix_integration.py +495 -0
- tests/test_artefact_converter.py +357 -0
- tests/test_artefact_extraction.py +564 -0
- tests/test_artefact_scan.py +1 -1
- tests/test_chat.py +162 -126
- tests/test_chat_givens_images.py +603 -0
- tests/test_chat_script_runner.py +454 -0
- tests/test_global_file_lister.py +1 -1
- tests/test_llm_utils.py +164 -0
- tests/test_prompt_chat.py +343 -0
- tests/test_prompt_extractor.py +683 -0
- tests/test_prompt_handler.py +12 -4
- tests/test_tag_extractor.py +19 -13
- tests/test_web_search.py +467 -0
- ara_cli/ara_command_parser.py +0 -605
- ara_cli/templates/prompt-modules/blueprints/complete_pytest_unittest.blueprint.md +0 -27
- ara_cli/templates/prompt-modules/blueprints/task_todo_list_implement_feature_BDD_way.blueprint.md +0 -30
- ara_cli/templates/prompt-modules/commands/artefact_classification.commands.md +0 -9
- ara_cli/templates/prompt-modules/commands/artefact_extension.commands.md +0 -17
- ara_cli/templates/prompt-modules/commands/artefact_formulation.commands.md +0 -14
- ara_cli/templates/prompt-modules/commands/behave_step_generation.commands.md +0 -102
- ara_cli/templates/prompt-modules/commands/code_generation_complex.commands.md +0 -20
- ara_cli/templates/prompt-modules/commands/code_generation_simple.commands.md +0 -13
- ara_cli/templates/prompt-modules/commands/error_fixing.commands.md +0 -20
- ara_cli/templates/prompt-modules/commands/feature_file_update.commands.md +0 -18
- ara_cli/templates/prompt-modules/commands/feature_formulation.commands.md +0 -43
- ara_cli/templates/prompt-modules/commands/js_code_generation_simple.commands.md +0 -13
- ara_cli/templates/prompt-modules/commands/refactoring.commands.md +0 -15
- ara_cli/templates/prompt-modules/commands/refactoring_analysis.commands.md +0 -9
- ara_cli/templates/prompt-modules/commands/reverse_engineer_feature_file.commands.md +0 -15
- ara_cli/templates/prompt-modules/commands/reverse_engineer_program_flow.commands.md +0 -19
- {ara_cli-0.1.10.0.dist-info → ara_cli-0.1.13.3.dist-info}/WHEEL +0 -0
- {ara_cli-0.1.10.0.dist-info → ara_cli-0.1.13.3.dist-info}/entry_points.txt +0 -0
- {ara_cli-0.1.10.0.dist-info → ara_cli-0.1.13.3.dist-info}/top_level.txt +0 -0
ara_cli/template_manager.py
CHANGED
|
@@ -5,6 +5,7 @@ from shutil import copy
|
|
|
5
5
|
from ara_cli.classifier import Classifier
|
|
6
6
|
from ara_cli.directory_navigator import DirectoryNavigator
|
|
7
7
|
from ara_cli.artefact_models.artefact_templates import template_artefact_of_type
|
|
8
|
+
from ara_cli.constants import VALID_ASPECTS
|
|
8
9
|
|
|
9
10
|
|
|
10
11
|
class TemplatePathManager:
|
|
@@ -27,7 +28,10 @@ class TemplatePathManager:
|
|
|
27
28
|
base_path = self.get_template_base_path_aspects()
|
|
28
29
|
return [
|
|
29
30
|
(base_path / f"template.{aspect}.md", f"{aspect}.md"),
|
|
30
|
-
(
|
|
31
|
+
(
|
|
32
|
+
base_path / f"template.{aspect}.exploration.md",
|
|
33
|
+
f"{aspect}.exploration.md",
|
|
34
|
+
),
|
|
31
35
|
]
|
|
32
36
|
|
|
33
37
|
def get_template_content(self, classifier):
|
|
@@ -63,7 +67,9 @@ class ArtefactFileManager:
|
|
|
63
67
|
os.mkdir(data_dir)
|
|
64
68
|
os.chdir(data_dir)
|
|
65
69
|
else:
|
|
66
|
-
raise ValueError(
|
|
70
|
+
raise ValueError(
|
|
71
|
+
f"File {artefact_file_path} does not exist. Please create it first."
|
|
72
|
+
)
|
|
67
73
|
|
|
68
74
|
def copy_aspect_templates_to_directory(self, aspect, print_relative_to=""):
|
|
69
75
|
"""Copies the templates for the given aspect to the current directory."""
|
|
@@ -84,7 +90,9 @@ class ArtefactFileManager:
|
|
|
84
90
|
steps_file_path = f"features/steps/{artefact_name}_steps.py"
|
|
85
91
|
|
|
86
92
|
behave_command = f"behave features/{artefact_name}.feature"
|
|
87
|
-
result = subprocess.run(
|
|
93
|
+
result = subprocess.run(
|
|
94
|
+
behave_command, shell=True, capture_output=True, text=True
|
|
95
|
+
)
|
|
88
96
|
|
|
89
97
|
# Stderr command output needs to be reduced to only given-when-then statements
|
|
90
98
|
if len(result.stderr) == 0:
|
|
@@ -94,26 +102,34 @@ class ArtefactFileManager:
|
|
|
94
102
|
|
|
95
103
|
def format_behave_command_output(self, raw_result):
|
|
96
104
|
# Split the input string by lines
|
|
97
|
-
lines = raw_result.split(
|
|
105
|
+
lines = raw_result.split("\n")
|
|
98
106
|
|
|
99
107
|
# Find the first given/when/then and last raise NotImplementedError line
|
|
100
108
|
keywords = ["@given", "@when", "@then"]
|
|
101
|
-
start_index = next(
|
|
102
|
-
|
|
109
|
+
start_index = next(
|
|
110
|
+
i
|
|
111
|
+
for i, line in enumerate(lines)
|
|
112
|
+
if any(keyword in line for keyword in keywords)
|
|
113
|
+
)
|
|
114
|
+
end_index = next(
|
|
115
|
+
i
|
|
116
|
+
for i, line in reversed(list(enumerate(lines)))
|
|
117
|
+
if "raise NotImplementedError" in line
|
|
118
|
+
)
|
|
103
119
|
|
|
104
120
|
# Extract the relevant given-when-then portion
|
|
105
|
-
formatted_code =
|
|
121
|
+
formatted_code = "\n".join(lines[start_index : end_index + 1])
|
|
106
122
|
return formatted_code
|
|
107
123
|
|
|
108
124
|
def save_behave_steps_to_file(self, artefact_name, behave_steps):
|
|
109
125
|
self.navigator.navigate_to_target()
|
|
110
126
|
file_path = f"features/steps/{artefact_name}_steps.py"
|
|
111
|
-
with open(file_path,
|
|
127
|
+
with open(file_path, "w", encoding="utf-8") as file:
|
|
112
128
|
file.write(behave_steps)
|
|
113
129
|
|
|
114
130
|
|
|
115
131
|
class SpecificationBreakdownAspects:
|
|
116
|
-
VALID_ASPECTS =
|
|
132
|
+
VALID_ASPECTS = VALID_ASPECTS
|
|
117
133
|
|
|
118
134
|
def __init__(self):
|
|
119
135
|
self.file_manager = ArtefactFileManager()
|
|
@@ -123,34 +139,49 @@ class SpecificationBreakdownAspects:
|
|
|
123
139
|
if artefact_name in Classifier.valid_classifiers:
|
|
124
140
|
raise ValueError(f"{artefact_name} is not a valid artefact name")
|
|
125
141
|
|
|
126
|
-
if
|
|
142
|
+
if (
|
|
143
|
+
not Classifier.is_valid_classifier(classifier)
|
|
144
|
+
or classifier in self.VALID_ASPECTS
|
|
145
|
+
):
|
|
127
146
|
raise ValueError(f"{classifier} is not a valid classifier.")
|
|
128
147
|
|
|
129
148
|
if aspect not in self.VALID_ASPECTS:
|
|
130
|
-
raise ValueError(
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
149
|
+
raise ValueError(
|
|
150
|
+
f"{aspect} does not exist. Please choose one of the {self.VALID_ASPECTS} list."
|
|
151
|
+
)
|
|
152
|
+
|
|
153
|
+
def create(
|
|
154
|
+
self,
|
|
155
|
+
artefact_name="artefact_name",
|
|
156
|
+
classifier="classifier",
|
|
157
|
+
aspect="specification_breakdown_aspect",
|
|
158
|
+
):
|
|
134
159
|
original_directory = os.getcwd()
|
|
135
160
|
navigator = DirectoryNavigator()
|
|
136
161
|
navigator.navigate_to_target()
|
|
137
162
|
|
|
138
163
|
self.validate_input(artefact_name, classifier, aspect)
|
|
139
|
-
artefact_file_path = self.file_manager.get_artefact_file_path(
|
|
164
|
+
artefact_file_path = self.file_manager.get_artefact_file_path(
|
|
165
|
+
artefact_name, classifier
|
|
166
|
+
)
|
|
140
167
|
data_dir = self.file_manager.get_data_directory_path(artefact_name, classifier)
|
|
141
168
|
self.file_manager.create_directory(artefact_file_path, data_dir)
|
|
142
|
-
self.file_manager.copy_aspect_templates_to_directory(
|
|
143
|
-
|
|
144
|
-
|
|
169
|
+
self.file_manager.copy_aspect_templates_to_directory(
|
|
170
|
+
aspect, print_relative_to=original_directory
|
|
171
|
+
)
|
|
172
|
+
|
|
173
|
+
if aspect == "step":
|
|
145
174
|
# Instead of generating from behave command, read from the template file
|
|
146
175
|
template_file_path = f"{aspect}.md"
|
|
147
176
|
try:
|
|
148
|
-
with open(template_file_path,
|
|
177
|
+
with open(template_file_path, "r", encoding="utf-8") as file:
|
|
149
178
|
steps_content = file.read()
|
|
150
|
-
self.file_manager.save_behave_steps_to_file(
|
|
179
|
+
self.file_manager.save_behave_steps_to_file(
|
|
180
|
+
artefact_name, steps_content
|
|
181
|
+
)
|
|
151
182
|
except FileNotFoundError:
|
|
152
183
|
# Fallback to the original behavior if template doesn't exist
|
|
153
184
|
steps = self.file_manager.generate_behave_steps(artefact_name)
|
|
154
185
|
self.file_manager.save_behave_steps_to_file(artefact_name, steps)
|
|
155
186
|
|
|
156
|
-
os.chdir(original_directory)
|
|
187
|
+
os.chdir(original_directory)
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
print('Hello Global')
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Given the existing feature file {feature_file_path} and the implementation change described in {implementation_change_reference} (for example, a specific source file or change request), create new scenarios and update the feature file directly so that the new behaviour is fully covered.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
I have changed the implementation file {updated_implementation_file_path} by adding new functionality after the existing comment markers. Update the related feature file {feature_file_path} so that the Then-steps match the new behaviour and, if needed, create additional scenarios to cover the new logic.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Analyse the codebase and all related feature files using the semantic search tool {codebase_collector_tool_name} (either codebase_collector_features or codebase_collector_frontend, depending on the project). Use a detailed semantic query {codebase_query_description} derived from the user story in {user_story_task_file_path}. Based on the retrieved context, list which new tasks are needed for code changes, tests, and documentation. Then, use the appropriate agents (autocoder_behavetests_agent, autocoder_agent, documentation_agent, feature_creation_agent, test_generation_agent, web_autocoder_agent) so that the necessary feature files and tests are created or updated according to your findings.
|
ara_cli/templates/prompt-modules/commands/choose_best_parent_artefact.interview_agent.commands.md
ADDED
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Using the find_the_best_suited_parent_artefact tool for the given artifact, determine which artefact is best suited to capture the value. Explain your reasoning and, if needed, propose concrete artefact names or formats.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
From the artefact content at {example_artefact_file_path}, create a set of implementation tasks with the exact specified names and content and assign them logically to the responsible user {assignee_identifier}. Do not modify the provided task texts; just materialise them as individual task entries in the appropriate location.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Create pytest tests for all modules that currently have 0% coverage according to the coverage report at {coverage_report_path}. Generate test files for each uncovered module in {tests_output_directory}, ensuring that basic behaviour and key error cases are tested.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Based on the information provided in the video described in {video_description_source} (or the attached video), derive the matching feature files and their content under {features_directory_path}. Use the parent user story in {user_story_file_path} and the existing matching rules in {matching_rules_file_path}, then update existing feature files or create new ones so that all described behaviours are covered.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Describe in detail what this agent can do for the user. Focus on supported capabilities, limitations, and typical workflows, and output the description as user-facing documentation. Do not use any tools.
|
|
@@ -1,14 +1,4 @@
|
|
|
1
1
|
### COMMANDS FOR ...
|
|
2
2
|
Your job is now:
|
|
3
|
-
*
|
|
4
|
-
* ...
|
|
5
|
-
|
|
6
|
-
* return your results in the following format, ensuring your generated code blocks are not just code snippets but at complete method levels. Use for every single generated code block this format:
|
|
7
|
-
```python
|
|
8
|
-
# [ ] extract
|
|
9
|
-
# filename: {path/filename}.py
|
|
10
|
-
{python code}
|
|
11
|
-
```
|
|
12
|
-
* the extract and filename statements are only allowed once per code block
|
|
13
|
-
|
|
14
|
-
* in case you think information is missing in order to generate a suffiently precise formulation, return a warning "WARNING: information is missing to correctly fullfill the job!" and then explain what kind of information you think is missing and how I could easily retrieve it.
|
|
3
|
+
* <main list for mandotory commands>
|
|
4
|
+
* ...
|
ara_cli/templates/prompt-modules/commands/execute_scoped_todos_in_task.interview_agent.commands.md
ADDED
|
@@ -0,0 +1 @@
|
|
|
1
|
+
In the task file at {task_file_path}, there are multiple TODOs. Perform only the TODOs that relate to {todo_scope_description} (for example, Docker image builds, logging clean-up, or UI copy changes), implement the required changes, and then mark only those relevant TODOs as completed inside the task file.
|
ara_cli/templates/prompt-modules/commands/explain_single_file_purpose.interview_agent.commands.md
ADDED
|
@@ -0,0 +1 @@
|
|
|
1
|
+
What is this file about: {input_file_path}? Read the file using the appropriate tools and return a concise explanation of its purpose, structure, and key domain concepts.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Read the file at {input_file_path} and extract all key information into bullet points. Group the bullets by topic (for example: decisions, open questions, action items) and avoid repeating minor details.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# general file generation and file extract instructions
|
|
2
|
+
* return only full copy pastable file content using this markdown codeblock format with 5 backticks:
|
|
3
|
+
`````
|
|
4
|
+
# [ ] extract
|
|
5
|
+
# filename: <absolute filepath>/<filename>.<file_extension>
|
|
6
|
+
{valid file content depending on the given file_extension}
|
|
7
|
+
`````
|
|
8
|
+
|
|
9
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
10
|
+
* 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 '#'
|
|
11
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
12
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# general markdown file generation and file extract instructions
|
|
2
|
+
* return full copy pastable file content using a markdown code block with 5-backticks:
|
|
3
|
+
`````
|
|
4
|
+
# [ ] extract
|
|
5
|
+
# filename: <filepath>/<filename>.md
|
|
6
|
+
{markdown formatted text}
|
|
7
|
+
`````
|
|
8
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
9
|
+
* 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 '#'
|
|
10
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
11
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# general python code file generation and file extract instructions
|
|
2
|
+
* return only full copy pastable file content using this markdown codeblock format:
|
|
3
|
+
|
|
4
|
+
```python
|
|
5
|
+
# [ ] extract
|
|
6
|
+
# filename: src/{filename}.py
|
|
7
|
+
{python code}
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
11
|
+
* 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 '#'
|
|
12
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
13
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
ara_cli/templates/prompt-modules/commands/feature_add_or_modifiy_specified_behavior.commands.md
ADDED
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
# COMMANDS FOR ADDING OR MODIFYING EXISTING SPECIFIED BEHAVIOR
|
|
2
|
+
|
|
3
|
+
**At first**:
|
|
4
|
+
|
|
5
|
+
Check if a set of feature files is given
|
|
6
|
+
|
|
7
|
+
* In case no feature files are given:
|
|
8
|
+
* Stop immediately and respond with: "Error in prompt context: no feature files are given as already specified application behavior"
|
|
9
|
+
|
|
10
|
+
* Else:
|
|
11
|
+
* Continue following the given instructions
|
|
12
|
+
|
|
13
|
+
# Instructions
|
|
14
|
+
Your job is now:
|
|
15
|
+
* Silently analyze the given feature files and the specified behavior.
|
|
16
|
+
* Silently analyze the additionally given information about new wanted behavior or changes of existing behavior
|
|
17
|
+
* 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
|
|
18
|
+
* Now formulate to fully cover the new or changed behavior (one, two or many changed or new feature files)
|
|
19
|
+
|
|
20
|
+
Follow these feature file quality rules:
|
|
21
|
+
* 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.
|
|
22
|
+
* Follow strictly the given feature file format in order to structure your feature files.
|
|
23
|
+
* 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.
|
|
24
|
+
|
|
25
|
+
* Wrap and return the formulated feature files as full copy pastable file content in the following format as markdown code block:
|
|
26
|
+
|
|
27
|
+
```artefact
|
|
28
|
+
# [ ] extract
|
|
29
|
+
# filename: ara/features/{filename}.feature
|
|
30
|
+
{formulation, with the valid feature file structure following the given feature files as reference}
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
34
|
+
* 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 '#'
|
|
35
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
36
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
ara_cli/templates/prompt-modules/commands/feature_generate_initial_specified_bevahior.commands.md
ADDED
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# COMMANDS FOR INITIALLY SPECIFYING APPLICATION BEHAVIOR USING FEATURE FILES
|
|
2
|
+
|
|
3
|
+
* Given a description of the wanted application behavior as bullet point list, specification document, ...
|
|
4
|
+
|
|
5
|
+
* And given this feature template with placeholders in <...>
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
@creator_Egermeier
|
|
9
|
+
Feature: <descriptive title>
|
|
10
|
+
|
|
11
|
+
As a <user>
|
|
12
|
+
I want to <do something | need something>
|
|
13
|
+
So that <I can achieve something>
|
|
14
|
+
|
|
15
|
+
Contributes to <here comes your parent artefact> <here comes your classifier of the parent artefact>
|
|
16
|
+
|
|
17
|
+
Description: <further optional description to understand
|
|
18
|
+
the rule, no format defined, the example artefact is only a placeholder>
|
|
19
|
+
|
|
20
|
+
Scenario: <descriptive scenario title>
|
|
21
|
+
Given <precondition>
|
|
22
|
+
When <action>
|
|
23
|
+
Then <expected result>
|
|
24
|
+
|
|
25
|
+
Scenario Outline: <descriptive scenario title>
|
|
26
|
+
Given <precondition>
|
|
27
|
+
When <action>
|
|
28
|
+
Then <expected result>
|
|
29
|
+
|
|
30
|
+
Examples:
|
|
31
|
+
| descriptive scenario title | precondition | action | expected result |
|
|
32
|
+
| <example title 1> | <example precond. 1> | <example action 1> | <example result 1> |
|
|
33
|
+
| <example title 2> | <example precond. 2> | <example action 2> | <example result 2> |
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
# Instructions
|
|
37
|
+
* Now formulate a set (one, two or many, each feature file should not consist of more than max 3 scenarios
|
|
38
|
+
* 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.
|
|
39
|
+
* 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.
|
|
40
|
+
* 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.
|
|
41
|
+
|
|
42
|
+
* Wrap and return the formulated feature files as full copy pastable file content in the following format as markdown code block:
|
|
43
|
+
|
|
44
|
+
```artefact
|
|
45
|
+
# [ ] extract
|
|
46
|
+
# filename: ara/features/{filename}.feature
|
|
47
|
+
{formulation, with the valid feature file structure as given by the feature gherkin template}
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
51
|
+
* 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 '#'
|
|
52
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
53
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
After the feature file {feature_file_path} was updated to reflect the changed functionality in {implementation_file_path}, the step definitions in {step_definitions_file_path} started failing. Run behave for this feature file, observe the failures, fix the step definitions, write the changes to disk, and repeat the cycle until all scenarios pass.
|
ara_cli/templates/prompt-modules/commands/fix_failing_pytest_tests.interview_agent.commands.md
ADDED
|
@@ -0,0 +1 @@
|
|
|
1
|
+
After the implementation file {implementation_file_path} was updated, the tests in {pytest_file_path} are failing. Run pytest for this test file, observe the results, fix the tests, write the changes to disk, and run pytest again. Continue the cycle until all tests pass.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
You are to generate a response that may include Markdown, code blocks, or content that itself contains backticks.
|
|
2
|
+
|
|
3
|
+
To ensure correct rendering follow this fencing policy:
|
|
4
|
+
|
|
5
|
+
- Code files: wrap each file’s output in a triple-backtick fence labeled with the file extension (e.g., ```py, ```js, ```json).
|
|
6
|
+
- Markdown or plain-text files: wrap each file’s output in a five-backtick fence labeled with md or txt (e.g., `````md or `````txt).
|
|
7
|
+
- Do not use dynamic or variable-length fences. Only use:
|
|
8
|
+
- 3 backticks for code file types.
|
|
9
|
+
- 5 backticks for .md and .txt files.
|
|
10
|
+
|
|
11
|
+
File block structure (mandatory, exact)
|
|
12
|
+
- Each file must be returned in its own fenced block with this exact header format as the first two lines:
|
|
13
|
+
1) "# [x] extract"
|
|
14
|
+
2) "# filename: <absolute filepath>/<filename>.<extension>"
|
|
15
|
+
- After these two lines, include the exact file content.
|
|
16
|
+
- The first character of line 1 and line 2 inside the fence must be '#'.
|
|
17
|
+
- The "# [x] extract" and "# filename:" headers must appear exactly once per fenced block.
|
|
18
|
+
|
|
19
|
+
In case of nested code inside file contents
|
|
20
|
+
- If the file content itself needs code blocks:
|
|
21
|
+
- Use standard triple backticks (```) inside the file content and for the outer fence five backticks (`````).
|
|
22
|
+
- For Markdown/Text files, this is safe because the outer fence is five backticks.
|
|
23
|
+
- For Code files, avoid embedding literal triple-backtick sequences inside the file content to prevent fence collisions. If unavoidable, ask the user to approve an .md/.txt wrapper instead.
|
|
24
|
+
|
|
25
|
+
Template examples
|
|
26
|
+
|
|
27
|
+
Code file (e.g., Python):
|
|
28
|
+
```py
|
|
29
|
+
# [x] extract
|
|
30
|
+
# filename: /abs/path/app.py
|
|
31
|
+
print("Hello")
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Markdown file:
|
|
35
|
+
`````md
|
|
36
|
+
# [x] extract
|
|
37
|
+
# filename: /abs/path/README.md
|
|
38
|
+
# Project Title
|
|
39
|
+
Some docs with a code block:
|
|
40
|
+
|
|
41
|
+
```js
|
|
42
|
+
console.log("hi");
|
|
43
|
+
```
|
|
44
|
+
`````
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
Generate pytest tests for the modules listed in {target_module_paths}, starting with {primary_module_name}. Aim for high coverage.
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
# Tech Stack Prompt Template Transformer
|
|
2
|
+
|
|
3
|
+
## PROMPT:
|
|
4
|
+
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.
|
|
5
|
+
|
|
6
|
+
### INPUT REQUIREMENTS:
|
|
7
|
+
1. **Target Technology Stack** (MANDATORY): The technology stack to transform to (e.g., 'C#', 'Java', 'React', 'TypeScript', 'Go', 'Rust', etc.)
|
|
8
|
+
2. **Source Prompt Templates** (MANDATORY): One or more Python prompt templates to transform
|
|
9
|
+
|
|
10
|
+
### TRANSFORMATION RULES:
|
|
11
|
+
1. **Preserve Structure and Intent**:
|
|
12
|
+
- Maintain the same logical flow and purpose of each prompt template
|
|
13
|
+
- Keep all sections and their hierarchical organization
|
|
14
|
+
- Preserve the extract/filename format for code generation
|
|
15
|
+
|
|
16
|
+
2. **Technology-Specific Adaptations**:
|
|
17
|
+
- Replace Python-specific references with target technology equivalents
|
|
18
|
+
- Update file extensions (.py → appropriate extension for target stack)
|
|
19
|
+
- Adapt coding standards (PEP8 → target language conventions)
|
|
20
|
+
- Replace Python packages with target language equivalents
|
|
21
|
+
- Update testing frameworks (pytest/behave → target language testing tools)
|
|
22
|
+
- Adapt documentation styles (numpy docstrings → target language documentation)
|
|
23
|
+
- Update logging approaches to target language standards
|
|
24
|
+
- Adjust line/method/class length limits based on target language best practices. Prefer lower length limits.
|
|
25
|
+
|
|
26
|
+
3. **Naming Convention**:
|
|
27
|
+
- Prefix each transformed template filename with the target technology
|
|
28
|
+
- Example: `python_bug_fixing_code.commands.md` → `csharp_bug_fixing_code.commands.md`
|
|
29
|
+
|
|
30
|
+
4. **Output Format**:
|
|
31
|
+
- Return each transformed template as a complete, copy-pastable markdown file in 5-backticks
|
|
32
|
+
- 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 '#'
|
|
33
|
+
- Use this format for each transformed template:
|
|
34
|
+
|
|
35
|
+
`````markdown
|
|
36
|
+
# [ ] extract
|
|
37
|
+
# filename: ara/.araconfig/custom-prompt-modules/commands/{technology}_{original_template_name}
|
|
38
|
+
{transformed template content}
|
|
39
|
+
`````
|
|
40
|
+
|
|
41
|
+
5. Markdown code block handling in prompt templates
|
|
42
|
+
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
|
|
43
|
+
|
|
44
|
+
6. **Technology Mapping Guidelines**:
|
|
45
|
+
**For C#/.NET:**
|
|
46
|
+
- PEP8 → C# Coding Conventions (Microsoft guidelines)
|
|
47
|
+
- pytest → NUnit/xUnit/MSTest
|
|
48
|
+
- behave → SpecFlow
|
|
49
|
+
- unittest.mock → Moq/NSubstitute
|
|
50
|
+
- numpy docstrings → XML documentation comments
|
|
51
|
+
- logging package → ILogger/Serilog/NLog
|
|
52
|
+
|
|
53
|
+
**For Java:**
|
|
54
|
+
- PEP8 → Java Code Conventions (Oracle/Google style)
|
|
55
|
+
- pytest → JUnit/TestNG
|
|
56
|
+
- behave → Cucumber-JVM
|
|
57
|
+
- unittest.mock → Mockito/EasyMock
|
|
58
|
+
- numpy docstrings → Javadoc
|
|
59
|
+
- logging package → SLF4J/Log4j
|
|
60
|
+
|
|
61
|
+
**For JavaScript/TypeScript:**
|
|
62
|
+
- PEP8 → ESLint/Prettier standards
|
|
63
|
+
- pytest → Jest/Mocha/Vitest
|
|
64
|
+
- behave → Cucumber.js, Selenium
|
|
65
|
+
- unittest.mock → Jest mocks/Sinon
|
|
66
|
+
- numpy docstrings → JSDoc/TSDoc
|
|
67
|
+
- logging package → Winston/Bunyan/Pino
|
|
68
|
+
|
|
69
|
+
**For React:**
|
|
70
|
+
- Include React-specific patterns (components, hooks, state management)
|
|
71
|
+
- pytest → Jest/React Testing Library
|
|
72
|
+
- behave → Selenium
|
|
73
|
+
- Add component testing guidelines
|
|
74
|
+
- Include JSX/TSX specific rules
|
|
75
|
+
|
|
76
|
+
7. **Preserve Key Constraints**:
|
|
77
|
+
- Maintain separation of concerns and single responsibility principles
|
|
78
|
+
- Keep modular/extensible design requirements
|
|
79
|
+
- Preserve testability requirements
|
|
80
|
+
- Maintain observability/logging requirements
|
|
81
|
+
|
|
82
|
+
### VALIDATION:
|
|
83
|
+
- Ensure all Python-specific references are properly transformed
|
|
84
|
+
- Verify file paths and extensions match target technology conventions
|
|
85
|
+
- Confirm testing and mocking frameworks are appropriate for target stack
|
|
86
|
+
- Check that documentation styles match target language standards
|
|
87
|
+
|
|
88
|
+
### OUTPUT SPECIFICATION:
|
|
89
|
+
- Replace '# [ ] extract' with '# [x] extract' in all output blocks
|
|
90
|
+
- Ensure each template is complete and ready for extraction
|
|
91
|
+
- Include a summary of key transformations made for each template
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
**Begin transformation after receiving target technology stack and source templates.**
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
### COMMANDS FOR FIXING BUGS
|
|
2
|
+
|
|
3
|
+
Your job is now to fix the described error:
|
|
4
|
+
|
|
5
|
+
* Silently analyze the given error description or error log files
|
|
6
|
+
* 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
|
|
7
|
+
* 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.
|
|
8
|
+
|
|
9
|
+
When you touch code or need to generate code for bug fixing:
|
|
10
|
+
* The max function or method length should not exceed 40 lines.
|
|
11
|
+
* The max class length should not exceed 150 lines.
|
|
12
|
+
* The max file length should not exceed 150 lines.
|
|
13
|
+
* Split implementation files or functions/methods/classes in case they exceed their defined length maximum.
|
|
14
|
+
* Apply as coding and design principle the separation of concerns and single responsibility principle in general and specifically when you need to split.
|
|
15
|
+
|
|
16
|
+
* 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.
|
|
17
|
+
* The fixed code must fully implement the specified behavior in an easy testable and modular/extensible way.
|
|
18
|
+
* Follow PEP8 coding guidelines.
|
|
19
|
+
* Use descriptive numpy style docstrings for inline method and class documentation.
|
|
20
|
+
* 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.
|
|
21
|
+
|
|
22
|
+
* Only return full copy pastable file content.
|
|
23
|
+
* Use for every single generated code block this markdown code block format:
|
|
24
|
+
|
|
25
|
+
```python
|
|
26
|
+
# [ ] extract
|
|
27
|
+
# filename: src/{filename}.py
|
|
28
|
+
{python code}
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
* The extract and filename statements are only allowed once per code block
|
|
32
|
+
* 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 '#'
|
|
33
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
34
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
### COMMANDS FOR IMPLEMENTING ONE OR A SET OF NEW OR CHANGED FEATURE FILES
|
|
2
|
+
|
|
3
|
+
Your job is now:
|
|
4
|
+
* Silently analyze the given feature files and the specified behavior.
|
|
5
|
+
* Develop implementation strategies that minimize code changes with respect to any given code and test files, prefer reusing existing methods over new implementations.
|
|
6
|
+
* The max function length should not exceed 25 lines. The max file length should not exceed 120 lines.
|
|
7
|
+
* Always prefer to use existing python packages over your own implementation.
|
|
8
|
+
* In case additional implementation instructions are given as:
|
|
9
|
+
* Specified in files with extensions "*.technology.md" follow strictly the specified mandatory python packages and tech stack
|
|
10
|
+
* Explicitly specified as example reference implementation: use this reference information as starting point for your own implementation
|
|
11
|
+
* 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.
|
|
12
|
+
* 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.
|
|
13
|
+
* 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.
|
|
14
|
+
* 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.
|
|
15
|
+
|
|
16
|
+
* 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:
|
|
17
|
+
|
|
18
|
+
```python
|
|
19
|
+
# [ ] extract
|
|
20
|
+
# filename: src/{filename}.py
|
|
21
|
+
{python code}
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
25
|
+
* 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 '#'
|
|
26
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
27
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
### COMMANDS FOR REFACTORING
|
|
2
|
+
|
|
3
|
+
Your job is now to refactor the code for enhancing the code quality and the design of the code according to the following guidelines:
|
|
4
|
+
* Refactoring = Changing the internal structure of code
|
|
5
|
+
* Without changing its external behavior
|
|
6
|
+
* Goal = Improve readability, maintainability, and design
|
|
7
|
+
-> "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."
|
|
8
|
+
-> "Refactoring changes how code is written, not what it does."
|
|
9
|
+
|
|
10
|
+
Now do:
|
|
11
|
+
* Silently analyze the given code base
|
|
12
|
+
* 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.
|
|
13
|
+
|
|
14
|
+
When you refactor the code remember:
|
|
15
|
+
* The max function or method length should not exceed 40 lines.
|
|
16
|
+
* The max class length should not exceed 150 lines.
|
|
17
|
+
* The max file length should not exceed 150 lines.
|
|
18
|
+
* Split implementation files or functions/methods/classes in case they exceed their defined length maximum.
|
|
19
|
+
* Apply as coding and design principle the separation of concerns and single responsibility principle in general and specifically when you need to split.
|
|
20
|
+
* Flatten nested code structures (e.g. if/while/for statements) to only one nesting level.
|
|
21
|
+
* The refactored code must fully implement the specified behavior in an easy testable and modular/extensible way.
|
|
22
|
+
* Follow PEP8 coding guidelines.
|
|
23
|
+
* Use descriptive numpy style docstrings for inline method and class documentation.
|
|
24
|
+
* 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.
|
|
25
|
+
|
|
26
|
+
Your output specification is:
|
|
27
|
+
* Only return full copy pastable file content.
|
|
28
|
+
* Use for every single generated code block this markdown code block format:
|
|
29
|
+
|
|
30
|
+
```python
|
|
31
|
+
# [ ] extract
|
|
32
|
+
# filename: src/{filename}.py
|
|
33
|
+
{python code}
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
* The extract and filename statements are only allowed once per markdown code block
|
|
37
|
+
* 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 '#'
|
|
38
|
+
* replace the '# [ ] extract' statement of the template with '# [x] extract' in your response
|
|
39
|
+
* in case of files get deprecated give me a list of files that can be safely deleted
|