claude-code-templates 1.21.1 → 1.21.3

package/cli-tool/components/commands/game-development/unity-project-setup.md

@@ -1,190 +0,0 @@
----
-allowed-tools: Read, Write, Edit, Bash
-argument-hint: [project-name] | --2d | --3d | --mobile | --vr | --console
-description: Use PROACTIVELY to set up professional Unity game development projects with industry-standard structure, essential packages, and platform-optimized configurations
-model: sonnet
----
-
-# Unity Project Setup & Development Environment
-
-Initialize professional Unity game development project: $ARGUMENTS
-
-## Current Unity Environment
-
-- Unity version: !`unity-editor --version 2>/dev/null || echo "Unity Editor not found"`
-- Current directory: !`pwd`
-- Available templates: !`find . -name "*.unitypackage" 2>/dev/null | wc -l` Unity packages
-- Git status: !`git status --porcelain 2>/dev/null | wc -l` uncommitted changes
-- System info: !`system_profiler SPSoftwareDataType | grep "System Version" 2>/dev/null || uname -a`
-
-## Task
-
-Set up a complete Unity project with professional development environment and platform-specific optimizations.
-
-## What it creates:
-
-### Project Structure
-```
-Assets/
-├── _Project/
-│   ├── Scripts/
-│   │   ├── Managers/
-│   │   ├── Player/
-│   │   ├── UI/
-│   │   ├── Gameplay/
-│   │   └── Utilities/
-│   ├── Art/
-│   │   ├── Textures/
-│   │   ├── Materials/
-│   │   ├── Models/
-│   │   └── Animations/
-│   ├── Audio/
-│   │   ├── Music/
-│   │   ├── SFX/
-│   │   └── Voice/
-│   ├── Prefabs/
-│   │   ├── Characters/
-│   │   ├── Environment/
-│   │   ├── UI/
-│   │   └── Effects/
-│   ├── Scenes/
-│   │   ├── Development/
-│   │   ├── Production/
-│   │   └── Testing/
-│   ├── Settings/
-│   │   ├── Input/
-│   │   ├── Rendering/
-│   │   └── Audio/
-│   └── Resources/
-├── Plugins/
-├── StreamingAssets/
-└── Editor/
-    ├── Scripts/
-    └── Resources/
-```
-
-### Essential Packages
-- Universal Render Pipeline (URP)
-- Input System
-- Cinemachine
-- ProBuilder
-- Timeline
-- Addressables
-- Unity Analytics
-- Version Control (if available)
-
-### Project Settings
-- Optimized quality settings for target platforms
-- Input system configuration
-- Physics settings
-- Time and rendering configurations
-- Build settings for multiple platforms
-
-### Development Tools
-- Code formatting rules (.editorconfig)
-- Git configuration with Unity-optimized .gitignore
-- Assembly definition files for better compilation
-- Custom editor scripts for workflow improvement
-
-### Version Control Setup
-- Git repository initialization
-- Unity-specific .gitignore
-- LFS configuration for large assets
-- Branching strategy documentation
-
-## Usage:
-
-```bash
-npx claude-code-templates@latest --command unity-project-setup
-```
-
-## Interactive Options:
-
-1. **Project Type Selection**
-   - 2D Game
-   - 3D Game
-   - Mobile Game
-   - VR/AR Game
-   - Hybrid (2D/3D)
-
-2. **Target Platforms**
-   - PC (Windows/Mac/Linux)
-   - Mobile (iOS/Android)
-   - Console (PlayStation/Xbox/Nintendo)
-   - WebGL
-   - VR (Oculus/SteamVR)
-
-3. **Version Control**
-   - Git
-   - Plastic SCM
-   - Perforce
-   - None
-
-4. **Additional Packages**
-   - TextMeshPro
-   - Post Processing
-   - Unity Ads
-   - Unity Analytics
-   - Unity Cloud Build
-   - Custom package selection
-
-## Generated Files:
-
-### Core Scripts
-- `GameManager.cs` - Main game controller
-- `SceneLoader.cs` - Scene management system
-- `AudioManager.cs` - Audio system controller
-- `InputManager.cs` - Input handling system
-- `UIManager.cs` - UI system manager
-- `SaveSystem.cs` - Save/load functionality
-
-### Editor Tools
-- `ProjectSetupWindow.cs` - Custom editor window
-- `SceneQuickStart.cs` - Scene setup automation
-- `AssetValidator.cs` - Asset validation tools
-- `BuildAutomation.cs` - Build pipeline helpers
-
-### Configuration Files
-- `ProjectSettings.asset` - Optimized project settings
-- `QualitySettings.asset` - Multi-platform quality tiers
-- `InputActions.inputactions` - Input system configuration
-- `AssemblyDefinitions` - Modular compilation setup
-
-### Documentation
-- `README.md` - Project overview and setup instructions
-- `CONTRIBUTING.md` - Development guidelines
-- `CHANGELOG.md` - Version history template
-- `API_REFERENCE.md` - Code documentation template
-
-## Post-Setup Checklist:
-
-- [ ] Review and adjust quality settings for target platforms
-- [ ] Configure input actions for your game controls
-- [ ] Set up build configurations for all target platforms
-- [ ] Review folder structure and rename as needed
-- [ ] Configure version control and make initial commit
-- [ ] Set up continuous integration if required
-- [ ] Configure analytics and crash reporting
-- [ ] Review and customize coding standards
-
-## Platform-Specific Configurations:
-
-### Mobile
-- Touch input configuration
-- Performance optimization settings
-- Battery usage optimization
-- App store submission setup
-
-### PC
-- Multi-resolution support
-- Keyboard/mouse input setup
-- Graphics options menu template
-- Windows/Mac/Linux build configs
-
-### Console
-- Platform-specific input mapping
-- Achievement/trophy integration setup
-- Online services configuration
-- Certification requirement templates
-
-This command creates a production-ready Unity project structure that scales from prototype to shipped game, following industry best practices and Unity's recommended patterns.

package/cli-tool/components/commands/git-workflow/branch-cleanup.md

@@ -1,181 +0,0 @@
----
-allowed-tools: Bash(git branch:*), Bash(git checkout:*), Bash(git push:*), Bash(git merge:*), Bash(gh:*), Read, Grep
-argument-hint: [--dry-run] | [--force] | [--remote-only] | [--local-only]
-description: Use PROACTIVELY to clean up merged branches, stale remotes, and organize branch structure
-model: sonnet
----
-
-# Git Branch Cleanup & Organization
-
-Clean up merged branches and organize repository structure: $ARGUMENTS
-
-## Current Repository State
-
-- All branches: !`git branch -a`
-- Recent branches: !`git for-each-ref --count=10 --sort=-committerdate refs/heads/ --format='%(refname:short) - %(committerdate:relative)'`
-- Remote branches: !`git branch -r`
-- Merged branches: !`git branch --merged main 2>/dev/null || git branch --merged master 2>/dev/null || echo "No main/master branch found"`
-- Current branch: !`git branch --show-current`
-
-## Task
-
-Perform comprehensive branch cleanup and organization based on the repository state and provided arguments.
-
-## Cleanup Operations
-
-### 1. Identify Branches for Cleanup
-- **Merged branches**: Find local branches already merged into main/master
-- **Stale remote branches**: Identify remote-tracking branches that no longer exist
-- **Old branches**: Detect branches with no recent activity (>30 days)
-- **Feature branches**: Organize feature/* hotfix/* release/* branches
-
-### 2. Safety Checks Before Deletion
-- Verify branches are actually merged using `git merge-base`
-- Check if branches have unpushed commits
-- Confirm branches aren't the current working branch
-- Validate against protected branch patterns
-
-### 3. Branch Categories to Handle
-- **Safe to delete**: Merged feature branches, old hotfix branches
-- **Needs review**: Unmerged branches with old commits
-- **Keep**: Main branches (main, master, develop), active feature branches
-- **Archive**: Long-running branches that might need preservation
-
-### 4. Remote Branch Synchronization
-- Remove remote-tracking branches for deleted remotes
-- Prune remote references with `git remote prune origin`
-- Update branch tracking relationships
-- Clean up remote branch references
-
-## Command Modes
-
-### Default Mode (Interactive)
-1. Show branch analysis with recommendations
-2. Ask for confirmation before each deletion
-3. Provide summary of actions taken
-4. Offer to push deletions to remote
-
-### Dry Run Mode (`--dry-run`)
-1. Show what would be deleted without making changes
-2. Display branch analysis and recommendations
-3. Provide cleanup statistics
-4. Exit without modifying repository
-
-### Force Mode (`--force`)
-1. Delete merged branches without confirmation
-2. Clean up stale remotes automatically
-3. Provide summary of all actions taken
-4. Use with caution - no undo capability
-
-### Remote Only (`--remote-only`)
-1. Only clean up remote-tracking branches
-2. Synchronize with actual remote state
-3. Remove stale remote references
-4. Keep all local branches intact
-
-### Local Only (`--local-only`)
-1. Only clean up local branches
-2. Don't affect remote-tracking branches
-3. Keep remote synchronization intact
-4. Focus on local workspace organization
-
-## Safety Features
-
-### Pre-cleanup Validation
-- Ensure working directory is clean
-- Check for uncommitted changes
-- Verify current branch is safe (not target for deletion)
-- Create backup references if requested
-
-### Protected Branches
-Never delete branches matching these patterns:
-- `main`, `master`, `develop`, `staging`, `production`
-- `release/*` (unless explicitly confirmed)
-- Current working branch
-- Branches with unpushed commits (unless forced)
-
-### Recovery Information
-- Display git reflog references for deleted branches
-- Provide commands to recover accidentally deleted branches
-- Show SHA hashes for branch tips before deletion
-- Create recovery script if multiple branches deleted
-
-## Branch Organization Features
-
-### Naming Convention Enforcement
-- Suggest renaming branches to follow team conventions
-- Organize branches by type (feature/, bugfix/, hotfix/)
-- Identify branches that don't follow naming patterns
-- Provide batch renaming suggestions
-
-### Branch Tracking Setup
-- Set up proper upstream tracking for feature branches
-- Configure push/pull behavior for new branches
-- Identify branches missing upstream configuration
-- Fix broken tracking relationships
-
-## Output and Reporting
-
-### Cleanup Summary
-```
-Branch Cleanup Summary:
-✅ Deleted 3 merged feature branches
-✅ Removed 5 stale remote references
-✅ Cleaned up 2 old hotfix branches
-⚠️  Found 1 unmerged branch requiring attention
-📊 Repository now has 8 active branches (was 18)
-```
-
-### Recovery Instructions
-```
-Branch Recovery Commands:
-git checkout -b feature/user-auth 1a2b3c4d  # Recover feature/user-auth
-git push origin feature/user-auth            # Restore to remote
-```
-
-## Best Practices
-
-### Regular Maintenance Schedule
-- Run cleanup weekly for active repositories
-- Use `--dry-run` first to review changes
-- Coordinate with team before major cleanups
-- Document any non-standard branches to preserve
-
-### Team Coordination
-- Communicate branch deletion plans with team
-- Check if anyone has work-in-progress on old branches
-- Use GitHub/GitLab branch protection rules
-- Maintain shared documentation of branch policies
-
-### Branch Lifecycle Management
-- Delete feature branches immediately after merge
-- Keep release branches until next major release
-- Archive long-term experimental branches
-- Use tags to mark important branch states before deletion
-
-## Example Usage
-
-```bash
-# Safe interactive cleanup
-/branch-cleanup
-
-# See what would be cleaned without changes
-/branch-cleanup --dry-run
-
-# Clean only remote tracking branches
-/branch-cleanup --remote-only
-
-# Force cleanup of merged branches
-/branch-cleanup --force
-
-# Clean only local branches
-/branch-cleanup --local-only
-```
-
-## Integration with GitHub/GitLab
-
-If GitHub CLI or GitLab CLI is available:
-- Check PR status before deleting branches
-- Verify branches are actually merged in web interface
-- Clean up both local and remote branches consistently
-- Update branch protection rules if needed

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/)