Initial release: 100-file Claude Code toolkit

20 specialized agents, 10 skills, 17 slash commands, 6 plugins,
12 hooks with scripts, 8 rule sets, 3 CLAUDE.md templates,
14 MCP server configs, and interactive setup installer.

plugins/smart-commit/.claude-plugin/plugin.json

@@ -0,0 +1,6 @@
+{
+  "name": "smart-commit",
+  "version": "1.0.0",
+  "description": "Intelligent git commits with conventional format, semantic analysis, and changelog generation",
+  "commands": ["commands/commit.md", "commands/changelog.md"]
+}

plugins/smart-commit/commands/changelog.md

@@ -0,0 +1,64 @@
+# /smart-commit:changelog
+
+Parse the git history since the last release tag and generate a structured markdown changelog.
+
+## Process
+
+1. Identify the latest release tag by running `git tag --sort=-v:refname | head -20`.
+   - Look for semver-formatted tags (v1.2.3, 1.2.3, etc.)
+   - If no tags exist, use the initial commit as the starting point
+
+2. Retrieve all commits since the last tag:
+   ```
+   git log <last-tag>..HEAD --pretty=format:"%H|%s|%an|%ad" --date=short
+   ```
+
+3. Parse each commit message and categorize by conventional commit type:
+   - **Added** - `feat` commits introducing new functionality
+   - **Fixed** - `fix` commits correcting bugs or errors
+   - **Changed** - `refactor`, `perf`, `style` commits modifying existing behavior
+   - **Deprecated** - commits mentioning deprecation in subject or body
+   - **Removed** - commits removing features, files, or dead code
+   - **Security** - commits addressing vulnerabilities or security concerns
+   - **Documentation** - `docs` commits
+   - **Internal** - `chore`, `ci`, `test`, `build` commits
+
+4. For each commit entry, format as:
+   - Concise description derived from the commit subject
+   - Scope in parentheses if present
+   - Shortened commit hash as a reference
+
+5. Suggest the next version number based on changes:
+   - MAJOR bump if any `BREAKING CHANGE` footers are present
+   - MINOR bump if any `feat` commits are present
+   - PATCH bump if only `fix`, `refactor`, `perf`, `docs`, `chore` commits
+
+6. Generate the changelog in Keep a Changelog format.
+
+## Output Format
+
+```markdown
+## [X.Y.Z] - YYYY-MM-DD
+
+### Added
+- Description of new feature (scope) [`abc1234`]
+
+### Fixed
+- Description of bug fix (scope) [`def5678`]
+
+### Changed
+- Description of modification (scope) [`ghi9012`]
+
+### Internal
+- Description of internal change [`jkl3456`]
+```
+
+## Rules
+
+- Group entries by category, not chronologically
+- Omit empty categories entirely
+- Keep descriptions user-facing: translate technical commits into impact statements
+- If a commit message is unclear, read the diff with `git show <hash> --stat` for context
+- Merge commits and revert-of-reverts should be excluded
+- Present the changelog for review before writing to CHANGELOG.md
+- Prepend to existing CHANGELOG.md if one exists, do not overwrite history

plugins/smart-commit/commands/commit.md

@@ -0,0 +1,59 @@
+# /smart-commit:commit
+
+Analyze all staged git changes and generate an intelligent conventional commit message.
+
+## Process
+
+1. Run `git diff --cached --stat` to identify all staged files and their change magnitudes.
+2. Run `git diff --cached` to read the full diff of staged changes.
+3. Determine the primary commit type based on the nature of changes:
+   - `feat` - New functionality, new files introducing features, new endpoints or UI components
+   - `fix` - Bug corrections, error handling improvements, null checks, edge case fixes
+   - `refactor` - Code restructuring without behavior change, renaming, extraction of functions
+   - `docs` - Documentation-only changes, comments, README updates, docstrings
+   - `test` - Adding or modifying tests, test fixtures, test utilities
+   - `chore` - Build config, dependency updates, CI changes, tooling, linting rules
+   - `perf` - Performance improvements, caching, query optimization, lazy loading
+   - `style` - Formatting, whitespace, semicolons, code style (no logic change)
+   - `ci` - CI/CD pipeline changes, workflow files, deployment configs
+
+4. Derive the scope from the most affected directory or module:
+   - Use the top-level directory name if changes span one area (e.g., `auth`, `api`, `ui`)
+   - Use a broader scope if changes span multiple areas (e.g., `core`, `app`)
+   - Omit scope if changes are truly cross-cutting or trivial
+
+5. Write the commit subject line (max 72 characters):
+   - Use imperative mood ("add" not "added", "fix" not "fixes")
+   - Focus on WHY the change was made, not WHAT files changed
+   - Be specific: "fix race condition in websocket reconnect" not "fix bug"
+   - Do not end with a period
+
+6. Determine if a body is needed (skip for obvious single-line changes):
+   - Explain the motivation behind the change
+   - Describe the approach taken and why alternatives were rejected
+   - Keep each line under 80 characters
+
+7. Add footers when applicable:
+   - `BREAKING CHANGE: <description>` if the change breaks existing APIs or behavior
+   - `Closes #<number>` if the change resolves a tracked issue
+   - `Refs: <context>` for related PRs, issues, or discussions
+
+8. Present the commit message for review, then execute `git commit` with the approved message.
+
+## Output Format
+
+```
+type(scope): concise imperative description
+
+Optional body explaining the motivation and approach.
+
+Optional footers.
+```
+
+## Rules
+
+- Never fabricate issue numbers or references
+- If multiple types apply equally, prefer the one with the largest behavioral impact
+- When in doubt between `feat` and `refactor`, ask: does the user-visible behavior change?
+- Run `git log --oneline -10` first to match the repository's existing commit style
+- If nothing is staged, inform the user and suggest what to stage