feat: make prompt better to include real project name

lua/chatgpt_nvim/init.lua

@@ -172,7 +172,10 @@ local function build_prompt(user_input, dirs, conf)
   env_lines[#env_lines+1] = "</environment_details>"
   table.insert(final_sections, table.concat(env_lines, "\n"))
 
-  return table.concat(final_sections, "\n\n")
+  local final_prompt = table.concat(final_sections, "\n\n")
+  -- Replace placeholder "%PROJECT_NAME%" with the actual project name from configuration
+  final_prompt = final_prompt:gsub("%%PROJECT_NAME%%", conf.project_name)
+  return final_prompt
 end
 
 local function handle_step_by_step_if_needed(prompt, conf)

lua/chatgpt_nvim/prompts.lua

@@ -210,10 +210,8 @@ local M = {
 
     6. **Output Format**  
        - Present any generated source code as well-organized Go files, respecting the single-package-per-folder rule.  
-       - When explaining your reasoning, include any relevant architectural trade-offs and rationale (e.g., “I placed function X in package Y to keep the domain-specific logic separate from the main execution flow.”).  
-       - If you modify an existing file, specify precisely which changes or additions you are making.  
-
-  Please follow these guidelines to ensure the generated or explained code aligns well with Golang’s best practices for large, modular projects.
+       - When explaining your reasoning, include any relevant architectural trade-offs and rationale (e.g., “I placed function X in package `my_lib` to keep the business logic separate from the command-line interface.”).  
+       - If you modify existing files, specify precisely which changes or additions you are making.  
   ]],
   ["typo3"] = [[
     ### TYPO3 Development Guidelines
@@ -277,8 +275,6 @@ local M = {
        - Clearly indicate where each file should be placed in the TYPO3 directory layout.  
        - When explaining your reasoning, include any relevant architectural decisions (e.g., “I created a separate extension for blog functionality to keep it isolated from the site’s main configuration.”).  
        - If you modify or extend an existing file, specify precisely which changes or additions you are making.  
-
-  Please follow these guidelines to ensure the generated or explained code aligns well with TYPO3’s best practices for large, maintainable projects.
   ]],
   ["rust"] = [[
     ### Rust Development Guidelines
@@ -320,14 +316,14 @@ local M = {
     4. **Coding & Documentation Best Practices**  
        - Write **idiomatic Rust** code:
          - Use `cargo fmt` (formatting) and `cargo clippy` (linter) to maintain consistency and quality.  
-         - Use `?` operator for error handling, prefer `Result<T, E>` over panicking unless absolutely necessary.  
+         - Use the `?` operator for error handling, preferring `Result<T, E>` over panicking unless absolutely necessary.  
        - Document your code using [Rustdoc](https://doc.rust-lang.org/rustdoc/) comments (`///` for public API) and provide examples when relevant.  
        - Write **unit tests** alongside the code (in `src/` files) and **integration tests** in a dedicated `tests/` folder.  
        - Keep functions short, focused, and ensure they have well-defined responsibilities.  
 
     5. **Reusability & Shared Code**  
        - Place common or reusable functionality into a dedicated **library** crate.  
-       - Ensure that crates depending on shared code add the appropriate `[dependencies]` or `[dev-dependencies]` in their `Cargo.toml`.  
+       - Ensure that crates depending on shared code add the appropriate `[dependencies]` or `[dev-dependencies]` in their Cargo.toml.  
        - Use the Rust standard library whenever possible before introducing external dependencies.  
 
     6. **Error Handling & Logging**  
@@ -339,13 +335,11 @@ local M = {
        - Present generated source code as well-organized Rust files, respecting the single main library or binary per crate (`lib.rs` or `main.rs`).  
        - When explaining your reasoning, include any architectural or design decisions (e.g., “I placed function X in crate `my_lib` to keep the business logic separate from the command-line interface.”).  
        - If you modify existing files, specify precisely which lines or sections have changed.  
-
-    Please follow these guidelines to ensure the generated or explained code aligns well with Rust best practices for large, modular projects.
   ]],
   ["basic"] = [[
     ### Basic Prompt
 
-    You are assisting me in a coding workflow for a project (e.g., "my_project"). **Every time you inspect, modify, or execute operations on files, you must strictly follow the YAML format described below.** Under no circumstances should you output file operations in plain text or deviate from this structure.
+    You are assisting me in a coding workflow for a project (e.g., "%PROJECT_NAME%"). **Every time you inspect, modify, or execute operations on files, you must strictly follow the YAML format described below.** Under no circumstances should you output file operations in plain text or deviate from this structure.
 
     #### Mandatory Guidelines
 
@@ -356,7 +350,7 @@ local M = {
     2. **Include the Project Name**  
        - Always include:  
          ```yaml
-         project_name: "my_project"
+         project_name: "%PROJECT_NAME%"
          ```
          This must be part of every YAML block you generate.
 
@@ -370,7 +364,7 @@ local M = {
     5. **File Inspection Before Modification**  
        - When you need to inspect a file’s contents, always use the following YAML format:
          ```yaml
-         project_name: "my_project"
+         project_name: "%PROJECT_NAME%"
          tools:
            - tool: "readFile"
              path: "relative/path/to/file"
@@ -380,7 +374,7 @@ local M = {
     6. **Modifying Files**  
        - To modify a file that you have already read, use:
          ```yaml
-         project_name: "my_project"
+         project_name: "%PROJECT_NAME%"
          tools:
            - tool: "editFile"
              path: "relative/path/to/file"
@@ -389,7 +383,7 @@ local M = {
          ```
        - Alternatively, for incremental changes, use:
          ```yaml
-         project_name: "my_project"
+         project_name: "%PROJECT_NAME%"
          tools:
            - tool: "replace_in_file"
              path: "relative/path/to/file"
@@ -401,7 +395,7 @@ local M = {
     7. **Executing Commands**  
        - To run any shell command (e.g., testing, listing files), use:
          ```yaml
-         project_name: "my_project"
+         project_name: "%PROJECT_NAME%"
          tools:
            - tool: "executeCommand"
              command: "shell command here"
@@ -425,7 +419,7 @@ local M = {
     #### Example YAML Block
 
     ```yaml
-    project_name: "my_project"
+    project_name: "%PROJECT_NAME%"
     tools:
       - tool: "readFile"
         path: "relative/path/to/file"
@@ -453,7 +447,7 @@ local M = {
 
     ---
 
-    This revised prompt should help ensure that the model always reads existing file contents before editing and that every file operation is returned in the strict YAML format you require.
+    This revised prompt ensures that during execution the placeholder "%PROJECT_NAME%" is replaced with the actual project name from the current configuration.
   ]],
   ["secure-coding"] = [[
     ### Secure Coding Guidelines
@@ -516,7 +510,7 @@ local M = {
        - Whenever possible, provide references to relevant security standards, best practices, or guidelines (e.g., OWASP, NIST).  
 
     Please follow these guidelines to ensure the generated or explained code prioritizes security at every level, mitigating potential risks and maintaining best practices for building secure software.
-  ]],
+  ]]
   ["step-prompt"] = [[
     It appears this request might exceed the model's prompt character limit if done all at once.
     Please break down the tasks into smaller steps and handle them one by one.