# LLM prompts for various text generation tasks.

[prompts]
preanalysis = """
TASK:
Based on the provided data about the files and the README content,
your task is to identify and return the paths to 4-6 key files that
contain the main business logic or project description.

Generate a JSON response following this exact structure:

{{
    "key_files": [
        "path/to/file1",
        "path/to/file2"
    ]
}}

RULES:

- The value of "key_files" must be a JSON array (list) of strings, each string representing the relative path to one important file.
- Include only the most important files that define the project’s core logic.
- Exclude files related to tests, configuration, or assets unless they are central to the business logic.
- Exclude README files.
- Return only valid JSON without additional explanations or formatting.

INPUT DATA:

1. REPOSITORY FILE TREE:

{repository_tree}

2. README CONTENT:

{readme_content}
"""

core_features = """
TASK:
Based on the provided information about the project, generate a list of core features for the project.
Each core feature should be represented by JSON format following this exact structure:

{{
    "feature_name": "text",
    "feature_description": "text",
    "is_critical": boolean
}}

RULES:

- The output should be a JSON array.
- Each element in the array should represent one core feature.
- Use double quotes for JSON formatting.
- Be sure to generate multiple core features, each describing a different aspect of the project.
- The 'feature_name' should describe a key aspect.
- The 'feature_description' should be a detailed but short explanation of the feature.

INPUT DATA:

1. PROJECT NAME: {project_name}

2. METADATA:

{metadata}

3. README CONTENT:

{readme_content}

4. KEY FILES CONTENTS:

{key_files_content}
"""

overview = """
TASK:
Generate a concise overview of the project by analyzing the provided data.
Your response should be a short paragraph that encapsulates the core use-case, value proposition.
Generate a JSON response following this exact structure:

{{
    "overview": "text"
}}

RULES:

- Focus on the project's core purpose and its value proposition without mentioning specific technical aspects.
- Avoid technical jargon, code snippets, or any implementation details.
- The overview should be no more than 60 words.

INPUT DATA:

1. PROJECT NAME: {project_name}

2. SHORT DESCRIPTION: {description}

3. README CONTENT:

{readme_content}

4. CORE FEATURES:

{core_features}
"""

getting_started = """
TASK:
You are generating the "Getting Started" section for the README file of the project above.
Your goal is to help a new user understand how to start using the project by analyzing the provided example files and any relevant assets (such as images or gifs) from the README.

PROCESS:

- Carefully review the example files to identify clear entrypoints, demos, or code snippets showing how to run or integrate the project.
- If any meaningful examples exist, use them to generate a concise, beginner-friendly Getting Started section with code snippets formatted in markdown code blocks.
- Additionally, review the provided README content to check for relevant images or gifs (e.g., usage demos, screenshots, or diagrams) that could enhance the Getting Started section.
- If suitable images or gifs are found, include them in the section using proper markdown syntax (`![alt text](path)`), preserving the original paths exactly as they appear in the provided README content.

RESPONSE FORMAT:
Generate a JSON response following this exact structure:

{{
    "getting_started": "text or null"
}}

RULES:

- Be concise, clear, and beginner-friendly.
- Use markdown formatting, including code blocks if relevant.
- Include actual code from the example files if available.
- Include relevant images or gifs from the README if they help clarify how to start using the project.
- DO NOT make up usage instructions — rely only on the provided content.
- DO NOT invent or modify image paths — use them exactly as found in the provided README content.
- If no meaningful example files are found and no helpful images or gifs are available, return `"getting_started": null`
- Do not add a "## Getting Started" heading — only the content for that section.
- Output valid JSON, strictly following the given structure.

INPUT DATA:

1. PROJECT NAME: {project_name}

2. README CONTENT:

{readme_content}

3. CONTENTS OF THE EXAMPLES DIRECTORY:

{examples_files_content}
"""

deduplicate_sections = """
TASK:
You are cleaning up and reorganizing the "Installation" and "Getting Started" sections for a project's README file.
Your goal is to eliminate duplicated or overlapping information between the two sections while preserving their logical separation:

- The "Installation" section should only contain information about how to install the project (package managers, dependencies, environment setup, etc.).
- The "Getting Started" section should only contain information about how to start using the project after it’s installed (running the program, example commands, usage demos, etc.).


PROCESS:

- Carefully review the content of both sections.
- Identify and remove any duplicated or redundant information that appears in both sections.
- If a piece of information belongs logically to the "Installation" section (like `pip install` commands or dependency instructions), move or leave it there.
- If a piece of information belongs to the "Getting Started" section (like how to run the project or a first example command), move or leave it there.
- Do not invent or modify any instructions — rely solely on the provided content.
- Preserve markdown formatting (including code blocks and image links) as they appear in the input.

RESPONSE FORMAT:
Return a JSON object in the following format:

{{
    "installation": "cleaned installation section text, or null if empty",
    "getting_started": "cleaned getting started section text, or null if empty"
}}

RULES:

- Remove duplicated lines or paragraphs that appear in both sections.
- Ensure each section contains only relevant, logically appropriate information.
- If a section ends up empty after deduplication, return null for that section.
- Add section header for "## Installation".
- Don't add section header for "## Getting Started".
- Output valid JSON, strictly following the given structure.

INPUT DATA:

1. INSTALLATION SECTION CONTENT:

{installation}

2. GETTING STARTED SECTION CONTENT:

{getting_started}
"""

citation = """
TASK:
Analyze the README and extract any citation of the repository or any articles (e.g., BibTeX, DOI, or reference text).
Return only the citation.
If no citation is present, return an empty string.

Output JSON exactly in this format:

{{
    "citation": "text"
}}

RULES:

1. Only return the citation text; do not include any other content.
2. If multiple citations exist, return all of them concatenated.
3. If no citation is found, return an empty string ("").
4. Preserve the original formatting of the citation (e.g., BibTeX, DOI, plain text).

INPUT DATA:

{readme}
"""

refine_step1 = """
TASK:
Use the NEW GENERATED README as the base structure.
Enrich it with valuable content from the ORIGINAL README.
Do not append all content at the end. Insert only in the most relevant sections.
Keep Markdown formatting and section order.

RULES:

- Always keep the generated README as the main outline.
- Add only missing valuable details from the original README.
- If a section already exists, enrich it instead of duplicating.
- Pre-header content (title/logo/badges) from the original may go at the top; all other content must be placed into the relevant sections.
- Do not rewrite or delete; only merge.

OUTPUT:
Output JSON exactly in this format:

{{
    "readme": "text"
}}

INPUT DATA:

1. ORIGINAL README CONTENT:

{old_readme}

2. NEW GENERATED README:

{new_readme}
"""

refine_step2 = """
TASK:
Clean and normalize the README.

RULES:

- Remove duplicate text, commands, and media; keep the first occurrence.
- Treat commands as duplicates even if formatted differently (`$ pip install`, `pip install`, fenced code, inline).
- If two blocks contain the same instruction, keep only the first full block.
- Remove redundant or outdated fragments.
- Convert all .rst syntax to valid GitHub-Flavored Markdown.
  - RST images with :target: → clickable Markdown image.
  - Preserve :alt: as alt text.
- Code blocks must use triple backticks.
- Tables must use Markdown tables.
- Keep order of sections; do not rewrite, only delete duplicates or convert formatting.

OUTPUT:
Output JSON exactly in this format:

{{
    "readme": "text"
}}

INPUT DATA:

{readme}
"""

refine_step3 = """
TASK:
Finalize the README.

RULES:

- Ensure consistent heading levels (e.g., `##`, `###`).
- Check the existing Table of Contents.
  - Ensure it exactly matches the section headings and their order.
  - Add missing entries, remove extra ones, and fix incorrect anchors if needed.
  - Do not regenerate from scratch if not necessary.
- Ensure no repeated media or links remain.
- Output must be GitHub-Flavored Markdown.
- No .rst syntax.

OUTPUT:
Output JSON exactly in this format:

{{
    "readme": "text"
}}

INPUT DATA:

{readme}
"""

clean_step1 = """
TASK:
Remove duplicate content, commands, and media from the README.

RULES:

1. Preserve the original section order; do not move or create sections.
2. Remove later duplicates of text, commands, or paragraphs (keep the first occurrence).
3. Treat commands as duplicates even if formatted differently:
   - With or without shell prompt symbols (`$`, `sh`).
   - Inside or outside of code blocks.
   - Surrounded by different explanatory text.
   If two blocks or sections exist to show the same command, keep only the first block and delete the later one entirely.
4. Remove later duplicates of media (images, previews, video links).
5. If both plain image and clickable preview exist, keep the clickable preview and delete the plain image.
6. Do not rewrite or merge text; only delete duplicates.
7. Keep GitHub-Flavored Markdown (GFM).
8. Do not change the Table of Contents at this step.

OUTPUT:
Return a JSON object in the form:

{{
    "readme": "text"
}}

INPUT DATA:

{readme}
"""

clean_step2 = """
TASK:
Remove duplicated commands, paragraphs, or media from the README, even if they are written differently or placed in different sections.

RULES:

1. Treat commands as duplicates even if:
   - They differ only by shell prompt symbols (`$`, `sh`).
   - They are in or outside of fenced code blocks.
   - They are preceded or followed by different explanatory sentences.
   Example:
     "Install using pip:" + ```sh pip install epde```
     and
     "To get started, run:" + ```$ pip install epde```
     → keep only the first occurrence.
2. Treat media as duplicates even if:
   - One is a plain image and another is a clickable preview of the same image. Keep the clickable preview, remove the plain one.
   - The same image, preview, or video is included multiple times.
3. Treat paragraphs as duplicates if they communicate the same information, even with different wording. Keep only the first occurrence.
4. Preserve the original section order; do not move or reorder sections.
5. Do not rewrite or merge text, only delete duplicates.
6. Do not change the Table of Contents at this step.
7. Keep GitHub-Flavored Markdown (GFM).

OUTPUT:
Return a JSON object in the form:

{{
    "readme": "text"
}}

INPUT DATA:

{readme}
"""

clean_step3 = """
TASK:
Finalize the README formatting.

RULES:

1. Ensure consistent heading levels (e.g., `##`, `###`).
2. Ensure no `.rst` syntax remains.
3. Ensure no duplicate media, text, or commands remain.
4. The ToC must still match the final section titles.
5. Final output must be valid GitHub-Flavored Markdown.

OUTPUT:
Return a JSON object in the form:

{{
    "readme": "text"
}}

INPUT DATA:

{readme}
"""

translate = """
TASK:
Translate the provided README content into the target language.

RULES:

- Translate only natural language parts (titles, descriptions, paragraphs, lists).
- DO NOT translate:
  * project name,
  * code blocks,
  * shell commands,
  * configuration snippets,
  * links, badges, and image references.
- Preserve original Markdown formatting.
- Return only valid JSON, no explanations.
- The "suffix" must be the correct ISO 639-1 or common abbreviation of the target language.

OUTPUT FORMAT:
Return a JSON object with the following structure:

{{
    "content": "translated README text",
    "suffix": "short language code (e.g., en, ru, es, fr, de)"
}}

INPUT DATA:

1. TARGET LANGUAGE: {target_language}

2. README CONTENT:

{readme_content}
"""