openclacky 0.6.4 → 0.7.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: dcf90e79799d6f487ba77c084b9b3b72fc7c5252e2ffc7a3e56a0973bb9df977
-  data.tar.gz: 52a2e19427036920d29ee27c5021f731cfc924fc9c6800e22040a017f74c7fc7
+  metadata.gz: d00dc4e2243d55c56a3f5df9838517d7588a96137b18348c750e42374d15f7d8
+  data.tar.gz: 0e0fb9b1fce48ac1fb5542e3fb4e5b3744aecb4cd9a51bd15ffa6ada3f892212
 SHA512:
-  metadata.gz: 90180817198ad434c4920c855e92215fafe0495f11b93cdf156e1a1a13239219bf3d68f061900265165cf897d601f6913a8815e5c22e60d341cdb3ea6b661bde
-  data.tar.gz: e09ba63257284794970bd5929d1e310465120e98fe5330be371cd5a00935976f1e537843b7d05e7532400f757564a8be860b3621125f665fecb30eb81ff76199
+  metadata.gz: ab6df815f041afa4fa586547299a61562e544de3ae2425b2e9c7a7c9256c05e7b0f79dc824553ccd810939bf3cf3d6e1376b32f4d8a92acedb03efedcfa1e552
+  data.tar.gz: a6409dd1ab5456f70ae2f6f576f209d47bb4140956caa14ee18815d91c3c901415219212cc73138e959b43531be9f450938fd8e767e63c1075444c520147fa7e

data/.clacky/skills/commit/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: commit
+description: Smart Git commit helper that analyzes changes and creates semantic commits
+disable-model-invocation: false
+user-invocable: true
+---
+
+# Smart Commit Skill
+
+This skill helps users create well-structured, semantic git commits by analyzing changes and suggesting appropriate commit messages.
+
+## ⚠️ CRITICAL REQUIREMENT: SINGLE-LINE COMMITS ONLY
+
+**ALL commit messages created by this skill MUST be single-line only.**
+
+- ✅ DO: `git commit -m "feat: add user authentication"`
+- ❌ DON'T: Multi-line commits with body text
+- ❌ DON'T: Multiple `-m` flags
+- ❌ DON'T: Commit messages with `\n` or additional paragraphs
+
+Keep commits concise and focused. If more detail is needed, suggest adding it separately in PR descriptions or documentation.
+
+## Overview
+
+This skill automates the process of reviewing git changes and creating meaningful, conventional commits following the semantic commit format (feat/fix/chore/test).
+
+## Usage
+
+To use this skill, simply say:
+- "Help me commit my changes"
+- "Create semantic commits"
+- "Review and commit changes"
+- Use the command: `/commit`
+
+## Process Steps
+
+### 1. Analyze Git Status
+
+First, check the current git status to understand:
+- What files have been modified, added, or deleted
+- Which files are staged vs unstaged
+- Overall state of the working directory
+
+```bash
+git status
+git diff --stat
+```
+
+### 2. Review Changes in Detail
+
+For each changed file, analyze:
+- The nature of changes (new feature, bug fix, refactoring, tests, documentation)
+- Scope of changes (which component/module)
+- Impact level (minor tweak vs major change)
+
+```bash
+git diff <file>
+```
+
+### 3. Generate Commit Messages
+
+Based on the analysis, generate commit messages following the conventional commit format:
+
+**Format**: `<type>: <description>`
+
+**Types**:
+- `feat`: New features or functionality
+- `fix`: Bug fixes
+- `chore`: Routine tasks, maintenance, dependencies
+- `test`: Adding or modifying tests
+- `docs`: Documentation changes
+- `refactor`: Code refactoring without changing functionality
+- `style`: Code style changes (formatting, whitespace)
+- `perf`: Performance improvements
+
+**CRITICAL GUIDELINES**:
+- **MUST BE SINGLE-LINE**: Commit messages MUST be a single line only. DO NOT create multi-line commit messages.
+- Keep messages concise (ideally under 50 characters)
+- Use imperative mood ("add feature" not "added feature")
+- Don't end with a period
+- Be specific but brief
+- One logical change per commit
+- If more detail is needed, suggest adding it in PR description or commit body separately, but the initial commit MUST be single-line
+
+**Examples**:
+- `feat: add user authentication`
+- `fix: resolve memory leak in parser`
+- `chore: update dependencies`
+- `test: add unit tests for validator`
+- `docs: update README installation steps`
+
+### 4. Group Changes
+
+Organize changes into logical commits:
+- Group related changes together
+- Separate features, fixes, and chores
+- Keep commits atomic and focused
+- Suggest the order of commits
+
+### 5. Present Suggestions
+
+Show the user:
+- List of proposed commits
+- Files included in each commit
+- Commit message for each group
+- Brief explanation of the grouping logic
+
+Format:
+```
+Commit 1: feat: add login endpoint
+  - lib/api/auth.rb
+  - spec/api/auth_spec.rb
+
+Commit 2: fix: resolve timeout in database connection
+  - lib/database/connection.rb
+
+Commit 3: chore: update rubocop configuration
+  - .rubocop.yml
+```
+
+### 6. Get User Confirmation
+
+Ask the user:
+- Review the proposed commits
+- Confirm if they want to proceed
+- Allow modifications if needed
+- Get explicit approval before committing
+
+### 7. Execute Commits
+
+For each approved commit:
+```bash
+# Stage specific files
+git add <file1> <file2> ...
+
+# Create commit with SINGLE-LINE message only
+git commit -m "<type>: <description>"
+```
+
+**IMPORTANT**: 
+- Use ONLY `git commit -m "single line message"` format
+- DO NOT use multi-line commits with additional body text
+- DO NOT use `-m` flag multiple times
+- Keep the commit message as a single, concise line
+
+Provide feedback after each commit:
+- Confirm successful commit
+- Show commit hash
+- Display summary
+
+### 8. Final Summary
+
+After all commits:
+- Show total number of commits created
+- List all commit messages
+- Suggest next steps (e.g., git push)
+
+## Commands Used
+
+```bash
+# Check status
+git status
+git status --short
+
+# View changes
+git diff
+git diff --stat
+git diff <file>
+
+# Stage files
+git add <file>
+
+# Create commit (SINGLE-LINE only)
+git commit -m "type: single line description"
+
+# NEVER use multi-line format like:
+# git commit -m "title" -m "body"  ❌ DON'T DO THIS
+# git commit -m "title\n\nbody"    ❌ DON'T DO THIS
+
+# View commit history
+git log --oneline -n 5
+```
+
+## Workflow Example
+
+```
+User: /commit
+
+AI:
+1. Analyzing git status...
+   Found 5 modified files
+
+2. Reviewing changes...
+   - lib/user.rb: New user registration feature
+   - lib/auth.rb: Fix password validation bug
+   - spec/user_spec.rb: Tests for user registration
+   - spec/auth_spec.rb: Tests for auth fix
+   - Gemfile: Updated dependencies
+
+3. Proposed commits:
+
+   Commit 1: feat: add user registration
+     - lib/user.rb
+     - spec/user_spec.rb
+
+   Commit 2: fix: correct password validation logic
+     - lib/auth.rb
+     - spec/auth_spec.rb
+
+   Commit 3: chore: update gem dependencies
+     - Gemfile
+
+   Do you want to proceed with these commits? (yes/no)
+
+User: yes
+
+AI:
+✓ Commit 1 created (a1b2c3d): feat: add user registration
+✓ Commit 2 created (e4f5g6h): fix: correct password validation logic
+✓ Commit 3 created (i7j8k9l): chore: update gem dependencies
+
+Summary: 3 commits created successfully!
+Next steps: Review with 'git log' or push with 'git push'
+```
+
+## Best Practices
+
+### Commit Message Rules
+- **MUST be single-line only** - Never use multi-line commit messages
+- Start with lowercase (except proper nouns)
+- Use present tense imperative
+- Be specific but concise
+- Focus on "what" and "why", not "how"
+- Maximum 72 characters for the single line
+
+### Commit Organization
+- One logical change per commit
+- Keep features separate from fixes
+- Don't mix refactoring with new features
+- Test files go with their related code changes
+
+### When to Split Commits
+- Multiple unrelated features
+- Features and bug fixes mixed
+- Code changes and config changes
+- Different modules/components affected
+
+### When to Combine Changes
+- Related test and implementation
+- Multiple files for same feature
+- Complementary changes for same fix
+
+## Error Handling
+
+- **No changes detected**: Inform user and exit gracefully
+- **Merge conflicts**: Warn user to resolve conflicts first
+- **Detached HEAD**: Alert user about repository state
+- **Uncommitted changes during conflict**: Suggest stashing or committing
+- **Empty commit message**: Request user input for clarification
+
+## Safety Features
+
+- Always review changes before committing
+- Require user confirmation before executing commits
+- Show exactly which files will be in each commit
+- Allow user to modify suggestions
+- Never force commits without approval
+- Preserve git history integrity
+
+## Integration with Workflow
+
+This skill works best:
+- After completing a feature or fix
+- Before pushing to remote
+- During code review preparation
+- When cleaning up messy commit history (use with `git reset` first)
+
+## Notes
+
+- This skill does NOT push commits (user controls when to push)
+- Follows conventional commits specification
+- Encourages atomic, well-documented commits
+- Helps maintain clean git history
+- Useful for both beginners and experienced developers
+
+## Dependencies
+
+- Git installed and configured
+- Working directory is a git repository
+- User has permissions to commit
+- Changes exist to commit
+
+## Version History
+
+- Created: 2025-02-01
+- Purpose: Improve commit quality and development workflow
+- Compatible with: Any git repository

data/.clacky/skills/gem-release/SKILL.md

@@ -0,0 +1,253 @@
+---
+name: gem-release
+description: Automates the complete process of releasing a new version of the openclacky Ruby gem
+disable-model-invocation: false
+user-invocable: true
+---
+
+# Gem Release Skill
+
+This skill automates the complete process of releasing a new version of the openclacky Ruby gem.
+
+## Overview
+
+This skill handles the entire gem release workflow from version bumping to publishing on RubyGems and creating GitHub releases.
+
+## Usage
+
+To use this skill, simply say:
+- "Release a new version"
+- "Publish a new gem version"
+- Use the command: `/gem-release`
+
+## Process Steps
+
+### 1. Pre-Release Checks
+- Check for uncommitted changes in the working directory
+- Verify all tests pass before proceeding
+- Ensure the repository is in a clean state
+
+### 2. Version Management
+- Read current version from `lib/clacky/version.rb`
+- Increment version number (typically patch version: x.y.z → x.y.z+1)
+- Update the VERSION constant in the version file
+
+### 3. Quality Assurance
+- Run the full test suite with `bundle exec rspec`
+- Ensure all 167+ tests pass
+- Verify no regressions introduced
+
+### 4. Build Process
+- Build the gem using `gem build openclacky.gemspec`
+- Generate the `.gem` file for distribution
+- Handle any build warnings appropriately
+
+### 5. Update Gemfile.lock and Verify CI
+
+1. **Update Gemfile.lock**
+   ```bash
+   bundle install
+   ```
+   This ensures Gemfile.lock reflects the new version.
+
+2. **Commit Gemfile.lock Changes**
+   ```bash
+   git add Gemfile.lock
+   git commit -m "chore: update Gemfile.lock to v{version}"
+   ```
+
+3. **Push and Verify CI**
+   ```bash
+   git push origin main
+   ```
+   - Wait for CI pipeline to complete successfully
+   - Verify all tests pass
+   - If CI fails, fix issues before proceeding
+
+4. **Proceed Only After CI Success**
+   - If CI fails: stop, fix issues, and restart the release process
+   - If CI passes: continue to build and publish
+
+### 6. Build and Publish Gem
+
+1. **Build the Gem**
+   ```bash
+   gem build openclacky.gemspec
+   ```
+   Generates `openclacky-{version}.gem` file.
+
+2. **Publish to RubyGems.org**
+   ```bash
+   gem push openclacky-{version}.gem
+   ```
+   Verify successful publication.
+
+3. **Create Git Tag and Push**
+   ```bash
+   git tag v{version}
+   git push origin main --tags
+   ```
+
+4. **Verify Publication**
+   - Check gem appears on RubyGems.org
+   - Verify version information is correct
+
+### 6. Documentation - CHANGELOG Writing Process
+
+**Critical Step: Review Commits Before Writing CHANGELOG**
+
+1. **Find Previous Version Tag**
+   - Get the latest version tag (e.g., v0.6.3)
+   - Use `git describe --tags --abbrev=0` or manually identify
+
+2. **Gather All Commits Since Last Release**
+   ```bash
+   git log {previous_tag}..HEAD --oneline
+   git diff {previous_tag}..HEAD --stat
+   ```
+
+3. **Analyze and Categorize Commits**
+   - Review each commit message and its changes
+   - Categorize into:
+     - **Major Features**: User-visible functionality additions
+     - **Improvements**: Performance, UX, architecture enhancements
+     - **Bug Fixes**: Error corrections and issue resolutions
+     - **Changes**: Breaking changes or significant refactoring
+     - **Minor Details**: Small fixes, style changes, trivial updates
+
+4. **Write CHANGELOG Entries**
+
+   **Format for Significant Items:**
+   ```
+   ## [Version] - Date
+
+   ### Added
+   - Feature description (link to related commits)
+
+   ### Improved
+   - Enhancement description
+
+   ### Fixed
+   - Bug fix description
+
+   ### Changed
+   - Breaking change description
+   ```
+
+   **Format for Minor Items (group under "More"):**
+   ```
+   ### More
+   - Minor fix 1
+   - Minor fix 2
+   ```
+
+5. **Prioritization Rules**:
+   - Place user-facing value at the top
+   - Group related commits together
+   - Skip very trivial commits (typos, minor formatting)
+   - Use imperative mood ("Add" not "Added")
+
+6. **Example CHANGELOG Section**:
+   ```markdown
+   ## [0.6.4] - 2026-02-03
+
+   ### Added
+   - Anthropic API support with full Claude model integration
+   - ClaudeCode environment compatibility (ANTHROPIC_API_KEY support)
+
+   ### Improved
+   - API client architecture for multi-provider support
+   - Config loading with source tracking
+
+   ### Fixed
+   - Handle absolute paths correctly in glob tool
+
+   ### More
+   - Update dependencies
+   - Minor style adjustments
+   ```
+
+7. **Commit and Push Documentation Updates**
+   - Commit CHANGELOG.md changes
+   - Push to remote repository
+
+### 7. Final Verification
+- Confirm the gem appears on RubyGems.org
+- Check that version information is correct
+- Verify installation works for end users
+
+## Commands Used
+
+```bash
+# Pre-release checks
+git status --porcelain
+
+# Run tests
+bundle exec rspec
+
+# Update Gemfile.lock
+bundle install
+git add Gemfile.lock
+git commit -m "chore: update Gemfile.lock to vX.Y.Z"
+git push origin main
+
+# Build and publish gem
+gem build openclacky.gemspec
+gem push openclacky-X.Y.Z.gem
+
+# Git operations
+git add lib/clacky/version.rb
+git commit -m "chore: bump version to X.Y.Z"
+git tag vX.Y.Z
+git push origin main
+git push origin --tags
+```
+
+## File Locations
+
+- Version file: `lib/clacky/version.rb`
+- Gem specification: `openclacky.gemspec`
+- Changelog: `CHANGELOG.md`
+- Built gem: `openclacky-{version}.gem`
+
+## Success Criteria
+
+- All tests pass
+- CI pipeline completes successfully
+- Gemfile.lock updated and committed
+- New version successfully published to RubyGems
+- Git repository updated with version tag
+- CHANGELOG.md updated with release notes
+- No build or deployment errors
+
+## Error Handling
+
+- If tests fail, stop the process and report issues
+- If CI fails after Gemfile.lock update, fix issues before proceeding
+- If gem build fails, check gemspec configuration
+- If git push fails, verify repository permissions
+- If gem push fails, check RubyGems credentials
+
+## Notes
+
+- This skill follows semantic versioning
+- Always update CHANGELOG.md as part of the release
+- Verify RubyGems.org shows the new version after publication
+- The search index on RubyGems may take a few minutes to update
+
+## Dependencies
+
+- Ruby development environment
+- Git repository access
+- RubyGems account with push permissions
+- Bundle and RSpec for testing
+
+## Version History
+
+- Created: 2026-01-18
+- Used for: openclacky gem releases
+- Compatible with: Ruby gems following standard conventions
+
+## User Experience Summary
+
+This skill takes the complexity out of gem releases. Instead of remembering 8+ different commands and worrying about the correct order, you just say "release a new version" and the AI handles everything - from running tests to publishing on RubyGems. It's like having an experienced release engineer on your team who never forgets a step, always runs the tests first, and makes sure your changelog is updated. The whole process that used to take 15-20 minutes and multiple terminal windows now happens smoothly in one conversation, with clear feedback at each step so you know exactly what's happening.

data/.clacky/skills/test-skill/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: test-skill
+description: A test skill for demonstrating skill loading
+disable-model-invocation: false
+user-invocable: true
+---
+
+# Test Skill
+
+This is a test skill to verify that skills are being loaded into the system prompt.
+
+When you see this skill in your context, you should:
+1. Acknowledge that you have access to this skill
+2. Explain what this skill does
+3. Demonstrate that you can use it

data/.clackyrules

@@ -25,7 +25,8 @@ It provides chat functionality and autonomous AI agent capabilities with tool us
 - **IMPORTANT**: All code comments must be written in English
 - Add descriptive comments for complex logic
 - Use clear, self-documenting code with English naming
-- **IMPORTANT**: Always use inline `private` with method definitions (e.g., `private def method_name`). Do NOT use standalone `private` keyword
+- **IMPORTANT**: Always use inline `private` with instance method definitions (e.g., `private def method_name`). Do NOT use standalone `private` keyword
+- **IMPORTANT**: For class methods (`def self.method_name`), do NOT use `private`. Class methods should be public
 
 ### Architecture Patterns
 - Tools inherit from `Clacky::Tools::Base`
@@ -45,6 +46,7 @@ It provides chat functionality and autonomous AI agent capabilities with tool us
 - **IMPORTANT**: When developing new features, write RSpec tests as needed and ensure they pass
 - **DO NOT** write custom test scripts unless explicitly requested by the user
 - **DO NOT** create markdown documentation unless explicitly requested by the user
+- **IMPORTANT**: When testing clacky commands or debugging, always use `bundle exec ruby bin/clacky` instead of the global `clacky` command. The global command loads the system-installed gem version (e.g., `openclacky-0.7.0`), not your local development code
 
 ### Tool Development
 When adding new tools:

data/CHANGELOG.md

@@ -7,6 +7,75 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.7.0] - 2026-02-06
+
+This is a major release with significant improvements to skill system, conversation memory management, and user experience.
+
+### 🎯 Major Features
+
+**Skill System**
+- Complete skill framework allowing users to extend AI capabilities with custom workflows
+- Skills can be invoked using shorthand syntax (e.g., `/commit`, `/gem-release`)
+- Support for user-created skills in `.clacky/skills/` directory
+- Built-in skills: commit (smart Git helper), gem-release (automated publishing)
+
+**Memory Compression**
+- Intelligent message compression to handle long conversations efficiently
+- LLM-based compression strategy that preserves context while reducing tokens
+- Automatic compression triggered based on message count and token usage
+- Significant reduction in API costs for extended sessions
+
+**Configuration Improvements**
+- API key validation on startup with helpful prompts
+- Interactive configuration UI with modal components
+- Source tracking for configuration (file, environment, defaults)
+- Better error messages and user guidance
+
+### Added
+- Request user feedback tool for interactive prompts during execution
+- Version display in welcome banner
+- File size limits for file_reader tool to prevent performance issues
+- Debug logging throughout the codebase
+
+### Improved
+- CLI output formatting and readability
+- Error handling with comprehensive debug information
+- Test coverage with 367 passing tests
+- Tool call output optimization for cleaner logs
+
+### Changed
+- Simplified CLI architecture by removing unused code
+- Enhanced modal component with new configuration features
+
+### Fixed
+- Message compression edge cases
+- Various test spec improvements
+
+## [0.6.4] - 2026-02-03
+
+### Added
+- Anthropic API support with full Claude model integration
+- ClaudeCode environment compatibility (ANTHROPIC_API_KEY support)
+- Model configuration with Anthropic defaults (claude-3-5-sonnet-20241022)
+- Enhanced error handling with AgentError and ToolCallError classes
+- format_tool_results for tool result formatting in agent execution
+- Comprehensive test suite for Anthropic API and configuration
+- Absolute path handling in glob tool
+
+### Improved
+- API client architecture for multi-provider support (OpenAI + Anthropic)
+- Config loading with source tracking (file, ClaudeCode, default)
+- Agent execution loop with improved tool result handling
+- Edit tool with improved pattern matching
+- User tip display in terminal
+
+### Changed
+- Refactored Error class to AgentError base class
+- Renamed connection methods for clarity (connection → openai_connection)
+
+### Fixed
+- Handle absolute paths correctly in glob tool
+
 ## [0.6.3] - 2026-02-01
 
 ### Added
@@ -151,7 +220,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 - **Agent Mode**: Autonomous AI agent with tool execution capabilities
-- **Built-in Tools**: 
+- **Built-in Tools**:
   - `safe_shell` - Safe shell command execution with security checks
   - `file_reader` - Read file contents
   - `write` - Create/overwrite files with diff preview
@@ -163,7 +232,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   - `todo_manager` - Task planning and tracking
   - `run_project` - Project dev server management
 - **Session Management**: Save, resume, and list conversation sessions
-- **Permission Modes**: 
+- **Permission Modes**:
   - `auto_approve` - Automatically execute all tools
   - `confirm_safes` - Auto-execute safe operations, confirm risky ones
   - `confirm_edits` - Confirm file edits only