Cloonar/chatgpt.vim
2
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

feat: remove unneeded debug command approach

Browse Source
This commit is contained in:
Dominik Polakovics Polakovics
2025-01-31 10:31:09 +01:00
parent fd8df2abd5
commit 0ff77954db
4 changed files with 63 additions and 202 deletions
Download Patch File Download Diff File Expand all files Collapse all files

117
lua/chatgpt_nvim/prompts.lua
View File

@@ -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.
@@ -81,7 +81,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.
@@ -110,21 +110,21 @@ 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.”).
- 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.
Please follow these guidelines to ensure the generated or explained code aligns well with Golang’s best practices for large, modular projects.
]],
["typo3-development"] = [[
### TYPO3 Development Guidelines
@@ -150,10 +150,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)**
@@ -186,10 +186,10 @@ 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.
Please follow these guidelines to ensure the generated or explained code aligns well with TYPO3’s best practices for large, maintainable projects.
]],
["rust-development"] = [[
### Rust Development Guidelines
@@ -204,11 +204,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/
@@ -226,7 +226,7 @@ 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:
@@ -256,54 +256,40 @@ local M = {
["basic-prompt"] = [[
### Basic Prompt
1. **Analyze Required Files**
- Check the project structure (or any provided file list).
- If you identify a file reference or function you do not have, **produce a YAML snippet** requesting that file’s content in full. For example:
```yaml
project_name: my_project
files:
- path: "relative/path/to/needed_file"
```
- Do not proceed with final changes if you lack the necessary file contents.
- Always provide the entire file content when you do include a file.
You are assisting me in a coding workflow for a project (e.g., "my_project"). Whenever you need to inspect or modify files, or execute commands, you must provide both:
2. **Request File Contents**
- For every file you need but don’t have, provide a short YAML snippet (like above) to retrieve it.
- Ask any clarifying questions outside the YAML code block.
1. `project_name: "<actual_project_name>"` (matching the real project name)
2. A `tools:` array describing the operations you want to perform.
3. **Provide Output YAML**
- When you have all information, output the final YAML in this format:
```yaml
project_name: my_project
**Example** (substitute `<actual_project_name>` with the real name):
```yaml
project_name: "my_project"
tools:
- tool: "readFile"
path: "relative/path/to/file"
files:
- path: "src/main.py"
content: |
# Updated main function
def main():
print("Hello, World!")
- tool: "replace_in_file"
path: "relative/path/to/file"
replacements:
- search: "old text"
replace: "new text"
- path: "docs/README.md"
delete: true
```
- `project_name` must match the project’s configured name.
- Each file item in `files` must have `path` and either `content` or `delete: true`.
- tool: "editFile"
path: "relative/path/to/file"
content: |
# Full updated file content here
4. **Explain Changes**
- After the final YAML, add a brief explanation of the modifications (outside the YAML).
- tool: "executeCommand"
command: "ls -la"
```
5. **Iterate as Needed**
- If further context or changes are required, repeat steps to request files or clarifications.
6. **Important Notes**
- Never modify or delete a file you haven’t explicitly requested or received.
- Use comments in code only to clarify code logic, not to explain your thought process.
- Explanations go outside the YAML.
7. **Best Practices**
- Keep file paths accurate to avoid mistakes during implementation.
- Maintain a clear, logical structure for your changes.
- Use the final YAML consistently for clarity.
**Key Points**:
- Always include `project_name: "<actual_project_name>"` in the same YAML as `tools`.
- If you only need one tool, include just one object in the `tools` array.
- If multiple tools are needed, list them sequentially under `tools`.
- Allways run at least one tool (e.g., `readFile`, `editFile`, `executeCommand`), exept you have finished.
- The plugin will verify the `project_name` is correct before running any tools.
- If the response grows too large, I'll guide you to break it into smaller steps.
]],
["secure-coding"] = [[
### Secure Coding Guidelines
@@ -370,33 +356,10 @@ local M = {
["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.
At each step, we'll provide relevant files or context if needed.
Thank you!
]],
["file-selection-instructions"] = [[
Delete lines for directories you do NOT want, then save & close (e.g. :wq, :x, or :bd)
]],
["debug-commands-info"] = [[
### Debugging Commands
If you need debugging commands, include them in your YAML response as follows:
```yaml
commands:
- command: "ls"
args: ["-l", "path/to/directory"]
- command: "grep"
args: ["-r", "searchString", "path/to/file/or/directory"]
```
The "ls" command uses the system's 'ls' command to list directory contents. You can pass flags or additional arguments in `args`.
The "grep" command searches for a given pattern in files or directories, again receiving flags or additional arguments in `args`.
If you omit `args` for grep, you can still use the older format with `pattern` and `target` for backward compatibility.
This are the only two commands supported at the moment.
When these commands are present and `enable_debug_commands` is true, I'll execute them and return the results in the clipboard.
]]
}