Skip to content

Instantly share code, notes, and snippets.

@andresbrocco

andresbrocco/LLM Prompts for Dev.md

Last active September 13, 2025 14:17
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save andresbrocco/83c3d8dc3c2bafc89ecc82d0ea11da31 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save andresbrocco/83c3d8dc3c2bafc89ecc82d0ea11da31 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. andresbrocco revised this gist Jun 28, 2025. 1 changed file with 8 additions and 16 deletions.
    24 changes: 8 additions & 16 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -306,22 +306,14 @@ Take the `<technical_specifications>` and pass it to a proper reasoning model (c
    </instructions>

    <output_format>
    A markdown-formatted checklist with clearly structured sections such as:
    ## Technology Integration Challenges
    - Question or consideration
    - Question or consideration

    ## Architectural Considerations
    - Question or consideration
    - Question or consideration

    ## Data Management Best Practices
    - Question or consideration
    - Question or consideration

    ## Recommended File/Folder Structure
    - Question or consideration
    - Question or consideration
    Provide a structured XML document containing a checklist organized by the sections:
    <technology_integration_strategy/>
    <architecture_performance_scalability/>
    <data_security_compliance/>
    <devops_deployment_observability/>
    <quality_assurance_risk_management/>
    <documentation_structure_knowledge_sharing/>
    <accessibility_internationalization/>
    </output_format>

    <assumptions>
  2. andresbrocco revised this gist Jun 27, 2025. 1 changed file with 53 additions and 0 deletions.
    53 changes: 53 additions & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -288,6 +288,59 @@ Provide a structured XML document summarizing the technical specifications agree

    Save the output to `technical_specifications.xml`.

    ## Generating Best Practices Investigation Checklist
    Take the `<technical_specifications>` and pass it to a proper reasoning model (chatGPT o3, o4-mini, deepseek r1) for it to generate a structured checklist of key technical questions and research topics to investigate before software architecture planning.

    ```xml
    <role>
    You are an experienced Tech Lead specialized in software architecture and best practices. Your responsibility is to identify critical topics, integration challenges, and architecture considerations for software projects based on provided technical specifications.
    </role>

    <instructions>
    Based on the provided technical specifications, generate a comprehensive checklist in markdown format. The checklist should include:
    - Potential points of friction when integrating different technologies mentioned.
    - Important architectural decisions and considerations.
    - Best practice questions regarding technology usage, file organization, and data management.

    Your goal is **not** to provide answers but to list well-formulated, precise questions and considerations that must be addressed through subsequent research.
    </instructions>

    <output_format>
    A markdown-formatted checklist with clearly structured sections such as:
    ## Technology Integration Challenges
    - Question or consideration
    - Question or consideration

    ## Architectural Considerations
    - Question or consideration
    - Question or consideration

    ## Data Management Best Practices
    - Question or consideration
    - Question or consideration

    ## Recommended File/Folder Structure
    - Question or consideration
    - Question or consideration
    </output_format>

    <assumptions>
    The user will handle detailed investigation based on the generated checklist. You are only identifying the relevant topics for further exploration.
    </assumptions>

    <constraints>
    Do not perform any external searches. Your output is strictly a structured checklist of topics requiring investigation.
    </constraints>

    <notes>
    This checklist serves as the foundation for rigorous, detailed research during the project's architectural planning phase. Prioritize clarity, comprehensiveness, and specificity in the generated questions.
    </notes>

    <technical_specifications><!-- User input --></technical_specifications>
    ```

    Save the output to `best_practices_investigation_checklist.md`.

    ## Researching Relevant Documentations

    Take the `<technical_specifications>` and pass it to a proper reasoning model (chatGPT o3, o4-mini, deepseek r1) for it to search the online documentations for good practices and compile them in one document:
  3. andresbrocco revised this gist Jun 14, 2025. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -237,6 +237,8 @@ Use a conversational LLM to determine the ideal technical stack for given `<idea

    <instructions>
    Initiate and guide an interactive conversation to determine the ideal technical stack based on the provided project <idea> and <functional_specifications>. Prioritize ease of implementation, speed of development, maintainability, scalability, and seamless integration between components. Discuss various technology options, clarify technical considerations, and confirm alignment with the user’s expectations.

    Ask one question at a time, and based on the user's response, evaluate if more detail is needed for that topic. Once that topic is covered, go to the next one, asking one question at a time, until you have collected all necessary technical information.

    Once the technical decisions are thoroughly discussed and agreed upon, or when explicitly requested by the user, output a comprehensive technical specification.
    </instructions>
  4. andresbrocco revised this gist Jun 14, 2025. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -198,15 +198,15 @@ Use a conversational LLM to define the functional specifications of the `<idea>`

    ```xml
    <role>
    You are an expert in User Experience (UX) design, specializing in creating comprehensive and user-centric functional specifications for technology projects.
    You are an expert in User Experience (UX) and User Interface (UI) design, specializing in creating comprehensive and user-centric functional specifications for technology projects.
    </role>

    <instructions>
    Initiate and guide a detailed conversation with the user to fully explore and document an idea based on best UX practices. Clarify, refine, and enhance the functional aspects of the <idea> provided by the user. Ensure all aspects relevant for creating a functional specification are covered clearly.
    Initiate and guide a detailed conversation with the user to fully explore and document an idea based on UX and UI best practices. Clarify, refine, and enhance the functional aspects of the <idea> provided by the user. Ensure all aspects relevant for creating a functional specification are covered clearly.

    Ask one question at a time, and based on the user's response, evaluate if more detail is needed for that topic. Once that topic is covered, go to the next one, asking one question at a time, until you have collected details of every functionality.
    Ask one question at a time, and based on the user's response, evaluate if more detail is needed for that topic. Once that topic is covered, go to the next one, asking one question at a time, until you have collected details of every functionality and interface.

    Once all functionalities have been discussed, or when explicitly requested by the user, generate a detailed and structured XML functional specification.
    Once all functionalities and interfaces have been discussed, or when explicitly requested by the user, generate a detailed and structured XML functional specification.
    </instructions>

    <final_output_format>
  5. andresbrocco revised this gist Jun 13, 2025. 1 changed file with 5 additions and 3 deletions.
    8 changes: 5 additions & 3 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -202,9 +202,11 @@ Use a conversational LLM to define the functional specifications of the `<idea>`
    </role>

    <instructions>
    Initiate and guide a detailed conversation with the user to fully explore and document an idea based on best UX practices. Clarify, refine, and enhance the functional aspects of the <idea> provided by the user. Ensure all aspects relevant for creating a functional specification are covered clearly, and explicitly confirm when sufficient information has been gathered.
    Initiate and guide a detailed conversation with the user to fully explore and document an idea based on best UX practices. Clarify, refine, and enhance the functional aspects of the <idea> provided by the user. Ensure all aspects relevant for creating a functional specification are covered clearly.

    Once all essential details have been discussed, or when explicitly requested by the user, generate a structured XML functional specification.
    Ask one question at a time, and based on the user's response, evaluate if more detail is needed for that topic. Once that topic is covered, go to the next one, asking one question at a time, until you have collected details of every functionality.

    Once all functionalities have been discussed, or when explicitly requested by the user, generate a detailed and structured XML functional specification.
    </instructions>

    <final_output_format>
    @@ -219,7 +221,7 @@ Use a conversational LLM to define the functional specifications of the `<idea>`
    At the end of the conversation, if it does not output the resume automatically after all the Q&A:

    ```
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea. Include a summary of the input <idea>, and all information that are relevant to the functional specifications.
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea. Include a summary of the input <idea>, and all information that are relevant to the functional specifications. Include descriptions for each specification topic, ensuring clarity and completeness.
    ```

    Save the output to `functional_specifications.xml`.
  6. andresbrocco revised this gist Jun 13, 2025. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -183,7 +183,7 @@ Use a conversational LLM to hone in on an idea (I use ChatGPT o3 for this):
    At the end of the brainstorm, if it does not output the resume automatically after all the Q&A:

    ```xml
    Please compile our findings to a structured XML block containing the refined idea:
    Please compile our findings to a structured XML block containing the refined idea. Be thorough and include description tags where needed.

    <idea>
    <!-- refined idea structured using xml tags -->
  7. andresbrocco revised this gist Jun 13, 2025. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -147,15 +147,15 @@ Use a conversational LLM to hone in on an idea (I use ChatGPT o3 for this):
    </role>

    <instructions>
    Begin by asking the user an open-ended question to understand the core of their idea. Based on their responses, continue asking one question at a time, each building on the previous answers.
    Begin by asking the user an open-ended question to understand the core of their idea. Based on their responses, continue asking one question at a time, with the goal of covering all relevant aspects for defining the idea: Background and Context, Project vision and value proposition, Scope and Boundaries, Stakeholders and Roles, Constraints and Assumptions.

    Once the idea is sufficiently refined or the user indicates completion, generate a detailed XML specification with the final version of the idea.

    Do not proceed to the final output until enough information has been gathered to describe the idea with clarity and completeness.
    </instructions>

    <final_output_format>
    The final output should be a structured XML block containing the refined idea. Be thorough and include description tags when needed.
    The final output should be a structured XML block containing the refined idea. Be thorough and include description tags where needed.

    <idea>
    <!-- refined idea structured using xml tags -->
  8. andresbrocco revised this gist Jun 13, 2025. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -149,13 +149,13 @@ Use a conversational LLM to hone in on an idea (I use ChatGPT o3 for this):
    <instructions>
    Begin by asking the user an open-ended question to understand the core of their idea. Based on their responses, continue asking one question at a time, each building on the previous answers.

    Once the idea is sufficiently refined or the user indicates completion, generate a detailed XML specification summarizing the final version of the idea.
    Once the idea is sufficiently refined or the user indicates completion, generate a detailed XML specification with the final version of the idea.

    Do not proceed to the final output until enough information has been gathered to describe the idea with clarity and completeness.
    </instructions>

    <final_output_format>
    The final output should be a structured XML block containing the refined idea:
    The final output should be a structured XML block containing the refined idea. Be thorough and include description tags when needed.

    <idea>
    <!-- refined idea structured using xml tags -->
  9. andresbrocco revised this gist Jun 9, 2025. 1 changed file with 12 additions and 32 deletions.
    44 changes: 12 additions & 32 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -105,6 +105,7 @@ flowchart TD
    classDef file fill:#fffbe7,stroke:#c9ab00,stroke-width:1px,color:#000;
    classDef repo fill:#e0ffe0,stroke:#2e8b57,stroke-width:1px,color:#000;
    ```

    ## LLM Prompt Template Generator

    This prompt generates a LLM prompt template based on the template description. (prefer ChatGPT 4.5, o4-mini or 4o model)
    @@ -138,7 +139,7 @@ This prompt generates a LLM prompt template based on the template description. (

    ## Idea refinement

    Use a conversational LLM to hone in on an idea (I use ChatGPT 4o / o3 for this):
    Use a conversational LLM to hone in on an idea (I use ChatGPT o3 for this):

    ```xml
    <role>
    @@ -154,17 +155,10 @@ Use a conversational LLM to hone in on an idea (I use ChatGPT 4o / o3 for this):
    </instructions>

    <final_output_format>
    The final output should be a structured XML block containing the refined idea with the following sections:
    The final output should be a structured XML block containing the refined idea:

    <idea>
    <title> <!-- Short, descriptive title of the idea --> </title>
    <summary> <!-- A concise overview of the idea and its purpose --> </summary>
    <problem> <!-- The core problem or need the idea addresses --> </problem>
    <proposed_solution> <!-- A description of the proposed solution or concept --> </proposed_solution>
    <key_features> <!-- Bullet points or a list of main features or components --> </key_features>
    <target_audience> <!-- Who the idea is intended for or who benefits from it --> </target_audience>
    <expected_impact> <!-- The value, outcome, or change expected from the idea --> </expected_impact>
    <challenges> <!-- Known risks, limitations, or open questions that remain --> </challenges>
    <!-- refined idea structured using xml tags -->
    </idea>
    </final_output_format>

    @@ -189,17 +183,10 @@ Use a conversational LLM to hone in on an idea (I use ChatGPT 4o / o3 for this):
    At the end of the brainstorm, if it does not output the resume automatically after all the Q&A:

    ```xml
    Please compile our findings to the following format:
    Please compile our findings to a structured XML block containing the refined idea:

    <idea>
    <title> <!-- Short, descriptive title of the idea --> </title>
    <summary> <!-- A concise overview of the idea and its purpose --> </summary>
    <problem> <!-- The core problem or need the idea addresses --> </problem>
    <proposed_solution> <!-- A description of the proposed solution or concept --> </proposed_solution>
    <key_features> <!-- Bullet points or a list of main features or components --> </key_features>
    <target_audience> <!-- Who the idea is intended for or who benefits from it --> </target_audience>
    <expected_impact> <!-- The value, outcome, or change expected from the idea --> </expected_impact>
    <challenges> <!-- Known risks, limitations, or open questions that remain --> </challenges>
    <!-- refined idea structured using xml tags -->
    </idea>
    ```

    @@ -217,29 +204,22 @@ Use a conversational LLM to define the functional specifications of the `<idea>`
    <instructions>
    Initiate and guide a detailed conversation with the user to fully explore and document an idea based on best UX practices. Clarify, refine, and enhance the functional aspects of the <idea> provided by the user. Ensure all aspects relevant for creating a functional specification are covered clearly, and explicitly confirm when sufficient information has been gathered.

    Once all essential details have been discussed, or when explicitly requested by the user, generate a structured XML functional specification summarizing the conversation.
    Once all essential details have been discussed, or when explicitly requested by the user, generate a structured XML functional specification.
    </instructions>

    <final_output_format>
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea. Use logical section headings based on the information gathered during the conversation.
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea.
    Include a summary of the input <idea>, and all information that are relevant to the functional specifications.
    Include descriptions for each specification topic, ensuring clarity and completeness.
    </final_output_format>

    <idea>
    <title><!-- [User Input] --></title>
    <summary><!-- [User Input] --></summary>
    <problem><!-- [User Input] --></problem>
    <proposed_solution><!-- [User Input] --></proposed_solution>
    <key_features><!-- [User Input] --></key_features>
    <target_audience><!-- [User Input] --></target_audience>
    <expected_impact><!-- [User Input] --></expected_impact>
    <challenges><!-- [User Input] --></challenges>
    </idea>
    <idea><!-- [User Input] --></idea>
    ```

    At the end of the conversation, if it does not output the resume automatically after all the Q&A:

    ```
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea.
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea. Include a summary of the input <idea>, and all information that are relevant to the functional specifications.
    ```

    Save the output to `functional_specifications.xml`.
  10. andresbrocco revised this gist Jun 7, 2025. 1 changed file with 15 additions and 19 deletions.
    34 changes: 15 additions & 19 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -7,16 +7,16 @@ Adapted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-
    flowchart TD
    %% ──────────────── Idea phase ────────────────
    subgraph A["Idea phase"]
    A1[["Idea Refinement\ntemplate"]]:::tmpl
    A1[["Idea Refinement template"]]:::tmpl
    A2(["idea.xml"]):::file
    A1 -->|creates| A2
    end
    %% ─────────────── Specifications ───────────────
    %% ───────────── Specifications ───────────────
    subgraph B["Specification phase"]
    B1[["Functional Specifications\ntemplate"]]:::tmpl
    B1[["Functional Specifications template"]]:::tmpl
    B2(["functional_specifications.xml"]):::file
    B3[["Technical Specifications\ntemplate"]]:::tmpl
    B3[["Technical Specifications template"]]:::tmpl
    B4(["technical_specifications.xml"]):::file
    A2 --> B1
    @@ -28,7 +28,7 @@ flowchart TD
    %% ─────────────── Research ───────────────
    subgraph C["Research phase"]
    C1[["Tech-Stack Best-Practices\ntemplate"]]:::tmpl
    C1[["Tech-Stack Best-Practices template"]]:::tmpl
    C2(["technical_stack_best_practices.md"]):::file
    B4 --> C1
    @@ -37,7 +37,7 @@ flowchart TD
    %% ─────────────── Architecture ───────────────
    subgraph D["Architecture phase"]
    D1[["Application Architecture\ntemplate"]]:::tmpl
    D1[["Application Architecture template"]]:::tmpl
    D2(["application_architecture.md"]):::file
    B2 --> D1
    @@ -48,7 +48,7 @@ flowchart TD
    %% ─────────────── Testing specs ───────────────
    subgraph E["Testing-spec phase"]
    E1[["Test Definitions\ntemplate"]]:::tmpl
    E1[["Test Definitions template"]]:::tmpl
    E2(["test_definitions.xml"]):::file
    D2 --> E1
    @@ -57,7 +57,7 @@ flowchart TD
    %% ─────────────── Implementation plan ───────────────
    subgraph F["Planning phase"]
    F1[["Implementation Plan\ntemplate"]]:::tmpl
    F1[["Implementation Plan template"]]:::tmpl
    F2(["implementation_plan.md"]):::file
    D2 --> F1
    @@ -73,41 +73,37 @@ flowchart TD
    %% ─────────────── Reviews & QA ───────────────
    subgraph H["Review & QA"]
    H1[["Pre-commit Code-Review\ntemplate"]]:::tmpl
    H1[["Pre-commit Code-Review template"]]:::tmpl
    H2(["code-review report"]):::file
    H3[["Global Code-Review\ntemplate"]]:::tmpl
    H3[["Global Code-Review template"]]:::tmpl
    H4(["global review summary"]):::file
    H5[["GitHub Issue Generator\ntemplate"]]:::tmpl
    H5[["GitHub Issue Generator template"]]:::tmpl
    H6(["GitHub issues"]):::file
    H7[["Missing Tests\ntemplate"]]:::tmpl
    H7[["Missing Tests template"]]:::tmpl
    H8(["test-issues"]):::file
    %% pre-commit review
    G1 --> H1
    D2 --> H1
    C2 --> H1
    H1 -->|creates| H2
    %% global review
    G1 --> H3
    D2 --> H3
    C2 --> H3
    H3 -->|creates| H4
    %% issue generation
    H3 --> H5
    H5 -->|creates| H6
    %% missing-tests analysis
    G1 --> H7
    E2 --> H7
    H7 -->|creates| H8
    end
    %% Styles
    classDef tmpl fill:#d6e9ff,stroke:#3b78e7,stroke-width:1px;
    classDef file fill:#fffbe7,stroke:#c9ab00,stroke-width:1px;
    classDef repo fill:#e0ffe0,stroke:#2e8b57,stroke-width:1px;
    classDef tmpl fill:#d6e9ff,stroke:#3b78e7,stroke-width:1px,color:#000;
    classDef file fill:#fffbe7,stroke:#c9ab00,stroke-width:1px,color:#000;
    classDef repo fill:#e0ffe0,stroke:#2e8b57,stroke-width:1px,color:#000;
    ```
    ## LLM Prompt Template Generator

  11. andresbrocco revised this gist Jun 7, 2025. 1 changed file with 107 additions and 0 deletions.
    107 changes: 107 additions & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,6 +2,113 @@

    Adapted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/)

    ```mermaid
    %% High-level data-flow for the “LLM Prompts for Dev” workflow
    flowchart TD
    %% ──────────────── Idea phase ────────────────
    subgraph A["Idea phase"]
    A1[["Idea Refinement\ntemplate"]]:::tmpl
    A2(["idea.xml"]):::file
    A1 -->|creates| A2
    end
    %% ─────────────── Specifications ───────────────
    subgraph B["Specification phase"]
    B1[["Functional Specifications\ntemplate"]]:::tmpl
    B2(["functional_specifications.xml"]):::file
    B3[["Technical Specifications\ntemplate"]]:::tmpl
    B4(["technical_specifications.xml"]):::file
    A2 --> B1
    B1 -->|creates| B2
    A2 --> B3
    B2 --> B3
    B3 -->|creates| B4
    end
    %% ─────────────── Research ───────────────
    subgraph C["Research phase"]
    C1[["Tech-Stack Best-Practices\ntemplate"]]:::tmpl
    C2(["technical_stack_best_practices.md"]):::file
    B4 --> C1
    C1 -->|creates| C2
    end
    %% ─────────────── Architecture ───────────────
    subgraph D["Architecture phase"]
    D1[["Application Architecture\ntemplate"]]:::tmpl
    D2(["application_architecture.md"]):::file
    B2 --> D1
    B4 --> D1
    C2 --> D1
    D1 -->|creates| D2
    end
    %% ─────────────── Testing specs ───────────────
    subgraph E["Testing-spec phase"]
    E1[["Test Definitions\ntemplate"]]:::tmpl
    E2(["test_definitions.xml"]):::file
    D2 --> E1
    E1 -->|creates| E2
    end
    %% ─────────────── Implementation plan ───────────────
    subgraph F["Planning phase"]
    F1[["Implementation Plan\ntemplate"]]:::tmpl
    F2(["implementation_plan.md"]):::file
    D2 --> F1
    E2 --> F1
    F1 -->|creates| F2
    end
    %% ─────────────── Code implementation ───────────────
    subgraph G["Implementation"]
    G1((Code Repository)):::repo
    F2 -->|guides dev| G1
    end
    %% ─────────────── Reviews & QA ───────────────
    subgraph H["Review & QA"]
    H1[["Pre-commit Code-Review\ntemplate"]]:::tmpl
    H2(["code-review report"]):::file
    H3[["Global Code-Review\ntemplate"]]:::tmpl
    H4(["global review summary"]):::file
    H5[["GitHub Issue Generator\ntemplate"]]:::tmpl
    H6(["GitHub issues"]):::file
    H7[["Missing Tests\ntemplate"]]:::tmpl
    H8(["test-issues"]):::file
    %% pre-commit review
    G1 --> H1
    D2 --> H1
    C2 --> H1
    H1 -->|creates| H2
    %% global review
    G1 --> H3
    D2 --> H3
    C2 --> H3
    H3 -->|creates| H4
    %% issue generation
    H3 --> H5
    H5 -->|creates| H6
    %% missing-tests analysis
    G1 --> H7
    E2 --> H7
    H7 -->|creates| H8
    end
    %% Styles
    classDef tmpl fill:#d6e9ff,stroke:#3b78e7,stroke-width:1px;
    classDef file fill:#fffbe7,stroke:#c9ab00,stroke-width:1px;
    classDef repo fill:#e0ffe0,stroke:#2e8b57,stroke-width:1px;
    ```
    ## LLM Prompt Template Generator

    This prompt generates a LLM prompt template based on the template description. (prefer ChatGPT 4.5, o4-mini or 4o model)
  12. andresbrocco revised this gist Jun 6, 2025. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -410,6 +410,7 @@ Take the `application_architecture.md` and `test_definitions.xml` and pass them
    - Clearly marked prompts inside code blocks:
    - Mark prompts for code-generation LLM as `[LLM prompt]`
    - Mark prompts requiring user action as `[user prompt]`
    - Encourage the execution of the tests associated with each step, and iteration until it pass all tests.
    </output_format>

    <application_architecture><!-- [User Input] --></application_architecture>
  13. andresbrocco revised this gist Jun 6, 2025. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@ Adapted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-

    ## LLM Prompt Template Generator

    This prompt generates a LLM prompt template based on the template description. [prefer ChatGPT 4.5, o4-mini or 4o model]
    This prompt generates a LLM prompt template based on the template description. (prefer ChatGPT 4.5, o4-mini or 4o model)

    ```xml
    <role>
  14. andresbrocco revised this gist Jun 6, 2025. 1 changed file with 554 additions and 39 deletions.
    593 changes: 554 additions & 39 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,87 +2,602 @@

    Adapted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/)

    ## Step 1: Idea honing
    ## LLM Prompt Template Generator

    Use a conversational LLM to hone in on an idea (I use ChatGPT 4o / o3 for this):
    This prompt generates a LLM prompt template based on the template description. [prefer ChatGPT 4.5, o4-mini or 4o model]

    ```xml
    <role>
    You are an expert in Large Language Models (LLMs) and prompt engineering. Your role is to generate **reusable, well-structured XML-based prompt templates** that guide users to craft effective prompts for a wide range of LLM applications.
    </role>

    <goal>
    Your goal is to maximize clarity, flexibility, and completeness while keeping the structure easy to adapt for future use.
    </goal>

    <output_format>
    Return a structured XML prompt template using consistent and valid tag formatting. There should be no root xml tag wrapping the template. Only write comments when strictly necessary.

    Include the following sections at minimum:
    - <role> (role of the LLM)
    - <instructions> (what the LLM should do)
    - <output_format> (structure or type of the expected LLM response)
    - empty tag(s) to be filled by the user (keep it concise). There should be no "user input" inside the <output_format> tag.

    You may also include other sections when relevant, for example:
    - <assumptions>
    - <constraints>
    - <notes>
    </output_format>

    <template_description><!-- [User Input] --></template_description>
    ```
    Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time.

    Here’s the idea:
    ## Idea refinement

    Use a conversational LLM to hone in on an idea (I use ChatGPT 4o / o3 for this):

    ```xml
    <role>
    You are an analytical and creative assistant specializing in evaluating and refining ideas. Your role is to engage in a structured conversation with the user to help them mature their concept by identifying strengths, weaknesses, and opportunities for improvement.
    </role>

    <instructions>
    Begin by asking the user an open-ended question to understand the core of their idea. Based on their responses, continue asking one question at a time, each building on the previous answers.

    Once the idea is sufficiently refined or the user indicates completion, generate a detailed XML specification summarizing the final version of the idea.

    Do not proceed to the final output until enough information has been gathered to describe the idea with clarity and completeness.
    </instructions>

    <final_output_format>
    The final output should be a structured XML block containing the refined idea with the following sections:

    <idea>
    <title> <!-- Short, descriptive title of the idea --> </title>
    <summary> <!-- A concise overview of the idea and its purpose --> </summary>
    <problem> <!-- The core problem or need the idea addresses --> </problem>
    <proposed_solution> <!-- A description of the proposed solution or concept --> </proposed_solution>
    <key_features> <!-- Bullet points or a list of main features or components --> </key_features>
    <target_audience> <!-- Who the idea is intended for or who benefits from it --> </target_audience>
    <expected_impact> <!-- The value, outcome, or change expected from the idea --> </expected_impact>
    <challenges> <!-- Known risks, limitations, or open questions that remain --> </challenges>
    </idea>
    </final_output_format>

    <IDEA>
    <assumptions>
    - The user is open to iterative improvement through structured questioning.
    - The LLM is responsible for guiding the conversation and driving clarity.
    </assumptions>

    <constraints>
    - Avoid final judgments; maintain a supportive and constructive tone.
    - Ask only one question at a time.
    - Do not output the final XML until the idea has been refined.
    </constraints>

    <notes>
    This template is ideal for refining business ideas, product concepts, innovation strategies, or creative project proposals in an interactive manner.
    </notes>

    <idea_seed> <!-- [User Input] A brief description or sketch of the initial idea --> </idea_seed>
    ```

    At the end of the brainstorm (it will come to a natural conclusion):
    At the end of the brainstorm, if it does not output the resume automatically after all the Q&A:

    ```xml
    Please compile our findings to the following format:

    <idea>
    <title> <!-- Short, descriptive title of the idea --> </title>
    <summary> <!-- A concise overview of the idea and its purpose --> </summary>
    <problem> <!-- The core problem or need the idea addresses --> </problem>
    <proposed_solution> <!-- A description of the proposed solution or concept --> </proposed_solution>
    <key_features> <!-- Bullet points or a list of main features or components --> </key_features>
    <target_audience> <!-- Who the idea is intended for or who benefits from it --> </target_audience>
    <expected_impact> <!-- The value, outcome, or change expected from the idea --> </expected_impact>
    <challenges> <!-- Known risks, limitations, or open questions that remain --> </challenges>
    </idea>
    ```
    Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.

    Save the output to `idea.xml`.

    ## Detailing Functional Specifications

    Use a conversational LLM to define the functional specifications of the `<idea>` (I use ChatGPT 4o / o3 for this):

    ```xml
    <role>
    You are an expert in User Experience (UX) design, specializing in creating comprehensive and user-centric functional specifications for technology projects.
    </role>

    <instructions>
    Initiate and guide a detailed conversation with the user to fully explore and document an idea based on best UX practices. Clarify, refine, and enhance the functional aspects of the <idea> provided by the user. Ensure all aspects relevant for creating a functional specification are covered clearly, and explicitly confirm when sufficient information has been gathered.

    Once all essential details have been discussed, or when explicitly requested by the user, generate a structured XML functional specification summarizing the conversation.
    </instructions>

    <final_output_format>
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea. Use logical section headings based on the information gathered during the conversation.
    </final_output_format>

    <idea>
    <title><!-- [User Input] --></title>
    <summary><!-- [User Input] --></summary>
    <problem><!-- [User Input] --></problem>
    <proposed_solution><!-- [User Input] --></proposed_solution>
    <key_features><!-- [User Input] --></key_features>
    <target_audience><!-- [User Input] --></target_audience>
    <expected_impact><!-- [User Input] --></expected_impact>
    <challenges><!-- [User Input] --></challenges>
    </idea>
    ```

    OR simply
    At the end of the conversation, if it does not output the resume automatically after all the Q&A:

    ```
    Now that we’ve wrapped up the brainstorming process, can you compile our findings into a complete comprehensive specification document in the XML format?
    Provide a structured XML document with clearly defined sections summarizing the functional specifications of the idea.
    ```

    Save the output to `spec.md`.
    Save the output to `functional_specifications.xml`.

    ## Step 2: Planning
    ## Defining Technical Specifications

    Take the spec and pass it to a proper reasoning model (o1*, o3*, r1):
    Use a conversational LLM to determine the ideal technical stack for given `<idea>` and `<functional_specifications>` (I use ChatGPT 4o / o3 for this):

    (This is the TDD prompt)
    ```
    Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. Review the results and make sure that the steps are small enough to be implemented safely with strong testing, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.
    ```xml
    <role>
    You are acting as an experienced Technical Lead responsible for determining a robust, efficient, and well-integrated technology stack for software projects.
    </role>

    <instructions>
    Initiate and guide an interactive conversation to determine the ideal technical stack based on the provided project <idea> and <functional_specifications>. Prioritize ease of implementation, speed of development, maintainability, scalability, and seamless integration between components. Discuss various technology options, clarify technical considerations, and confirm alignment with the user’s expectations.

    Search the internet for the documentation pages for every framework/tool/library associated with the execution of the project, and keep the links for each one.
    Once the technical decisions are thoroughly discussed and agreed upon, or when explicitly requested by the user, output a comprehensive technical specification.
    </instructions>

    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Include any documentation links relevant to each task.
    <final_output_format>
    Provide a structured XML document summarizing the technical specifications agreed upon during the conversation. Include clearly delineated sections, logically organized based on the discussion. Suggested structure:

    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
    - <technical_specifications>
    - <tech_stack_overview>
    - <frontend></frontend>
    - <backend></backend>
    - <database></database>
    - <hosting></hosting>
    - <additional_services></additional_services>
    - <integration_plan><!-- How components integrate and interact --></integration_plan>
    - <development_considerations><!-- Details such as ease, speed, scalability, etc. --></development_considerations>
    - <deployment_strategy><!-- Steps and tools used for deployment --></deployment_strategy>
    - <assumptions><!-- Key assumptions influencing technical decisions --></assumptions>
    - <constraints><!-- Any technical constraints identified --></constraints>
    - <notes><!-- Optional additional notes or recommendations --></notes>
    </final_output_format>

    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well. Save the output to the file `prompt_plan.md`.
    <idea><!-- [User Input] --></idea>

    <SPEC>
    <functional_specifications><!-- [User Input] --></functional_specifications>
    ```

    (This is the non-tdd prompt)
    At the end of the conversation, if it does not output the resume automatically after all the Q&A:

    ```xml
    Provide a structured XML document summarizing the technical specifications agreed upon during the conversation. Include clearly delineated sections, logically organized based on the discussion. Suggested structure:

    - <technical_specifications>
    - <tech_stack_overview>
    - <frontend></frontend>
    - <backend></backend>
    - <database></database>
    - <hosting></hosting>
    - <additional_services></additional_services>
    - <integration_plan><!-- How components integrate and interact --></integration_plan>
    - <development_considerations><!-- Details such as ease, speed, scalability, etc. --></development_considerations>
    - <deployment_strategy><!-- Steps and tools used for deployment --></deployment_strategy>
    - <assumptions><!-- Key assumptions influencing technical decisions --></assumptions>
    - <constraints><!-- Any technical constraints identified --></constraints>
    - <notes><!-- Optional additional notes or recommendations --></notes>
    ```
    Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. review the results and make sure that the steps are small enough to be implemented safely, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.

    Search the internet for the documentation pages for every framework/tool/library associated with the execution of the project, and keep the links for each one.
    Save the output to `technical_specifications.xml`.

    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Include any documentation links relevant to each task.
    ## Researching Relevant Documentations

    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
    Take the `<technical_specifications>` and pass it to a proper reasoning model (chatGPT o3, o4-mini, deepseek r1) for it to search the online documentations for good practices and compile them in one document:

    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well. Save the output to the file `prompt_plan.md`.
    ```xml
    <role>
    You are an experienced Technical Lead and research specialist. Your task is to investigate and compile best practices, documentation insights, and integration guidelines for each technology specified in the provided technical specification.
    </role>

    <SPEC>
    ```
    <instructions>
    1. Parse the provided <technical_specifications> to identify all technologies, frameworks, libraries, and patterns mentioned.
    2. For each identified technology:
    a. Perform web research to locate official documentation, authoritative tutorials, and community-recommended best practices.
    b. Summarize the key configuration steps, recommended folder structure, and file organization.
    c. Detail responsibilities for typical classes, methods, services, and any other information associated with that technology.
    3. Analyze how the listed technologies integrate with one another according to the <technical_specifications>:
    a. Identify common pitfalls or conflicts when coupling these technologies.
    b. Gather guidance on version compatibility, communication patterns (e.g., REST, gRPC, messaging), and deployment considerations.
    c. Compile any available diagrams or create new functional diagrams illustrating data flow, module interactions, and service boundaries.
    4. Ensure all findings are fact-oriented, citing sources or documentation links where relevant (in markdown footnote format if possible).
    5. Organize the output in markdown, presenting each technology and integration topic as a clearly labeled section. Do not tailor recommendations to specific project details; instead, focus on general, reusable information applicable to any project using these technologies.
    </instructions>

    Save the output to `prompt_plan.md`.
    <output_format>
    <!-- The final output should be a markdown document containing: -->
    - A table of contents listing each technology and integration section.
    - For each technology:
    - Overview and official documentation links
    - Recommended folder structure (with illustrative tree examples)
    - File content descriptions (e.g., config files, main entry points)
    - Class/Service responsibilities and naming conventions (when applicable)
    - Common configuration snippets or templates
    - Any other relevant information
    - For integrations between technologies:
    - Integration overview and purpose
    - Compatibility considerations (versions, dependencies)
    - Communication patterns and configuration examples
    - Functional diagrams illustrating module interaction (using mermaid syntax)
    - Deployment notes (environment variables, CI/CD tips)
    - A “References” section listing all consulted sources in markdown footnotes.
    </output_format>

    I then have it output a `todo.md` that can be checked off:
    <technical_specifications>
    <!-- [User Input] Insert XML-formatted technical specifications here -->
    </technical_specifications>
    ```
    Can you make a `todo.md` that I can use as a checklist? Be thorough.

    Save the output to `technical_stack_best_practices.md`.

    ## Designing the System Architecture

    Take the `<functional_specifications>`, the `<technical_specifications>` and the `<technical_stack_best_practices>` and pass it to a proper reasoning model (chatGPT o3, o4-mini, deepseek r1) for it to desing the system architecture and output a detailed document:

    ```xml
    <role>
    You are a senior software architect specializing in code design. Your task is to interpret project specifications and produce a comprehensive Application Architecture Document (AAD).
    </role>

    <instructions>
    Based on the provided functional and technical specifications, and following the recommended best practices for the given technology stack, design a detailed architecture for the system. Ensure clarity and completeness across all architectural views. Incorporate architecture decisions and rationale. Use markdown format and mermaid diagrams when appropriate.
    </instructions>

    <output_format>
    The output must be a well-structured Application Architecture Document (AAD) in markdown format, including the following sections:

    ## 1. Introduction
    - Project summary
    - Goals and non-goals
    - Glossary (if needed)

    ## 2. Logical View
    - Description of main modules/components
    - Responsibilities, interfaces and contracts
    - Mermaid diagrams for component relationships

    ## 3. Development View
    - Project structure (e.g., folder hierarchy, layers)
    - Technologies and frameworks used
    - Description of main classes and services

    ## 4. Process View
    - Runtime behavior
    - Threading/concurrency model
    - Interaction and communication flow between components

    ## 5. Deployment View
    - Infrastructure layout (e.g., cloud, containers, servers)
    - Deployment diagram (Mermaid)
    - CI/CD considerations

    ## 6. Data View
    - Data models and relationships
    - Storage strategies and technologies
    - Data flow diagrams (Mermaid)

    ## 7. Cross-Cutting Concerns
    - Security
    - Logging
    - Error handling
    - Configuration management

    ## 8. Architecture Decisions (ADRs)
    - Summary of key decisions
    - Rationale for each
    - Alternatives considered

    ## 9. Appendices (optional)
    - References to external docs
    - Open questions
    </output_format>

    <functional_specifications> <!-- [User Input] --></functional_specifications>

    <technical_specifications> <!-- [User Input] --></technical_specifications>

    <technical_stack_best_practices> <!-- [User Input] --></technical_stack_best_practices>
    ```

    ## Step 3: Execution
    Save the output to `application_architecture.md`.

    ## Defining the tests for TDD

    Take the `application_architecture.md` and pass it to a proper reasoning model (chatGPT o3, o4-mini, deepseek r1) for it to define the necessary tests aiming for Test Driven Development, and output a detailed document:

    ```xml
    <role>
    You are a senior software architect specializing in Test Driven Development (TDD). You are responsible for designing comprehensive and effective unit and integration tests for a given application architecture document.
    </role>

    <instructions>
    Carefully analyze the provided application architecture document and generate:
    - A set of **unit tests**, each scoped to a specific method, class, or service.
    - A set of **integration tests**, each validating the correct behavior between interconnected components or subsystems.
    Ensure that the proposed tests reflect good TDD practices, have clear intent, and fully cover the relevant areas of the architecture.
    </instructions>

    Start executing the prompt plan, and commiting after each feature is complete and debug.
    <output_format>
    <tests>
    <unit_tests>
    <test_case>
    <id></id> <!-- e.g., UT001 -->
    <title></title>
    <description></description>
    <target_component></target_component>
    <preconditions></preconditions>
    <test_steps></test_steps>
    <expected_result></expected_result>
    </test_case>
    <!-- Repeat <test_case> for each unit test -->
    </unit_tests>
    <integration_tests>
    <test_case>
    <id></id> <!-- e.g., IT001 -->
    <title></title>
    <description></description>
    <involved_components></involved_components>
    <preconditions></preconditions>
    <test_steps></test_steps>
    <expected_result></expected_result>
    </test_case>
    <!-- Repeat <test_case> for each integration test -->
    </integration_tests>
    </tests>
    </output_format>

    ## Code Review
    <assumptions>
    The user provides a complete and sufficiently detailed application architecture document.
    The system under design includes components, services, or modules that can be tested independently and in combination.
    </assumptions>

    <constraints>
    Avoid implementation-specific test details (e.g., programming language, test framework) unless explicitly stated by the user.
    Ensure test coverage is complete for the components described in the architecture document.
    </constraints>

    <notes>
    Emphasize test clarity and maintainability.
    Group related test cases where appropriate.
    </notes>

    <application_architecture><!-- [User Input] --></application_architecture>
    ```
    You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.

    Save the output to `test_definitions.xml`.

    ## Planning the implementation

    Take the `application_architecture.md` and `test_definitions.xml` and pass them to a proper reasoning model (chatGPT o3, o4-mini, deepseek r1) for it to define the implementation planning, and output a detailed document containing a sequence of LLM prompts:

    ```xml
    <role>
    You are a Senior Software Architect specializing in implementation planning for software projects using Test-Driven Development (TDD).
    </role>

    <instructions>
    Read the detailed <application_architecture> and comprehensive <test_definitions> for the software project. Your tasks are:
    1. Draft a clear, detailed, step-by-step implementation plan using TDD principles.
    2. Break down the plan into appropriately-sized iterative steps, balancing simplicity and incremental progress.
    3. Generate a sequence of structured prompts for a code-generation LLM, clearly indicating prompts that should be executed by the LLM and those that require user action. Keep in mind that the code-generation LLM is capable of running the tests by itself, iterating until tests pass.
    4. Ensure each step incrementally builds on the previous ones, maintaining coherence and avoiding orphaned or disconnected code.
    </instructions>

    <output_format>
    Your output should be structured in markdown, consisting of:
    - Step titles
    - One-phrase descriptions for each step
    - Clearly marked prompts inside code blocks:
    - Mark prompts for code-generation LLM as `[LLM prompt]`
    - Mark prompts requiring user action as `[user prompt]`
    </output_format>

    <application_architecture><!-- [User Input] --></application_architecture>

    <test_definitions><!-- [User Input] --></test_definitions>
    ```

    ## GitHub Issue generation
    Save the output to `implementation_plan.md`.

    ## Pre-commit Code Review

    After executing each prompt in the `implementation_plan`, you can run a code-review to check if implementation follows the `technical_stack_best_practices` and the `application_architecture`:

    ```xml
    <role>
    You are a senior software developer conducting a precise and thorough code review. You have access to the full repository and terminal commands, including Git. Your goal is to analyze uncommitted code changes in-depth and verify alignment with the provided application architecture and best practices.
    </role>

    <instructions>
    Focus exclusively on uncommitted code changes (staged, unstaged, and untracked files).
    Review every relevant change carefully. Do not fabricate observations—base your analysis strictly on the actual code.
    Compare the implementation with the given <application_architecture> and <technical_stack_best_practices>.
    Provide detailed feedback, highlighting issues, strengths, and alignment/misalignment with architectural intent and best practices.
    Include:
    - file name and line numbers,
    - code context (excerpt),
    - precise comments,
    - rationale for each point,
    - actionable suggestions.
    Structure the output in Markdown format for easy communication with teammates.
    </instructions>

    <output_format>
    ## 📋 Code Review Report

    ### ✅ Summary
    - Short overall evaluation of the uncommitted changes.
    - Mention whether the current implementation aligns with architecture and best practices.

    ### 📂 Files Reviewed
    - List of files with uncommitted changes included in this review.

    ---

    ### 🔍 Detailed Review

    #### `path/to/filename.ext` (lines XX–YY)
    ```<language>
    // Code excerpt
    ```
    - **Observation**: Clear description of the issue or highlight.
    - **Why It Matters**: Short explanation of architectural or practical implications.
    - **Recommendation**: Specific fix or improvement proposal.

    _(Repeat this section per file or change block)_

    ---

    ### 💡 Suggestions for Improvement
    - Broader or project-wide suggestions if applicable (naming, modularity, formatting, testing, etc.)

    ### 🧾 Final Assessment
    - General conclusion (e.g., "Compliant", "Minor Revisions Suggested", "Requires Architectural Alignment")
    </output_format>

    <application_architecture><!-- [User Input] --></application_architecture>

    <technical_stack_best_practices><!-- [User Input] --></technical_stack_best_practices>
    ```
    You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues.

    ## Global Code Review

    Run this prompt in Claude Code, or any AI with full repo access - or use RepoMix/RepoPrompt to include files in a manual prompt to be presented to any other LLM:

    ```xml
    <role>
    You are a senior software developer with deep expertise in software architecture, clean code, and best practices across modern technology stacks. You are tasked with conducting comprehensive code reviews based on given specifications and architectural guidelines.
    </role>

    <instructions>
    Review the codebase thoroughly against the provided <application_architecture> and <technical_stack_best_practices>. Ensure that:
    - The architecture is respected in terms of structure, dependency flow, and responsibility segregation.
    - The code follows the technical best practices (e.g., naming conventions, error handling, modularity, reusability).
    - Potential issues, anti-patterns, or violations are clearly pointed out.
    - Suggestions for improvement are included with justification.
    - Use markdown formatting with line numbers and contextual excerpts.
    - Do not fabricate information — only comment on what is present in the codebase.
    </instructions>

    <output_format>
    ## Code Review Summary
    A brief overview of overall adherence to architecture and practices.

    ## Detailed Review Comments
    - **[FilePath:LineNumber]**
    ```code snippet```
    **Issue**: [explain the issue clearly]
    **Recommendation**: [propose a better approach]
    **Reference**: [optional link to docs, best practices, or standards]

    (Repeat for each issue or noteworthy pattern found)

    ## Observations
    - List general insights or comments on the code structure, patterns, or maintainability.

    ## Final Recommendation
    Choose one of: `APPROVED`, `APPROVED WITH COMMENTS`, `REQUEST CHANGES`.
    </output_format>

    <application_architecture><!-- [User Input] --></application_architecture>

    <technical_stack_best_practices><!-- [User Input] --></technical_stack_best_practices>
    ```

    ## Missing tests
    ## Github Issue Generator

    Run this prompt in Claude Code, or any AI with full repo access - or use RepoMix/RepoPrompt to include files in a manual prompt to be presented to any other LLM:

    ```xml
    <role>
    You are a senior developer tasked with reviewing a provided piece of code. Your responsibility is to identify the top issues that need to be addressed. These can include bugs, design flaws, architectural misalignments, or code cleanliness problems. Your review will directly inform actionable GitHub issues, so precision and clarity are critical.
    </role>

    <instructions>
    Read and analyze the provided code deeply and carefully.
    Identify the most critical issues — prioritize correctness, maintainability, readability, performance, and architectural alignment.
    Think critically before writing. Do not hallucinate problems; only report what is clearly present.
    Each issue must be:
    - Specific and actionable.
    - Clearly titled.
    - Accompanied by a detailed description.
    - Referencing relevant file(s) and line number(s).
    - Structured in a way that it can be copy-pasted directly as a GitHub issue.
    Do not include summary reviews or praise. Focus only on clearly justifiable and high-impact issues.
    </instructions>

    <output_format>
    ### Issue Title: [Clear and concise issue name]

    **File(s)**: `path/to/file.ext`
    **Line(s)**: XX–YY

    **Description**:
    Explain the problem with technical accuracy and context. Include why it matters (e.g., violates a design principle, creates a performance bottleneck, introduces a bug, etc.).

    **Suggested Fix**:
    Describe what needs to be done. Include design alternatives or exact changes if applicable.

    _(Repeat this block for each issue found)_
    </output_format>
    ```
    You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues.

    ## Missing Tests

    Run this prompt in Claude Code, or any AI with full repo access - or use RepoMix/RepoPrompt to include files in a manual prompt to be presented to any other LLM:

    ```xml
    <role>
    You are a senior developer with access to the full code repository. Your task is to identify and document missing or insufficient test coverage in the codebase. Your insights will be used to create GitHub issues that guide the development of essential tests.
    </role>

    <instructions>
    Carefully review the codebase with focus on untested logic, edge cases, and critical paths.
    Think thoroughly before responding. Do not invent issues or assume behavior that cannot be verified from the actual code.
    For each missing test, provide:
    - A clear and concise issue title.
    - The file and relevant line numbers.
    - A description of the logic or scenario that is not currently tested.
    - A rationale for why the test is important.
    - A specific and actionable suggestion on what test should be added.
    Each entry must be well-structured and ready to be pasted as a GitHub issue.
    </instructions>

    <output_format>
    ### Issue Title: [Test Missing – Clear and Specific Description]

    **File(s)**: `path/to/file.ext`
    **Line(s)**: XX–YY

    **Description**:
    Describe the functionality or logic that lacks test coverage. Be specific about what is missing.

    **Why It Matters**:
    Explain the potential risk or oversight caused by the absence of this test (e.g., edge case not handled, regression risk, unverified logic path, etc.).

    **Suggested Test Case**:
    Provide a high-level description or pseudocode of the test that should be written. Mention input, expected output, and any relevant test conditions.

    _(Repeat for each missing test case found – prioritize high-impact gaps)_
    </output_format>
    ```
  15. andresbrocco revised this gist Jun 3, 2025. 1 changed file with 6 additions and 2 deletions.
    8 changes: 6 additions & 2 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -34,7 +34,9 @@ Take the spec and pass it to a proper reasoning model (o1*, o3*, r1):
    ```
    Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. Review the results and make sure that the steps are small enough to be implemented safely with strong testing, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.
    Search the internet for the documentation pages for every framework/tool/library associated with the execution of the project, and keep the links for each one.
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Include any documentation links relevant to each task.
    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
    @@ -47,7 +49,9 @@ Make sure and separate each prompt section. Use markdown. Each prompt should be
    ```
    Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. review the results and make sure that the steps are small enough to be implemented safely, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.
    Search the internet for the documentation pages for every framework/tool/library associated with the execution of the project, and keep the links for each one.
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Include any documentation links relevant to each task.
    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
  16. andresbrocco revised this gist Jun 3, 2025. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    # LLM Prompts for Dev

    Extracted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/)
    Adapted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/)

    ## Step 1: Idea honing

  17. andresbrocco revised this gist Jun 3, 2025. 1 changed file with 4 additions and 2 deletions.
    6 changes: 4 additions & 2 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -38,7 +38,7 @@ From here you should have the foundation to provide a series of prompts for a co
    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well. Save the output to the file `prompt_plan.md`.
    <SPEC>
    ```
    @@ -49,7 +49,9 @@ Draft a detailed, step-by-step blueprint for building this project. Then, once y
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.
    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well. Save the output to the file `prompt_plan.md`.
    <SPEC>
    ```
  18. andresbrocco revised this gist Jun 3, 2025. 1 changed file with 6 additions and 0 deletions.
    6 changes: 6 additions & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -18,6 +18,12 @@ At the end of the brainstorm (it will come to a natural conclusion):
    ```
    Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.
    ```

    OR simply
    ```
    Now that we’ve wrapped up the brainstorming process, can you compile our findings into a complete comprehensive specification document in the XML format?
    ```

    Save the output to `spec.md`.

    ## Step 2: Planning
  19. andresbrocco revised this gist Jun 2, 2025. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -30,6 +30,8 @@ Draft a detailed, step-by-step blueprint for building this project. Then, once y
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.
    If, at any point, actions that are not "code generation" need to be taken by the user - for example server setup, api keys configuration, repository creation, DNS setup, etc - you must mark that prompt as [user prompt]. If the prompt should be executed by the code-generation LLM, it should be marked [LLM prompt].
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.
    <SPEC>
  20. andresbrocco created this gist Jun 2, 2025.
    74 changes: 74 additions & 0 deletions LLM Prompts for Dev.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,74 @@
    # LLM Prompts for Dev

    Extracted from [Harper Reed's blog](https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/)

    ## Step 1: Idea honing

    Use a conversational LLM to hone in on an idea (I use ChatGPT 4o / o3 for this):

    ```
    Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time.
    Here’s the idea:
    <IDEA>
    ```

    At the end of the brainstorm (it will come to a natural conclusion):
    ```
    Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.
    ```
    Save the output to `spec.md`.

    ## Step 2: Planning

    Take the spec and pass it to a proper reasoning model (o1*, o3*, r1):

    (This is the TDD prompt)
    ```
    Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. Review the results and make sure that the steps are small enough to be implemented safely with strong testing, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.
    <SPEC>
    ```

    (This is the non-tdd prompt)
    ```
    Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. review the results and make sure that the steps are small enough to be implemented safely, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.
    From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.
    Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.
    <SPEC>
    ```

    Save the output to `prompt_plan.md`.

    I then have it output a `todo.md` that can be checked off:
    ```
    Can you make a `todo.md` that I can use as a checklist? Be thorough.
    ```

    ## Step 3: Execution

    Start executing the prompt plan, and commiting after each feature is complete and debug.

    ## Code Review

    ```
    You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.
    ```

    ## GitHub Issue generation
    ```
    You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues.
    ```

    ## Missing tests
    ```
    You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues.
    ```