@eldrforge/ai-service 0.1.15 → 0.1.16

package/dist/index.js

@@ -1627,36 +1627,59 @@ async function runAgenticCommit(config) {
   };
 }
 function buildSystemPrompt$2(toolGuidance) {
-  return `You are an expert software engineer tasked with generating meaningful commit messages.
+  return `You are a professional software engineer writing commit messages for your team.
 
 ${toolGuidance}
 
-## Investigation Strategy
+## Your Task
 
-For simple changes (1-3 files, obvious purpose):
-- Use 1-2 tools: get_recent_commits to avoid duplicates, get_related_tests if logic changed
+Write a commit message that clearly explains what changed and why. Your message should help teammates understand the changes without needing to read the diff.
 
-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
+Think about:
+- What problem does this solve?
+- How do the changes work together?
+- What should reviewers focus on?
+- Are there any important implications?
 
-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
+Use the available tools to investigate the changes. The more you understand, the better your message will be.
 
-Always use tools to understand context - don't rely only on the diff.
+**Important**: If additional context is provided (from context files or other sources), use your judgment:
+- If the context is relevant to these specific changes, incorporate it
+- If the context describes unrelated changes or other packages, ignore it
+- Don't force connections between unrelated information
+- Focus on accurately describing what actually changed in this commit
 
-## Guidelines
-- Follow conventional commit format when appropriate (feat:, fix:, refactor:, docs:, test:, chore:)
-- Consider suggesting split commits for unrelated changes
-- 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
+## Investigation Approach
 
-Output format:
-When you're ready to provide the final commit message, format it as:
+Use tools based on what you need to know:
+- group_files_by_concern - understand how files relate
+- get_file_content - see full context when diffs are unclear
+- get_file_history - understand how code evolved
+- get_file_dependencies - assess impact of changes
+- get_recent_commits - avoid duplicate messages
+- get_related_tests - understand behavior changes
+- search_codebase - find usage patterns
+
+## Writing Style
+
+Write naturally and directly:
+- Use plain language, not corporate speak
+- Be specific and concrete
+- Avoid buzzwords and jargon
+- No emojis or excessive punctuation
+- No phrases like "this commit" or "this PR"
+- No meta-commentary about the commit itself
+
+Follow conventional commit format when appropriate (feat:, fix:, refactor:, docs:, test:, chore:), but prioritize clarity over formality.
+
+## Output Format
+
+When ready, format your response as:
 
 COMMIT_MESSAGE:
-[Your generated commit message here]
+[Your commit message here]
 
-If you recommend splitting into multiple commits, also include:
+If changes should be split into multiple commits:
 
 SUGGESTED_SPLITS:
 Split 1:
@@ -1667,7 +1690,7 @@ Message: [commit message for this split]
 Split 2:
 ...
 
-If changes should remain as one commit, do not include SUGGESTED_SPLITS section.`;
+Output only the commit message and splits. No conversational remarks or follow-up offers.`;
 }
 function buildUserMessage$1(changedFiles, diffContent, userDirection, logContext) {
   let message = `I have staged changes that need a commit message.
@@ -1690,9 +1713,16 @@ ${logContext}`;
   }
   message += `
 
-Please investigate these changes and generate an appropriate commit message.
-Use the available tools to gather additional context as needed.
-If these changes should be split into multiple commits, suggest the groupings.`;
+Analyze these changes and write a clear commit message. Consider:
+- What problem does this solve?
+- How do the changes work together?
+- Should this be one commit or multiple?
+
+If context information is provided, use it only if relevant to these specific changes.
+Don't force connections that don't exist - if context doesn't apply to this package,
+simply ignore it and focus on the actual changes.
+
+Investigate as needed to write an accurate, helpful message.`;
   return message;
 }
 function parseAgenticResult$1(finalMessage) {
@@ -2455,56 +2485,79 @@ async function runAgenticRelease(config) {
   };
 }
 function buildSystemPrompt$1(toolGuidance) {
-  return `You are an expert software engineer and technical writer tasked with generating comprehensive, thoughtful release notes.
+  return `You are a professional software engineer writing release notes for your team and users.
 
 ${toolGuidance}
-- 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
+## Your Task
+
+Write release notes that clearly explain what's in this release and why it matters. Your notes should help users and developers understand what changed without needing to read every commit.
+
+Focus on:
+- What problems does this release solve?
+- What new capabilities does it add?
+- What's the impact on users and developers?
+- Are there breaking changes or important considerations?
 
-**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
+Use the available tools to investigate the changes. The more you understand, the better your notes will be.
 
-**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
+**Important**: If additional context is provided (from context files or other sources), use your judgment:
+- If the context is relevant to this specific package/release, incorporate it appropriately
+- If the context describes changes in other packages or unrelated work, ignore it
+- Don't fabricate connections between this package and unrelated context
+- Be honest about what changed - only mention what actually happened in this release
+- Context is supplemental information, not a requirement to include
 
-## Your Investigation Strategy
+## Investigation Approach
 
-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
+Use tools based on what you need to know:
 
-Use at least 6-8 tools per release to ensure comprehensive analysis. Each tool provides a different lens on the changes.
+**Context:**
+- get_tag_history - understand release patterns
+- get_release_stats - quantify scope
+- compare_previous_release - see how this compares
 
-Output format:
-When you're ready to provide the final release notes, format them as JSON:
+**Understanding:**
+- group_files_by_concern - identify themes
+- analyze_commit_patterns - detect patterns
+- get_file_content - see full context
+- analyze_diff_section - expand unclear changes
+- get_file_history - understand evolution
+
+**Impact:**
+- get_file_dependencies - assess reach
+- search_codebase - find usage patterns
+- get_related_tests - understand behavior changes
+- get_breaking_changes - identify breaking changes (always use)
+
+## Writing Style
+
+Write naturally and directly:
+- Use plain language that users can understand
+- Be specific about what changed and why
+- Avoid marketing speak and buzzwords
+- No emojis or excessive punctuation
+- No phrases like "we're excited to announce"
+- No meta-commentary about the release itself
+- Focus on facts and implications, not enthusiasm
+
+Structure your notes logically:
+- Start with the most important changes
+- Group related changes together
+- Explain breaking changes clearly
+- Include practical examples when helpful
+
+## Output Format
+
+When ready, format your response as JSON:
 
 RELEASE_NOTES:
 {
-  "title": "A concise, single-line title capturing the most significant changes",
-  "body": "The detailed release notes in Markdown format, following best practices for structure, depth, and analysis"
-}
-
-The release notes should:
-- Demonstrate genuine understanding of the changes
-- Provide context and explain implications
-- 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 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`;
+  "title": "Clear, factual title describing the main changes",
+  "body": "Detailed release notes in Markdown format"
+}
+
+Output only the JSON. No conversational remarks or follow-up offers.`;
 }
 function buildUserMessage(params) {
   const { fromRef, toRef, logContent, diffContent, milestoneIssues, releaseFocus, userContext } = params;
@@ -2537,15 +2590,17 @@ ${userContext}`;
   }
   message += `
 
-Please investigate these changes thoroughly and generate comprehensive release notes that:
-1. Demonstrate deep understanding of what changed and why
-2. Provide context about how changes relate to each other
-3. Explain implications for users and developers
-4. Connect this release to previous releases and project evolution
-5. Identify any breaking changes or significant architectural shifts
-6. Follow best practices for technical writing and release notes
+Analyze these changes and write clear release notes. Consider:
+- What's the main story of this release?
+- What problems does it solve?
+- What's the impact on users and developers?
+- Are there breaking changes?
+
+If context information is provided, use it only if relevant to this specific package.
+Don't force connections that don't exist - if context describes changes in other packages
+or unrelated features, simply ignore it and focus on what actually changed in this release.
 
-Use the available tools to gather additional context as needed. Take your time to understand the changes deeply before writing the release notes.`;
+Investigate as needed to write accurate, helpful release notes.`;
   return message;
 }
 function parseAgenticResult(finalMessage) {