claude-code-templates 1.21.13 → 1.22.0

package/cli-tool/components/commands/git-workflow/commit.md

@@ -1,167 +0,0 @@
----
-allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*)
-argument-hint: [message] | --no-verify | --amend
-description: Create well-formatted commits with conventional commit format and emoji
-model: sonnet
----
-
-# Smart Git Commit
-
-Create well-formatted commit: $ARGUMENTS
-
-## Current Repository State
-
-- Git status: !`git status --porcelain`
-- Current branch: !`git branch --show-current`
-- Staged changes: !`git diff --cached --stat`
-- Unstaged changes: !`git diff --stat`
-- Recent commits: !`git log --oneline -5`
-
-## What This Command Does
-
-1. Unless specified with `--no-verify`, automatically runs pre-commit checks:
-   - `pnpm lint` to ensure code quality
-   - `pnpm build` to verify the build succeeds
-   - `pnpm generate:docs` to update documentation
-2. Checks which files are staged with `git status`
-3. If 0 files are staged, automatically adds all modified and new files with `git add`
-4. Performs a `git diff` to understand what changes are being committed
-5. Analyzes the diff to determine if multiple distinct logical changes are present
-6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
-7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
-
-## Best Practices for Commits
-
-- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
-- **Atomic commits**: Each commit should contain related changes that serve a single purpose
-- **Split large changes**: If changes touch multiple concerns, split them into separate commits
-- **Conventional commit format**: Use the format `<type>: <description>` where type is one of:
-  - `feat`: A new feature
-  - `fix`: A bug fix
-  - `docs`: Documentation changes
-  - `style`: Code style changes (formatting, etc)
-  - `refactor`: Code changes that neither fix bugs nor add features
-  - `perf`: Performance improvements
-  - `test`: Adding or fixing tests
-  - `chore`: Changes to the build process, tools, etc.
-- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
-- **Concise first line**: Keep the first line under 72 characters
-- **Emoji**: Each commit type is paired with an appropriate emoji:
-  - ✨ `feat`: New feature
-  - 🐛 `fix`: Bug fix
-  - 📝 `docs`: Documentation
-  - 💄 `style`: Formatting/style
-  - ♻️ `refactor`: Code refactoring
-  - ⚡️ `perf`: Performance improvements
-  - ✅ `test`: Tests
-  - 🔧 `chore`: Tooling, configuration
-  - 🚀 `ci`: CI/CD improvements
-  - 🗑️ `revert`: Reverting changes
-  - 🧪 `test`: Add a failing test
-  - 🚨 `fix`: Fix compiler/linter warnings
-  - 🔒️ `fix`: Fix security issues
-  - 👥 `chore`: Add or update contributors
-  - 🚚 `refactor`: Move or rename resources
-  - 🏗️ `refactor`: Make architectural changes
-  - 🔀 `chore`: Merge branches
-  - 📦️ `chore`: Add or update compiled files or packages
-  - ➕ `chore`: Add a dependency
-  - ➖ `chore`: Remove a dependency
-  - 🌱 `chore`: Add or update seed files
-  - 🧑‍💻 `chore`: Improve developer experience
-  - 🧵 `feat`: Add or update code related to multithreading or concurrency
-  - 🔍️ `feat`: Improve SEO
-  - 🏷️ `feat`: Add or update types
-  - 💬 `feat`: Add or update text and literals
-  - 🌐 `feat`: Internationalization and localization
-  - 👔 `feat`: Add or update business logic
-  - 📱 `feat`: Work on responsive design
-  - 🚸 `feat`: Improve user experience / usability
-  - 🩹 `fix`: Simple fix for a non-critical issue
-  - 🥅 `fix`: Catch errors
-  - 👽️ `fix`: Update code due to external API changes
-  - 🔥 `fix`: Remove code or files
-  - 🎨 `style`: Improve structure/format of the code
-  - 🚑️ `fix`: Critical hotfix
-  - 🎉 `chore`: Begin a project
-  - 🔖 `chore`: Release/Version tags
-  - 🚧 `wip`: Work in progress
-  - 💚 `fix`: Fix CI build
-  - 📌 `chore`: Pin dependencies to specific versions
-  - 👷 `ci`: Add or update CI build system
-  - 📈 `feat`: Add or update analytics or tracking code
-  - ✏️ `fix`: Fix typos
-  - ⏪️ `revert`: Revert changes
-  - 📄 `chore`: Add or update license
-  - 💥 `feat`: Introduce breaking changes
-  - 🍱 `assets`: Add or update assets
-  - ♿️ `feat`: Improve accessibility
-  - 💡 `docs`: Add or update comments in source code
-  - 🗃️ `db`: Perform database related changes
-  - 🔊 `feat`: Add or update logs
-  - 🔇 `fix`: Remove logs
-  - 🤡 `test`: Mock things
-  - 🥚 `feat`: Add or update an easter egg
-  - 🙈 `chore`: Add or update .gitignore file
-  - 📸 `test`: Add or update snapshots
-  - ⚗️ `experiment`: Perform experiments
-  - 🚩 `feat`: Add, update, or remove feature flags
-  - 💫 `ui`: Add or update animations and transitions
-  - ⚰️ `refactor`: Remove dead code
-  - 🦺 `feat`: Add or update code related to validation
-  - ✈️ `feat`: Improve offline support
-
-## Guidelines for Splitting Commits
-
-When analyzing the diff, consider splitting commits based on these criteria:
-
-1. **Different concerns**: Changes to unrelated parts of the codebase
-2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
-3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
-4. **Logical grouping**: Changes that would be easier to understand or review separately
-5. **Size**: Very large changes that would be clearer if broken down
-
-## Examples
-
-Good commit messages:
-- ✨ feat: add user authentication system
-- 🐛 fix: resolve memory leak in rendering process
-- 📝 docs: update API documentation with new endpoints
-- ♻️ refactor: simplify error handling logic in parser
-- 🚨 fix: resolve linter warnings in component files
-- 🧑‍💻 chore: improve developer tooling setup process
-- 👔 feat: implement business logic for transaction validation
-- 🩹 fix: address minor styling inconsistency in header
-- 🚑️ fix: patch critical security vulnerability in auth flow
-- 🎨 style: reorganize component structure for better readability
-- 🔥 fix: remove deprecated legacy code
-- 🦺 feat: add input validation for user registration form
-- 💚 fix: resolve failing CI pipeline tests
-- 📈 feat: implement analytics tracking for user engagement
-- 🔒️ fix: strengthen authentication password requirements
-- ♿️ feat: improve form accessibility for screen readers
-
-Example of splitting commits:
-- First commit: ✨ feat: add new solc version type definitions
-- Second commit: 📝 docs: update documentation for new solc versions
-- Third commit: 🔧 chore: update package.json dependencies
-- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
-- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
-- Sixth commit: 🚨 fix: resolve linting issues in new code
-- Seventh commit: ✅ test: add unit tests for new solc version features
-- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
-
-## Command Options
-
-- `--no-verify`: Skip running the pre-commit checks (lint, build, generate:docs)
-
-## Important Notes
-
-- By default, pre-commit checks (`pnpm lint`, `pnpm build`, `pnpm generate:docs`) will run to ensure code quality
-- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
-- If specific files are already staged, the command will only commit those files
-- If no files are staged, it will automatically stage all modified and new files
-- The commit message will be constructed based on the changes detected
-- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
-- If suggesting multiple commits, it will help you stage and commit the changes separately
-- Always reviews the commit diff to ensure the message matches the changes

package/cli-tool/components/commands/git-workflow/create-pr.md

@@ -1,19 +0,0 @@
-# Create Pull Request Command
-
-Create a new branch, commit changes, and submit a pull request.
-
-## Behavior
-- Creates a new branch based on current changes
-- Formats modified files using Biome
-- Analyzes changes and automatically splits into logical commits when appropriate
-- Each commit focuses on a single logical change or feature
-- Creates descriptive commit messages for each logical unit
-- Pushes branch to remote
-- Creates pull request with proper summary and test plan
-
-## Guidelines for Automatic Commit Splitting
-- Split commits by feature, component, or concern
-- Keep related file changes together in the same commit
-- Separate refactoring from feature additions
-- Ensure each commit can be understood independently
-- Multiple unrelated changes should be split into separate commits

package/cli-tool/components/commands/git-workflow/create-pull-request.md

@@ -1,126 +0,0 @@
-# How to Create a Pull Request Using GitHub CLI
-
-This guide explains how to create pull requests using GitHub CLI in our project.
-
-## Prerequisites
-
-1. Install GitHub CLI if you haven't already:
-
-   ```bash
-   # macOS
-   brew install gh
-
-   # Windows
-   winget install --id GitHub.cli
-
-   # Linux
-   # Follow instructions at https://github.com/cli/cli/blob/trunk/docs/install_linux.md
-   ```
-
-2. Authenticate with GitHub:
-   ```bash
-   gh auth login
-   ```
-
-## Creating a New Pull Request
-
-1. First, prepare your PR description following the template in `.github/pull_request_template.md`
-
-2. Use the `gh pr create` command to create a new pull request:
-
-   ```bash
-   # Basic command structure
-   gh pr create --title "✨(scope): Your descriptive title" --body "Your PR description" --base main --draft
-   ```
-
-   For more complex PR descriptions with proper formatting, use the `--body-file` option with the exact PR template structure:
-
-   ```bash
-   # Create PR with proper template structure
-   gh pr create --title "✨(scope): Your descriptive title" --body-file <(echo -e "## Issue\n\n- resolve:\n\n## Why is this change needed?\nYour description here.\n\n## What would you like reviewers to focus on?\n- Point 1\n- Point 2\n\n## Testing Verification\nHow you tested these changes.\n\n## What was done\npr_agent:summary\n\n## Detailed Changes\npr_agent:walkthrough\n\n## Additional Notes\nAny additional notes.") --base main --draft
-   ```
-
-## Best Practices
-
-1. **PR Title Format**: Use conventional commit format with emojis
-
-   - Always include an appropriate emoji at the beginning of the title
-   - Use the actual emoji character (not the code representation like `:sparkles:`)
-   - Examples:
-     - `✨(supabase): Add staging remote configuration`
-     - `🐛(auth): Fix login redirect issue`
-     - `📝(readme): Update installation instructions`
-
-2. **Description Template**: Always use our PR template structure from `.github/pull_request_template.md`:
-
-   - Issue reference
-   - Why the change is needed
-   - Review focus points
-   - Testing verification
-   - PR-Agent sections (keep `pr_agent:summary` and `pr_agent:walkthrough` tags intact)
-   - Additional notes
-
-3. **Template Accuracy**: Ensure your PR description precisely follows the template structure:
-
-   - Don't modify or rename the PR-Agent sections (`pr_agent:summary` and `pr_agent:walkthrough`)
-   - Keep all section headers exactly as they appear in the template
-   - Don't add custom sections that aren't in the template
-
-4. **Draft PRs**: Start as draft when the work is in progress
-   - Use `--draft` flag in the command
-   - Convert to ready for review when complete using `gh pr ready`
-
-### Common Mistakes to Avoid
-
-1. **Incorrect Section Headers**: Always use the exact section headers from the template
-2. **Modifying PR-Agent Sections**: Don't remove or modify the `pr_agent:summary` and `pr_agent:walkthrough` placeholders
-3. **Adding Custom Sections**: Stick to the sections defined in the template
-4. **Using Outdated Templates**: Always refer to the current `.github/pull_request_template.md` file
-
-### Missing Sections
-
-Always include all template sections, even if some are marked as "N/A" or "None"
-
-## Additional GitHub CLI PR Commands
-
-Here are some additional useful GitHub CLI commands for managing PRs:
-
-```bash
-# List your open pull requests
-gh pr list --author "@me"
-
-# Check PR status
-gh pr status
-
-# View a specific PR
-gh pr view <PR-NUMBER>
-
-# Check out a PR branch locally
-gh pr checkout <PR-NUMBER>
-
-# Convert a draft PR to ready for review
-gh pr ready <PR-NUMBER>
-
-# Add reviewers to a PR
-gh pr edit <PR-NUMBER> --add-reviewer username1,username2
-
-# Merge a PR
-gh pr merge <PR-NUMBER> --squash
-```
-
-## Using Templates for PR Creation
-
-To simplify PR creation with consistent descriptions, you can create a template file:
-
-1. Create a file named `pr-template.md` with your PR template
-2. Use it when creating PRs:
-
-```bash
-gh pr create --title "feat(scope): Your title" --body-file pr-template.md --base main --draft
-```
-
-## Related Documentation
-
-- [PR Template](.github/pull_request_template.md)
-- [Conventional Commits](https://www.conventionalcommits.org/)
-- [GitHub CLI documentation](https://cli.github.com/manual/)

package/cli-tool/components/commands/git-workflow/create-worktrees.md

@@ -1,174 +0,0 @@
-# Git Worktree Commands
-
-## Create Worktrees for All Open PRs
-
-This command fetches all open pull requests using GitHub CLI, then creates a git worktree for each PR's branch in the `./tree/<BRANCH_NAME>` directory.
-
-```bash
-# Ensure GitHub CLI is installed and authenticated
-gh auth status || (echo "Please run 'gh auth login' first" && exit 1)
-
-# Create the tree directory if it doesn't exist
-mkdir -p ./tree
-
-# List all open PRs and create worktrees for each branch
-gh pr list --json headRefName --jq '.[].headRefName' | while read branch; do
-  # Handle branch names with slashes (like "feature/foo")
-  branch_path="./tree/${branch}"
-  
-  # For branches with slashes, create the directory structure
-  if [[ "$branch" == */* ]]; then
-    dir_path=$(dirname "$branch_path")
-    mkdir -p "$dir_path"
-  fi
-
-  # Check if worktree already exists
-  if [ ! -d "$branch_path" ]; then
-    echo "Creating worktree for $branch"
-    git worktree add "$branch_path" "$branch"
-  else
-    echo "Worktree for $branch already exists"
-  fi
-done
-
-# Display all created worktrees
-echo "\nWorktree list:"
-git worktree list
-```
-
-### Example Output
-
-```
-Creating worktree for fix-bug-123
-HEAD is now at a1b2c3d Fix bug 123
-Creating worktree for feature/new-feature
-HEAD is now at e4f5g6h Add new feature
-Worktree for documentation-update already exists
-
-Worktree list:
-/path/to/repo                      abc1234 [main]
-/path/to/repo/tree/fix-bug-123     a1b2c3d [fix-bug-123]
-/path/to/repo/tree/feature/new-feature e4f5g6h [feature/new-feature]
-/path/to/repo/tree/documentation-update d5e6f7g [documentation-update]
-```
-
-### Cleanup Stale Worktrees (Optional)
-
-You can add this to remove stale worktrees for branches that no longer exist:
-
-```bash
-# Get current branches
-current_branches=$(git branch -a | grep -v HEAD | grep -v main | sed 's/^[ *]*//' | sed 's|remotes/origin/||' | sort | uniq)
-
-# Get existing worktrees (excluding main worktree)
-worktree_paths=$(git worktree list | tail -n +2 | awk '{print $1}')
-
-for path in $worktree_paths; do
-  # Extract branch name from path
-  branch_name=$(basename "$path")
-  
-  # Skip special cases
-  if [[ "$branch_name" == "main" ]]; then
-    continue
-  fi
-  
-  # Check if branch still exists
-  if ! echo "$current_branches" | grep -q "^$branch_name$"; then
-    echo "Removing stale worktree for deleted branch: $branch_name"
-    git worktree remove --force "$path"
-  fi
-done
-```
-
-## Create New Branch and Worktree
-
-This interactive command creates a new git branch and sets up a worktree for it:
-
-```bash
-#!/bin/bash
-
-# Ensure we're in a git repository
-if ! git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
-  echo "Error: Not in a git repository"
-  exit 1
-fi
-
-# Get the repository root
-repo_root=$(git rev-parse --show-toplevel)
-
-# Prompt for branch name
-read -p "Enter new branch name: " branch_name
-
-# Validate branch name (basic validation)
-if [[ -z "$branch_name" ]]; then
-  echo "Error: Branch name cannot be empty"
-  exit 1
-fi
-
-if git show-ref --verify --quiet "refs/heads/$branch_name"; then
-  echo "Warning: Branch '$branch_name' already exists"
-  read -p "Do you want to use the existing branch? (y/n): " use_existing
-  if [[ "$use_existing" != "y" ]]; then
-    exit 1
-  fi
-fi
-
-# Create branch directory
-branch_path="$repo_root/tree/$branch_name"
-
-# Handle branch names with slashes (like "feature/foo")
-if [[ "$branch_name" == */* ]]; then
-  dir_path=$(dirname "$branch_path")
-  mkdir -p "$dir_path"
-fi
-
-# Make sure parent directory exists
-mkdir -p "$(dirname "$branch_path")"
-
-# Check if a worktree already exists
-if [ -d "$branch_path" ]; then
-  echo "Error: Worktree directory already exists: $branch_path"
-  exit 1
-fi
-
-# Create branch and worktree
-if git show-ref --verify --quiet "refs/heads/$branch_name"; then
-  # Branch exists, create worktree
-  echo "Creating worktree for existing branch '$branch_name'..."
-  git worktree add "$branch_path" "$branch_name"
-else
-  # Create new branch and worktree
-  echo "Creating new branch '$branch_name' and worktree..."
-  git worktree add -b "$branch_name" "$branch_path"
-fi
-
-echo "Success! New worktree created at: $branch_path"
-echo "To start working on this branch, run: cd $branch_path"
-```
-
-### Example Usage
-
-```
-$ ./create-branch-worktree.sh
-Enter new branch name: feature/user-authentication
-Creating new branch 'feature/user-authentication' and worktree...
-Preparing worktree (creating new branch 'feature/user-authentication')
-HEAD is now at abc1234 Previous commit message
-Success! New worktree created at: /path/to/repo/tree/feature/user-authentication
-To start working on this branch, run: cd /path/to/repo/tree/feature/user-authentication
-```
-
-### Creating a New Branch from a Different Base
-
-If you want to start your branch from a different base (not the current HEAD), you can modify the script:
-
-```bash
-read -p "Enter new branch name: " branch_name
-read -p "Enter base branch/commit (default: HEAD): " base_commit
-base_commit=${base_commit:-HEAD}
-
-# Then use the specified base when creating the worktree
-git worktree add -b "$branch_name" "$branch_path" "$base_commit"
-```
-
-This will allow you to specify any commit, tag, or branch name as the starting point for your new branch.

package/cli-tool/components/commands/git-workflow/fix-github-issue.md

@@ -1,13 +0,0 @@
-Please analyze and fix the GitHub issue: $ARGUMENTS.
-
-Follow these steps:
-
-1. Use `gh issue view` to get the issue details
-2. Understand the problem described in the issue
-3. Search the codebase for relevant files
-4. Implement the necessary changes to fix the issue
-5. Write and run tests to verify the fix
-6. Ensure code passes linting and type checking
-7. Create a descriptive commit message
-
-Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks.