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

@@ -44,7 +44,7 @@ local M = {
     5. **Styling & CSS Management**  
        - Use your preferred styling approach (CSS Modules, [Tailwind CSS](https://tailwindcss.com/), or standard CSS/SCSS files).  
        - Keep global styles minimal, focusing on utility classes or base styling; keep component-level styles scoped whenever possible.  
-     - If using CSS-in-JS solutions or third-party libraries, ensure they integrate cleanly with Solid’s reactivity.  
+       - If using CSS-in-JS solutions or third-party libraries, ensure they integrate cleanly with Solid’s reactivity.  
 
     6. **TypeScript & Linting**  
        - Use **TypeScript** to ensure type safety and improve maintainability.  
@@ -170,7 +170,7 @@ local M = {
     1. **Go Modules**  
        - Use a single `go.mod` file at the project root for module management.  
        - Ensure you use proper import paths based on the module name.  
-     - If you refer to internal packages, use relative paths consistent with the module’s structure (e.g., `moduleName/internal/packageA`).  
+       - If you refer to internal packages, use relative paths consistent with the module’s structure (e.g., `moduleName/internal/packageA`).  
 
     2. **Package Structure**  
        - Each folder should contain exactly one package.  
@@ -199,21 +199,19 @@ local M = {
     4. **Coding Best Practices**  
        - Maintain idiomatic Go code (e.g., short function and variable names where obvious, PascalCase for exported symbols).  
        - Keep functions short, focused, and tested.  
-     - Use Go’s standard library where possible before adding third-party dependencies.  
+       - Use Go’s standard library where possible before adding third-party dependencies.  
        - When introducing new functions or types, ensure they are uniquely named to avoid collisions.  
 
     5. **Import Management**  
        - Ensure that every import is actually used in your code.  
        - Remove unused imports to keep your code clean and maintainable.  
        - Include all necessary imports for anything referenced in your code to avoid missing imports.  
-     - Verify that any introduced import paths match your module’s structure and do not cause naming conflicts.  
+       - Verify that any introduced import paths match your module’s structure and do not cause naming conflicts.  
 
     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.”).  
+       - 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 an existing file, specify precisely which changes or additions you are making.  
+       - If you modify existing files, 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.
   ]],
   ["typo3"] = [[
     ### TYPO3 Development Guidelines
@@ -239,10 +237,10 @@ local M = {
        - Keep site configuration in `config/sites/` (for TYPO3 v9+).  
 
     2. **Extension Development**  
-     - Create custom functionality as separate extensions (site packages, domain-specific extensions, etc.) following TYPO3’s recommended structure:
+       - Create custom functionality as separate extensions (site packages, domain-specific extensions, etc.) following TYPO3’s recommended structure:
          - **Key files**: `ext_emconf.php`, `ext_localconf.php`, `ext_tables.php`, `ext_tables.sql`, `Configuration/`, `Classes/`, `Resources/`.  
          - Use **PSR-4** autoloading and name extensions logically (e.g., `my_sitepackage`, `my_blogextension`).  
-     - Keep your extension’s code under `Classes/` (e.g., Controllers, Models, Services).  
+       - Keep your extension’s code under `Classes/` (e.g., Controllers, Models, Services).  
        - Place Fluid templates, partials, and layouts under `Resources/Private/` (e.g., `Resources/Private/Templates`, `Resources/Private/Partials`, `Resources/Private/Layouts`).  
 
     3. **Configuration (TypoScript & TCA)**  
@@ -275,10 +273,8 @@ local M = {
     7. **Output Format**  
        - Present any generated source code or configuration files in a well-organized structure.  
        - 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.”).  
+       - 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
@@ -293,11 +289,11 @@ local M = {
     2. **Crates & Packages**  
        - Split the application into logical crates (libraries and/or binaries).  
        - Each crate should have a single main **library** (`lib.rs`) or **binary** (`main.rs`) in its `src/` folder.  
-     - Name crates, modules, and files clearly, following Rust’s naming conventions (e.g., `snake_case` for files/modules, `PascalCase` for types).  
+       - Name crates, modules, and files clearly, following Rust’s naming conventions (e.g., `snake_case` for files/modules, `PascalCase` for types).  
        - Avoid duplicating the same function or type in multiple crates; share common functionality via a dedicated library crate if needed.  
 
     3. **Folder & Module Structure**  
-     - Organize code within each crate using Rust’s module system, keeping related functions and types in logical modules/submodules.  
+       - Organize code within each crate using Rust’s module system, keeping related functions and types in logical modules/submodules.  
        - A typical directory layout for a workspace with multiple crates might look like:
          ```
          myproject/
@@ -315,19 +311,19 @@ local M = {
          ├── target/
          └── ...
          ```
-     - If you have integration tests, store them in a `tests/` folder at the crate root, or use the workspace root’s `tests/` directory if they span multiple crates.  
+       - If you have integration tests, store them in a `tests/` folder at the crate root, or use the workspace root’s `tests/` directory if they span multiple crates.  
 
     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.