claude_memory 0.13.1 → 0.13.2

data/.claude/skills/release/SKILL.md

@@ -1,206 +0,0 @@
----
-name: release
-description: Prepare and publish a new gem release — bumps version across all required files, validates tests/linting/MCP server, commits, and creates the GitHub release. Use this skill when the user says "release", "publish a new version", "bump the version", "cut a release", "prepare for release", "ship it", or any variation of wanting to publish a new gem version. Also use when the user asks about the release process or what steps are needed to release.
-agent: general-purpose
-allowed-tools: Read, Grep, Edit, Write, Bash
-arguments:
-  - name: version
-    description: "The new version number (e.g., '0.10.0'). If omitted, you'll be asked."
-    required: false
----
-
-# Release Workflow
-
-Automate the full release lifecycle for the ClaudeMemory gem. This workflow was codified from the actual 0.9.0 release process.
-
-The release has three phases: **prepare** (automated), **publish** (user-driven), and **announce** (automated). The middle phase requires user action because it pushes to a shared remote and publishes to RubyGems — destructive operations that must never happen without explicit confirmation.
-
-## Phase 1: Prepare
-
-### Step 1: Determine the new version
-
-If a version was passed as an argument, use it. Otherwise, read the current version from `lib/claude_memory/version.rb` and ask the user what the new version should be.
-
-### Step 2: Find and update all version references
-
-The version lives in exactly three files. Grep to confirm there are no others:
-
-```bash
-grep -rn "CURRENT_VERSION" --include="*.rb" --include="*.json" --include="*.gemspec" . | grep -v "CHANGELOG\|node_modules\|vendor\|\.git/"
-```
-
-Update all three:
-
-1. **`lib/claude_memory/version.rb`** — the `VERSION` constant (canonical source)
-2. **`.claude-plugin/plugin.json`** — the `"version"` field
-3. **`.claude-plugin/marketplace.json`** — the `"version"` field inside the plugins array
-
-If grep reveals any additional hardcoded references, update those too and flag them to the user as something that should be DRYed up.
-
-### Step 3: Update Gemfile.lock
-
-```bash
-bundle install
-```
-
-Verify both `claude_memory (X.Y.Z)` entries in Gemfile.lock match the new version.
-
-### Step 4: Verify MCP server reports the new version
-
-The MCP server reads `ClaudeMemory::VERSION` dynamically. Confirm it picks up the change:
-
-```bash
-echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' | bundle exec claude-memory serve-mcp 2>/dev/null | grep -o '"version":"[^"]*"'
-```
-
-Expected output: `"version":"X.Y.Z"` matching the new version. If it doesn't match, something is wrong with the require chain — investigate before proceeding.
-
-### Step 5: Run the full test suite
-
-```bash
-bundle exec rspec
-```
-
-All tests must pass. Do not proceed with any failures. Fix them first.
-
-### Step 6: Run the pre-release hook smoke gate
-
-```bash
-bin/pre-release-smoke
-```
-
-This script:
-
-1. Re-runs `bundle exec rake install` so the PATH-resolved `claude-memory` binary matches the working tree.
-2. Triggers each gem-managed hook against a temp DB.
-3. Verifies every field listed in `spec/smoke/expected_fields.yml` is populated on the resulting `activity_events.detail_json`.
-4. Exits non-zero with the missing field name(s) and `since_version` if any expected field is null/absent.
-
-**This catches the class of bug specs cannot:** a code change that adds a new `detail_json` field but forgets `rake install`, leaving the installed gem stale and production hooks silently missing the field. Sprung that trap on 2026-04-16 (ActivityLog) and again on 2026-04-30 (#47 token-budget) — the gate is here so it can't happen a third time.
-
-If the gate fails, **stop the release**, address the missing field (usually `bundle exec rake install` followed by re-running the gate), and only proceed when it exits 0.
-
-### Step 7: Run the benchmark scoreboard diff
-
-```bash
-bin/run-evals --benchmarks
-bin/bench-diff
-```
-
-`bin/run-evals --benchmarks` writes `spec/benchmarks/results/<version>.json` — the diff-friendly snapshot of the current release's pass rates by category and per-scenario. `bin/bench-diff` then compares that snapshot against the most recent prior tagged version's scoreboard and exits non-zero if any tracked pass-rate dropped beyond the threshold (default -5%; configurable via `--threshold`).
-
-The first release with this gate (0.12.0) has no prior scoreboard to compare against — `bench-diff` exits 0 with a "No baseline scoreboard available" note. From 0.13.0 onward it actively gates.
-
-If the diff reports a regression, **stop the release**, investigate (the regressed metric path is named in stderr — e.g. `metrics.evals.by_scenario.tech_stack_recall.pass_rate`), and only proceed once you've either (a) fixed the regression or (b) made a deliberate decision that the lower pass rate is acceptable. If (b), document the new baseline in CHANGELOG so future-you isn't surprised.
-
-For real-mode E2E coverage (~$2-8 per run), pass `EVAL_MODE=real`:
-
-```bash
-EVAL_MODE=real bin/run-evals --all && bin/bench-diff
-```
-
-### Step 8: Run the linter
-
-```bash
-bundle exec rake standard:fix
-```
-
-Ensure no remaining violations.
-
-### Step 9: Verify CHANGELOG.md
-
-The CHANGELOG should already have a release section written during development (via `/improve`, manual commits, or other workflow). **Do not auto-generate release notes** — they should reflect the actual development narrative.
-
-Check that:
-- The `## [X.Y.Z] - YYYY-MM-DD` section exists with today's date
-- It has Added, Changed, Fixed subsections as appropriate
-- Upgrade Notes are included if there are breaking changes or manual migration steps
-- The `## [Unreleased]` section above it is empty or ready for the next cycle
-
-If the CHANGELOG section is missing or incomplete, **stop and ask the user**. Do not fabricate release notes.
-
-### Step 10: Commit the version bump
-
-```bash
-git add lib/claude_memory/version.rb .claude-plugin/plugin.json .claude-plugin/marketplace.json Gemfile.lock
-git commit -m "[Release] Bump version to X.Y.Z"
-```
-
-Do NOT push yet. Report what was committed and proceed to Phase 2.
-
-## Phase 2: Publish (User-Driven)
-
-This phase involves pushing to a shared remote and publishing to RubyGems. These are **irreversible shared-state operations** — never execute them automatically.
-
-Tell the user:
-
-> Version X.Y.Z is prepared and committed locally. To publish:
->
-> ```bash
-> git push origin main
-> rake release
-> ```
->
-> `rake release` will create the git tag, build the gem, and push to RubyGems. Let me know when that's done and I'll create the GitHub release.
-
-Wait for the user to confirm before proceeding to Phase 3.
-
-## Phase 3: Announce
-
-### Step 11: Fix any stale "Latest" flags on GitHub releases
-
-Check current release state:
-
-```bash
-gh release list --limit 5
-```
-
-If an older release is incorrectly marked "Latest" (this happens when releases are created out of order or with `--latest` set manually):
-
-```bash
-gh release edit v<old-version> --latest=false
-```
-
-### Step 12: Create the GitHub release
-
-Extract the release notes from CHANGELOG.md — everything between `## [X.Y.Z]` and the next `## [` heading. Write to a temp file:
-
-```bash
-# Extract the section between the new version header and the next version header
-sed -n '/^## \[X\.Y\.Z\]/,/^## \[/{ /^## \[X\.Y\.Z\]/d; /^## \[/d; p; }' CHANGELOG.md > /tmp/release-notes.md
-```
-
-Create the release:
-
-```bash
-gh release create vX.Y.Z \
-  --title "vX.Y.Z — Short descriptive title" \
-  --latest \
-  --verify-tag \
-  --notes-file /tmp/release-notes.md
-```
-
-The title should capture the theme of the release in a few words (e.g., "Predicate Design Overhaul, Reject/Restore, Telemetry"). Read the CHANGELOG to derive this — don't ask the user unless the theme isn't obvious.
-
-### Step 13: Verify the release
-
-```bash
-gh release list --limit 5
-```
-
-Confirm:
-- The new release appears at the top
-- It's marked "Latest"
-- No older release is incorrectly marked "Latest"
-
-Report the release URL to the user.
-
-## Error Handling
-
-- **Smoke gate fails (`bin/pre-release-smoke` exits non-zero)**: The script names the missing `detail_json` field and `since_version` in stderr. Most common cause: code that adds a new field landed without a follow-up `bundle exec rake install`, so the installed gem is stale. Re-run `rake install`, then re-run the gate. If the field was newly added but no `rake install` was run, that's the bug the gate is designed to catch — don't bypass it. If the manifest needs updating because a field was intentionally removed, edit `spec/smoke/expected_fields.yml` AND add a CHANGELOG breaking-change note (removing a `detail_json` field is a public API change per `docs/api_stability.md` §4).
-- **Bench-diff fails (`bin/bench-diff` exits 1)**: Stderr names the metric path that regressed (e.g. `metrics.evals.by_scenario.tech_stack_recall.pass_rate`). Investigate the regression — is it a real correctness issue, or a measurement-noise issue (e.g. real-mode flake)? If real, fix before releasing. If a deliberate baseline change (we knowingly traded N% in metric X for some other gain), update CHANGELOG with the new baseline and re-run with a temporarily looser `--threshold` to ship; the next release picks up the new floor automatically. **Don't bypass the gate without an explicit baseline-change note** — that defeats the entire scoreboard.
-- **Tests fail**: Fix first. Never release with failing tests.
-- **CHANGELOG missing**: Ask the user. Never fabricate release notes.
-- **Version already tagged**: The tag may exist from a prior attempt. Ask the user whether to delete and recreate, or use a different version.
-- **`gh` not available**: Tell the user to create the GitHub release manually, providing the release notes content.
-- **`rake release` fails**: Common causes: not logged into RubyGems, tag already exists, uncommitted changes. Help the user diagnose but don't retry automatically.

data/.claude/skills/review-commit/SKILL.md

@@ -1,199 +0,0 @@
----
-name: review-commit
-description: Quick quality review of staged changes for pre-commit validation. Checks Ruby best practices and flags critical issues.
-agent: general-purpose
-allowed-tools: Bash, Read, Grep, Glob
----
-
-# Pre-Commit Quality Review
-
-Review the staged changes in this commit for code quality issues before committing.
-
-## Objectives
-
-- **Fast**: Complete review in < 30 seconds
-- **Focused**: Only review staged Ruby files
-- **Actionable**: Clear pass/fail with specific fixes
-- **Non-interactive**: Works in headless mode
-- **Expert-driven**: Apply Ruby best practices from industry experts
-
-## Expert Panel
-
-Apply principles from these Ruby/software design experts:
-
-1. **Sandi Metz** - POODR principles, small methods/classes, SRP, DRY
-2. **Jeremy Evans** - Sequel best practices, transaction safety, performance
-3. **Kent Beck** - Simple design, revealing names, Command-Query Separation
-4. **Avdi Grimm** - Confident Ruby, null objects, tell-don't-ask, meaningful returns
-5. **Gary Bernhardt** - Functional core/imperative shell, fast tests, immutability
-
-## Review Process
-
-1. **Get staged files:**
-   ```bash
-   git diff --cached --name-only --diff-filter=ACM | grep '\.rb$'
-   ```
-
-2. **For each staged Ruby file, check:**
-   - Get the full diff: `git diff --cached <file>`
-   - Review only the added/modified lines (lines starting with `+`)
-
-3. **Look for critical issues (❌ BLOCK):**
-
-   **Sandi Metz violations:**
-   - ❌ Missing `frozen_string_literal: true` in new files
-   - ❌ Methods > 15 lines (SRP violation, too complex)
-   - ❌ Classes > 200 lines (god object)
-   - ❌ Obvious code duplication (DRY violation)
-
-   **Jeremy Evans (Sequel) violations:**
-   - ❌ Raw SQL strings instead of Sequel dataset methods
-   - ❌ Database writes without transaction wrapper
-   - ❌ N+1 queries (multiple queries in loops)
-
-   **Kent Beck violations:**
-   - ❌ Overly complex solutions (nested conditionals > 3 levels)
-   - ❌ Command-Query Separation violation (methods that both mutate and return calculated values)
-
-   **Avdi Grimm violations:**
-   - ❌ Defensive nil checks everywhere (should use null objects)
-   - ❌ Implicit nil returns in public methods
-   - ❌ Bare `raise` or `rescue` without exception class
-
-   **Gary Bernhardt violations:**
-   - ❌ I/O operations mixed with business logic (should separate)
-   - ❌ Mutable state in value objects
-   - ❌ Database/file I/O in unit tests (makes tests slow)
-
-   **Testing:**
-   - ❌ New public methods without corresponding tests
-
-4. **Look for medium issues (⚠️ WARNING):**
-
-   **Sandi Metz:**
-   - ⚠️ Methods 10-15 lines (consider extracting)
-   - ⚠️ Classes 100-200 lines (approaching god object)
-   - ⚠️ Method parameters > 3 (use parameter object)
-
-   **Jeremy Evans:**
-   - ⚠️ Missing indexes on foreign keys
-   - ⚠️ Connection not properly managed
-
-   **Kent Beck:**
-   - ⚠️ Poor naming (unclear variable/method names, abbreviations)
-   - ⚠️ Methods doing multiple things (and/or in method name)
-
-   **Avdi Grimm:**
-   - ⚠️ Law of Demeter violations (chained method calls like `foo.bar.baz.qux`)
-   - ⚠️ Asking instead of telling (lots of getters instead of sending commands)
-
-   **Gary Bernhardt:**
-   - ⚠️ Business logic scattered in imperative shell
-   - ⚠️ Missing value objects (primitives passed around)
-
-   **General:**
-   - ⚠️ Missing documentation for public APIs
-   - ⚠️ Tight coupling between modules
-
-## Output Format
-
-Provide a clear summary with expert attributions:
-
-```
-# Pre-Commit Quality Review
-
-## Files Reviewed
-- file1.rb (23 lines changed)
-- file2.rb (8 lines changed)
-
-## Status: ❌ BLOCK / ✅ PASS / ⚠️ WARNING
-
-### Critical Issues ❌ (must fix before commit)
-
-**Sandi Metz violations:**
-- file1.rb:1 - Missing frozen_string_literal: true
-- file2.rb:15-38 - Method too long (24 lines, max 15)
-
-**Jeremy Evans violations:**
-- file1.rb:42 - Raw SQL string instead of Sequel dataset method
-- file1.rb:50 - Database write without transaction wrapper
-
-**Avdi Grimm violations:**
-- file2.rb:10 - Implicit nil return in public method
-
-### Medium Issues ⚠️ (consider fixing)
-
-**Sandi Metz:**
-- file3.rb:20-32 - Method is 13 lines (consider extracting)
-
-**Kent Beck:**
-- file2.rb:5 - Variable name `x` is unclear (revealing intent)
-
-**Avdi Grimm:**
-- file3.rb:45 - Law of Demeter violation: user.account.settings.theme
-
-### Recommendations
-
-1. Add `frozen_string_literal: true` to file1.rb (Sandi Metz)
-2. Convert raw SQL at file1.rb:42 to Sequel dataset (Jeremy Evans)
-3. Wrap database write at file1.rb:50 in transaction (Jeremy Evans)
-4. Extract file2.rb:15-38 into smaller methods (Sandi Metz)
-5. Return explicit value instead of nil at file2.rb:10 (Avdi Grimm)
-6. Rename `x` to describe what it contains (Kent Beck)
-7. Extract file3.rb:20-32 for better readability (Sandi Metz)
-8. Use tell-don't-ask at file3.rb:45 (Avdi Grimm)
-
-## Suggested Actions
-
-[If BLOCK] Run: git reset HEAD <files> && fix issues && git add <files>
-[If WARNING] Consider fixing before commit or create a follow-up task
-[If PASS] Commit looks good! 🚀
-```
-
-## Exit Behavior
-
-- **Return clear judgment**: BLOCK, WARNING, or PASS
-- **Be specific**: Include file:line references for all issues
-- **Be helpful**: Suggest concrete fixes
-- **Be fast**: Don't over-analyze, focus on obvious problems
-
-## Quick Reference Checklist
-
-For each added/modified line in the diff, scan for:
-
-**Sandi Metz:**
-- [ ] frozen_string_literal at top?
-- [ ] Methods < 15 lines? (warn at 10+)
-- [ ] Classes < 200 lines? (warn at 100+)
-- [ ] No duplicate code?
-- [ ] Parameters <= 3? (warn if more)
-
-**Jeremy Evans:**
-- [ ] Sequel datasets not raw SQL?
-- [ ] DB writes in transactions?
-- [ ] No N+1 queries in loops?
-
-**Kent Beck:**
-- [ ] Nested conditionals <= 3?
-- [ ] Clear, revealing names?
-- [ ] Methods do one thing?
-- [ ] Command-Query Separation?
-
-**Avdi Grimm:**
-- [ ] Null objects instead of nil checks?
-- [ ] Explicit returns (not implicit nil)?
-- [ ] Specific exception classes?
-- [ ] Law of Demeter (max 2 dots)?
-
-**Gary Bernhardt:**
-- [ ] Business logic separate from I/O?
-- [ ] Value objects immutable?
-- [ ] Tests avoid I/O?
-
-## Success Criteria
-
-The review is complete when:
-- All staged Ruby files have been checked
-- Clear BLOCK/WARNING/PASS verdict is given
-- All critical issues have file:line references with expert attribution
-- Concrete fix suggestions are provided with expert rationale

data/.claude/skills/review-for-quality/SKILL.md

@@ -1,154 +0,0 @@
----
-name: review-for-quality
-description: Comprehensive code quality review through expert perspectives (Sandi Metz, Jeremy Evans, Kent Beck, Avdi Grimm, Gary Bernhardt). Updates docs/quality_review.md with findings.
-agent: Plan
-allowed-tools: Read, Grep, Glob
----
-
-# Code Quality Review
-
-Critically review this Ruby codebase for best-practices, idiom use, and overall quality through the eyes of Ruby experts.
-
-## Expert Perspectives
-
-Analyze the codebase through these 5 perspectives:
-
-1. **Sandi Metz** (POODR principles)
-   - Single Responsibility Principle
-   - Small, focused methods (< 5 lines ideal)
-   - Classes with single purpose
-   - DRY principle
-   - Clear dependencies
-   - High test coverage
-
-2. **Jeremy Evans** (Sequel maintainer)
-   - Proper Sequel usage patterns (datasets over raw SQL)
-   - Database performance optimization
-   - Schema design best practices
-   - Connection management
-   - Transaction safety
-   - Sequel plugins and extensions
-
-3. **Kent Beck** (TDD, Simple Design)
-   - Test-first design
-   - Simple solutions over complex ones
-   - Revealing intent through naming
-   - Clear boundaries between components
-   - Testability without mocks
-   - Command-Query Separation
-
-4. **Avdi Grimm** (Confident Ruby)
-   - Confident code (no defensive nil checks everywhere)
-   - Tell, don't ask principle
-   - Null object pattern
-   - Meaningful return values (not nil)
-   - Duck typing
-   - Result objects over exceptions
-
-5. **Gary Bernhardt** (Boundaries, Fast Tests)
-   - Functional core, imperative shell
-   - Fast unit tests (no I/O in logic)
-   - Clear boundaries between layers
-   - Separation of I/O and pure logic
-   - Value objects
-   - Immutable data structures
-
-## Review Process
-
-1. **Explore the codebase systematically:**
-   - `lib/claude_memory/` (all subdirectories)
-   - Identify the largest files (> 500 lines)
-   - Find code duplication patterns
-   - Check architecture and design patterns
-
-2. **Document EVERY issue found** with:
-   - Priority: 🔴 Critical / High / 🟡 Medium / Low
-   - Specific file:line references
-   - Which expert's principle is violated
-   - Concrete improvement suggestions with code examples
-   - Estimated effort to fix
-
-3. **Track progress:**
-   - Compare with previous review date
-   - Show metrics (lines of code, god objects, etc.)
-   - Identify what's been fixed since last review
-   - Highlight new issues that have emerged
-
-4. **Provide actionable recommendations:**
-   - High priority items (this week)
-   - Medium priority items (next week)
-   - Low priority items (later)
-   - Quick wins (can do today)
-
-## Output Format
-
-Update `docs/quality_review.md` with:
-
-### Structure:
-```
-# Code Quality Review - Ruby Best Practices
-
-**Review Date:** [YYYY-MM-DD]
-**Previous Review:** [YYYY-MM-DD]
-
-## Executive Summary
-[Progress since last review + new critical issues]
-
-## 1. Sandi Metz Perspective
-### What's Been Fixed ✅
-### Critical Issues 🔴
-### Medium Issues 🟡
-
-## 2. Jeremy Evans Perspective
-[Same structure]
-
-## 3. Kent Beck Perspective
-[Same structure]
-
-## 4. Avdi Grimm Perspective
-[Same structure]
-
-## 5. Gary Bernhardt Perspective
-[Same structure]
-
-## 6. General Ruby Idioms
-[Style and convention issues]
-
-## 7. Positive Observations
-[What's working well]
-
-## 8. Priority Refactoring Recommendations
-### High Priority (This Week)
-### Medium Priority (Next Week)
-### Low Priority (Later)
-
-## 9. Conclusion
-[Summary + risk assessment + next steps]
-
-## Appendix A: Metrics Comparison
-[Table showing progress]
-
-## Appendix B: Quick Wins
-[Things that can be done immediately]
-
-## Appendix C: File Size Report
-[Largest files identified]
-```
-
-## Important Notes
-
-- Be thorough and critical - find real issues to improve
-- Every issue needs a specific file:line reference
-- Provide code examples for suggested fixes
-- Don't just praise - identify concrete problems
-- Compare metrics with previous review date
-- Estimate effort for each recommendation (days)
-
-## Success Criteria
-
-The review is complete when:
-- `docs/quality_review.md` is updated with dated findings
-- Every issue has file:line references
-- Concrete code examples are provided
-- Metrics comparison table is included
-- Actionable priorities are listed with time estimates

data/.claude/skills/review-for-quality/expert-checklists.md

@@ -1,79 +0,0 @@
-# Expert Review Checklists
-
-## Sandi Metz (POODR) Checklist
-
-- [ ] Classes under 100 lines
-- [ ] Methods under 5 lines
-- [ ] Method parameters limited (< 4)
-- [ ] Single Responsibility Principle followed
-- [ ] No god objects (classes > 500 lines)
-- [ ] DRY violations eliminated
-- [ ] Dependencies injected, not created
-- [ ] Public interface is minimal
-- [ ] Private methods grouped at bottom
-- [ ] attr_reader used appropriately
-
-## Jeremy Evans (Sequel) Checklist
-
-- [ ] Using Sequel datasets, not raw SQL
-- [ ] Transactions wrap multi-step operations
-- [ ] DateTime columns instead of String timestamps
-- [ ] Sequel migrations used (not manual)
-- [ ] Connection pooling configured
-- [ ] Sequel plugins utilized (timestamps, validation_helpers)
-- [ ] No N+1 query patterns
-- [ ] Batch queries used for multiple records
-- [ ] Foreign keys defined properly
-- [ ] Indexes created for common queries
-
-## Kent Beck (TDD, Simple Design) Checklist
-
-- [ ] Dependencies can be injected for testing
-- [ ] No side effects in constructors
-- [ ] Methods reveal intent through naming
-- [ ] Complex boolean logic is extracted and named
-- [ ] No large case statements (use polymorphism)
-- [ ] Tests exist for failure modes
-- [ ] Command-Query Separation followed
-- [ ] Simple solutions chosen over complex ones
-- [ ] Test coverage for edge cases
-- [ ] Clear boundaries between components
-
-## Avdi Grimm (Confident Ruby) Checklist
-
-- [ ] Null Object pattern used instead of nil checks
-- [ ] Consistent return values (not mixed types)
-- [ ] Result objects for success/failure
-- [ ] Tell, don't ask (no ask-then-do patterns)
-- [ ] Early returns minimized (use guard clauses)
-- [ ] Primitive obsession eliminated (use value objects)
-- [ ] Domain objects instead of hashes
-- [ ] Duck typing enables polymorphism
-- [ ] Meaningful default values
-- [ ] Confident code (no defensive programming everywhere)
-
-## Gary Bernhardt (Boundaries) Checklist
-
-- [ ] I/O separated from business logic
-- [ ] Core logic is pure (no side effects)
-- [ ] Fast unit tests (no database/filesystem)
-- [ ] Value objects used for domain concepts
-- [ ] State passed as parameters, not stored in instance variables
-- [ ] Clear layer boundaries (presentation → application → domain → infrastructure)
-- [ ] File I/O abstracted (dependency injection)
-- [ ] Database access abstracted (repository pattern)
-- [ ] Functional core, imperative shell pattern
-- [ ] Immutable data structures preferred
-
-## General Ruby Idioms Checklist
-
-- [ ] frozen_string_literal: true in all files
-- [ ] Consistent method parentheses style
-- [ ] Keyword arguments for methods with > 2 params
-- [ ] Parameter objects for long parameter lists
-- [ ] Consistent hash access (symbols vs strings)
-- [ ] Specific exception rescues (not bare rescue)
-- [ ] ENV access centralized
-- [ ] Boolean traps eliminated (use explicit values)
-- [ ] Ruby 3 features used where appropriate
-- [ ] Standard Ruby linter passing

data/.claude/skills/setup-memory

@@ -1 +0,0 @@
-../../skills/setup-memory