feat: add ClaudeKit configuration

Add agent definitions, slash commands, hooks, and settings for
Claude Code project tooling.

.claude/commands/git/checkout.md

@@ -0,0 +1,108 @@
+---
+description: Smart branch creation and switching with conventional naming
+allowed-tools: Bash(git:*), Read
+category: workflow
+argument-hint: "<branch-type/branch-name | branch-name>"
+---
+
+# Git Checkout: Smart Branch Management
+
+Create or switch to branches with intelligent naming conventions and setup.
+
+## Current Branch Status
+
+!`git branch --show-current 2>/dev/null || echo "(no branch)"`
+
+## Available Branches
+
+!`git branch -a 2>/dev/null | head -20`
+
+## Branch Creation Task
+
+Based on the arguments provided: `$ARGUMENTS`
+
+Parse the branch specification and create/switch to the appropriate branch.
+
+### Supported Branch Types
+- `feature/` - New features and enhancements
+- `bugfix/` - Bug fixes (non-critical)
+- `hotfix/` - Urgent production fixes
+- `release/` - Release preparation branches
+- `chore/` - Maintenance and cleanup tasks
+- `experiment/` - Experimental features
+- `docs/` - Documentation updates
+- `test/` - Test-related changes
+- `refactor/` - Code refactoring
+
+### Branch Naming Rules
+1. If argument contains `/`, use as-is (e.g., `feature/user-auth`)
+2. If argument is single word, suggest adding a prefix
+3. Convert spaces to hyphens
+4. Lowercase all characters
+5. Remove special characters except hyphens and slashes
+6. Validate branch name is git-compatible
+
+### Workflow
+
+1. **Parse the branch argument**:
+   - If empty, show current branch and available branches
+   - If contains `/`, treat as type/name format
+   - If single word without `/`, ask for branch type or suggest `feature/`
+
+2. **Validate branch name**:
+   - Check if branch already exists locally
+   - Check if branch exists on remote
+   - Ensure name follows git conventions
+   - Warn if name is too long (>50 chars)
+
+3. **Create or switch branch**:
+   - If branch exists locally: `git checkout <branch>`
+   - If branch exists only on remote: `git checkout -b <branch> origin/<branch>`
+   - If new branch: `git checkout -b <branch>`
+
+4. **Set up branch configuration**:
+   - For hotfix branches: Base off main/master
+   - For feature branches: Base off current branch or develop
+   - For release branches: Base off develop or main
+
+5. **Report status**:
+   - Confirm branch switch/creation
+   - Show upstream tracking status
+   - Suggest next steps (e.g., "Ready to start working. Use /git:push to set upstream when ready to push.")
+
+### Examples
+
+```bash
+# Create feature branch
+/git:checkout feature/user-authentication
+
+# Create hotfix from main
+/git:checkout hotfix/security-patch
+
+# Switch to existing branch
+/git:checkout develop
+
+# Create branch without prefix (will prompt)
+/git:checkout payment-integration
+```
+
+### Special Handling
+
+For hotfix branches:
+- Automatically checkout from main/master first
+- Set high priority indicator
+- Suggest immediate push after fix
+
+For feature branches:
+- Check if develop branch exists, use as base
+- Otherwise use current branch as base
+
+For release branches:
+- Validate version format if provided (e.g., release/v1.2.0)
+- Set up from develop or main
+
+### Error Handling
+
+- If branch name is invalid, suggest corrections
+- If checkout fails, show git error and provide guidance
+- If working directory is dirty, warn and suggest stashing or committing

.claude/commands/git/commit.md

@@ -0,0 +1,76 @@
+---
+description: Create a git commit following the project's established style
+category: workflow
+allowed-tools: Bash(git:*), Bash(echo:*), Bash(head:*), Bash(wc:*), Bash(test:*), Bash([:[*), Bash(grep:*), Read, Edit, Task
+---
+
+Create a git commit following the project's established style
+
+## Git Expert Integration
+For complex commit scenarios (merge commits, conflict resolution, commit history issues, interactive rebasing), consider using the Task tool with `git-expert` subagent for specialized git expertise.
+
+## Efficiency Note:
+This command intelligently reuses recent git:status results when available to avoid redundant operations. If you just ran /git:status, the commit process will be faster.
+
+When git conventions are already documented in CLAUDE.md/AGENTS.md, use them directly without verbose explanation.
+
+All git commands are combined into a single bash call for maximum speed.
+
+## Steps:
+1. Check if the previous message contains git:status results:
+   - Look for patterns like "Git Status Analysis", "Modified Files:", "Uncommitted Changes:"
+   - If found and recent (within last 2-3 messages): Reuse those results
+   - If not found or stale: Run a single combined git command:
+   !git --no-pager status --porcelain=v1 && echo "---STAT---" && git --no-pager diff --stat 2>/dev/null && echo "---DIFF---" && git --no-pager diff 2>/dev/null | head -2000 && echo "---LOG---" && git --no-pager log --oneline -5
+   - Note: Only skip git status if you're confident the working directory hasn't changed
+   - Note: Full diff is capped at 2000 lines to prevent context flooding. The stat summary above shows all changed files
+2. Review the diff output to verify:
+   - No sensitive information (passwords, API keys, tokens) in the changes
+   - No debugging code or console.log statements left in production code
+   - No temporary debugging scripts (test-*.js, debug-*.py, etc.) created by Claude Code
+   - No temporary files or outputs in inappropriate locations (move to project's temp directory or delete)
+   - All TODO/FIXME comments are addressed or intentionally left
+3. Use documented git commit conventions from CLAUDE.md/AGENTS.md
+   - If conventions are not documented, analyze recent commits and document them
+4. If the project uses ticket/task codes, ask the user for the relevant code if not clear from context
+5. Check if README.md or other documentation needs updating to reflect the changes (see "Documentation Updates" section below)
+6. Run tests and lint commands to ensure code quality (unless just ran before this command)
+7. Stage all relevant files (including any updated documentation)
+8. Create commit with appropriate message matching the project's conventions
+9. Verify commit succeeded - Report with ✅ success indicator
+10. Check if any post-commit hooks need to be considered (e.g., pushing to remote, creating PR)
+
+## Documentation Updates:
+Consider updating relevant documentation when committing changes:
+- README.md: New features, API changes, installation steps, usage examples
+- CHANGELOG.md: Notable changes, bug fixes, new features
+- API documentation: New endpoints, changed parameters, deprecated features
+- User guides: New workflows, updated procedures
+- Configuration docs: New settings, changed defaults
+
+## Commit Convention Documentation:
+Only when conventions are NOT already documented: Analyze the commit history and document the observed conventions in CLAUDE.md under a "Git Commit Conventions" section. Once documented, use them without verbose explanation.
+
+The documentation should capture whatever style the project uses, for example:
+- Simple descriptive messages: "Fix navigation bug"
+- Conventional commits: "feat(auth): add OAuth support"
+- Prefixed style: "[BUGFIX] Resolve memory leak in parser"
+- Task/ticket codes: "PROJ-123: Add user authentication"
+- JIRA integration: "ABC-456 Fix memory leak in parser"
+- GitHub issues: "#42 Update documentation"
+- Imperative mood: "Add user authentication"
+- Past tense: "Added user authentication"
+- Or any other project-specific convention
+
+Example CLAUDE.md section:
+```markdown
+## Git Commit Conventions
+Based on analysis of this project's git history:
+- Format: [observed format pattern]
+- Tense: [imperative/past/present]
+- Length: [typical subject line length]
+- Ticket codes: [if used, note the pattern like "PROJ-123:" or "ABC-456 "]
+- Other patterns: [any other observed conventions]
+
+Note: If ticket/task codes are used, always ask the user for the specific code rather than inventing one.
+```

.claude/commands/git/ignore-init.md

@@ -0,0 +1,62 @@
+---
+description: Initialize .gitignore with Claude Code specific patterns
+allowed-tools: Read, Edit, Write, Bash(echo:*), Bash(cat:*), Bash(test:*)
+category: workflow
+---
+
+# Initialize .gitignore for Claude Code
+
+Set up or update the project's .gitignore file with Claude Code specific patterns.
+
+## Core Claude Code Files to Ignore
+
+Ensure these Claude Code local configuration files are ignored:
+- `CLAUDE.local.md` - Local AI assistant instructions (root)
+- `.claude/settings.local.json` - Personal Claude Code settings
+- `.mcp.local.json` - Local MCP server configuration (root)
+
+## Development Patterns
+
+These common development artifacts will also be added:
+- `temp/` - Temporary working directory
+- `temp-*/` - Temporary directories with prefix
+- `test-*/` - Test directories with prefix
+- `debug-*.js` - Debug scripts
+- `test-*.js` - Test scripts
+- `*-test.js` - Test files with suffix
+- `*-debug.js` - Debug files with suffix
+
+## Current .gitignore Status
+
+!`[ -f .gitignore ] && echo "EXISTS: .gitignore found" && echo "---CONTENTS---" && cat .gitignore || echo "MISSING: No .gitignore file found"`
+
+## Task
+
+Based on the above status:
+1. Create `.gitignore` if it doesn't exist
+2. Add all patterns that aren't already present
+3. Preserve existing entries and comments
+4. Report what was added
+
+## Patterns to Add
+
+```gitignore
+# Claude Code local files
+CLAUDE.local.md
+.claude/settings.local.json
+.mcp.local.json
+
+# Temporary and debug files
+temp/
+temp-*/
+test-*/
+debug-*.js
+test-*.js
+*-test.js
+*-debug.js
+```
+
+Implement this by:
+1. Using the gitignore status above to determine what's missing
+2. Adding missing patterns with appropriate comments
+3. Preserving the existing file structure and entries

.claude/commands/git/push.md

@@ -0,0 +1,47 @@
+---
+description: Intelligently push commits to remote with safety checks and insights
+category: workflow
+allowed-tools: Bash(git:*), Task
+---
+
+Push commits to remote repository with appropriate safety checks and branch management.
+
+## Git Expert Integration
+For complex push scenarios (force push requirements, diverged branches, upstream conflicts, protected branch workflows), consider using the Task tool with `git-expert` subagent for specialized git expertise.
+
+## Efficiency Note:
+Be concise. Use single bash calls where possible. Skip verbose explanations and intermediate status messages. Execute the push directly if safe, show only the result.
+
+## Instructions for Claude:
+
+1. Run safety checks in a single bash call:
+!git status --porcelain=v1 && echo "---" && git branch -vv | grep "^\*" && echo "---" && git remote -v | head -2 && echo "---" && git log --oneline @{u}..HEAD 2>/dev/null
+
+Parse output to check:
+- Any uncommitted changes (warn if present)
+- Current branch and tracking info
+- Remote repository URL
+- Commits to be pushed
+
+2. If safe to push (no uncommitted changes), execute push immediately:
+   - For tracked branch: `git push`
+   - For new branch: `git push -u origin [branch-name]`
+   - If behind remote: Stop and suggest `git pull --rebase`
+
+3. Show only the final result:
+   - If successful: Show the push output with ✅ emoji and success message
+   - If failed: Show error and suggest fix
+   - If unsafe: Show what needs to be done first
+
+4. Special cases to handle:
+   - Diverged branches: Suggest rebase or merge strategy
+   - No upstream branch: Use -u flag
+   - Force push needed: Warn strongly, require confirmation
+   - Protected branch: Remind about PR workflow
+
+Example concise output:
+- Skip: "Let me check if it's safe to push"
+- Skip: "I'll analyze your branch status"
+- Skip: "Ready to push X commits"
+- Skip: "Executing push..."
+- Just show the push result directly

.claude/commands/git/status.md

@@ -0,0 +1,42 @@
+---
+description: Intelligently analyze git status and provide insights about current project state
+category: workflow
+allowed-tools: Bash(git:*), Task
+---
+
+Analyze the current git status and provide an intelligent summary of what's happening in the project.
+
+## Git Expert Integration
+For complex git analysis scenarios (merge conflicts, complex branch states, repository issues), consider using the Task tool with `git-expert` subagent for specialized git expertise.
+
+## Efficiency Note:
+Be concise. Skip verbose explanations of what commands you're running. Focus on the actual status results.
+
+## Instructions for Claude:
+
+1. Run all git commands in a single bash call for speed:
+!git status --porcelain=v1 && echo "---" && git diff --stat 2>/dev/null && echo "---" && git branch -vv | grep "^\*" && echo "---" && git log --oneline -1 && echo "---" && git diff --cached --stat 2>/dev/null
+
+Note: The output will be separated by "---" markers. Parse each section accordingly.
+
+3. Provide results directly without explaining the process:
+   - **Summary**: Brief overview of the current state
+   - **Modified Files**: Group by type (docs, code, tests, config)
+   - **Uncommitted Changes**: What's been changed and why it might matter
+   - **Branch Status**: Relationship to remote branch
+   - **Suggestions**: What actions might be appropriate
+
+Provide insights about:
+- Whether changes appear related or should be separate commits
+- If any critical files are modified (package.json, config files, etc.)
+- Whether the working directory is clean for operations like rebasing
+- Any patterns in the modifications (e.g., all test files, all docs, etc.)
+- If there are stashed changes that might be forgotten
+
+Make the output concise but informative, focusing on what matters most to the developer.
+
+Example of concise output:
+- Skip: "I'll analyze the current git status for you."
+- Skip: "Let me gather the details efficiently:"
+- Skip: "I see there are changes. Let me gather the details:"
+- Just show the results directly