Merge pull request #902 from thesimplekid/goose_recipe

feat(misc): add Goose AI recipes for automated changelog and git message

CHANGELOG.md

@@ -4,6 +4,20 @@
 <!-- The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), -->
 <!-- and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). -->
 
+## [Unreleased]
+
+### Added
+- cashu: `KeySetInfos` type alias and `KeySetInfosMethods` trait for filtering keysets ([thesimplekid]).
+
+### Changed
+- cdk: Refactored wallet keyset management methods for better clarity and separation of concerns ([thesimplekid]).
+- cdk: Renamed `get_keyset_keys` to `fetch_keyset_keys` to indicate network operation ([thesimplekid]).
+- cdk: Renamed `get_active_mint_keyset` to `fetch_active_keyset` for consistency ([thesimplekid]).
+- cdk: Updated `get_active_mint_keysets` to `refresh_keysets` with improved keyset refresh logic ([thesimplekid]).
+- cdk: Improved `load_mint_keysets` method to be the primary method for getting keysets for token operations ([thesimplekid]).
+- cdk: Enhanced keyset management with better offline/online operation separation ([thesimplekid]).
+- cdk: Updated method documentation to clarify storage vs network operations ([thesimplekid]).
+
 
 
 ## [0.11.0](https://github.com/cashubtc/cdk/releases/tag/v0.11.0)

justfile

@@ -129,6 +129,18 @@ typos:
 typos-fix:
   just typos -w
 
+# Goose AI Recipe Commands
+
+# Create git message from staged changes using Goose AI
+goose-changelog-update:
+  #!/usr/bin/env bash
+  goose run --recipe ./misc/recipes/changelog-update.yaml --interactive
+  
+# Update changelog from staged changes using Goose AI  
+goose-git-msg:
+  #!/usr/bin/env bash
+  goose run --recipe ./misc/recipes/git-commit-message.yaml --interactive
+
 itest db:
   #!/usr/bin/env bash
   ./misc/itests.sh "{{db}}"

misc/recipes/changelog-update.yaml

@@ -0,0 +1,73 @@
+version: 1.0.0
+title: Update Changelog from staged
+description: a custom recipe instance from this chat session
+instructions: Analyze staged Git changes and automatically update project changelogs following Keep a Changelog format. Read staged files using git diff, understand the nature of code changes (API refactoring, new features, bug fixes, etc.), and add appropriately categorized entries to the Unreleased section. Use the git author's username for attribution and follow established changelog patterns including proper formatting with contributor links. Requires git command line tools and file editing capabilities.
+prompt: |
+  You are tasked with updating the CHANGELOG.md file based on staged Git changes. Follow these instructions:
+
+  ## Analysis Process:
+  1. **Read staged changes**: Use `git diff --staged` to analyze what files and code changes are currently staged for commit
+  2. **Get git author**: Use `git config --get user.name` to get the author name for attribution
+  3. **Analyze change types**: Categorize changes into:
+     - **Added**: New features, new functions, new files, new functionality
+     - **Changed**: Modifications to existing functionality, refactoring, API changes, dependency updates
+     - **Fixed**: Bug fixes, error handling improvements, corrections
+     - **Removed**: Deleted files, deprecated functions, removed dependencies
+
+  ## CHANGELOG.md Update Requirements:
+  1. **Preserve existing format**: Keep the exact formatting style of the existing CHANGELOG.md
+  2. **Update Unreleased section**: Add new entries to the "## [Unreleased]" section only
+  3. **Use proper categories**: Add entries under the appropriate subsections (Added, Changed, Fixed, Removed)
+  4. **Follow format pattern**: Each entry should follow this exact format:
+     ```
+     - component: Description of change ([author]).
+     ```
+  5. **Author attribution**: Use the git author name in square brackets at the end of each entry
+  6. **Component identification**: Identify the relevant component (e.g., "cdk", "cashu", "cdk-cli", etc.) from file paths
+  7. **Maintain formatting**: 
+     - Use proper bullet points with hyphens
+     - Maintain consistent spacing
+     - Keep entries concise but descriptive
+     - End each entry with period before author attribution
+
+  ## Example Entry Format:
+  ```markdown
+  ### Added
+  - cdk: New keyset refresh functionality with improved error handling ([thesimplekid]).
+
+  ### Changed  
+  - cdk: Refactored wallet keyset management for better performance ([thesimplekid]).
+
+  ### Fixed
+  - cdk-cli: Fixed token parsing error for malformed inputs ([thesimplekid]).
+  ```
+
+  ## Important Guidelines:
+  - **DO NOT** modify any existing changelog entries
+  - **DO NOT** change the structure or format of the changelog
+  - **ONLY** add new entries to the Unreleased section
+  - **DO NOT** add duplicate entries
+  - **BE SPECIFIC** about what changed, not just which files
+  - **FOCUS** on user-facing changes and important internal improvements
+  - **IGNORE** trivial changes like whitespace, comments, or formatting unless they're significant
+
+  ## Steps to Execute:
+  1. Read current CHANGELOG.md file to understand format
+  2. Get git author name  
+  3. Analyze staged changes with `git diff --staged`
+  4. Categorize and write appropriate changelog entries
+  5. Update the CHANGELOG.md file preserving all existing content
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+activities:
+- Update changelog from staged changes
+- Analyze API refactoring commits
+- Add new feature entries
+- Categorize bug fix changes
+- Format contributor attributions
+author:
+  contact: thesimplekid

misc/recipes/git-commit-message.yaml

@@ -0,0 +1,83 @@
+version: 1.0.0
+title: Create git commit message from staged changes
+description: Generate meaningful git commit messages by analyzing staged changes
+prompt: |
+  You are tasked with creating a clear and descriptive git commit message based on staged Git changes. Follow these instructions:
+
+  ## Analysis Process:
+  1. **Read staged changes**: Use `git diff --staged` to analyze what files and code changes are currently staged for commit
+  2. **Analyze change scope**: Identify which components/modules are affected (e.g., cdk, cashu, cdk-cli, etc.)
+  3. **Determine change type**: Categorize the primary change as:
+     - **feat**: New features or functionality
+     - **fix**: Bug fixes
+     - **refactor**: Code refactoring without functional changes
+     - **docs**: Documentation changes
+     - **style**: Code style/formatting changes
+     - **test**: Adding or updating tests
+     - **chore**: Maintenance tasks, dependency updates, build changes
+
+  ## Commit Message Format:
+  Follow conventional commit format:
+  ```
+  type(scope): description
+
+  Optional body with more details if needed
+  ```
+
+  ### Examples:
+  ```
+  feat(cdk): add keyset refresh functionality with improved error handling
+
+  refactor(wallet): improve keyset management for better performance
+
+  fix(cdk-cli): resolve token parsing error for malformed inputs
+
+  docs(README): update installation instructions
+
+  chore(deps): update rust dependencies to latest versions
+  ```
+
+  ## Commit Message Guidelines:
+  1. **Subject line (first line)**:
+     - Start with conventional commit type and scope
+     - Use imperative mood ("add", "fix", "update", not "added", "fixed", "updated")
+     - Keep under 72 characters
+     - Don't end with a period
+     - Be specific and descriptive
+
+  2. **Body (optional)**:
+     - Add if the change needs more explanation
+     - Wrap at 72 characters
+     - Explain **what** and **why**, not **how**
+     - Separate from subject with blank line
+
+  3. **Scope identification**:
+     - Use component names from file paths (cdk, cashu, cdk-cli, etc.)
+     - Use general scopes like "deps", "ci", "docs" for broad changes
+     - Omit scope if change affects multiple unrelated areas
+
+  ## Analysis Priority:
+  1. **Focus on the main change**: If multiple types of changes, pick the most significant one
+  2. **Combine related changes**: Group similar modifications into one cohesive message
+  3. **Ignore trivial changes**: Don't mention minor formatting, whitespace, or comment changes unless that's the primary purpose
+  4. **Be user/developer focused**: Describe impact rather than implementation details
+
+  ## Steps to Execute:
+  1. Analyze staged changes with `git diff --staged`
+  2. Identify primary change type and affected components
+  3. Write a clear, descriptive commit message following conventional format
+  4. Output ONLY the commit message (no additional explanation unless asked)
+extensions:
+- type: builtin
+  name: developer
+  display_name: Developer
+  timeout: 300
+  bundled: true
+activities:
+- Analyze staged git changes
+- Generate conventional commit messages
+- Identify change types and scopes
+- Create clear and descriptive commit subjects
+- Format commit messages properly
+author:
+  contact: thesimplekid