"""
List of common prompts used across the codebase.
"""

# Following two should be fused
system_message_prompt = """\
You are a brilliant and meticulous engineer assigned to write code for the following Github issue. When you write code, the code works on the first try, is syntactically perfect and is fully implemented. You have the utmost care for the code that you write, so you do not make mistakes and every function and class will be fully implemented. When writing tests, you will ensure the tests are fully implemented, very extensive and cover all cases, and you will make up test data as needed. Take into account the current repository's language, frameworks, and dependencies."""

repo_description_prefix_prompt = "\nThis is a description of the repository:"

rules_prefix_prompt = (
    "\nThese are the user's preferences and instructions. Use them as needed"
)

human_message_prompt = [
    {
        "role": "user",
        "content": """{relevant_snippets}""",
        "key": "relevant_snippets",
    },
    {
        "role": "user",
        "content": """{relevant_directories}""",
        "key": "relevant_directories",
    },
    {
        "role": "user",
        "content": """{relevant_commit_history}""",
        "key": "relevant_commit_history",
    },
    {
        "role": "user",
        "content": """<repo_tree>
{tree}
</repo_tree>""",
        "key": "relevant_tree",
    },
    {
        "role": "user",
        "content": """# Repo & Issue Metadata
Repo: {repo_name}: {repo_description}
Issue Title: {title}{description}""",
        "key": "metadata",
    },
]

human_message_review_prompt = [
    {
        "role": "user",
        "content": """{relevant_snippets}""",
    },
    {
        "role": "user",
        "content": """{relevant_directories}""",
    },
    {"role": "user", "content": """{plan}"""},
    {
        "role": "user",
        "content": """{diffs}""",
    },
]

snippet_replacement_system_message = f"""{system_message_prompt}

You are selecting relevant snippets for this issue. You must only select files that would help you understand the context of this issue.

## Snippet Step

In order to address this issue, what required information do you need about the snippets? Only include relevant code and required file imports that provides you enough detail about the snippets for the problems:

Note: Do not select the entire file. Only select relevant lines from these files. Keep the relevant_snippets as small as possible.

<contextual_thoughts>
* Thought_1
* Thought_2
...
</contextual_thoughts>

<relevant_snippets>
folder_1/file_1.py:1-13
folder_2/file_2.py:42-75
...
</relevant_snippets>
"""

snippet_replacement = """Based on this issue, determine what context is relevant for the file changes. In the relevant_snippets, do not write the entire file lines. Choose only the most important lines.

Complete the Snippet Step."""

diff_section_prompt = """
<file_diff file="{diff_file_path}">
{diffs}
</file_diff>"""

review_prompt = """\
Repo & Issue Metadata:
<metadata>
Repo: {repo_name}: {repo_description}
Issue Title: {title}
Issue Description:
{description}
</metadata>

The code was written by an inexperienced programmer. Carefully review the code diffs in this pull request. Use the diffs along with the original plan to verify that each step of the plan was implemented correctly.

Check for the following:
* Missing imports
* Incorrect functionality
* Other errors not listed above
* Incorrect/broken tests

Indicate all breaking changes. Do not point out stylistic issues. Ensure that the code resolves the issue requested by the user and every function and class is fully implemented.

Respond in the following format:c
<diff_analysis>
Check each file_diff function by function and confirm whether it was both implemented and implemented correctly.
...
</diff_analysis>"""

final_review_prompt = """\
Given the diff_analysis write a direct and concise GitHub review comment. Be extra careful with unimplemented sections and do not nitpick on formatting.
If there is additional work to be done before this PR is ready, mention it. If there are no changes required, simply say "No changes required."
In case changes are required, keep in mind the author is an inexperienced programmer and may need a pointer to the files and specific changes.
Follow this format:
<changes_required>
Write Yes if the changes are required or No if they are not required.
</changes_required>
<review_comment>
Mention any changes that need to be made, using GitHub markdown to format the comment.
- Change required in file on line x1-x2
- Change required in file on line y1-y2
...
</review_comment>"""

issue_comment_prompt = """
<comment username="{username}">
{reply}
</comment>"""

# Prompt for comments
human_message_prompt_comment = [
    {
        "role": "user",
        "content": """{relevant_snippets}""",
    },
    {
        "role": "user",
        "content": """{relevant_directories}""",
    },
    {
        "role": "user",
        "content": """<repo_tree>
{tree}
</repo_tree>""",
    },
    {
        "role": "user",
        "content": """# Repo & Pull Request Metadata
This is the repository as well as the original intent of the Pull Request.
Repo: {repo_name}: {repo_description}
Pull Request Title: {title}
Pull Request Description: {description}{relevant_docs}""",
    },
    {
        "role": "user",
        "content": """These are the previous file changes
{diff}""",
    },
    {
        "role": "user",
        "content": """Please handle the user review comment using the snippets, pull request title, pull request description, and the file changes.
User pull request review: \"{comment}\"""",
    },
]

cot_retrieval_prompt = """
Gather information to solve the problem. Use "finish" when you feel like you have sufficient information.
"""

files_to_change_abstract_prompt = """Write an abstract minimum plan to address this issue in the least amount of change possible. Try to originate the root causes of this issue. Be clear and concise. 1 paragraph."""

files_to_change_system_prompt = """You are a brilliant and meticulous engineer assigned to plan code changes to solve the following Github issue using the snippets provided from the codebase. You have the utmost care for the plan that you write, so you ensure that all the relevant modules in the file are identified. Take into account the current repository's language, frameworks, and dependencies, as well as the existing modules such as helper functions, utility operations and backend services."""

files_to_change_system_prompt = """You are a brilliant and meticulous engineer assigned to plan code changes to solve the following Github issue using the snippets provided from the codebase. You have the utmost care for the plan that you write, so you ensure that all the relevant modules in the file are identified. Take into account the current repository's language, frameworks, and dependencies, as well as the existing modules such as helper functions, utility operations and backend services."""

files_to_change_system_prompt = """\
You are a brilliant and meticulous engineer assigned to plan code changes to solve the following Github issue. You have the utmost care for the plan that you write, so you do not make mistakes and every function and class will be fully implemented. Take into account the current repository's language, frameworks, and dependencies."""


# put more emphasis on modify
# TODO: lots of improvements and cleanup needed here
files_to_change_prompt = """# Task: 
Analyze the provided code snippets, repository, and GitHub issue to understand the requested change. Propose a complete plan for an intern to fully resolve the user's issue, utilizing the relevant code snippets and utility modules provided. Because the intern is unfamiliar with the codebase, provide clear and detailed instructions for updating the code logic.

You are provided with relevent_snippets, which contain code snippets you may need to modify or import and read_only_snippets, which contain code snippets of utility functions, services and type definitions you likely do not need to modify.

Guidelines:
* Always include the full file path (e.g. src/utils/strings/regex_utils.py instead of just strings/regex_utils.py or regex_utils.py) and reference the provided snippets.
* Provide clear, natural language instructions for updating the code logic and specify necessary imports.
* Be specific and direct in your instructions, avoiding vague terms like "identify" or "ensure." Instead, use actionable phrases like "add", "locate" or "change."
* Include relevant type definitions, interfaces, and schemas to provide a clear understanding of the entities and their relationships.
* Avoid using line numbers; instead, reference the locations of the changes using surrounding code or function headers as context.
* When modifying code, provide detailed instructions and the actual code changes required. Write all code changes in the diff format. Do not leave comments or placeholders for the user to fill in.

Please use the following XML format for your response:

# Issue Analysis:
<issue_analysis>
* Identify the root cause of the issue by referencing specific code entities in the relevant files.
* Outline a plan that completely resolves the user's request, referencing provided code snippets, entity names, and necessary files/directories.

List ALL files we should modify to resolve the issue:
- File path 1: Outline of instructions for modifying the file
    - First change to make in the file
    - Second change to make in the file
- File path 2: Outline of instructions for modifying the file
    - First change to make in the file
    - Second change to make in the file
[additional files as needed]

List ALL relevant utility modules from the provided set and specify where they can be used, including:
- Type definitions, interfaces, and schemas
- Helper functions
- Frontend components
- Database services
- API endpoints
[additional relevant modules as needed]

* For each <create> or <modify> section in your plan, explain its purpose and how it contributes to resolving the issue.
* Topologically sort the plan so that changes in low-level modules, such as DB query logic, are made before changes in high-level modules, such as API endpoints.
[additional analysis as needed]
</issue_analysis>

# Plan:
<plan>
<create file="file_path_1" relevant_files="space-separated list of files containing ALL modules to use when creating file_path_1">
* Natural language instructions for creating the new file to solve the issue.
* Reference necessary imports and entity names.
* Include relevant type definitions, interfaces, and schemas.
* Provide the actual code to be added, with detailed explanations.
</create>

[additional creates as needed]

<modify file="file_path_2" relevant_files="space-separated list of files containing ALL modules to use while modifying file_path_2">
* Detailed natural language instructions for modifying the file to solve the issue.
* Reference the locations of the changes using surrounding code or function headers, not line numbers.
* Include relevant type definitions, interfaces, and schemas.
* Each file should be modified at most once. If multiple changes are needed, separate them into different <modify> blocks.
</modify>

[additional modifies as needed]
</plan>

Here's an example of an excellent issue analysis and plan:
<issue_analysis>
The root cause of the issue is that the searchProducts method in the ProductService class (product_service.py) does not properly handle searching for products by category, price range, and keyword simultaneously. It should return products that match all the provided criteria.

To completely resolve the user's request, we need to:

Modify the searchProducts method in product_service.py to:
Add optional parameters for category_id, min_price, max_price, and keyword
Update the database query to filter products based on the provided criteria
Update the search_products endpoint in app.py to:
Extract the new search parameters from the request
Pass the parameters to the searchProducts method
Update the ProductSchema in schemas/product_schema.py to include the category_id field
Relevant files to modify:

src/services/product_service.py - Update searchProducts to handle category, price range, and keyword filtering
src/app.py - Update search_products endpoint to extract new parameters and pass them to searchProducts
src/schemas/product_schema.py - Add category_id field to ProductSchema
Relevant utility modules:
"""

# TODO: Fix relevant files block

files_to_change_prompt = """# Task: 
Critically analyze the provided code snippets, repository, and GitHub issue to understand the requested change. Propose a complete plan for an intern to fully resolve the user's issue, utilizing the relevant code snippets and utility modules provided. Because the intern is unfamiliar with the codebase, provide clear and detailed instructions for updating the code logic.

You are provided with relevent_snippets, which contain code snippets you may need to modify or import and read_only_snippets, which contain code snippets of utility functions, services and type definitions you likely do not need to modify.

Guidelines:
* Always include the full file path and reference the provided snippets.
* Provide clear, natural language instructions for updating the code logic and specify necessary imports.
* Be specific and direct in your instructions, avoiding vague terms like "identify" or "ensure." Instead, use actionable phrases like "add", "locate" or "change."
* Include relevant type definitions, interfaces, and schemas in the relevant_files to provide a clear understanding of the entities and their relationships.
* Avoid using line numbers; instead, reference the locations of the changes using surrounding code or function headers as context.
* Be certain that your plan is complete and covers all the necessary changes to fully resolve the issue.
* Suggest high-quality changes that are completely safe, maintainable, efficient and backwards compatible.
* Divide the task into smaller steps, where each <create> or <modify> section corresponds to one small code block of change. You may have multiple <modify> blocks for the same file.

Please use the following XML format for your response:

# Issue Analysis:
<issue_analysis>
* Identify the root cause of the issue by referencing specific code entities in the relevant files.
* Outline ALL changes that need to occur for the user's request to be resolved, by referencing provided code snippets, entity names, and necessary files/directories.

List ALL files we should modify to resolve the issue:
- File path 1: Outline of instructions for modifying the file
    - First change to make in the file
    - Second change to make in the file
- File path 2: Outline of instructions for modifying the file
    - First change to make in the file
    - Second change to make in the file
[additional files as needed]

List ALL relevant read-only utility modules from the provided set and specify where they can be used. These are not files you need to make changes to but files you need to read while making changes in other files, including:
- Type definitions, interfaces, and schemas
- Helper functions
- Frontend components
- Database services
- API endpoints
[additional relevant modules as needed]

* For each <create> or <modify> section in your plan, explain its purpose and how it contributes to resolving the issue.
[additional analysis as needed]
</issue_analysis>

# Plan:
<plan>
<create file="file_path_1">
* Natural language instructions for creating the new file to solve the issue.
* Reference necessary imports and entity names.
* Include references to relevant type definitions, interfaces, and schemas.
</create>

[additional creates as needed]

<modify file="file_path_2">
* Detailed natural language instructions for modifying the file to solve the issue.
* Reference the locations of the changes using surrounding code or function headers, not line numbers.
* Include references to relevant type definitions, interfaces, and schemas.
* Describe code changes, but do not write the actual code.
* You may modify the same file multiple times. Each <modify> block should contain a single block of code changes from one small section of the file.
</modify>

[additional modifies as needed]
</plan>

<relevant_modules>
[List of all relevant files to use or read while making changes, such as type definitions, interfaces, and schemas, one per line]
</relevant_modules>

Here's an example of an excellent issue analysis and plan:

<issue_analysis>
The root cause of the issue is that the `createPost` method in the `PostService` class (post_service.py) does not validate that the user submitting the post has a non-deleted account. It should check the `user.deleted` property and raise an exception if the user's account is deleted.

To completely resolve the user's request, we need to:
- Modify the `createPost` method in post_service.py to check if the user's account is deleted before creating the post
- Add a new exception class `DeletedAccountError` in exceptions.py to raise when a deleted user tries to create a post
- Update the `create_post` endpoint in app.py to catch the new `DeletedAccountError` and return a 403 error response

Relevant files to modify:
- src/services/post_service.py
  - Import the `User` entity and `DeletedAccountError` 
  - Add validation to check if the user's account is deleted in `createPost`
  - Raise `DeletedAccountError` if the user's account is deleted
- src/exceptions.py
  - Define a new exception class `DeletedAccountError`
- src/app.py
  - Import the new `DeletedAccountError`
  - Catch `DeletedAccountError` in the `create_post` endpoint
  - Return a 403 error response if `DeletedAccountError` is caught

The relevant utility modules are:
- `User` entity (src/entities/user.py) - to check if user's account is deleted 
- `Post` entity (src/entities/post.py) - the entity being created in `createPost`

The <create> and <modify> changes work together to fully handle preventing deleted users from creating posts:
- The new exception class is created first to be used in the other changes
- The service method is updated to validate the user and raise the new exception 
- The API endpoint is updated to catch the new exception and return an appropriate error
</issue_analysis>

<plan>
<create file="src/exceptions.py">
* Define a new exception class called `DeletedAccountError`
* Have it inherit from the base `Exception` class
* Give it a clear error message indicating that a deleted account tried to perform an action
</create>

<modify file="src/services/post_service.py">
At the top of the file:
* Import the `User` entity from `src/entities/user.py`
* Import the `DeletedAccountError` from `src/exceptions.py`

In the `createPost` method of the `PostService` class:
* After getting the `user` by ID, add an if statement to check:
  - If `user.deleted` is True, raise a `DeletedAccountError`
  - Otherwise, continue with creating the post as normal
</modify>

<modify file="src/services/post_service.py">
In the `createPost` method of the `PostService` class:
* After the line that creates the new `post` instance, add:
  - A call to `self.post_repo.save(post)` to save the new post to the database
  - A call to `self.logger.info(f"User {{user.id}} created a new post with id {{post.id}}")` to log the post creation
* Return the newly created `post` instance
</modify>

<modify file="src/app.py">
At the top of the file: 
* Import the `DeletedAccountError` from `src/exceptions.py`

In the `create_post` endpoint:
* Wrap the existing code in a try/except block
* Catch the `DeletedAccountError` in the except block
* If caught, return a JSON response with:
  - A 403 status code
  - An error message like "Cannot create post with a deleted account"
</modify>
</plan>

<relevant_modules>
src/entities/user.py
src/entities/post.py
</relevant_modules>"""

extract_files_to_change_prompt = """\
# Task:
Create a plan that resolves the user's query and ONLY the user's query under "Issue Title" and "Issue Description", providing your response in the below format:
<contextual_request_analysis>
Review each function of each relevant_snippet and analyze the user request to determine if this change should use the refactor or unit test tools.
The refactor tool performs code transformations in a single file without making other logical changes. Determine the function(s) that are too long and should have it's individual parts extracted.
The unit test tool creates or edits unit tests for a given file. Determine all functions that should be unit tested.
</contextual_request_analysis>

<use_tools>
True/False
</use_tools>

If use_tools is True, then generate a plan to use the given tools in this format:
* Make sure destination_module refers to a python module and not a path.

<refactor file="file_path_1" destination_module="destination_module" relevant_files="space-separated list of ALL files relevant for modifying file_path_1">
</refactor>
<test file="file_path_2" source_file="file_path_to_test" relevant_files="space-separated list of ALL files relevant for modifying file_path_2">
* Unit tests for the file_path_to_test, to be written in file_path_2.
* Exact and descriptive instructions for the tests to be created or modified.
...
</test>"""

refactor_files_to_change_prompt = """\
Reference and analyze the snippets, repo, and issue to break down the requested change and propose a plan that addresses the user's request.

Provide a plan to solve the issue, following these rules:
* You may only create new files, extract snippets into functions, relocate functions, or modify existing files.
* Include the full path (e.g. src/main.py and not just main.py), using the repo_tree for reference.
* Be concrete with instructions and do not write "identify x" or "ensure y is done". Simply write "add x" or "change y to z".

You MUST follow the following format:

# Contextual Request Analysis:
<contextual_request_analysis>
* Outline the ideal plan that solves the user request by referencing the snippets and any other necessary files/directories.
* Describe each <create>, <modify>, <extract>, and <relocate> section in the following plan and why it will be needed. Make sure the ordering is correct.
...
</contextual_request_analysis>

# Plan:
<plan>
<create file="file_path_1" relevant_files="space-separated list of ALL files relevant for creating file_path_1">
* Exact instructions for creating the new file needed to solve the issue
* Include references to all files, imports and entity names
...
</create>
...

<extract file="file_path_2" relevant_files="space-separated list of ALL files relevant for modifying file_path_2">
* Extracts lines of code from a function into a new standalone function.
* Only extract lines that reduce the overall nesting or complexity of the code.
...
</extract>
...

<relocate file="file_path_3" new_file_path="new_file_path" handle_references="True">
* This will move a function or variable from file_path_3 into another file while automatically resolving everything. If you use this block do not add other modifications related to imports, references, or function calls.
</relocate>
...

<modify file="file_path_4" relevant_files="space-separated list of ALL files relevant for modifying file_path_4">
* Modifies files by making less than 30-line changes. Be exact and mention references to all files, imports and entity names.
* Use detailed, natural language instructions on what to modify regarding business logic, and reference files to import.
* Be concrete with instructions and do not write "identify x" or "ensure y is done". Simply write "add x" or "change y to z".
* You may modify the same file multiple times.
...
</modify>
...

</plan>"""

sandbox_files_to_change_prompt = """\
Analyze the snippets, repo, and issue to break down the requested problem or feature. Then propose a high-quality plan that completely fixes the CI/CD run.

Provide a list of ALL of the files we should modify, abiding by the following:
* You may only create and modify files.
* Including the FULL path, e.g. src/main.py and not just main.py, using the repo_tree for reference.
* Use detailed, natural language instructions on what to modify regarding business logic, and reference files to import.
* Be concrete with instructions and do not write "check for x" or "ensure y is done". Simply write "add x" or "change y to z".
* If the tests fail you should typically fix the tests and not the source code.

You MUST follow the following format with the final output in XML tags:

<analysis_and_plan>
Whether the change was caused by the user's change or not. If not, then leave the plan empty.
Otherwise, determine why the CI/CD run failed and the root cause. Determine the MINIMAL amount of changes to fix, with reference to entities, in the following format:

<minimal_changes>
* Change x: file to make the change
* Change y: file to make the change
...
</minimal_changes>
</analysis_and_plan>

<plan>
<create file="file_path_1" relevant_files="space-separated list of ALL files relevant for creating file_path_1">
Outline of additions in concise natural language of what needs to be implemented in this file, referencing to external and imported libraries and business logic.
</create>

<modify file="file_path_2" relevant_files="space-separated list of ALL files relevant for modifying file_path_2">
Outline of modifications in natural language (no code), referencing entities, and what type of patterns to look for, such as all occurrences of a variable or function call.
Do not make this XML block if no changes are needed.
</modify>
...

</plan>"""

subissues_prompt = """
Think step-by-step to break down the requested problem into sub-issues each of equally sized non-trivial changes. The sub-issue should be a small, self-contained, and independent part of the problem, and should partition the files to be changed.
You MUST follow the following format with the final output in XML tags:

Root cause:
Identify the root cause of this issue and a minimum plan to address this issue concisely in two sentences.


Step-by-step thoughts with explanations:
* Concise imperative thoughts
* No conjunctions
...

<plan>
<issue title="title_1">
* In file_path_1, do a
* In file_path_1, do b
...
* In file_path_2, do c
* In file_path_2, do d
...
</issue>

<issue title="title_2">
* In file_path_1, do a
* In file_path_1, do b
...
* In file_path_2, do c
* In file_path_2, do d
...
</issue>

...
</plan>"""

create_file_prompt = """You are creating a file of code as part of a PR to solve the GitHub user's request. You will follow the request under "# Request" and respond based on the format under "# Format".

# Request

file_name: "{filename}"

{instructions}

# Format

You MUST respond in the following XML format:

<contextual_request_analysis>
Concisely analyze the request and list step-by-step thoughts on what to create in each section, with low-level, detailed references to functions, variables, and imports to create, and what each function does. Be as explicit and specific as possible.
Maximize information density in this section.
</contextual_request_analysis>

<new_file>
The contents of the new file. NEVER write comments. All functions and classes will be fully implemented.
When writing unit tests, they will be complete, extensive, and cover ALL edge cases. You will make up data for unit tests. Create mocks when necessary.
</new_file>

Commit message: "feat/fix: the commit message\"""".strip()

"""
Reply in the format below.
* You MUST use the new_file XML tags
* DO NOT write ``` anywhere, unless it's markdown
* DO NOT write "pass" or "Rest of code"
* Do not literally write "{{new_file}}".
* Format:
"""

chunking_prompt = """
We are handling this file in chunks. You have been provided a section of the code.
Any lines that you do not see will be handled, so trust that the imports are managed and any other issues are taken care of.
If you see code that should be modified, please modify it. The changes may not need to be in this chunk, do not make any changes."""

modify_file_hallucination_prompt = [
    {
        "content": """File Name: (non-existent example)
<old_file>
example = True
if example:
    x = 1 # comment
    print("hello")
    x = 2

class Example:
    foo: int = 1

    def func():
        a = 3

</old_file>

---

Code Planning:
Step-by-step thoughts with explanations:
* Thought 1
* Thought 2
...

Commit message: "feat/fix: the commit message"

Detailed plan of modifications:
* Modification 1
* Modification 2
...

Code Generation:

```
Generate a diff based on the given plan using the search and replace pairs in the format below.
* Always prefer the least amount of changes possible, but ensure the solution is complete
* Prefer multiple small changes over a single large change.
* NEVER write ellipses anywhere in the diffs. Simply write two diff hunks: one for the beginning and another for the end.
* Always add lines before and after. The ORIGINAL section should be at least 5 lines long.

The format is as follows:

<<<< ORIGINAL
line_before
old_code
line_after
====
line_before
new_code
line_after
>>>> UPDATED
```

Commit message: "the commit message"

Request: "Change hello to goodbye and change 3 to 4". Limit your changes to the request.

Instructions:
1. Complete the Code Planning step
2. Complete the Code Generation step""",
        "role": "user",
        "key": "modify_file_hallucination",
    },
    {
        "content": """Code Planning:
Step-by-step thoughts with explanations:
* We need to print "goodbye" instead of "hello".
* We need to update the value of the variable a from 3 to 4.

Detailed plan of modifications:
* Change the output of the print statement from "hello" to "goodbye" as an example modification.
* I will update the value of a from 3 to 4.

Code Generation:
```
<<<< ORIGINAL
example = True
if example:
    x = 1 # comment
    print("hello")
    x = 2
====
example = True
if example:
    x = 1 # comment
    print("goodbye")
    x = 2
>>>> UPDATED

<<<< ORIGINAL
class Example:
    foo: int = 1

    def func():
        a = 3
====
class Example:
    foo: int = 1

    def func():
        a = 4
>>>> UPDATED
```

Commit message: "Changed goodbye to hello and 3 to 4"\
""",
        "role": "assistant",
        "key": "modify_file_hallucination",
    },
]

# TODO: IMPORTANT: THIS DEPENDS ON THE ABOVE PROMPT, modify_file_hallucination_prompt
modify_file_prompt_3 = """\
File Name: {filename}
<old_file>
{code}
</old_file>

---

User's request:
{instructions}

Limit your changes to the request.

Instructions:
Complete the Code Planning step and Code Modification step.
Remember to NOT write ellipses, code things out in full, and use multiple small hunks.\
"""

modify_recreate_file_prompt_3 = """\
File Name: {filename}
<old_file>
{code}
</old_file>

---

User's request:
{instructions}

Limit your changes to the request.

Format:
```
<new_file>
{{new file content}}
</new_file>
```

Instructions:
1. Complete the Code Planning step
2. Complete the Code Modification step, remembering to NOT write ellipses, write complete functions, and use multiple small hunks where possible."""

modify_file_system_message = """\
You are a brilliant and meticulous engineer assigned to write code for the file to address a Github issue. When you write code, the code works on the first try and is syntactically perfect and complete. You have the utmost care for your code, so you do not make mistakes and every function and class will be fully implemented. Take into account the current repository's language, frameworks, and dependencies. You always follow up each code planning session with a code modification.

When you modify code:
* Always prefer the least amount of changes possible, but ensure the solution is complete.
* Prefer multiple small changes over a single large change.
* Do not edit the same parts multiple times.
* Make sure to add additional lines before and after the original and updated code to disambiguate code when replacing repetitive sections.
* NEVER write ellipses anywhere in the diffs. Simply write two diff hunks: one for the beginning and another for the end.

Respond in the following format. Both the Code Planning and Code Modification steps are required.

### Format ###

## Code Planning:

Thoughts and detailed plan:
1.
2.
3.
...

Commit message: "feat/fix: the commit message"

## Code Modification:

Generated diff hunks based on the given plan using the search and replace pairs in the format below.
```
The first hunk's description

<<<< ORIGINAL
{exact copy of lines you would like to change}
====
{updated lines}
>>>> UPDATED

The second hunk's description

<<<< ORIGINAL
second line before
first line before
old code
first line after
second line after
====
second line before
first line before
new code
first line after
second line after
>>>> UPDATED
```"""

RECREATE_LINE_LENGTH = -1

modify_file_prompt_4 = """\
File Name: {filename}

<file>
{code}
</file>

---

Modify the file by responding in the following format:

Code Planning:

Step-by-step thoughts with explanations:
* Thought 1
* Thought 2
...

Detailed plan of modifications:
* Replace x with y
* Add a foo method to bar
...

Code Modification:

```
Generate a diff based on the given instructions using the search and replace pairs in the following format:

<<<< ORIGINAL
second line before
first line before
old code
first line after
second line after
====
second line before
first line before
new code
first line after
second line after
>>>> UPDATED
```

Commit message: "the commit message"

The user's request is:
{instructions}

Instructions:
1. Complete the Code Planning step
2. Complete the Code Modification step
"""

rewrite_file_system_prompt = "You are a brilliant and meticulous engineer assigned to write code for the file to address a Github issue. When you write code, the code works on the first try and is syntactically perfect and complete. You have the utmost care for your code, so you do not make mistakes and every function and class will be fully implemented. Take into account the current repository's language, frameworks, and dependencies."

rewrite_file_prompt = """\
File Name: {filename}
<old_file>
{code}
</old_file>

---

User's request:
{instructions}

Limit your changes to the request.

Rewrite the following section from the old_file to handle this request.

<section>

{section}

</section>

Think step-by-step on what to modify, then wrap the final answer in the brackets <section></section> XML tags. Only rewrite the section and do not close hanging parentheses and tags.\
"""

sandbox_code_repair_modify_prompt_2 = """
File Name: {filename}

<file>
{code}
</file>

---

Above is the code that was written by an inexperienced programmer, and contain errors such as syntax errors, linting erors and type-checking errors. The CI pipeline returned the following logs:

stdout:
```
{stdout}
```

stderr
```
{stderr}
```

Respond in the following format:

Code Planning

Determine the following in code planning:
1. Are there any syntax errors? Look through the file to find all syntax errors.
2. Are there basic linting errors, like undefined variables, undefined members or type errors?
3. Are there incorrect imports and exports?
4. Are there any other errors not listed above?

Determine whether changes are necessary based on the errors (ignore warnings).

Code Modification:

Generate a diff based on the given plan using the search and replace pairs in the format below.
* Always prefer the least amount of changes possible, but ensure the solution is complete
* Prefer multiple small changes over a single large change.
* NEVER write ellipses anywhere in the diffs. Simply write two diff hunks: one for the beginning and another for the end.
* DO NOT modify the same section multiple times.
* Always add lines before and after. The ORIGINAL section should be at least 5 lines long.
* Restrict the changes to fixing the errors from the logs.

The format is as follows:

```
<<<< ORIGINAL
second line before
first line before
old code of first hunk
first line after
second line after
====
second line before
first line before
new code of first hunk
first line after
second line after
>>>> UPDATED

<<<< ORIGINAL
second line before
first line before
old code of second hunk
first line after
second line after
====
second line before
first line before
new code of second hunk
first line after
second line after
>>>> UPDATED
```

Commit message: "the commit message"

Instructions:
1. Complete the Code Planning step
2. Complete the Code Modification step
"""

pr_code_prompt = ""  # TODO: deprecate this

pull_request_prompt = """Now, create a PR for your changes. Be concise but cover all of the changes that were made.
For the pr_content, add two sections, description and summary.
Use GitHub markdown in the following format:

pr_title = "..."
branch = "..."
pr_content = \"\"\"
...
...
\"\"\""""

summarize_system_prompt = """
You are an engineer assigned to helping summarize code instructions and code changes.
"""

user_file_change_summarize_prompt = """
Summarize the given instructions for making changes in a pull request.
Code Instructions:
{message_content}
"""

assistant_file_change_summarize_prompt = """
Please summarize the following file using the file stubs.
Be sure to repeat each method signature and docstring. You may also add additional comments to the docstring.
Do not repeat the code in the file stubs.
Code Changes:
{message_content}
"""

code_repair_check_system_prompt = """\
You are a genius trained for validating code.
You will be given two pieces of code marked by xml tags. The code inside <diff></diff> is the changes applied to create user_code, and the code inside <user_code></user_code> is the final product.
Our goal is to validate if the final code is valid. This means there are no undefined variables, no syntax errors, has no unimplemented functions (e.g. pass's, comments saying "rest of code") and the code runs.
"""

code_repair_check_prompt = """\
This is the diff that was applied to create user_code. Only make changes to code in user_code if the code was affected by the diff.

This is the user_code.
<user_code>
{user_code}
</user_code>

Reply in the following format:

Step-by-step thoughts with explanations:
1. No syntax errors: True/False
2. No undefined variables: True/False
3. No unimplemented functions: True/False
4. Code runs: True/False

<valid>True</valid> or <valid>False</valid>
"""

code_repair_system_prompt = """\
You are a genius trained for code stitching.
You will be given two pieces of code marked by xml tags. The code inside <diff></diff> is the changes applied to create user_code, and the code inside <user_code></user_code> is the final product. The intention was to implement a change described as {feature}.
Our goal is to return a working version of user_code that follows {feature}. We should follow the instructions and make as few edits as possible.
"""

code_repair_prompt = """\
This is the diff that was applied to create user_code. Only make changes to code in user_code if the code was affected by the diff.

This is the user_code.
<user_code>
{user_code}
</user_code>

Instructions:
* Do not modify comments, docstrings, or whitespace.

The only operations you may perform are:
1. Indenting or dedenting code in user_code. This code MUST be code that was modified by the diff.
2. Adding or deduplicating code in user_code. This code MUST be code that was modified by the diff.

Return the working user_code without xml tags. All of the text you return will be placed in the file.
"""

doc_query_rewriter_system_prompt = """\
You must rewrite the user's github issue to leverage the docs. In this case we want to look at {package}. It's used for: {description}. Using the github issue, write a search query that searches for the potential answer using the documentation. This query will be sent to a documentation search engine with vector and lexical based indexing. Make this query contain keywords relevant to the {package} documentation.
"""

doc_query_rewriter_prompt = """\
This is the issue:
{issue}

Write a comprehensive search query for the answer.
"""

should_edit_code_system_prompt = """\
We are processing a large file and trying to make code changes to it.
The file is definitely relevant, but the section we observe may not be relevant.
Your job is to determine whether the instructions are referring to the given section of the file.
"""

should_edit_code_prompt = """\
Here are the instructions to change the code in the file:
{problem_description}
Here is the code snippet from the file:
{code_snippet}

To determine whether the instructions are referring to this section of the file, respond in the following format:
1. Step-by-step thoughts with explanations:
* Thought 1 - Explanation 1
* Thought 2 - Explanation 2
...
2. Planning:
* Is the code relevant?
* If so, what is the relevant part of the code?
* If not, what is the reason?

3. In the last line of your response, write either <relevant>True</relevant> or <relevant>False</relevant>.
"""

slow_mode_system_prompt = """You are a brilliant and meticulous software architect. Your job is to take in the user's GitHub issue and the relevant context from their repository to:
1. Gather more code snippets using a code search engine.
2. Expand upon the plan to address the issue."""

generate_plan_and_queries_prompt = """Think step-by-step to break down the requested problem or feature, and write up to three queries for the code search engine. These queries should find relevant code that is not already mentioned in the existing snippets. They should all mention different files and subtasks of the initial issue, avoid duplicates.
Then add more instructions that build on the user's instructions. These instructions should help plan how to solve the issue.
* The code search engine is based on semantic similarity. Ask questions that involve code snippets, function references, or mention relevant file paths.
* The user's instructions should be treated as the source of truth, but sometimes the user will not mention the entire context. In that case, you should add the missing context.
* Gather files that are relevant, including dependencies and similar files in the codebase. For example, if the user asked to write tests, look at similar tests.

You MUST follow the following format delimited with XML tags:

Step-by-step thoughts with explanations:
* Thought 1 - Explanation 1
* Thought 2 - Explanation 2
...

<queries>
* query 1
* query 2
* query 3
</queries>

<additional_instructions>
* additional instructions to be appended to the user's instructions
</additional_instructions>
"""

external_search_system_prompt = (
    "You are an expert at summarizing content from pages that are relevant to a query."
    " You will be given a page and asked to summarize it."
)

external_search_prompt = """\
Here is the page metadata:
```
{page_metadata}
```

The user is attempting to solve the following problem:
\'\'\'
{problem}
\'\'\'

Provide a summary of the page relevant to the problem, including all code snippets.
"""


docs_qa_system_prompt = """You are an expert at summarizing documentation for programming-related to help the user solve the problem. You will be given a question and relevant snippets of documentation, and be asked to provide a summary of relevant snippets for solving the problem."""
docs_qa_user_prompt = """Here are the relevant documentation snippets:
{snippets}

The user is attempting to solve the following problem:
{problem}
"""

linting_new_file_prompt = """
<new_file>
{code}
</new_file>
"""

linting_modify_prompt = """Code Planning:
Step-by-step thoughts with explanations:
* Thought 1
* Thought 2
...

Detailed plan of modifications:
* Modification 1
* Modification 2
...

Code Generation:

```
Generate a diff based on the given plan using the search and replace pairs in the format below.
* Always prefer the least amount of changes possible
* Prefer many small edits over few large edits
* Always add lines before and after. The ORIGINAL section should be at least 5 lines long.

The linter returned the following logs:
<linter_logs>
{logs}
</linter_logs>

Modify your created file. Note if no changes are needed.

---

The format is as follows:

<<<< ORIGINAL
====
>>>> UPDATED

Instructions:
1. Complete the Code Planning step
2. Complete the Code Generation step"""

summarize_snippet_system_prompt = """You are a technical writer. Summarize code for an engineer. Be concise but detailed. Mention all entities implicitly. Never say "the code does x", just say "x". Keep it within 30 lines.

E.g: If `issue_comment` is None, set `issue_comment` to `current_issue.create_comment(first_comment)`, otherwise edit comment via `issue_comment.edit(first_comment)`"""

summarize_snippet_prompt = """# Code
```
{code}
```

# Repo Metadata
{metadata}

# Issue
{issue}

# Instructions
Losslessly summarize the code in a ordered list for an engineer to search for relevant code to solve the above GitHub issue."""


use_chunking_message = """\
Respond with a list of the MINIMUM sections that should be modified. To insert code after a function, fetch the last few lines of the function."""

dont_use_chunking_message = """\
Respond with a list of the MINIMUM sections that should be modified. To insert code after a function, fetch the last few lines of the function."""
