docs: update readme

README.md

@@ -4,26 +4,34 @@
 This plugin integrates a ChatGPT O1 model workflow into Neovim. It allows you to:
 
 1. Generate prompts containing:
-   - An **initial prompt** (from `.chatgpt_config.yaml` or `chatgpt_config.yaml`)
+   - An **initial prompt** (loaded from `.chatgpt_config.yaml` or `chatgpt_config.yaml`)
-   - A list of directories (also specified in `.chatgpt_config.yaml` or `chatgpt_config.yaml`) from which it gathers the project structure and file contents
+   - A list of directories (as specified in your configuration) from which it gathers the project structure
-   - **Interactive file selection** if enabled, so you can pick exactly which directories to include
+   - **Interactive file selection** (if enabled) so you can choose which directories to include
-   - Any **initial files** you define (e.g., `README.md`, etc.)
+   - Any **initial files** you define (e.g. `README.md`, etc.)
+   - Optionally, **file contents** can be appended to the prompt when the new `include_file_contents` flag is enabled
 
 2. Copy these prompts to your clipboard to paste into ChatGPT O1.
-3. Receive YAML changes from ChatGPT, then run `:ChatGPTPaste` to apply them or supply additional files.
+3. Receive YAML changes from ChatGPT and run `:ChatGPTPaste` to apply them or to supply additional files.
 
 ## New Key Features
 
 - **Step-by-Step Prompting** (`enable_step_by_step: true`):  
-  If the request grows too large (exceeds `token_limit`), the plugin automatically generates a special prompt asking the model to split the task into smaller steps, working through them one by one. This approach helps you stay within the model’s maximum token limit without having to manually break things apart.
+  If the generated prompt grows too large (exceeding the configured `prompt_char_limit`), the plugin automatically produces a special prompt asking the model to split the task into smaller steps. This ensures you remain within the model’s maximum token capacity without manually breaking your task apart.
 
-- **Partial Acceptance**: If `partial_acceptance: true`, you can open a buffer that lists the final changes. Remove or comment out lines you don’t want, then only those changes are applied.
+- **Partial Acceptance**:  
+  If `partial_acceptance: true`, you can open a buffer displaying the proposed changes. Remove or comment out lines you do not wish to apply, and only the remaining changes will be executed.
 
-- **Preview Changes**: If `preview_changes: true`, you get a buffer showing proposed changes before you apply them.
+- **Preview Changes**:  
+  If `preview_changes: true`, a buffer will show the proposed changes before they are applied.
 
-- **Interactive File Selection**: If `interactive_file_selection: true`, you choose which directories from `.chatgpt_config.yaml` or `chatgpt_config.yaml` get included in the prompt, reducing token usage.
+- **Interactive File Selection**:  
+  When `interactive_file_selection: true`, you can choose which directories (from your config file) to include in the prompt, thus managing token usage more effectively.
 
-- **Improved Debug**: If `improved_debug: true`, debug logs go into a dedicated `ChatGPT_Debug_Log` buffer for easier reading.
+- **Include File Contents**:  
+  A new configuration flag `include_file_contents` (default: `false`) lets you include the entire contents of the project files in the prompt. When enabled, the plugin gathers and appends the file contents from the selected directories. It counts the total characters and, if the combined file contents exceed the `prompt_char_limit`, it notifies you to disable this feature to avoid exceeding the model’s capacity.
+
+- **Improved Debug**:  
+  If `improved_debug: true`, detailed debug logs are sent to a dedicated `ChatGPT_Debug_Log` buffer for easier review.
 
 ## Example `.chatgpt_config.yaml` or `chatgpt_config.yaml`
 
@@ -37,40 +45,43 @@ directories:
 initial_files:
   - "README.md"
 debug: false
+include_file_contents: false  # Set to true to include file contents in the prompt
 enable_step_by_step: true
 preview_changes: true
 interactive_file_selection: true
 partial_acceptance: true
 improved_debug: true
-token_limit: 3000
+prompt_char_limit: 300000  # Maximum characters allowed in the prompt
 ```
 
 ## Usage
 
 1. **`:ChatGPT`**  
-   - If `interactive_file_selection` is on, you’ll pick directories to include in a buffer named `ChatGPT_File_Selection`.
+   - If `interactive_file_selection` is enabled, you will select directories via a buffer (named `ChatGPT_File_Selection`).
-   - Save & close with `:wq`, `:x`, or `:bd` (you don’t have to use `:q`).
+   - Save and close the buffer with `:wq`, `:x`, or `:bd` (no need to use `:q`).
-   - If `enable_step_by_step` is on and the prompt might exceed `token_limit`, the plugin will generate instructions prompting the model to address each step separately.
+   - If `enable_step_by_step` is active and the prompt might exceed `prompt_char_limit`, the plugin will generate a step-by-step instruction prompt.
 
 2. **Paste Prompt to ChatGPT**  
-   - If the task is split into steps, simply copy/paste them one by one into ChatGPT.
+   - If the task is split into steps, copy and paste them one by one into ChatGPT.
 
 3. **`:ChatGPTPaste`**  
-   - The plugin reads the YAML from your clipboard. If it requests more files, it might again suggest a step-by-step approach.  
+   - The plugin reads the YAML response from your clipboard. If additional files are requested, a step-by-step approach might be suggested.
-   - If final changes are provided:
+   - When final changes are provided:
-     - Optionally preview them (`preview_changes`).  
+     - You can optionally preview them (`preview_changes`).
-     - Optionally partially accept them (`partial_acceptance`).  
+     - You can optionally partially accept them (`partial_acceptance`).
-     - Then the plugin writes/deletes files as specified.
+     - Finally, the plugin applies file writes or deletions as specified in the YAML.
 
 ## Troubleshooting & Tips
-- Adjust `token_limit` in `.chatgpt_config.yaml` as needed.
+
-- If partial acceptance is confusing, remember to remove or prepend `#` to lines you don’t want before saving and closing the buffer.
+- Adjust `prompt_char_limit` in your configuration file as needed.
-- If step-by-step prompting occurs, ensure you follow each prompt the model provides in the correct order.  
+- If partial acceptance is confusing, simply remove or comment out lines you do not want before finalizing the buffer.
-- Check `ChatGPT_Debug_Log` if `improved_debug` is on, or the Neovim messages if `debug` is on, for detailed info.
+- When step-by-step prompting occurs, ensure you follow each instruction in the correct order.
-- You can close the selection or prompt buffers at any time with commands like `:bd`, `:x`, or `:wq`. No need to rely on `:q`.
+- For detailed debug information, check the `ChatGPT_Debug_Log` buffer (if `improved_debug` is enabled) or the standard Neovim messages (if `debug` is enabled).
+- You can close the selection or prompt buffers at any time using commands like `:bd`, `:x`, or `:wq`.
 
 ## Debug Commands
-If `enable_debug_commands` is true, you can include commands like these in your YAML:
+
+If `enable_debug_commands` is true, you can include commands such as:
 ```yaml
 commands:
   - command: "list"
@@ -80,21 +91,23 @@ commands:
     pattern: "searchString"
     target: "path/to/file/or/directory"
 ```
-The **list** command now uses the Linux `ls` command to list directory contents. The **grep** command searches for a given pattern in a file or all files in a directory.
+The **list** command uses the Linux `ls` command to list directory contents, while the **grep** command searches for a given pattern within files or directories.
 
-Enjoy your improved, more flexible ChatGPT Neovim plugin with step-by-step support!
+Enjoy your improved, flexible ChatGPT NeoVim plugin with step-by-step support and enhanced file inclusion capabilities!
 
-## Test when developing
+## Test when Developing
-add new plugin to runtimepath
+
+- **Add plugin to runtimepath:**
   ```vim
   :set rtp^=~/temp_plugins/chatgpt.vim
   ```
-Clear Lua module cache
+
+- **Clear Lua module cache:**
   ```vim
   :lua for k in pairs(package.loaded) do if k:match("^chatgpt_nvim") then package.loaded[k]=nil end end
   ```
-Load new plugin code
+
+- **Load new plugin code:**
   ```vim
   :runtime plugin/chatgpt.vim
   ```
-

lua/chatgpt_nvim/prompts.lua

@@ -73,6 +73,95 @@ local M = {
 
     Please follow these guidelines to ensure the generated or explained code aligns well with SolidJS best practices for large, maintainable projects.
   ]],
+  ["nodejs-development"] = [[
+    You are helping me develop a large Node.js application. Please keep the following points in mind when generating or explaining code:
+
+    1. **Project & Folder Structure**  
+       - Maintain a clear, top-level directory layout. For example:
+         ```
+         my-node-app/
+         ├── src/
+         │   ├── controllers/
+         │   ├── models/
+         │   ├── routes/
+         │   ├── services/
+         │   ├── utils/
+         │   └── index.js (or app.js)
+         ├── tests/
+         │   └── ...
+         ├── package.json
+         ├── .env (if needed)
+         ├── .eslintrc.js
+         └── ...
+         ```
+       - Keep your application logic separated in folders:
+         - **controllers/** (or handlers) for request handling logic,  
+         - **services/** for core business logic or data processing,  
+         - **models/** for database schemas/entities,  
+         - **routes/** for defining routes/endpoints,  
+         - **utils/** for reusable helper functions.  
+
+    2. **Dependencies & Package Management**  
+       - Use **npm** or **yarn** (pick one and stay consistent) to manage dependencies.  
+       - Keep your `package.json` clean by removing unused dependencies.  
+       - Pin exact versions for critical or sensitive dependencies to ensure reproducible builds.  
+
+    3. **Configuration & Environment Variables**  
+       - Use environment variables to store sensitive or environment-specific information (e.g., database credentials, API keys).  
+       - Consider a config management library (like [dotenv](https://github.com/motdotla/dotenv) or [dotenv-flow](https://github.com/kerimdzhanov/dotenv-flow)) to load environment variables from `.env` files.  
+       - Keep secrets out of version control (e.g., `.env` should be in `.gitignore`).  
+
+    4. **Code Organization & Module Patterns**  
+       - Use **ES Modules** (`import`/`export`) or **CommonJS** (`require`/`module.exports`) consistently across the project.  
+       - Keep each module focused on a single responsibility.  
+       - Use a **service layer** for business logic to avoid bloated controllers.  
+       - Use **async/await** for asynchronous operations, ensuring proper error handling (try/catch blocks or .catch callbacks).  
+
+    5. **Database & Data Persistence**  
+       - Use an ORM/ODM (e.g., [Sequelize](https://sequelize.org/) for SQL, [Mongoose](https://mongoosejs.com/) for MongoDB) or a query builder ([Knex.js](https://knexjs.org/)) to maintain cleaner database interactions.  
+       - Keep database-related logic in separate **models/** or **repositories/**.  
+       - Handle database migrations carefully (e.g., with [db-migrate](https://db-migrate.readthedocs.io/), [Liquibase](https://www.liquibase.org/), or built-in ORM migration tools).  
+
+    6. **Logging & Monitoring**  
+       - Use a structured logging library (e.g., [Winston](https://github.com/winstonjs/winston), [Pino](https://github.com/pinojs/pino)) to capture logs in JSON or another parseable format.  
+       - Ensure logs include enough context (request IDs, timestamps, etc.) to troubleshoot issues.  
+       - Consider external logging and monitoring solutions (e.g., [Datadog](https://www.datadoghq.com/), [New Relic](https://newrelic.com/)) for production environments.  
+
+    7. **Security & Best Practices**  
+       - Sanitize and validate all user inputs (e.g., using libraries like [validator](https://github.com/validatorjs/validator.js)).  
+       - Avoid SQL injection by using parameterized queries or ORM features.  
+       - Implement rate limiting or request throttling to prevent abuse (e.g., [express-rate-limit](https://github.com/nfriedly/express-rate-limit)).  
+       - Ensure **HTTPS** is used in production and secure headers are set (e.g., [helmet](https://github.com/helmetjs/helmet) for Express).  
+       - Keep dependencies updated to patch known vulnerabilities (use `npm audit` or equivalent).  
+
+    8. **Error Handling**  
+       - Use centralized error handling middleware (if using a framework like Express) to catch and process errors consistently.  
+       - Provide clear error messages but avoid leaking sensitive info in production.  
+       - Separate operational errors (e.g., user-related) from programmer errors (e.g., logic bugs) to handle them appropriately.  
+
+    9. **Testing & Quality Assurance**  
+       - Write **unit tests** for individual modules or functions (e.g., using [Jest](https://jestjs.io/), [Mocha](https://mochajs.org/)).  
+       - Use **integration tests** or **end-to-end tests** (e.g., [Supertest](https://github.com/visionmedia/supertest) for API endpoints).  
+       - Aim for high coverage but focus on critical business logic and error cases.  
+       - Automate tests in your CI pipeline.  
+
+    10. **Linting & Formatting**  
+        - Use **ESLint** (with recommended or popular config like [Airbnb](https://www.npmjs.com/package/eslint-config-airbnb)) for consistent code quality.  
+        - Use **Prettier** for code formatting to maintain a standardized style.  
+        - Configure linting and formatting checks in a pre-commit hook or CI (e.g., [Husky](https://typicode.github.io/husky/), [lint-staged](https://github.com/okonet/lint-staged)).  
+
+    11. **Deployment & Environment Management**  
+        - Containerize your app with Docker if possible, specifying a secure and minimal base image.  
+        - Use process managers like [PM2](https://pm2.keymetrics.io/) or systemd for production Node.js processes.  
+        - Maintain separate configuration (or environment variables) for staging, production, etc.  
+
+    12. **Output Format**  
+        - Present any generated source code with clear folder and file placement (e.g., `controllers/`, `services/`).  
+        - When explaining your reasoning, highlight the architectural decisions or patterns used (e.g., “I introduced a service layer to separate business logic from route handling.”).  
+        - If you modify existing files, specify precisely which lines or sections have changed, and why.  
+
+    Please follow these guidelines to ensure the generated or explained code aligns well with Node.js best practices for large, maintainable projects.
+  ]]
   ["go-development"] = [[
     ### Go Development Guidelines