@eldrforge/ai-service 0.1.13 → 0.1.14

package/dist/index.js

@@ -1136,7 +1136,7 @@ function createGetFileHistoryTool$1() {
 function createGetFileContentTool$1() {
   return {
     name: "get_file_content",
-    description: "Get the complete current content of a file to understand context around changes",
+    description: "Get the complete current content of a file to understand context around changes. Returns a message if the file does not exist (e.g., if it was deleted).",
     parameters: {
       type: "object",
       properties: {
@@ -1166,6 +1166,11 @@ function createGetFileContentTool$1() {
         }
         return content;
       } catch (error) {
+        if (error.code === "ENOENT" || error.message?.includes("ENOENT")) {
+          return `File not found: ${filePath}
+
+This file may have been deleted in this release or does not exist in the current working tree. Check the diff to see if this file was removed.`;
+        }
         throw new Error(`Failed to read file: ${error.message}`);
       }
     }
@@ -1207,7 +1212,7 @@ function createSearchCodebaseTool$1() {
         const output = await run(command, { cwd: workingDir });
         return output.stdout || "No matches found";
       } catch (error) {
-        if (error.message.includes("exit code 1")) {
+        if (error.message.includes("exit code 1") || error.stderr?.includes("did not match any file")) {
           return "No matches found";
         }
         throw new Error(`Search failed: ${error.message}`);
@@ -1494,29 +1499,42 @@ async function runAgenticCommit(config) {
 function buildSystemPrompt$1() {
   return `You are an expert software engineer tasked with generating meaningful commit messages.
 
-You have access to tools that let you investigate changes in detail:
-- get_file_history: View commit history for files
-- get_file_content: Read full file contents
-- search_codebase: Search for patterns across the codebase
-- get_related_tests: Find test files related to changes
-- get_file_dependencies: Understand file dependencies and imports
-- analyze_diff_section: Get expanded context around specific changes
-- get_recent_commits: See recent commits to the same files
-- group_files_by_concern: Suggest logical groupings of changed files
+You have access to tools to understand changes deeply. Use them strategically based on what you see:
+
+## When to Use Each Tool
+
+**Understanding What Changed:**
+- get_file_content: Use when you need full context. Good for: seeing entire class/function being modified, checking imports, understanding overall structure
+- analyze_diff_section: Use when diff is confusing. Good for: expanding context around small changes, seeing how code integrates
+- get_file_dependencies: Use for import/refactor changes. Good for: understanding what's being moved/reorganized, checking dependency impact
+
+**Understanding Why:**
+- get_file_history: Use to see evolution. Good for: understanding if this continues previous work, checking for patterns
+- get_recent_commits: Use to check recent context. Good for: avoiding duplicate messages, understanding if this is part of a series
+- search_codebase: Use to understand usage. Good for: seeing if changes affect multiple places, finding patterns
+
+**Organizing Changes:**
+- group_files_by_concern: Use when multiple files changed. Good for: identifying logical groupings, determining if split is needed
+- get_related_tests: Use for logic changes. Good for: understanding intent from test changes, verifying behavior changes
+
+## Investigation Strategy
+
+For simple changes (1-3 files, obvious purpose):
+- Use 1-2 tools: get_recent_commits to avoid duplicates, get_related_tests if logic changed
+
+For moderate changes (4-10 files, clear theme):
+- Use 2-4 tools: group_files_by_concern, get_file_content for key files, get_recent_commits, get_related_tests
 
-Your process should be:
-1. Analyze the changed files and diff to understand the scope
-2. Use tools to investigate specific changes that need more context
-3. Identify if changes represent one cohesive commit or multiple logical commits
-4. Generate a commit message (or multiple if splits suggested) that accurately describes changes
+For complex changes (10+ files, or unclear purpose):
+- Use 4-6 tools: group_files_by_concern, get_file_history, get_file_content for key files, get_file_dependencies, get_related_tests, search_codebase
 
-Guidelines:
-- Use tools strategically - don't call every tool on every file
-- Look at test changes to understand intent
-- Check recent history to avoid redundant messages
+Always use tools to understand context - don't rely only on the diff.
+
+## Guidelines
+- Follow conventional commit format when appropriate (feat:, fix:, refactor:, docs:, test:, chore:)
 - Consider suggesting split commits for unrelated changes
-- Synthesize findings into clear, informative commit messages
-- Follow conventional commit format when appropriate (feat:, fix:, refactor:, etc.)
+- Output only the commit message and/or splits - no conversational remarks
+- NEVER include phrases like "If you want" or "Let me know" or offer follow-up actions
 
 Output format:
 When you're ready to provide the final commit message, format it as:
@@ -1645,7 +1663,7 @@ function createGetFileHistoryTool() {
 function createGetFileContentTool() {
   return {
     name: "get_file_content",
-    description: "Get the complete current content of a file to understand context around changes",
+    description: "Get the complete current content of a file to understand context around changes. Returns a message if the file does not exist (e.g., if it was deleted).",
     parameters: {
       type: "object",
       properties: {
@@ -1675,6 +1693,11 @@ function createGetFileContentTool() {
         }
         return content;
       } catch (error) {
+        if (error.code === "ENOENT" || error.message?.includes("ENOENT")) {
+          return `File not found: ${filePath}
+
+This file may have been deleted in this release or does not exist in the current working tree. Check the diff to see if this file was removed.`;
+        }
         throw new Error(`Failed to read file: ${error.message}`);
       }
     }
@@ -1716,7 +1739,7 @@ function createSearchCodebaseTool() {
         const output = await run(command, { cwd: workingDir });
         return output.stdout || "No matches found";
       } catch (error) {
-        if (error.message.includes("exit code 1")) {
+        if (error.message.includes("exit code 1") || error.stderr?.includes("did not match any file")) {
           return "No matches found";
         }
         throw new Error(`Search failed: ${error.message}`);
@@ -2292,38 +2315,40 @@ async function runAgenticRelease(config) {
 function buildSystemPrompt() {
   return `You are an expert software engineer and technical writer tasked with generating comprehensive, thoughtful release notes.
 
-You have access to tools that let you investigate the release in detail:
-- get_file_history: View commit history for specific files
-- get_file_content: Read full file contents to understand context
-- search_codebase: Search for patterns across the codebase
-- get_related_tests: Find test files to understand functionality
-- get_file_dependencies: Understand file dependencies and impact
-- analyze_diff_section: Get expanded context around specific changes
-- get_recent_commits: See recent commits to the same files
-- group_files_by_concern: Identify logical groupings of changes
-- get_tag_history: View previous release tags and patterns
-- compare_previous_release: Compare with previous releases
-- get_release_stats: Get comprehensive statistics about the release
-- get_breaking_changes: Identify potential breaking changes
-- analyze_commit_patterns: Identify themes and patterns in commits
+You have access to tools to investigate the release in depth. Use them strategically:
+
+## Investigation Tools
+
+**Understanding Context & History:**
+- get_file_history: Use when you need to understand how a file evolved. Good for: seeing if a refactor is part of a larger pattern, understanding why certain decisions were made
+- get_recent_commits: Use to see what happened to files recently. Good for: detecting related work, understanding if this is part of an ongoing effort
+- compare_previous_release: Use to contextualize scope. Good for: comparing size/impact of this release vs previous ones, identifying if this is major/minor
+- get_tag_history: Use early to understand release cadence. Good for: establishing context about project versioning patterns
+
+**Analyzing Current Changes:**
+- get_file_content: Use when diff alone isn't enough. Good for: understanding APIs, seeing full class/function context, checking imports
+- analyze_diff_section: Use to expand context around cryptic changes. Good for: seeing surrounding code, understanding integration points
+- get_file_dependencies: Use for refactors/moves. Good for: assessing impact scope, identifying what depends on changed code
+- search_codebase: Use to find usage patterns. Good for: checking if APIs are widely used, finding similar patterns elsewhere
+
+**Pattern Recognition:**
+- group_files_by_concern: Use when many files changed. Good for: organizing changes into logical themes, identifying what actually happened
+- analyze_commit_patterns: Use for many commits. Good for: detecting themes across commits, identifying if work is focused or scattered
+- get_release_stats: Use to quantify scope. Good for: getting concrete metrics on scale of changes
+
+**Risk Assessment:**
+- get_breaking_changes: Always use. Good for: identifying API changes, finding removals/signature changes that could break users
+- get_related_tests: Use for significant logic changes. Good for: understanding what behavior changed, verifying test coverage exists
+
+## Your Investigation Strategy
 
-Your process should be:
-1. Analyze the commit log and diff to understand the overall scope of changes
-2. Use tools strategically to investigate significant changes that need more context
-3. Look at previous releases to understand how this release fits into the project's evolution
-4. Identify patterns, themes, and connections between changes
-5. Check for breaking changes and significant architectural shifts
-6. Understand the "why" behind changes by examining commit messages, issues, and code
-7. Synthesize findings into comprehensive, thoughtful release notes
+1. **Start broad** (2-3 tools): get_tag_history, get_release_stats, analyze_commit_patterns
+2. **Identify themes** (1-2 tools): group_files_by_concern if many files, compare_previous_release for context
+3. **Deep dive** (3-5 tools): get_file_content for key changes, get_file_dependencies for refactors, analyze_diff_section for unclear changes
+4. **Verify understanding** (2-3 tools): get_related_tests for logic changes, search_codebase for impact
+5. **Check risks** (1 tool): get_breaking_changes always
 
-Guidelines:
-- Use tools strategically - focus on understanding significant changes
-- Look at test changes to understand intent and functionality
-- Check previous releases to provide context and compare scope
-- Identify patterns and themes across multiple commits
-- Consider the audience and what context they need
-- Be thorough and analytical, especially for large releases
-- Follow the release notes format and best practices provided
+Use at least 6-8 tools per release to ensure comprehensive analysis. Each tool provides a different lens on the changes.
 
 Output format:
 When you're ready to provide the final release notes, format them as JSON:
@@ -2340,7 +2365,11 @@ The release notes should:
 - Connect related changes to reveal patterns
 - Be substantial and analytical, not formulaic
 - Sound like they were written by a human who studied the changes
-- Be grounded in actual commits and issues (no hallucinations)`;
+- Be grounded in actual commits and issues (no hallucinations)
+- Be standalone documentation that can be published as-is
+- NEVER include conversational elements like "If you want, I can also..." or "Let me know if..."
+- NEVER offer follow-up actions, questions, or suggestions for additional work
+- End with substantive content, not conversational closing remarks`;
 }
 function buildUserMessage(params) {
   const { fromRef, toRef, logContent, diffContent, milestoneIssues, releaseFocus, userContext } = params;