@kurokeita/add-skill 1.13.0 → 1.14.0

package/dist/skills/git-branch/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: git-branch
+description: This skill should be used when the user asks to "create a branch", "branch naming", "branch strategy", or "follow conventional branch". Provides guidelines for version control branching strategies and rules.
+version: 1.0.0
+---
+
+# Git Branch
+
+Guide for managing version control branching strategies following the Conventional Branch specification.
+
+## When to Use This Skill
+
+- Creating new feature, bugfix, or maintenance branches
+- Ensuring branch names follow project standards
+- Managing branch lifecycle and organization
+- Integrating issue tracker IDs into branch names
+
+## Branching Strategy
+
+Follow the [Conventional Branch](https://conventional-branch.github.io/) specification for consistent and descriptive branch naming.
+
+### Structure
+
+The branch structure follows a categorized format:
+`<type>/<description>`
+
+### Types (`<type>`)
+
+- `main`: The primary development branch (e.g., `main`, `master`, or `develop`).
+- `feat/`: For new features (e.g., `feat/add-login-page`).
+- `fix/`: For bug fixes (e.g., `fix/header-bug`).
+- `hotfix/`: For urgent production fixes (e.g., `hotfix/security-patch`).
+- `release/`: For preparing a new release (e.g., `release/v1.2.0`).
+- `chore/`: For non-code tasks like dependencies or documentation updates (e.g., `chore/update-dependencies`).
+
+### Naming Rules
+
+- **Character Set**: Use lowercase alphanumerics (`a-z`, `0-9`), hyphens (`-`), and dots (`.`).
+- **Separators**: Use hyphens to separate words in the description. Dots are permitted in `release/` branches for versioning.
+- **Restrictions**:
+  - Avoid special characters, underscores, or spaces.
+  - No consecutive hyphens or dots (e.g., avoid `new--login`).
+  - No leading or trailing hyphens/dots in the description.
+- **Conciseness**: Keep names descriptive yet brief.
+- **Ticket Integration**: Include project management ticket numbers if applicable (e.g., `feat/issue-123-new-login`).
+
+### Workflow
+
+1. Start from the main integration branch.
+2. Ensure the local branch is up-to-date: `git pull origin main`.
+3. Create the new branch: `git checkout -b <type>/<description>`.
+
+## Additional Resources
+
+### Reference Files
+
+For detailed patterns and advanced git workflows, consult:
+
+- **`references/branching-workflows.md`** - Advanced branching and merging strategies.

package/dist/skills/git-clean/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: git-clean
+description: This skill should be used when the user asks to "clean the repository", "remove stale branches", "clear old stashes", "manage git hygiene", or "scan for redundant worktrees". Uses the @kurokeita/git-clean-up tool to audit and safely remove unused Git resources.
+version: 1.0.0
+---
+
+# Git Clean Skill
+
+Maintain repository hygiene by scanning for and removing stale branches, forgotten stashes, and redundant worktrees using the `@kurokeita/git-clean-up` tool.
+
+## When to Use This Skill
+
+- Auditing the repository for stale or merged branches.
+- Cleaning up old stashes or redundant Git worktrees.
+- Improving local performance by removing unneeded Git objects.
+- Automating repository hygiene tasks.
+
+## Workflow
+
+Follow this procedure to safely clean the repository:
+
+### 1. Detect package runner
+
+Determine whether to use `pnpx` or `npx` by checking if `pnpm` is installed. Always prioritize `pnpx`.
+
+```bash
+# Check for pnpm
+pnpm --version
+```
+
+- If `pnpm` is available: Use `pnpx @kurokeita/git-clean-up`
+- If `pnpm` is NOT available: Use `npx @kurokeita/git-clean-up`
+
+### 2. Audit findings
+
+Run an initial scan using the `--json` flag to identify hygiene issues without making any changes. This enables precise analysis of the findings.
+
+```bash
+<runner> @kurokeita/git-clean-up scan --json
+```
+
+### 3. Present report
+
+Summarize the findings for the user, categorized by:
+
+- **Branches**: Merged, squash-merged, or branches without upstreams.
+- **Stashes**: Old stashes or stale WIPs.
+- **Worktrees**: Missing paths or detached HEADs.
+
+### 4. Solicit confirmation
+
+Present the findings to the user and ask which items or categories they would like to clean. Do NOT proceed to deletion without explicit user approval.
+
+### 5. Preview cleanup (Optional but Recommended)
+
+If the user wants to see exactly what will be deleted for a specific selection, run the clean command without the `--apply` flag.
+
+```bash
+# Preview all deletions
+<runner> @kurokeita/git-clean-up clean --all
+
+# Preview specific categories
+<runner> @kurokeita/git-clean-up clean --include branches,stashes
+```
+
+### 6. Execute cleanup
+
+After receiving confirmation, run the clean command with the `--apply` flag.
+
+```bash
+# Clean everything confirmed
+<runner> @kurokeita/git-clean-up clean --apply --all
+
+# Clean specific categories
+<runner> @kurokeita/git-clean-up clean --apply --include branches
+```
+
+## Safety Considerations
+
+- **Protected Branches**: The tool automatically protects `main`, `master`, `develop`, and `dev`. Do not attempt to override these protections unless explicitly instructed.
+- **Active Branches**: Branches checked out in other worktrees are skipped by default.
+- **Verification**: Always verify the list of findings with the user before applying deletions.
+
+## Additional Resources
+
+### Reference Files
+
+- **`references/tool-options.md`**: Detailed CLI options and configuration settings for `git-clean-up`.
+
+### Example Configurations
+
+- **`examples/config.json`**: Sample `.git-clean-up.json` for repository-specific hygiene policies.

package/dist/skills/git-clean/examples/config.json

@@ -0,0 +1,7 @@
+{
+	"protectedBranches": ["release/*", "hotfix/*", "production"],
+	"includeCategories": ["branches", "stashes", "worktrees"],
+	"stashAgeDays": 21,
+	"defaultTargetBranch": "origin/main",
+	"branchInactiveDays": 60
+}

package/dist/skills/git-clean/references/tool-options.md

@@ -0,0 +1,59 @@
+# Git Clean Up Tool Options
+
+Detailed reference for CLI options and configuration settings for the `@kurokeita/git-clean-up` tool.
+
+## Core Commands
+
+### `scan`
+
+Audits the repository and lists hygiene issues without modifying any resources.
+
+**Options:**
+
+- `--json`: Output findings in JSON format for programmatic parsing.
+- `--include <categories>`: Comma-separated list of categories to scan (branches, stashes, worktrees).
+- `--target <branch>`: Specify the primary integration branch (default: `main` or `master`).
+- `--age-days <number>`: Filter stashes or inactive branches older than X days.
+
+### `clean`
+
+Previews or applies deletions based on hygiene audit results.
+
+**Options:**
+
+- `--apply`: Actually execute the deletion of selected items. Without this flag, the command only provides a preview.
+- `--all`: Select all identified hygiene issues for cleanup.
+- `--include <categories>`: Limit cleanup to specific categories (e.g., `--include branches`).
+- `--force`: Force removal even if safety checks fail (use with extreme caution).
+
+## Configuration File
+
+Behavior can be customized using a `.git-clean-up.json` file in the repository root or a global configuration at `~/.git-clean-up.json`.
+
+### Example Configuration
+
+```json
+{
+  "protectedBranches": [
+    "release/*",
+    "hotfix/*",
+    "production"
+  ],
+  "includeCategories": [
+    "branches",
+    "stashes",
+    "worktrees"
+  ],
+  "stashAgeDays": 14,
+  "defaultTargetBranch": "origin/develop",
+  "branchInactiveDays": 30
+}
+```
+
+## Policy Enforcement (CI Mode)
+
+The tool can be used in CI pipelines to enforce repository hygiene.
+
+- `--fail-on <level>`: Exit with a non-zero code if findings of a certain risk level (low, medium, high) are found.
+- `--max-findings <number>`: Fail if the total number of hygiene issues exceeds the specified threshold.
+- `--summary`: Output a high-level summary of findings, ideal for build logs.

package/dist/skills/git-commit/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: git-commit
+description: This skill should be used when the user asks to "commit changes", "commit message", or "follow conventional commits". Provides guidelines for Conventional Commits specification and commit message formatting.
+version: 1.0.0
+---
+
+# Git Commit
+
+Guide for managing version control commit message formatting following the Conventional Commits specification.
+
+## When to Use This Skill
+
+- Formatting commit messages to follow project standards
+- Learning the Conventional Commits specification
+- Ensuring consistency across the repository's history
+
+## Conventional Commits
+
+Format commit messages according to the [Conventional Commits](https://www.conventionalcommits.org/) specification to enable automated changelog generation and easier history browsing.
+
+### Structure
+
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Types
+
+- `feat`: A new feature
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `perf`: A code change that improves performance
+- `test`: Adding missing tests or correcting existing tests
+- `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+- `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+- `chore`: Other changes that don't modify src or test files
+- `revert`: Reverts a previous commit
+
+### Guidelines
+
+- **Description**: Use the imperative, present tense (e.g., "add", not "added" or "adds").
+- **Case**: The description should be in lower-case or sentence-case.
+- **Scope**: Use a scope to provide additional contextual information (e.g., `feat(auth): add login validation`).
+- **Body**: Use the body to explain the "what" and "why" of the change, not the "how".
+- **Footer**: Use the footer to reference issues (e.g., `Closes #123`) or breaking changes.
+
+## Additional Resources
+
+### Reference Files
+
+For detailed patterns and advanced git workflows, consult:
+
+- **`references/conventional-commits.md`** - Detailed Conventional Commits specification.
+
+### Example Files
+
+Working examples in `examples/`:
+
+- **`commit-messages.txt`** - Examples of well-formatted commit messages.

package/dist/skills/git-pr/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: git-pr
+description: This skill should be used when the user asks to "create a pull request", "open a PR", "prepare a pull request", or "review a PR description". Provides guidelines for effective pull request management and industry-standard templates.
+version: 1.0.0
+---
+
+# Git Pull Request
+
+Guide for creating and managing clear and informative pull requests to facilitate effective code review and collaboration.
+
+## When to Use This Skill
+
+- Preparing and creating pull requests
+- Writing pull request descriptions
+- Ensuring pull requests meet quality standards before submission
+- Managing the PR lifecycle and reviewer feedback
+
+## Pull Request Management
+
+Create clear and informative pull requests to ensure that reviewers can understand the impact and context of your changes.
+
+### PR Creation Process
+
+1. **Push your branch**: `git push origin <branch-name>`.
+2. **Open the PR**: Use the GitHub CLI or web interface.
+3. **Title**: Use the Conventional Commits format for the title (e.g., `feat(ui): add dashboard widgets`).
+4. **Description**: Use a template (if available) to describe:
+    - What changes were made.
+    - Why they were made.
+    - How they were tested.
+    - Any breaking changes or new dependencies.
+
+### Best Practices
+
+- **Keep it focused**: One PR per logical change. Avoid "mega-PRs".
+- **Self-review**: Review your own changes before asking others.
+- **Link issues**: Use keywords like `Fixes #123` or `Closes #123` in the description.
+- **Update regularly**: Rebase or merge from the main branch if the PR becomes stale.
+
+## Additional Resources
+
+### Reference Files
+
+For detailed patterns and industry-standard analysis, consult:
+
+- **`references/pr-best-practices.md`** - Analysis of PR patterns from top repositories.
+
+### Example Files
+
+Working examples in `examples/`:
+
+- **`pr-description-template.md`** - A standard, industry-standard PR description template.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kurokeita/add-skill",
-	"version": "1.13.0",
+	"version": "1.14.0",
 	"description": "CLI to install AI agent skills to various platforms",
 	"type": "module",
 	"bin": {

package/dist/skills/git-convention/SKILL.md

@@ -1,112 +0,0 @@
----
-name: git-convention
-description: This skill should be used when the user asks to "create a branch", "commit changes", "create a pull request", "manage branches", or "follow conventional commits". Provides guidelines for version control workflows and commit message formatting.
-version: 1.0.0
----
-
-# Git Convention
-
-Guide for managing version control workflows, including branching strategies, commit message formatting following Conventional Commits, and pull request management.
-
-## When to Use This Skill
-
-- Creating new feature, bugfix, or maintenance branches
-- Formatting commit messages to follow project standards
-- Preparing and creating pull requests
-- Managing branch lifecycle and cleanup
-- Ensuring consistency across the repository's history
-
-## Branching Strategy
-
-Follow a consistent naming convention for branches to ensure clarity and organization.
-
-### Branch Naming Convention
-
-Use a prefix followed by a descriptive name in kebab-case:
-
-- `feature/` - New features or significant functional additions (e.g., `feature/user-authentication`)
-- `fix/` - Bug fixes and patches (e.g., `fix/login-error`)
-- `refactor/` - Code restructuring without changing behavior (e.g., `refactor/api-client`)
-- `docs/` - Documentation updates (e.g., `docs/update-readme`)
-- `chore/` - Maintenance tasks, dependency updates, or internal tooling (e.g., `chore/update-deps`)
-- `test/` - Adding or modifying tests (e.g., `test/unit-tests-auth`)
-
-### Workflow
-
-1. Start from the main integration branch (e.g., `main` or `develop`).
-2. Ensure the local branch is up-to-date: `git pull origin main`.
-3. Create the new branch: `git checkout -b <prefix>/<description>`.
-
-## Conventional Commits
-
-Format commit messages according to the [Conventional Commits](https://www.conventionalcommits.org/) specification to enable automated changelog generation and easier history browsing.
-
-### Structure
-
-```
-<type>(<scope>): <description>
-
-[optional body]
-
-[optional footer(s)]
-```
-
-### Types
-
-- `feat`: A new feature
-- `fix`: A bug fix
-- `docs`: Documentation only changes
-- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
-- `refactor`: A code change that neither fixes a bug nor adds a feature
-- `perf`: A code change that improves performance
-- `test`: Adding missing tests or correcting existing tests
-- `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
-- `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
-- `chore`: Other changes that don't modify src or test files
-- `revert`: Reverts a previous commit
-
-### Guidelines
-
-- **Description**: Use the imperative, present tense (e.g., "add", not "added" or "adds").
-- **Case**: The description should be in lower-case or sentence-case.
-- **Scope**: Use a scope to provide additional contextual information (e.g., `feat(auth): add login validation`).
-- **Body**: Use the body to explain the "what" and "why" of the change, not the "how".
-- **Footer**: Use the footer to reference issues (e.g., `Closes #123`) or breaking changes.
-
-## Pull Request Management
-
-Create clear and informative pull requests to facilitate effective code review and collaboration.
-
-### PR Creation Process
-
-1. **Push your branch**: `git push origin <branch-name>`.
-2. **Open the PR**: Use the GitHub CLI or web interface.
-3. **Title**: Use the Conventional Commits format for the title (e.g., `feat(ui): add dashboard widgets`).
-4. **Description**: Use a template (if available) to describe:
-    - What changes were made.
-    - Why they were made.
-    - How they were tested.
-    - Any breaking changes or new dependencies.
-
-### Best Practices
-
-- **Keep it focused**: One PR per logical change. Avoid "mega-PRs".
-- **Self-review**: Review your own changes before asking others.
-- **Link issues**: Use keywords like `Fixes #123` or `Closes #123` in the description.
-- **Update regularly**: Rebase or merge from the main branch if the PR becomes stale.
-
-## Additional Resources
-
-### Reference Files
-
-For detailed patterns and advanced git workflows, consult:
-
-- **`references/conventional-commits.md`** - Detailed Conventional Commits specification.
-- **`references/branching-workflows.md`** - Advanced branching and merging strategies.
-
-### Example Files
-
-Working examples in `examples/`:
-
-- **`commit-messages.txt`** - Examples of well-formatted commit messages.
-- **`pr-description-template.md`** - A standard PR description template.