gaunt-sloth-assistant 0.1.5 → 0.3.0

package/docs/CONFIGURATION.md

@@ -1,17 +1,17 @@
 # Configuration
 
-Populate `.gsloth.preamble.review.md` with your project details and quality requirements.
+Populate `.gsloth.guidelines.md` with your project details and quality requirements.
 Proper preamble is a paramount for good inference.
-Check [.gsloth.preamble.review.md](../.gsloth.preamble.review.md) for example.
+Check [.gsloth.guidelines.md](../.gsloth.guidelines.md) for example.
 
 Your project should have the following files in order for gsloth to function:
 - Configuration file (one of):
   - `.gsloth.config.js` (JavaScript module)
   - `.gsloth.config.json` (JSON file)
   - `.gsloth.config.mjs` (JavaScript module with explicit module extension)
-- `.gsloth.preamble.review.md`
+- `.gsloth.guidelines.md`
 
-> Gaunt Sloth currently only functions from the directory which has one of the configuration files and `.gsloth.preamble.review.md`.
+> Gaunt Sloth currently only functions from the directory which has one of the configuration files and `.gsloth.guidelines.md`.
 > Global configuration to invoke gsloth anywhere is in [ROADMAP](../ROADMAP.md).
 
 ## Config initialization
@@ -62,7 +62,7 @@ JSON configuration is simpler but less flexible than JavaScript configuration. I
 {
   "llm": {
     "type": "vertexai",
-    "model": "gemini-2.5-pro-exp-03-25",
+    "model": "gemini-2.5-pro-preview-05-06",
     "temperature": 0
   }
 }
@@ -109,7 +109,7 @@ export async function configure(importFunction, global) {
     const vertexAi = await importFunction('@langchain/google-vertexai');
     return {
         llm: new vertexAi.ChatVertexAI({
-            model: "gemini-2.5-pro-exp-03-25", // Consider checking for latest recommended model versions
+            model: "gemini-2.5-pro-preview-05-06", // Consider checking for latest recommended model versions
             // API Key from AI Studio should also work
             temperature: 0,
             //// Other parameters might be relevant depending on Vertex AI API updates.
@@ -146,16 +146,106 @@ See [Langchain documentation](https://js.langchain.com/docs/tutorials/llm_chain/
 
 ### JIRA
 
+Gaunt Sloth supports two methods to integrate with JIRA:
+
+#### 1. Modern Jira REST API (Scoped Token)
+
+This method uses the Atlassian REST API v3 with a Personal Access Token (PAT). It requires your Atlassian Cloud ID.
+
+**Prerequisites:**
+
+1. **Cloud ID**: You can find your Cloud ID by visiting `https://yourcompany.atlassian.net/_edge/tenant_info` while authenticated.
+
+2. **Personal Access Token (PAT)**: Create a PAT with the appropriate permissions from `Atlassian Account Settings -> Security -> Create and manage API tokens -> [Create API token with scopes]`.
+   - For issue access, the recommended permission is `read:jira-work` (classic)
+   - Alternatively granular access would require: `read:issue-meta:jira`, `read:issue-security-level:jira`, `read:issue.vote:jira`, `read:issue.changelog:jira`, `read:avatar:jira`, `read:issue:jira`, `read:status:jira`, `read:user:jira`, `read:field-configuration:jira`
+
+Refer to JIRA API documentation for more details [https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-get](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-get)
+
+**Environment Variables Support:**
+
+For better security, you can set the JIRA username, token, and cloud ID using environment variables instead of placing them in the configuration file:
+
+- `JIRA_USERNAME`: Your JIRA username (e.g., `user@yourcompany.com`).
+- `JIRA_API_PAT_TOKEN`: Your JIRA Personal Access Token with scopes.
+- `JIRA_CLOUD_ID`: Your Atlassian Cloud ID.
+
+If these environment variables are set, they will take precedence over the values in the configuration file.
+
+JSON:
+
+```json
+{
+  "llm": {"type": "vertexai", "model": "gemini-2.5-pro-preview-05-06"},
+  "requirementsProvider": "jira",
+  "requirementsProviderConfig": {
+    "jira": {
+      "username": "username@yourcompany.com",
+      "token": "YOUR_JIRA_PAT_TOKEN",
+      "cloudId": "YOUR_ATLASSIAN_CLOUD_ID"
+    }
+  }
+}
+```
+
+Optionally displayUrl can be defined to have a clickable link in the output:
+
+```json
+{
+  "llm": {"type": "vertexai", "model": "gemini-2.5-pro-preview-05-06"},
+  "requirementsProvider": "jira",
+  "requirementsProviderConfig": {
+    "jira": {
+      "displayUrl": "https://yourcompany.atlassian.net/browse/"
+    }
+  }
+}
+```
+
+JavaScript:
+
+```javascript
+export async function configure(importFunction, global) {
+    const vertexAi = await importFunction('@langchain/google-vertexai');
+    return {
+        llm: new vertexAi.ChatVertexAI({
+            model: "gemini-2.5-pro-preview-05-06"
+        }),
+        requirementsProvider: 'jira',
+        requirementsProviderConfig: {
+            'jira': {
+                username: 'username@yourcompany.com', // Your Jira username/email
+                token: 'YOUR_JIRA_PAT_TOKEN',        // Your Personal Access Token
+                cloudId: 'YOUR_ATLASSIAN_CLOUD_ID'    // Your Atlassian Cloud ID
+            }
+        }
+    }
+}
+```
+
+#### 2. Legacy Jira REST API (Unscoped Token)
+
+This uses the Unscoped API token (Aka Legacy API token) method with REST API v2.
+
+A legacy token can be acquired from `Atlassian Account Settings -> Security -> Create and manage API tokens -> [Create API token without scopes]`.
+
 Example configuration setting up JIRA integration using a legacy API token for both `review` and `pr` commands.
 Make sure you use your actual company domain in `baseUrl` and your personal legacy `token`.
 
-A legacy token can be acquired from `Atlassian Account Settings -> Security -> Create and manage API tokens`.
+**Environment Variables Support:**
+
+For better security, you can set the JIRA username and token using environment variables instead of placing them in the configuration file:
+
+- `JIRA_USERNAME`: Your JIRA username (e.g., `user@yourcompany.com`).
+- `JIRA_LEGACY_API_TOKEN`: Your JIRA legacy API token.
+
+If these environment variables are set, they will take precedence over the values in the configuration file.
 
 JSON:
 
 ```json
 {
-  "llm": {"type": "vertexai", "model": "gemini-2.5-pro-exp-03-25"},
+  "llm": {"type": "vertexai", "model": "gemini-2.5-pro-preview-05-06"},
   "requirementsProvider": "jira-legacy",
   "requirementsProviderConfig": {
     "jira-legacy": {
@@ -174,7 +264,7 @@ export async function configure(importFunction, global) {
     const vertexAi = await importFunction('@langchain/google-vertexai');
     return {
         llm: new vertexAi.ChatVertexAI({
-            model: "gemini-2.5-pro-exp-03-25"
+            model: "gemini-2.5-pro-preview-05-06"
         }),
         requirementsProvider: 'jira-legacy',
         requirementsProviderConfig: {
@@ -187,4 +277,3 @@ export async function configure(importFunction, global) {
     }
 }
 ```
-

package/docs/RELEASE-HOWTO.md

@@ -16,11 +16,17 @@ git push --tags
 
 Note the release version and do 
 ```shell
-gh release create --generate-notes
+gh release create --notes "notes"
 ```
 
 Publish to NPM
 ```shell
 npm login
 npm publish
+```
+
+Delete incidental remote and local tag
+```shell
+git push --delete v0.3.0
+git push --delete origin v0.3.0
 ```

package/eslint.config.js

@@ -1,38 +1,116 @@
-import js from "@eslint/js";
-import { defineConfig } from "eslint/config";
-import jasmine from "eslint-plugin-jasmine"
-import globals from "globals";
+import jsConfig from '@eslint/js';
+import { defineConfig } from 'eslint/config';
+import globals from 'globals';
+import tseslint from '@typescript-eslint/eslint-plugin';
+import tsParser from '@typescript-eslint/parser';
+import prettierConfig from 'eslint-config-prettier';
+import prettierPlugin from 'eslint-plugin-prettier';
+import path from 'path';
+import { fileURLToPath } from 'url';
 
-const { setTimeout, setInterval, clearInterval, Buffer, fetch } = globals.node;
+// Get the directory path of the current module
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+// Global ignores applied to all configurations
+const globalIgnores = ['**/node_modules/**', '**/dist/**', 'coverage/**', '.git/**'];
 
 export default defineConfig([
+  // Ignore files config - applies first
+  {
+    ignores: globalIgnores,
+  },
+  // Base configuration for all JavaScript files
   {
-    files: ["src/**/*.js"],
+    files: ['**/*.js'],
+    languageOptions: {
+      ecmaVersion: 2022,
+      sourceType: 'module',
+      globals: {
+        ...globals.node,
+      },
+    },
     plugins: {
-      js,
+      prettier: prettierPlugin,
     },
-    extends: ["js/recommended"],
     rules: {
-      semi: "error",
-      "eol-last": "error"
+      ...jsConfig.configs.recommended.rules,
+      ...prettierConfig.rules,
+      semi: 'error',
+      'eol-last': 'error',
+      'prettier/prettier': 'error',
+      'no-unused-vars': ['error', { argsIgnorePattern: '^_', varsIgnorePattern: '^_' }],
     },
+  },
+  // Source TypeScript files
+  {
+    files: ['src/**/*.ts'],
     languageOptions: {
+      parser: tsParser,
+      parserOptions: {
+        ecmaVersion: 2022,
+        sourceType: 'module',
+        project: path.resolve(__dirname, 'tsconfig.json'),
+      },
       globals: {
-        setTimeout,
-        setInterval,
-        clearInterval,
-        Buffer,
-        fetch
+        ...globals.node,
       },
     },
+    plugins: {
+      '@typescript-eslint': tseslint,
+      prettier: prettierPlugin,
+    },
+    rules: {
+      ...tseslint.configs.recommended.rules,
+      ...prettierConfig.rules,
+      semi: 'error',
+      'eol-last': 'error',
+      'prettier/prettier': 'error',
+      '@typescript-eslint/explicit-function-return-type': 'off',
+      '@typescript-eslint/no-explicit-any': 'warn',
+      '@typescript-eslint/no-unused-vars': [
+        'error',
+        { argsIgnorePattern: '^_', varsIgnorePattern: '^_', caughtErrorsIgnorePattern: '^_' },
+      ],
+    },
   },
+  // Test TypeScript files with separate project reference
   {
-    files: ["spec/**/*.js"],
-    plugins: { jasmine },
-    extends: ["jasmine/recommended"],
+    files: ['spec/**/*.ts', 'vitest.config.ts'],
+    languageOptions: {
+      parser: tsParser,
+      parserOptions: {
+        ecmaVersion: 2022,
+        sourceType: 'module',
+        // No project needed for tests to avoid parser errors
+      },
+      globals: {
+        ...globals.node,
+        describe: 'readonly',
+        it: 'readonly',
+        expect: 'readonly',
+        beforeEach: 'readonly',
+        afterEach: 'readonly',
+        vi: 'readonly',
+      },
+    },
+    plugins: {
+      '@typescript-eslint': tseslint,
+      prettier: prettierPlugin,
+    },
     rules: {
-      semi: "error",
-      "eol-last": "error",
-    }
+      ...tseslint.configs.recommended.rules,
+      ...prettierConfig.rules,
+      semi: 'error',
+      'eol-last': 'error',
+      'prettier/prettier': 'error',
+      '@typescript-eslint/explicit-function-return-type': 'off',
+      '@typescript-eslint/no-explicit-any': 'off', // Allow any in test files
+      '@typescript-eslint/no-unused-vars': [
+        'error',
+        { argsIgnorePattern: '^_', varsIgnorePattern: '^_' },
+      ], // Error for unused vars in tests
+      'no-unused-vars': ['error', { argsIgnorePattern: '^_', varsIgnorePattern: '^_' }], // For .js test files
+    },
   },
 ]);

package/gth-ASK-2025-05-16T14-11-39.md

@@ -0,0 +1,3 @@
+⚠️ Your input, consisting of a single hyphen ('-'), is ambiguous. To provide a correct and useful response, I require a more specific query.
+
+Please elaborate on how I may assist you.

package/gth-ASK-2025-05-16T14-18-27.md

@@ -0,0 +1,3 @@
+⚠️ Your input, consisting of a single hyphen ('-'), is ambiguous. To provide a correct and useful response, I require a more specific query.
+
+Please elaborate on how I may assist you.

package/gth-ASK-2025-05-16T14-18-56.md

@@ -0,0 +1 @@
+✅ Understood. I am ready for your programming-related inquiries. Please state your requirements.

package/gth-ASK-2025-05-16T14-41-20.md

@@ -0,0 +1,3 @@
+✅ Test acknowledged.
+
+Do you have a programming query or a code-related task for me?

package/gth-ASK-2025-05-16T14-43-31.md

@@ -0,0 +1,51 @@
+This `package.json` file is reasonably well-structured. I have a few observations:
+
+*   ✅ **`name`, `version`, `license`, `author`, `type`, `main`, `repository`**: These fields are correctly defined. Using `"type": "module"` is a modern choice.
+*   ✅ **`engines`**: Clearly specifies Node.js `>=22.0.0` and npm `>=10.9.0`. These are very recent versions, which is a deliberate choice that limits broader compatibility but ensures usage of newer features.
+*   ✅ **`scripts`**:
+    *   `build`, `lint`, `format`: Standard and appropriate.
+    *   `test`: `"npm run build && vitest run"` is good practice, ensuring tests run against the compiled output.
+    *   `prepare`: `"npm run build"` is also standard, ensuring the package is built after installation and before publishing.
+*   ✅ **`dependencies`** and **`devDependencies`**: The listed packages are appropriate for the described functionality (Langchain, CLI tools) and development (TypeScript, ESLint, Prettier, Vitest). Versions are up-to-date.
+*   ✅ **`imports`**: The subpath import `"#src/*.js": "./dist/*.js"` is a modern way to define internal package aliases.
+    *   ⚠️ For a smoother development experience with TypeScript, ensure your `tsconfig.json` has a corresponding `paths` alias, for example:
+        ```json
+        {
+          "compilerOptions": {
+            "baseUrl": ".", // Or "./src"
+            "paths": {
+              "#src/*": ["src/*"] // Or just "*" if baseUrl is "./src"
+            }
+          }
+        }
+        ```
+        This allows TypeScript to resolve `#src/...` imports to your source files during development and type-checking.
+
+Now, for more critical points:
+
+*   ❌ **`bin` configuration**:
+    ```json
+    "bin": {
+      "gsloth": "index.js",
+      "gth": "index.js"
+    }
+    ```
+    Your `main` field is `"dist/index.js"`, indicating that your compiled, runnable JavaScript code resides in the `dist` directory. However, your `bin` entries point to `index.js` in the project root.
+    If `index.js` in the root is your TypeScript source file (or does not exist), this will not work when the package is installed globally or used via `npx`. The `bin` entries should point to the executable JavaScript files generated by your build process.
+    Typically, this would be something like:
+    ```json
+    "bin": {
+      "gsloth": "dist/index.js", // Or a specific CLI entry point like "dist/cli.js"
+      "gth": "dist/index.js"    // Same here
+    }
+    ```
+    The target file (e.g., `dist/index.js` or `dist/cli.js`) must be executable and should start with a shebang line (e.g., `#!/usr/bin/env node`). If your main TypeScript entry point (e.g., `src/index.ts` or `src/cli.ts`) includes this shebang, `tsc` usually preserves it in the output JavaScript file.
+
+*   ⚠️ **`description`**: The `description` field is empty.
+    ```json
+    "description": "",
+    ```
+    Providing a concise description is highly recommended. It improves the package's discoverability on npm and helps users understand its purpose quickly.
+
+In summary:
+The most critical issue is the `bin` configuration, which likely needs to be updated to point to files within your `dist` directory. The empty `description` is a minor omission. The `imports` setup is good, but ensure your TypeScript configuration complements it for development.

package/gth-ASK-2025-05-16T16-05-52.md

@@ -0,0 +1,62 @@
+Okay, I've reviewed your `package.json` file. Here's my assessment:
+
+## `package.json` Review
+
+Overall, this `package.json` is well-structured and sets up a modern Node.js TypeScript project with appropriate tooling for LangChain/LangGraph development. However, there are a few points to address.
+
+### ✅ Positive Aspects
+
+*   **Modern Node.js Setup**:
+    *   `"type": "module"`: Correctly enables ES module syntax.
+    *   `"engines"`: Specifying Node.js (`>=22.0.0`) and npm (`>=10.9.0`) versions is good practice for ensuring environment compatibility.
+*   **Build and Development Scripts**:
+    *   `"build": "tsc"`: Standard TypeScript compilation.
+    *   `"test": "npm run build && vitest run"`: Ensures code is built before tests run. `vitest` is a good choice for a modern testing framework.
+    *   `"lint": "eslint . --ext .js,.ts"`: Proper linting setup.
+    *   `"format": "prettier --write 'src/**/*.{js,ts}'"`: Standard code formatting.
+    *   `"prepare": "npm run build"`: Excellent practice to ensure the project is built after installation, making it ready for use, especially if it's a library or a CLI tool.
+*   **Dependencies**:
+    *   The LangChain/LangGraph dependencies (`@langchain/anthropic`, `@langchain/core`, `@langchain/google-vertexai`, `@langchain/groq`, `@langchain/langgraph`) are correctly listed. Using `^` for versioning allows for non-breaking updates.
+    *   Utility dependencies like `chalk`, `commander`, and `uuid` are appropriate for a CLI/assistant type of project.
+*   **Dev Dependencies**:
+    *   A comprehensive set of development tools is included: TypeScript, ESLint (with TypeScript and Prettier plugins), Prettier, and type definitions (`@types/node`, `@types/uuid`).
+*   **Subpath Imports**:
+    *   `"imports": { "#src/*.js": "./dist/*.js" }`: This is a good use of Node.js subpath imports, allowing for cleaner import statements within your compiled code (e.g., `import ... from '#src/module.js'`).
+
+### ⚠️ Areas for Improvement / Potential Issues
+
+*   **Missing Description**:
+    *   The `"description"` field is empty. It's good practice to provide a brief description of your package. This is helpful for `npm search` and general understanding.
+    *   **Recommendation**: Add a concise description.
+*   **`globals` Dependency**:
+    *   The `globals` package is listed in `devDependencies`. While it can be used to define global variables for ESLint, modern ESLint configurations (especially with `@eslint/js` and `@typescript-eslint/parser`) often handle this directly within the ESLint configuration file (e.g., `env` or `globals` sections in `.eslintrc.js`).
+    *   **Recommendation**: Verify if this dependency is actively used and necessary. If your ESLint configuration handles globals sufficiently, this might be redundant.
+
+### ❌ Critical Issues
+
+*   **Incorrect `bin` Path(s)**:
+    *   The `"bin"` field defines CLI commands:
+        ```json
+        "bin": {
+          "gsloth": "index.js",
+          "gth": "index.js"
+        }
+        ```
+    *   However, your `"main"` field is `"dist/index.js"`, and your build script (`tsc`) compiles TypeScript from `src` to `dist`. This strongly suggests that the executable entry point for your CLI should be within the `dist` directory (likely `dist/index.js` or a specific CLI entry file in `dist`).
+    *   Pointing `bin` to `index.js` in the project root will either:
+        1.  Fail if `index.js` doesn't exist or isn't executable.
+        2.  Run the wrong (uncompiled or placeholder) code if an `index.js` exists in the root but isn't the intended compiled entry point.
+    *   **Recommendation**: Change the `bin` paths to point to the compiled JavaScript entry file. For example:
+        ```json
+        "bin": {
+          "gsloth": "dist/index.js",
+          "gth": "dist/index.js"
+        }
+        ```
+        Or, if you have a dedicated CLI entry point, adjust accordingly (e.g., `dist/cli.js`). Ensure the target file has a shebang (e.g., `#!/usr/bin/env node`) if it's meant to be directly executable.
+
+### Summary
+
+The `package.json` is largely well-configured for a TypeScript-based LangChain/LangGraph project. The most critical issue to address is the `bin` path configuration to ensure your CLI commands work correctly after installation. The other points are minor improvements.
+
+Please provide the actual code files (TypeScript/JavaScript) when you're ready for a review of the LangChain/LangGraph logic itself.

package/gth-DIFF-review-2025-05-16T16-07-53.md

@@ -0,0 +1,56 @@
+Greetings. I have reviewed the submitted diff. The changes introduce significant architectural improvements, enhance configuration flexibility, and refine the user experience.
+
+Here is my assessment:
+
+**Architectural and Flow Improvements:**
+*   ✅ The introduction of `src/llmUtils.ts` is a commendable refactoring. Centralizing the LangChain/LangGraph LLM invocation logic into a reusable `invoke` function simplifies the `questionAnsweringModule` and `reviewModule` considerably. This promotes the DRY principle and makes the core LLM interaction logic easier to manage and test.
+*   ✅ The use of `StateGraph`, `MessagesAnnotation`, and `MemorySaver` from `@langchain/langgraph` within `llmUtils.ts` is appropriate for managing the LLM interaction state.
+*   ✅ The separation of prompt concerns into distinct files (`.gsloth.backstory.md`, `.gsloth.guidelines.md`, `.gsloth.review.md`) and corresponding loader functions (`readBackstory`, `readGuidelines`, `readReviewInstructions`) in `src/prompt.ts` provides better organization and clarity for prompt engineering.
+*   ✅ Handling of standard input (`stdin`) has been cleanly moved to `src/systemUtils.ts` and cached, which is a more logical placement.
+
+**Configuration Enhancements:**
+*   ✅ The `SlothConfig` interface and default configurations in `src/config.ts` have been updated to include `projectGuidelines` and `projectReviewInstructions`. This allows for more tailored prompting.
+*   ✅ The type hint for the LLM instance in `SlothConfig` has been refined from `LanguageModelLike` to the more specific `BaseChatModel`.
+*   ✅ Documentation (`README.md`, `docs/CONFIGURATION.md`) and initialization logic (`initCommand`) have been updated to reflect the new configuration file names (e.g., `.gsloth.guidelines.md`).
+
+**Code Quality and Testing:**
+*   ✅ Test suites (`*.spec.ts`) have been diligently updated to reflect the refactoring. Mocks are handled more cleanly (e.g., top-level `vi.mock`), and tests cover the new `llmUtils.ts` and changes in existing modules.
+*   ✅ The new output file prefix `gth-` (e.g., `gth-ASK`, `gth-DIFF-review`) is consistently applied across the codebase and tests, and is now included in `.gitignore`.
+*   ✅ TypeScript types are used effectively, and improvements have been made (e.g., `BaseChatModel`).
+*   ✅ The new global `--verbose` option in `src/index.ts` for enabling detailed LLM prompt logging is a useful debugging feature.
+
+**User Experience:**
+*   ✅ The `ProgressIndicator` in `src/utils.ts` has been significantly improved. It now provides continuous feedback for long-running operations by default and includes a `stop()` method for clean termination. It also supports a manual indication mode.
+
+**Specific Feedback & Suggestions:**
+
+*   ⚠️ **Security Suggestion (Important):** In `src/commands/reviewCommand.ts`, there's a `TODO` comment regarding `prId` sanitization:
+    ```typescript
+    // src/commands/reviewCommand.ts
+    // ...
+    // TODO sanitize prId
+    await review(`gth-PR-${prId}-review`, systemMessage.join('\n'), content.join('\n'));
+    ```
+    If `prId` can be influenced by user input (e.g., from a command-line argument that might not be strictly numeric or could contain path characters), it's crucial to sanitize it before using it in a filename. This prevents potential path traversal or other file system vulnerabilities. Please ensure `prId` is appropriately validated or sanitized.
+
+*   ✅ **Refactoring of `reviewInner` and `askQuestionInner`:** The logic previously in these internal functions has been effectively moved to the generic `llmUtils.invoke` function. This is a good simplification.
+
+*   ✅ **File Reading Utilities:** The new `readFileFromCurrentOrInstallDir` utility in `src/utils.ts` is a good addition for robustly loading configuration/prompt files.
+
+*   ⚠️ **Nitpick (Minor):** In `src/modules/questionAnsweringModule.ts`, the comment:
+    ```typescript
+    // TODO highlight LLM output with something like Prism.JS (maybe system emoj are enough ????????????)
+    ```
+    The series of question marks makes it appear less formal than typical `TODO` comments. This is a minor point of style.
+
+**Overall:**
+
+The submitted changes are of high quality and represent a significant improvement in the codebase's structure, maintainability, and user experience. The refactoring to centralize LLM interaction is particularly noteworthy.
+
+---
+
+**Recommendation:**
+
+✅ **I recommend approving this PR.**
+
+The changes are largely excellent. The primary point to consider before merging is the `prId` sanitization mentioned above to ensure robustness against potentially malformed inputs. The other points are minor.