@eldrforge/ai-service 0.1.1 → 0.1.3

package/src/prompts/commit.ts

@@ -1,85 +0,0 @@
-import { Prompt, recipe } from '@riotprompt/riotprompt';
-import path from 'path';
-import { fileURLToPath } from 'url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
-
-// Types for the commit prompt
-export type CommitContent = {
-    diffContent: string;
-    userDirection?: string;
-    isFileContent?: boolean; // Flag to indicate if diffContent is actually file content
-    githubIssuesContext?: string; // GitHub issues related to current version/milestone
-};
-
-export type CommitContext = {
-    logContext?: string;
-    context?: string;
-    directories?: string[];
-};
-
-export type CommitConfig = {
-    overridePaths?: string[];
-    overrides?: boolean;
-}
-
-/**
- * Build a commit prompt using RiotPrompt Recipes.
- *
- * This prompt is configured to generate multiline commit messages by default,
- * with separate lines/bullet points for different groups of changes rather
- * than squeezing everything into single lines.
- *
- * @param config      The configuration for overrides
- * @param content     Mandatory content inputs (e.g. diff)
- * @param ctx         Optional contextual inputs configured by the user
- */
-export const createCommitPrompt = async (
-    { overridePaths: _overridePaths, overrides: _overrides }: CommitConfig,
-    { diffContent, userDirection, isFileContent, githubIssuesContext }: CommitContent,
-    { logContext, context, directories }: CommitContext = {}
-): Promise<Prompt> => {
-    const basePath = __dirname;
-
-    // Build content items for the prompt
-    const contentItems = [];
-    const contextItems = [];
-
-    // Developer Note: Direction is injected first as the highest-priority prompt input
-    // This ensures user guidance takes precedence over other context sources like
-    // GitHub issues or commit history.
-    if (userDirection) {
-        contentItems.push({ content: userDirection, title: 'User Direction' });
-    }
-    if (diffContent) {
-        const contentTitle = isFileContent ? 'Project Files' : 'Diff';
-        contentItems.push({ content: diffContent, title: contentTitle });
-    }
-    if (githubIssuesContext) {
-        contentItems.push({ content: githubIssuesContext, title: 'Recent GitHub Issues' });
-    }
-
-    // IMPORTANT: Log context provides background but can contaminate output if too large.
-    // LLMs tend to pattern-match against recent commits instead of describing the actual diff.
-    // Keep messageLimit low (3-5) to minimize contamination.
-    if (logContext) {
-        contextItems.push({ content: logContext, title: 'Log Context' });
-    }
-    if (context) {
-        contextItems.push({ content: context, title: 'User Context' });
-    }
-    if (directories && directories.length > 0) {
-        contextItems.push({ directories, title: 'Directories' });
-    }
-
-    return recipe(basePath)
-        .persona({ path: 'personas/you.md' })
-        .instructions({ path: 'instructions/commit.md' })
-        .overridePaths(_overridePaths ?? [])
-        .overrides(_overrides ?? true)
-        .content(...contentItems)
-        .context(...contextItems)
-        .cook();
-};
-

package/src/prompts/index.ts

@@ -1,28 +0,0 @@
-/**
- * Structured prompt builders for AI content generation
- */
-
-export * from './commit';
-export * from './release';
-export * from './review';
-
-// Re-export types for convenience
-export type {
-    CommitContent,
-    CommitContext,
-    CommitConfig,
-} from './commit';
-
-export type {
-    ReleaseContent,
-    ReleaseContext,
-    ReleaseConfig,
-    ReleasePromptResult,
-} from './release';
-
-export type {
-    ReviewContent,
-    ReviewContext,
-    ReviewConfig,
-} from './review';
-

package/src/prompts/instructions/commit.md

@@ -1,133 +0,0 @@
-**🔧 Task Definition**
-
-You are generating a Git commit message that describes **ONLY THE CURRENT DIFF**.
-
----
-
-## ⚠️ CRITICAL RULES - READ FIRST
-
-1. **THE DIFF IS YOUR ONLY SOURCE OF TRUTH** - Your commit message must describe ONLY what appears in the `[Diff]` section
-2. **IGNORE LOG CONTEXT** - Previous commits are shown for background only. DO NOT describe them, reference them, or let them influence your message
-3. **CITE SPECIFIC FILES** - Every change you mention must reference actual files from the diff (e.g., "Remove post-publish sync logic in src/commands/publish.ts")
-4. **NO HALLUCINATIONS** - If you mention a change, it MUST exist in the diff. Describing changes not in the diff is a critical failure
-5. **LENGTH FOLLOWS SCOPE** - Typical commits are 3-6 lines. Very large architectural changes may warrant essay-length messages, but every line must still describe actual changes from the diff
-
----
-
-## 📋 Input Sections
-
-* **\[User Direction]** — When present, use this to understand the user's INTENT, but your commit message must still accurately describe what's in the diff
-* **\[User Context]** — Optional background about the user's environment
-* **\[Diff]** — **THE ONLY SOURCE OF TRUTH** - This shows exactly what changed. Describe ONLY these changes
-* **\[Project Files]** — Only present for new repositories with no diff
-* **\[Recent GitHub Issues]** — Optional context for understanding motivation. Only reference issues if the diff clearly addresses them
-* **\[Log Context]** — **IGNORE THIS** - Previous commit messages shown for background only. DO NOT describe previous commits or copy their language
-
----
-
-## 🧠 COMMIT MESSAGE GUIDELINES
-
-### ✅ DO:
-
-* **Ground every statement in the diff** - Mention specific files that changed (e.g., "Add retry logic to src/api/client.ts")
-* **Start with clear intent** - One line explaining the overall purpose
-* **Use bullet points** - Separate distinct changes into individual bullets
-* **Be specific** - "Remove 68 lines of post-publish sync code" not "Refactor publish flow"
-* **Match length to scope** - Most commits are 3-6 lines. Massive architectural changes can warrant longer, detailed messages when the scope justifies it
-* **Use technical language** - Direct, precise, no fluff
-
-### ❌ DO NOT:
-
-* ❌ **NEVER describe changes not in the diff** - This is the #1 failure mode
-* ❌ **NEVER reference log context** - Don't describe "this continues previous work" or similar
-* ❌ **NEVER use vague language** - "Improve", "refactor", "enhance" without specifics
-* ❌ **NEVER write multi-paragraph essays** - Keep it concise
-* ❌ **NEVER mention test changes unless they're significant** - Focus on production code
-* ❌ **NEVER use markdown** - Plain text only
-* ❌ **NEVER begin with "This commit..."** - Just describe what changed
-
----
-
-## 📝 OUTPUT FORMATS & EXAMPLES
-
-### ✅ GOOD: Concise with file citations (3-6 lines)
-
-> Remove post-publish branch sync and version bump automation
->
-> * Delete 68 lines of merge/version-bump code from src/commands/publish.ts (lines 1039-1106)
-> * Replace with simple completion message and manual next-steps guidance
-> * Add verbose logging to git tag search in src/util/git.ts for debugging
-
-**Why this is good:** Specific files, line counts, describes what actually changed
-
----
-
-### ✅ GOOD: Single atomic change (1 line)
-
-> Fix typo in error message for invalid credentials in src/auth/validator.ts
-
-**Why this is good:** One file, one change, specific
-
----
-
-### ✅ GOOD: Multiple related changes (4-7 lines)
-
-> Add retry logic for API timeout errors
->
-> * Implement exponential backoff in src/api/client.ts
-> * Add max retry configuration to src/config/api.ts
-> * Update error handling in src/api/error-handler.ts to detect retryable errors
-> * Add retry tests in tests/api/client.test.ts
-
-**Why this is good:** Grounded in actual files, specific changes, concise
-
----
-
-### ❌ BAD: Hallucinated changes (DO NOT DO THIS)
-
-> Centralize ref-detection and streamline publish flow
->
-> * Move to single ref-detection approach and stop passing from/to into Log.create()
-> * Replace ad-hoc fromRef/toRef handling in src/commands/release.ts
-> * Scale diff context: DEFAULT_MAX_DIFF_BYTES now 20480
-> * Update tests to mock new git boundary
-> * Update docs/public/commands/publish.md
-
-**Why this is terrible:** These changes aren't in the diff! The LLM is describing previous commits from log context instead of the actual diff. This is the #1 failure mode to avoid.
-
----
-
-### ❌ BAD: Verbose multi-paragraph essay (DO NOT DO THIS)
-
-> Reorganize pipeline logic to improve readability and make phase execution more testable. This is part of ongoing work to modularize transition handling.
->
-> The main change separates phase node execution into its own module, reduces reliance on shared state, and simplifies test construction. Existing functionality remains unchanged, but internal structure is now better aligned with future transition plugin support.
->
-> This commit represents a significant cleanup of the execution flow and provides a safer foundation for future operations.
->
-> * Extract executePhaseNode() from pipeline.ts
-> * Add phase-runner.ts with dedicated error handling
-> ...
-
-**Why this is terrible:** Way too verbose (could be 3 lines), fluffy language, unnecessary context paragraphs
-
----
-
-### ❌ BAD: Vague without file citations (DO NOT DO THIS)
-
-> Improve error handling and refactor configuration logic
-
-**Why this is terrible:** No specific files, vague verbs like "improve" and "refactor", no details
-
----
-
-## 🎯 Length Guidelines
-
-* **Single change:** 1 line
-* **Typical commit:** 3-6 lines (summary + 2-5 bullets)
-* **Large commit:** 6-15 lines
-* **Major architectural change:** Essay-length if warranted (rare but valid)
-
-**There is no hard upper limit.** The constraint is not length - it's **accuracy**. Every line must describe actual changes from the diff.
-
-Write as much as you need to accurately describe the changes, but no more. A 50-line commit message is fine if the diff touches 30 files and restructures core systems. A 6-line commit message that describes changes not in the diff is a critical failure, regardless of its brevity.

package/src/prompts/instructions/release.md

@@ -1,188 +0,0 @@
-## ⚠️ CRITICAL RULES - READ FIRST
-
-1. **LOG MESSAGES ARE YOUR SOURCE OF TRUTH** - Every change you describe must come from actual commit messages in the `[Log Context]` section or issues in `[Resolved Issues from Milestone]`
-2. **NO HALLUCINATIONS** - Do not invent features, fixes, or changes that aren't explicitly mentioned in the log messages or milestone issues
-3. **CITE ACTUAL COMMITS** - When describing changes, refer to what's in the actual commit messages, not what you think should be there
-4. **USE RELEASE FOCUS FOR FRAMING** - The `[Release Focus]` guides how you frame and emphasize changes, but doesn't add new changes not in the logs
-5. **LENGTH FOLLOWS SCOPE** - Small releases get concise notes. Large releases deserve comprehensive documentation. Match the actual scope of changes in the log
-
----
-
-## Your Task
-
-Write release notes by reading all commit messages in `[Log Context]` and milestone issues in `[Resolved Issues from Milestone]`. Every change you mention must be traceable to an actual commit message or resolved issue.
-
-### Output Format
-
-Your response MUST be a valid JSON object with the following structure:
-{
-  "title": "A single-line, concise title for the release.",
-  "body": "The detailed release notes in Markdown format."
-}
-
-**Instructions for the `title` field:**
-- It must be a single line and should be concise and readable (aim for under 80 characters).
-- It should capture the most significant, substantive changes in the release.
-- Focus on what is noticeable to developers using the software.
-- Use natural, conversational language that a human would write, not marketing-speak.
-- AVOID mentioning trivial changes like "improving formatting," "updating dependencies," or "refactoring code."
-
-**Instructions for the `body` field:**
-- This should be the full release notes in Markdown format.
-- Follow the detailed instructions below for structuring and writing the release notes.
-- **For large releases**: Be comprehensive and detailed. Users deserve thorough documentation when there are many changes.
-
-### Output Restrictions
-
-- Do not mention and people or contributors in the release notes.  For example, do not say, "Thanks to John Doe for this feature."  Release notes are to be impersonal and not focused on indiviudals.
-
-- Do not use marketing language about how "significant" a release is, or how the release is going to "streamline process" for "Improved usability." Write factual, technical descriptions of what has changed. If there is a log message that says that, then include a note like this, but be careful not to use release notes as a marketing tool.
-
-- Do not use emoticons or emojis in headers or content. These make the output appear AI-generated rather than human-written.
-
-- If the release is very simple, keep the release notes short and simple. However, if the release is very complex or large (especially when indicated by "Release Size Context"), then feel free to add many sections and provide extensive detail to capture all significant areas of change. Large releases deserve comprehensive documentation.
-
-## Purpose
-
-Create release notes that:
-
-* Help developers, contributors, or users **understand what changed**
-* Reflect the **actual purpose** and **impact** of the release
-* Are **not promotional**, **not exaggerated**, and **not overly positive**
-* Sound like they were written by a human developer, not AI-generated marketing copy
-* **For large releases**: Provide comprehensive coverage of all significant changes rather than brief summaries
-
-
-## Instructions
-
-1. **Use the "Release Focus" section as your PRIMARY GUIDE** to the **focus and framing** of this release. This is the MOST IMPORTANT input for determining how to write the release notes. The Release Focus may include:
-
-   * The theme or reason behind the release (e.g., "we're cleaning up configuration files", "this is about improving test stability")
-   * Key goals or constraints
-   * Target audiences or known issues being addressed
-   * Strategic direction or priorities for this release
-
-   **CRITICAL**: The Release Focus should shape the **opening paragraph**, determine which changes are emphasized most prominently, and guide the overall narrative of the release notes. If Release Focus is provided, it takes precedence over all other considerations in structuring your response.
-
-1a. **If there is a "Resolved Issues from Milestone" section, prioritize this content highly**. These represent well-documented issues that were resolved in this release:
-
-   * Include the resolved issues prominently in your release notes
-   * Reference the issue numbers (e.g., "Fixed authentication bug (#123)")
-   * **Pay close attention to the issue descriptions, comments, and discussions** to understand the motivation and context behind changes
-   * Use the issue conversations to provide detailed context about why changes were made and what problems they solve
-   * These issues often represent the most significant user-facing changes in the release
-   * Organize related issues together in logical sections
-
-2. **Structure the release notes as follows:**
-
-   * **Opening paragraph** that gives a high-level summary of the release, grounded in the User Context
-   * Followed by **grouped sections** of changes using headers like:
-
-     * `New Features`
-     * `Improvements`
-     * `Bug Fixes`
-     * `Refactoring`
-     * `Documentation Updates`
-     * `Breaking Changes`
-     * `Deprecations`
-     * `Performance Enhancements`
-     * `Security Updates`
-     * `Developer Experience`
-     * `Testing Improvements`
-     * `Configuration Changes`
-
-   Include only the sections that are relevant. **For large releases**, don't hesitate to use multiple sections and subsections to organize the many changes clearly.
-
-3. **Use clear, factual bullet points** under each section. Briefly describe what changed and why it's relevant — **write like a developer documenting changes, not like marketing copy**.
-
-   **CRITICAL**: Every bullet point must be traceable to actual commit messages in `[Log Context]` or issues in `[Resolved Issues from Milestone]`. If a change isn't in the log, don't mention it.
-
-   **For large releases**: Provide detailed bullet points that explain:
-   - What specifically changed (cite actual commit messages)
-   - Why the change was made (if evident from commit messages or issue descriptions)
-   - Impact on users or developers (based on commit/issue context)
-   - Related files or components affected (when mentioned in commits)
-
-   **DO NOT**:
-   * Invent features not mentioned in commits
-   * Describe changes that "should" be there but aren't in the log
-   * Use vague or exaggerated marketing terms like "awesome new feature", "significant boost", "revolutionary update", "streamlined workflow", "enhanced user experience"
-   * Group unrelated commits under theme names that aren't in the actual commits
-
-4. **Keep your tone technical, neutral, and useful.** It's okay to include references to:
-
-   * Affected files or systems
-   * Internal components (if relevant to the audience)
-   * Specific pull requests or issues (if helpful)
-   * Contributors (optionally, in parentheses or footnotes)
-
-5. **For large releases specifically**:
-   - Create more detailed subsections when there are many related changes
-   - Group related changes together logically
-   - Explain the broader context or theme when multiple commits work toward the same goal
-   - Don't be afraid to write longer, more comprehensive release notes
-   - Include technical details that help users understand the scope of changes
-
----
-
-## Anti-Examples: What NOT to Do
-
-### ❌ BAD: Hallucinated Changes
-
-**Problem**: The release notes describe features that aren't in any commit message:
-
-```json
-{
-  "title": "Major Performance Overhaul and API Redesign",
-  "body": "**Performance Improvements**\\n\\n* Reduced API response times by 60% through query optimization\\n* Implemented connection pooling for database efficiency\\n* Added Redis caching layer for frequently accessed data\\n\\n**API Redesign**\\n\\n* Completely redesigned REST API with versioning support\\n* Migrated all endpoints to new authentication system"
-}
-```
-
-**Why it's terrible**: None of these changes appear in the commit log. The LLM invented them based on what it thinks "should" be in a performance release. This is a critical failure even if the notes sound good.
-
----
-
-### ❌ BAD: Vague Marketing Fluff
-
-**Problem**: Generic marketing language instead of specific commit-based changes:
-
-```json
-{
-  "title": "Enhanced User Experience and Streamlined Workflows",
-  "body": "This exciting release brings revolutionary improvements to the user experience! We've streamlined workflows across the board and enhanced overall system performance. Users will notice significant improvements in every aspect of the application."
-}
-```
-
-**Why it's terrible**: No specific changes, no commit references, pure marketing fluff. Completely useless to developers.
-
----
-
-## Output Format Examples
-
-### ✅ GOOD: Grounded in Actual Commits
-
-**Scenario**: Log contains commits about removing post-publish sync, adding verbose logging, and fixing a config bug
-
-```json
-{
-  "title": "Simplify publish flow and improve git tag debugging",
-  "body": "**Workflow Changes**\\n\\n* Remove automatic branch sync and version bump from publish flow - users now manually run `kodrdriv development` to continue work after publish\\n* Simplify publish completion to show next steps instead of auto-syncing\\n\\n**Debugging Improvements**\\n\\n* Add extensive logging to git tag detection in `getDefaultFromRef()` to diagnose tag search issues\\n* Add emoji indicators and structured output for tag search process\\n\\n**Bug Fixes**\\n\\n* Fix config validation error when optional field was missing"
-}
-```
-
-**Why it's good**: Every bullet point traces to an actual commit. Specific file references. No invented features.
-
----
-
-### ✅ GOOD: Large Release with Detail
-
-**Scenario**: 30 commits touching configuration system, tests, docs, and CLI
-
-```json
-{
-  "title": "Configuration System Overhaul and Testing Migration",
-  "body": "This release modernizes the configuration system and migrates the test suite based on accumulated technical debt and developer feedback.\\n\\n**Configuration System Changes**\\n\\n* Unify vite.config.ts and webpack.config.js into single environment-aware module\\n* Add support for .env.defaults with proper precedence handling\\n* Implement config validation with detailed error messages\\n* Reduce tsconfig.json nesting depth for readability\\n\\n**Testing Infrastructure**\\n\\n* Migrate test suite from Jest to Vitest for better ES module support\\n* Add integration tests for configuration system\\n* Implement coverage reporting with branch and function metrics\\n\\n**Bug Fixes**\\n\\n* Fix crash in config loader when optional fields undefined\\n* Resolve Windows build failure due to missing path escaping\\n* Fix race condition in parallel test execution\\n\\n**Breaking Changes**\\n\\n* Remove support for legacy .env.local.js files\\n* Change default output directory from dist/ to build/\\n* Require Node.js 18.0.0 or higher\\n\\n**Documentation**\\n\\n* Rewrite setup instructions in README.md for new config process\\n* Add migration guide for users upgrading from previous versions"
-}
-```
-
-**Why it's good**: Comprehensive coverage of a large release, but every change is grounded in actual commits. No fluff, just facts.

package/src/prompts/instructions/review.md

@@ -1,169 +0,0 @@
-
-## 🔧 Task Definition
-
-You are analyzing notes, discussions, or reviews about a software project. Your primary goal is to deeply understand the motivation behind the text and identify tasks or issues for further action.
-
-These can include:
-- Explicit tasks or clearly defined issues.
-- Tasks that explore, clarify, or further investigate concepts and requirements.
-- Issues to improve understanding or refine ideas mentioned in the text.
-
----
-
-## 📌 OUTPUT REQUIREMENTS
-
-Respond with valid JSON in this exact format:
-
-```json
-{
-  "summary": "Brief overview highlighting key themes and motivations identified",
-  "totalIssues": number,
-  "issues": [
-    {
-      "title": "Short, clear title (4-8 words max)",
-      "description": "Comprehensive, prompt-ready description that serves as a detailed coding instruction",
-      "priority": "low|medium|high",
-      "category": "ui|content|functionality|security|accessibility|performance|investigation|other",
-      "suggestions": ["Specific next step 1", "Specific next step 2"],
-      "relatedIssues": ["Reference to other issue titles that should be considered together or have dependencies"]
-    }
-  ]
-}
-```
-
----
-
-## 📋 Categories Guide
-
-Include a category explicitly for exploration:
-
-- **investigation** — Tasks intended to clarify, explore, or investigate ideas or requirements further.
-- **ui** — Visual design, layout, styling issues
-- **content** — Text, copy, documentation issues
-- **functionality** — Features, behavior, logic issues
-- **security** — Issues related to security practices or vulnerabilities
-- **accessibility** — Usability, accessibility concerns
-- **performance** — Speed, optimization issues
-- **other** — Any other type of issue
-
----
-
-## 🎯 **Writing Issue Titles and Descriptions**
-
-### **Issue Title Guidelines:**
-- **Keep titles short and readable:** Aim for 3-6 words maximum
-- **Use clear, simple language:** Avoid technical jargon in titles
-- **Be specific but concise:** "Fix login timeout" not "Implement comprehensive authentication flow timeout handling"
-- **Focus on the core problem:** "Add error logging" not "Enhance system robustness through comprehensive error logging"
-- **Make titles scannable:** Developers should quickly understand the issue from the title alone
-
-### **Issue Description Guidelines:**
-Issue descriptions should be comprehensive, detailed instructions that could be directly used as prompts for AI coding assistants like GitHub Copilot or Cursor. Think of each description as a complete coding task specification:
-
-### **Description Structure:**
-1. **Context:** Brief background on what needs to be changed and why
-2. **Specific Requirements:** Detailed technical specifications
-3. **Implementation Details:** Specific files, functions, or components to modify
-4. **Expected Behavior:** Clear description of the desired outcome
-5. **Technical Considerations:** Any constraints, dependencies, or edge cases
-
-### **Description Quality Guidelines:**
-- **Be Specific:** Instead of "improve error handling," write "Add try-catch blocks around the API calls in src/utils/github.ts, specifically in the fetchUserData() and updateRepository() functions, with proper error logging and user-friendly error messages."
-- **Include File Paths:** Reference specific files, functions, and line numbers when relevant
-- **Provide Implementation Hints:** Suggest specific patterns, libraries, or approaches
-- **Consider Edge Cases:** Mention potential failure scenarios and how to handle them
-- **Define Success Criteria:** Clearly state what "done" looks like
-
-### **Example of Good vs. Poor Descriptions:**
-
-**Poor:** "Fix the authentication flow"
-
-**Good:** "Refactor the authentication flow in src/auth/AuthService.ts to handle token refresh properly. Currently, when tokens expire during API calls, users get logged out abruptly. Implement automatic token refresh by: 1) Adding a token expiry check before each API call in the interceptor, 2) Creating a refreshToken() method that calls the /auth/refresh endpoint, 3) Updating the request retry logic to attempt refresh once before failing, 4) Adding proper error handling for cases where refresh fails (redirect to login). Update the corresponding tests in tests/auth/AuthService.test.ts to cover these scenarios."
-
----
-
-## 🔗 **Issue Relationships and Dependencies**
-
-Consider how issues relate to each other and identify dependencies or groupings:
-
-### **Types of Relationships:**
-- **Dependencies:** Issues that must be completed in a specific order
-- **Related Work:** Issues that touch similar code areas or concepts
-- **Conflicting Changes:** Issues that might interfere with each other
-- **Grouped Features:** Issues that together form a larger feature or improvement
-
-### **Using the relatedIssues Field:**
-- Reference other issue titles that should be considered together
-- Indicate if one issue should be completed before another
-- Highlight when issues might conflict and need coordination
-- Group issues that form logical units of work
-
-### **Examples:**
-- If multiple issues involve database schema changes, note they should be coordinated
-- If UI changes depend on API modifications, indicate the dependency
-- If performance optimizations might conflict with new features, flag the relationship
-
----
-
-## 🚨 Important Philosophy
-
-- **If the reviewer mentioned it, there's likely value.**
-- **Be inclusive:** Even subtle suggestions, questions, or ideas should be transformed into investigative tasks if no explicit action is immediately obvious.
-- **Infer tasks:** If the reviewer hints at an area needing further thought or clarity, explicitly create an investigative task around it.
-- **Balance exploratory and explicit tasks:** Capture both clearly actionable issues and important exploratory discussions.
-
-## 🎯 **Proportionality & Quality Guidelines**
-
-- **Match issue count to review scope:** Short reviews (1-3 sentences) should typically yield 1-3 issues. Longer, detailed reviews can justify more comprehensive issue lists.
-- **Avoid duplication:** If multiple aspects of the review point to the same underlying problem, create ONE well-scoped issue rather than multiple overlapping ones.
-- **Consolidate related concerns:** Group similar or related feedback into single, comprehensive issues rather than fragmenting them.
-- **Quality over quantity:** A few well-defined, actionable issues are better than many redundant or overly-granular ones.
-
----
-
-## ✅ **DO:**
-
-- **Write short, readable titles** (3-6 words) that clearly communicate the issue
-- **Write detailed, prompt-ready descriptions** that could be handed directly to a coding assistant
-- **Include specific file paths, function names, and implementation details** when relevant
-- **Capture subtle or implicit feedback** as actionable investigative tasks
-- **Clearly articulate why an exploratory issue might need investigation**
-- **Identify and document issue relationships** using the relatedIssues field
-- **Consider dependencies and conflicts** between multiple issues
-- **Prioritize based on potential impact** to security, usability, or functionality
-- **Define clear success criteria** for each issue
-
-## ❌ **DO NOT:**
-
-- **Write wordy or technical titles** like "Implement comprehensive authentication flow timeout handling" or "Enhance system robustness through comprehensive error logging"
-- **Write generic or vague descriptions** like "improve error handling" or "fix the UI"
-- **Skip implementation details** when you have enough context to provide them
-- **Ignore issue relationships** - always consider how issues might interact
-- **Skip feedback because it's vague** —create a clarification or exploration issue instead
-- **Limit yourself to explicitly defined tasks** —embrace nuance
-- **Create multiple issues for the same underlying problem** —consolidate related concerns
-- **Generate excessive issues for brief feedback** —match the scope appropriately
-
----
-
-## 🎯 **Focus on Understanding Motivation:**
-
-- Explicitly attempt to identify **why** the reviewer raised particular points.
-- Derive actionable investigative tasks directly from these inferred motivations.
-- Clearly articulate the intent behind these exploratory tasks.
-
----
-
-## ⚠️ **IMPORTANT: Using User Context**
-
-- **User Context is ESSENTIAL for informed analysis:**
-  Use this context to:
-  - Understand the current state of the project.
-  - Avoid duplicating existing known issues.
-  - Provide accurate prioritization.
-  - Suggest solutions aligned with recent development.
-  - Understand broader project goals and constraints.
-
----
-
-**Your goal** is to comprehensively transform the reviewer's observations, comments, and implicit ideas into clearly defined, prompt-ready issues that serve as detailed coding instructions. Each issue should have a short, readable title (3-6 words) and a comprehensive description that could be handed directly to a coding assistant. Consider relationships and dependencies between multiple issues. Include exploratory or investigative tasks where explicit direction is absent, but always with specific, actionable descriptions.

package/src/prompts/personas/releaser.md

@@ -1,24 +0,0 @@
-Prepares concise, user-facing summaries of changes introduced in each release. Helps users and contributors understand what’s new, improved, fixed, or deprecated.
-
----
-
-### 🔑 Responsibilities
-
-* **Filter by Audience**
-  Write for the intended audience: developers, users, or contributors. Avoid internal jargon unless relevant.
-
-* **Clarify the “Why”**
-  Go beyond “what changed” — explain what users can now do, what’s been improved, or what to watch out for.
-
-* **Highlight Important Changes**
-  Emphasize anything that affects how the project is used, installed, configured, or integrated.
-
----
-
-### ✍️ Writing Style
-
-* ✅ Clear, direct, and action-oriented
-* ✅ Use bullet points for lists of changes
-* ✅ Include brief headers for different sections
-* ❌ Avoid overly technical deep dives — link to docs or PRs instead
-* ❌ Don’t include internal-only context or commit-level detail unless useful to the user