claude_memory 0.13.1 → 0.13.2

data/.claude/skills/study-repo/focus-examples.md

@@ -1,327 +0,0 @@
-# Focused Analysis Examples
-
-When using the `--focus` flag, narrow the analysis to specific aspects of the repository. This is especially useful for:
-- Very large repositories (>5000 files)
-- Time-constrained analysis
-- Specific adoption goals
-- Deep study of one component
-
-## How Focus Mode Works
-
-1. **Narrows file exploration** to relevant paths only
-2. **Focuses comparison** on the specific aspect
-3. **Targets recommendations** to the focused area
-4. **Reduces context usage** for faster analysis
-5. **Produces smaller** influence documents
-
-## Example Focus Topics
-
-### Testing Strategy
-
-```bash
-/study-repo /tmp/repo --focus="testing strategy"
-```
-
-**What to analyze**:
-- Test files and directory structure (spec/, test/)
-- Test framework choice (RSpec, Minitest, etc.)
-- CI configuration (.github/workflows/, .circleci/)
-- Test coverage tools and reporting
-- Mocking/stubbing patterns
-- Integration vs unit test balance
-- Test factories and fixtures
-- Performance test practices
-
-**Output focus**:
-- How they organize tests
-- What patterns they use for test data
-- How they achieve high coverage
-- CI/CD testing pipeline design
-
----
-
-### MCP Integration
-
-```bash
-/study-repo /tmp/repo --focus="MCP server implementation"
-```
-
-**What to analyze**:
-- MCP server files (mcp/, server/)
-- Tool definitions and schemas
-- Request/response handling
-- Error handling approach
-- Tool composition and organization
-- JSON-RPC implementation
-- Streaming support
-- Authentication/security
-
-**Output focus**:
-- How tools are structured
-- Best practices for tool design
-- Error handling patterns
-- Performance optimizations
-
----
-
-### Database Schema
-
-```bash
-/study-repo /tmp/repo --focus="database design"
-```
-
-**What to analyze**:
-- Schema files (db/schema.rb, migrations/)
-- Index strategies
-- Query optimization patterns
-- Transaction management
-- Connection pooling
-- Database abstraction layer
-- Migration practices
-- Backup/restore approaches
-
-**Output focus**:
-- Schema design decisions
-- Performance optimizations
-- Migration safety patterns
-- Query efficiency techniques
-
----
-
-### CLI Architecture
-
-```bash
-/study-repo /tmp/repo --focus="CLI design"
-```
-
-**What to analyze**:
-- Entry points (bin/, exe/)
-- Command organization (commands/, lib/commands/)
-- Argument parsing (Thor, OptionParser, etc.)
-- Help text and documentation
-- Error messages and exit codes
-- Subcommand structure
-- Configuration file handling
-- Output formatting
-
-**Output focus**:
-- Command organization patterns
-- User experience considerations
-- Error handling best practices
-- Testing CLI commands
-
----
-
-### Performance Optimizations
-
-```bash
-/study-repo /tmp/repo --focus="performance"
-```
-
-**What to analyze**:
-- Caching strategies (Redis, in-memory)
-- Batch processing patterns
-- Query optimization
-- Resource management
-- Profiling and metrics
-- Lazy loading techniques
-- Memory efficiency
-- Concurrency patterns
-
-**Output focus**:
-- What they optimize and how
-- Benchmarking approaches
-- Trade-offs made
-- Performance monitoring
-
----
-
-### Error Handling
-
-```bash
-/study-repo /tmp/repo --focus="error handling"
-```
-
-**What to analyze**:
-- Exception hierarchy
-- Error class organization
-- Recovery strategies
-- User-facing error messages
-- Logging practices
-- Retry logic
-- Graceful degradation
-- Error reporting/telemetry
-
-**Output focus**:
-- Exception design patterns
-- Error communication to users
-- Debugging support
-- Resilience patterns
-
----
-
-### Configuration Management
-
-```bash
-/study-repo /tmp/repo --focus="configuration"
-```
-
-**What to analyze**:
-- Config file formats (YAML, JSON, TOML)
-- Environment variable handling
-- Default value strategies
-- Configuration validation
-- Secret management
-- Multi-environment support
-- Configuration discovery
-- Override precedence
-
-**Output focus**:
-- Configuration architecture
-- Validation and defaults
-- Security practices
-- User experience
-
----
-
-### Domain Modeling
-
-```bash
-/study-repo /tmp/repo --focus="domain model"
-```
-
-**What to analyze**:
-- Core domain objects
-- Value objects vs entities
-- Aggregate boundaries
-- Repository pattern usage
-- Domain events
-- Business logic organization
-- Validation rules
-- Domain services
-
-**Output focus**:
-- How domain is modeled
-- Separation of concerns
-- Business rule implementation
-- Pattern usage
-
----
-
-### Dependency Injection
-
-```bash
-/study-repo /tmp/repo --focus="dependency injection"
-```
-
-**What to analyze**:
-- DI container (if any)
-- Constructor injection patterns
-- Service locator usage
-- Factory patterns
-- Testability approaches
-- Configuration of dependencies
-- Lifecycle management
-- Interface abstractions
-
-**Output focus**:
-- DI strategy and patterns
-- Testing benefits
-- Complexity vs benefits
-- Best practices
-
----
-
-### API Design
-
-```bash
-/study-repo /tmp/repo --focus="API design"
-```
-
-**What to analyze**:
-- REST/GraphQL/RPC patterns
-- Endpoint organization
-- Request/response formats
-- Versioning strategy
-- Authentication/authorization
-- Rate limiting
-- Documentation (OpenAPI, etc.)
-- Client SDK design
-
-**Output focus**:
-- API structure and conventions
-- Versioning approach
-- Documentation practices
-- Client experience
-
----
-
-## Custom Focus Topics
-
-You can specify any aspect you want to focus on:
-
-```bash
-/study-repo /tmp/repo --focus="logging and observability"
-/study-repo /tmp/repo --focus="file system abstraction"
-/study-repo /tmp/repo --focus="plugin architecture"
-/study-repo /tmp/repo --focus="webhook handling"
-```
-
-The skill will adapt the analysis to your specified topic.
-
-## When to Use Focus Mode
-
-### Use Focus When:
-- Repository has >1000 files
-- You have a specific adoption goal
-- You want deep analysis of one aspect
-- Time is limited
-- You're comparing specific features
-
-### Use Full Analysis When:
-- Repository is small (<500 files)
-- You want comprehensive overview
-- Architecture understanding is the goal
-- Time allows for thorough exploration
-- Making major adoption decisions
-
-## Output Differences
-
-### Full Analysis Output:
-```
-docs/influence/project-name.md
-- All sections populated
-- Broad recommendations
-- Comprehensive comparison
-- 10-20 pages typical
-```
-
-### Focused Analysis Output:
-```
-docs/influence/project-name-focus.md
-- Focused sections only
-- Targeted recommendations
-- Specific comparison
-- 3-8 pages typical
-```
-
-## Combining Focuses
-
-For very large projects, run multiple focused analyses:
-
-```bash
-# Study different aspects separately
-/study-repo /tmp/big-repo --focus="MCP implementation"
-/study-repo /tmp/big-repo --focus="testing strategy"
-/study-repo /tmp/big-repo --focus="database design"
-```
-
-Each produces a separate influence document focused on that aspect.
-
-## Tips for Effective Focus
-
-1. **Be specific**: "MCP server" is better than "server stuff"
-2. **Match their terminology**: Use terms from their docs/code
-3. **Start broad, then focus**: Run full analysis first to identify interesting areas
-4. **Combine with grep**: Search for keywords related to your focus
-5. **Review examples**: Look at their tests for the focused component

data/.claude/skills/upgrade-dependencies/SKILL.md

@@ -1,154 +0,0 @@
----
-name: upgrade-dependencies
-description: "Upgrade all Ruby gem dependencies to their latest versions with release note review and codebase alignment checks. Use this skill whenever the user asks to update, upgrade, or bump dependencies, gems, or packages — even casually like 'update my gems' or 'are my deps up to date?'"
-agent: general-purpose
-allowed-tools: Read, Grep, Glob, Bash, Edit, Write, Agent, WebFetch
----
-
-# Dependency Upgrade Skill
-
-Systematically upgrade Ruby gem dependencies by researching latest versions, reviewing release notes for breaking changes, updating version constraints, verifying with tests, and confirming codebase alignment.
-
-The goal is a *thoughtful* upgrade — not blindly bumping versions, but understanding what changed and ensuring the codebase is compatible. This matters because a silent API change can introduce bugs that tests don't catch if the tests don't exercise the affected code path.
-
-## Process Overview
-
-1. **Discover** current dependencies and their constraints
-2. **Research** latest versions and release notes (in parallel)
-3. **Analyze** breaking changes and codebase impact
-4. **Upgrade** version constraints and install
-5. **Verify** with the full test suite
-6. **Report** a summary table with upgrade details
-
-## Step 1: Discover Current Dependencies
-
-Read the gemspec and Gemfile to build a complete dependency inventory.
-
-```
-Read *.gemspec        → runtime dependencies (add_dependency)
-Read Gemfile          → development dependencies (gem declarations)
-Run: bundle outdated  → current vs latest versions, which are constrained
-```
-
-Build a working list with these columns:
-- **Gem name**
-- **Source** (gemspec or Gemfile)
-- **Current constraint** (e.g., `~> 5.0`)
-- **Installed version** (from `bundle outdated` or `Gemfile.lock`)
-- **Latest version** (from `bundle outdated`)
-- **Constrained?** (is the version constraint preventing upgrade?)
-
-## Step 2: Research Release Notes
-
-For each gem that has a newer version available, research what changed. Launch these as parallel Agent subagents — one per gem — to avoid sequential delays.
-
-Each research agent should:
-
-1. Run `gem search <name> --exact --versions` to confirm the latest version
-2. Fetch the changelog or release notes from GitHub (check CHANGELOG.md, CHANGES, HISTORY.md, or GitHub Releases)
-3. Summarize changes between the installed version and latest version
-4. Flag any **breaking changes**, **deprecations**, or **API changes**
-5. Note if it's a **major version bump** (higher risk)
-
-For transitive dependencies (not directly declared but showing in `bundle outdated`), research is optional — focus on direct dependencies. Transitive deps are upgraded automatically when their parent gem allows it.
-
-### What to look for in release notes
-
-- **Removed methods or classes** the codebase might use
-- **Renamed options or changed defaults** that could silently alter behavior
-- **New required arguments** to methods we call
-- **Deprecated features** we rely on (working now, but will break later)
-- **Changed return types** or data structures
-- **Minimum Ruby version bumps** that could affect CI or deployment
-
-## Step 3: Analyze Codebase Impact
-
-For each gem with breaking changes or API modifications:
-
-1. **Grep the codebase** for usage of affected APIs
-2. **Check test coverage** — are the affected code paths tested?
-3. **Determine if changes are needed** before or after the upgrade
-
-Classify each upgrade:
-
-- **Safe** — no breaking changes, or breaking changes don't affect our usage
-- **Needs code changes** — our code uses a deprecated or removed API
-- **Held back** — a transitive dependency constraint prevents the upgrade (explain which parent gem and why)
-
-If code changes are needed, make them *before* bumping the version constraint so the upgrade commit is clean.
-
-## Step 4: Upgrade Dependencies
-
-### Gemspec dependencies (runtime)
-
-Update version constraints to target the latest version. Use `~>` with the appropriate precision:
-
-- For stable gems (1.0+): `~> X.Y` allows patch updates (e.g., `~> 5.102` allows 5.102.x)
-- For pre-1.0 gems: `~> 0.X, ">= 0.X.Y"` to pin a minimum while allowing patches
-- For gems where a specific fix matters: add `">= X.Y.Z"` as an additional constraint
-
-### Gemfile dependencies (development)
-
-Same approach. If a major version bump is available (e.g., lefthook 1.x → 2.x), check the migration guide before bumping.
-
-### Install
-
-```bash
-bundle update
-```
-
-If `bundle update` fails due to dependency conflicts, resolve them. Common strategies:
-- Relax an overly tight constraint
-- Update the conflicting parent gem first
-- Accept that a gem can't be upgraded yet and document why
-
-## Step 5: Verify with Tests
-
-Run the full test suite:
-
-```bash
-bundle exec rspec
-```
-
-Also run the linter to catch any style issues:
-
-```bash
-bundle exec rake standard
-```
-
-If tests fail:
-1. Read the failure carefully — is it caused by the upgrade or pre-existing?
-2. If caused by the upgrade, fix the code to work with the new version
-3. If unfixable, revert that specific gem's upgrade and note it in the report
-
-## Step 6: Present Summary
-
-Present a clear summary table of all changes:
-
-```markdown
-| Gem | Old Version | New Version | Old Constraint | New Constraint | Notes |
-|-----|------------|-------------|----------------|----------------|-------|
-| sequel | 5.100.0 | 5.102.0 | ~> 5.0 | ~> 5.102 | No breaking changes |
-| lefthook | 1.13.6 | 2.1.4 | ~> 1.6 | ~> 2.1 | Major version bump, reviewed migration guide |
-```
-
-Follow the table with:
-
-1. **Breaking changes found** — what changed and how the codebase was updated
-2. **Gems held back** — which gems couldn't be upgraded and why (e.g., "diff-lcs 2.0 held back by rspec's ~> 1.4 constraint")
-3. **Notable new features** — anything worth adopting from the new versions
-4. **Test results** — confirmation that all tests pass
-
-## Edge Cases
-
-### Gems with no GitHub repository
-Fall back to `gem info <name>` and the RubyGems page for release history. Note reduced confidence in the review.
-
-### Yanked versions
-If `bundle update` fails because a version was yanked, try the next most recent version.
-
-### Pre-release versions
-Do not upgrade to pre-release or alpha versions unless the user explicitly asks. Stick to stable releases.
-
-### Monorepo gems
-Some gems (like rails components) are versioned together. Upgrade them as a group.