aico-cli 0.0.1

package/package.json

@@ -0,0 +1,57 @@
+{
+  "name": "aico-cli",
+  "version": "0.0.1",
+  "packageManager": "pnpm@9.15.9",
+  "description": "AI CLI",
+  "repository": {
+    "type": "git",
+    "url": "https://code.devcloud.cnpc:8091/gitlab/AI-AGENT/tpl/ai-cli.git"
+  },
+  "license": "MIT",
+  "author": "WYP",
+  "main": "dist/index.mjs",
+  "module": "dist/index.mjs",
+  "types": "dist/index.d.mts",
+  "bin": {
+    "aico": "bin/aico.mjs"
+  },
+  "files": [
+    "dist",
+    "bin",
+    "templates"
+  ],
+  "scripts": {
+    "dev": "tsx ./src/cli.ts",
+    "build": "unbuild",
+    "typecheck": "tsc",
+    "prepublishOnly": "npm run build",
+    "test": "vitest",
+    "test:ui": "vitest --ui",
+    "test:coverage": "vitest --coverage",
+    "test:run": "vitest run",
+    "test:watch": "vitest watch",
+    "changeset": "changeset",
+    "version": "changeset version",
+    "release": "pnpm build && changeset publish"
+  },
+  "dependencies": {
+    "ansis": "^3.17.0",
+    "cac": "^6.7.14",
+    "dayjs": "^1.11.13",
+    "find-up-simple": "^1.0.1",
+    "inquirer": "^12.9.0",
+    "pathe": "^2.0.3",
+    "tinyexec": "^1.0.1"
+  },
+  "devDependencies": {
+    "@changesets/cli": "^2.29.5",
+    "@types/inquirer": "^9.0.8",
+    "@types/node": "^22.17.0",
+    "@vitest/coverage-v8": "^3.2.4",
+    "@vitest/ui": "^3.2.4",
+    "tsx": "^4.20.3",
+    "typescript": "^5.9.2",
+    "unbuild": "^3.6.0",
+    "vitest": "^3.2.4"
+  }
+}

package/templates/CLAUDE.md

@@ -0,0 +1,5 @@
+@language.md
+@personality.md
+@rules.md
+@technical-guides.md
+@mcp.md

package/templates/en/memory/mcp.md

@@ -0,0 +1,6 @@
+### Prioritize using MCP service
+
+- `Context7`: Query latest library documentation/examples
+- `DeepWiki`: Query related GitHub repository documentation/examples
+- `Exa`: Use Exa AI for web search - real-time web search, can capture specific URL content. Supports configurable result count and returns most relevant website content
+- `Playwright`: Direct browser control for browser-related operations

package/templates/en/memory/personality.md

@@ -0,0 +1 @@
+You are an experienced [professional domain, e.g., Software Development Engineer / System Designer / Code Architect], specializing in building [core strengths, e.g., high-performance / maintainable / robust / domain-driven] solutions.

package/templates/en/memory/rules.md

@@ -0,0 +1,45 @@
+Your mission is: **Review, understand, and iteratively improve/advance a [project type, e.g., existing codebase / software project / technical process].**
+
+Throughout the entire workflow, you must internalize and strictly adhere to the following core programming principles, ensuring that every output and recommendation reflects these concepts:
+
+- **Keep It Simple, Stupid (KISS):** Pursue ultimate simplicity and intuitiveness in code and design, avoiding unnecessary complexity.
+- **You Aren't Gonna Need It (YAGNI):** Implement only the functionality that is clearly needed now, resist over-engineering and unnecessary future feature reservations.
+- **SOLID Principles:**
+  - **S (Single Responsibility Principle):** Each component, class, and function should have only one clear responsibility.
+  - **O (Open/Closed Principle):** Software entities should be open for extension but closed for modification.
+  - **L (Liskov Substitution Principle):** Subtypes must be substitutable for their base types seamlessly.
+  - **I (Interface Segregation Principle):** Interfaces should be specific and focused, avoiding "fat interfaces."
+  - **D (Dependency Inversion Principle):** Depend on abstractions, not concrete implementations.
+- **Don't Repeat Yourself (DRY):** Identify and eliminate repetitive patterns in code or logic to improve reusability.
+- **Documentation Sync:** Code changes must be synchronized with relevant documentation updates.
+
+**Please strictly follow the workflow and output requirements below:**
+
+1. **Deep Understanding and Initial Analysis (Understanding Phase):**
+
+   - Thoroughly review the provided [materials/code/project description], comprehensively understanding its current architecture, core components, business logic, and pain points.
+   - Based on this understanding, preliminarily identify potential applications or violations of **KISS, YAGNI, DRY, SOLID** principles within the project.
+
+2. **Clear Objectives and Iterative Planning (Planning Phase):**
+
+   - Based on user requirements and understanding of the existing project, clearly define the specific task scope and measurable expected outcomes for this iteration.
+   - When planning solutions, prioritize how to achieve simpler, more efficient, and more scalable improvements through applying the above principles, rather than blindly adding features.
+
+3. **Step-by-Step Implementation and Specific Improvements (Execution Phase):**
+
+   - Provide detailed explanations of your improvement proposals and break them down into logically clear, actionable steps.
+   - For each step, specifically explain how you will operate and how these operations embody **KISS, YAGNI, DRY, SOLID** principles. For example:
+     - "Split this module into smaller services to follow SRP and OCP."
+     - "To avoid DRY violations, abstract the repetitive XXX logic into a common function."
+     - "Simplified the user flow for Y feature, embodying the KISS principle."
+     - "Removed Z redundant design, following the YAGNI principle."
+   - Focus on specific implementation details for [project type, e.g., code quality optimization / architecture refactoring / feature enhancement / user experience improvement / performance tuning / maintainability improvement / bug fixes].
+
+4. **Summary, Reflection, and Outlook (Reporting Phase):**
+   - Check if documentation needs updating (README, CHANGELOG, API docs, etc.).
+   - Provide a clear, structured summary report that includes **actual code/design change recommendations (if applicable)**.
+   - The report must include:
+     - **Core tasks completed in this iteration** and their specific outcomes.
+     - **How you specifically applied** **KISS, YAGNI, DRY, SOLID** **principles in this iteration**, with brief explanations of the benefits they brought (e.g., reduced code volume, improved readability, enhanced extensibility).
+     - **Challenges encountered** and how they were overcome.
+     - **Clear plans and recommendations for next steps.**

package/templates/en/memory/technical-guides.md

@@ -0,0 +1,97 @@
+# Technical Execution Guidelines
+
+This document provides best practices for Claude Code when executing technical tasks.
+
+## Dangerous Operations Confirmation
+
+**Important**: The following operations require explicit user confirmation before execution:
+
+### Operations Requiring Confirmation
+- **File System**: Delete files/directories, bulk modifications, move system files
+- **Code Commits**: `git commit`, `git push`, `git reset --hard`
+- **System Config**: Modify environment variables, system settings, permissions
+- **Data Operations**: Database deletions, schema changes, bulk updates
+- **Network Requests**: Send sensitive data, call production APIs
+- **Package Management**: Global install/uninstall, update core dependencies
+
+### Confirmation Process
+Before executing dangerous operations:
+1. Clearly explain the operation and its impacts
+2. Wait for explicit user confirmation (e.g., "yes", "confirm", "proceed")
+3. If user hesitates or declines, provide more information or alternatives
+
+## Command Execution Best Practices
+
+### Path Handling Standards
+
+**Important**: Always use double quotes to wrap file paths when executing commands.
+
+```bash
+# ✅ Correct
+cd "C:\Users\name\My Documents"
+node "/path/with spaces/app.js"
+
+# ❌ Incorrect
+cd C:\Users\name\My Documents
+```
+
+### Cross-Platform Compatibility
+- Prefer forward slashes `/` as path separators
+- When using backslashes, ensure paths are double-quoted
+
+## Search Tool Usage
+
+### Content Search
+**Always prioritize `rg` (ripgrep)** - faster and won't timeout.
+
+```bash
+# ✅ Preferred
+rg "pattern" .
+rg -t js "console.log" .
+
+# ⚠️ Fallback
+grep -r "pattern" .
+```
+
+> Note: If `rg` unavailable, remind user to install: `brew/scoop/apt install ripgrep`
+
+### File Finding
+- Use Glob tool for pattern matching
+- Use LS tool for directory listings
+- Avoid using `find` command
+
+## Tool Usage Principles
+
+1. **Prefer Specialized Tools**: Use Read, Write, Edit instead of cat, echo
+2. **Batch Operations**: Call multiple tools simultaneously for efficiency
+3. **Error Handling**: Check path quoting first when commands fail
+
+## Performance Optimization
+
+- Use Task tool for complex searches in large projects
+- Understand project structure before searching
+- Use file type filters wisely for efficiency
+
+## Documentation Update Check
+
+Automatically check documentation update needs after task completion:
+
+### Criteria
+- **New Features**: Update README, CHANGELOG, usage docs
+- **API Changes**: Update API docs, type definitions, interface specs
+- **Config Changes**: Update config guides, CLAUDE.md, env var docs
+- **Bug Fixes**: Usually no doc updates needed (unless usage affected)
+
+### Process
+1. Analyze code change type and impact scope
+2. Auto-identify documentation files in project
+3. List documents needing updates
+4. Request user confirmation: `The following docs may need updates: [doc list]. Would you like me to update them?`
+5. Update relevant docs after confirmation
+
+### Common Document Types
+- **README.md**: Features, usage, configuration
+- **CHANGELOG.md**: Version history
+- **CLAUDE.md**: AI assistant config and instructions
+- **API Docs**: Interface definitions, parameters
+- **Config Docs**: Environment variables, settings

package/templates/en/workflow/bmad/commands/bmad-init.md

@@ -0,0 +1,103 @@
+# /bmad-init Command
+
+This command initializes BMad Method in your project.
+
+## When this command is invoked:
+
+1. Check if BMad is already installed by looking for `.bmad-core/install-manifest.yaml`
+2. If installed, check version in manifest against latest version
+3. If not installed or outdated, execute: `npx bmad-method@latest install -f -d . -i claude-code`
+4. Display success message and prompt user to restart Claude Code
+
+## Implementation
+
+```javascript
+const fs = require('fs');
+const path = require('path');
+const { execSync } = require('child_process');
+
+async function initBmad() {
+  // Check if already installed and get version
+  const manifestPath = path.join(process.cwd(), '.bmad-core', 'install-manifest.yaml');
+  let needsInstall = true;
+  let currentVersion = null;
+  
+  if (fs.existsSync(manifestPath)) {
+    try {
+      // Simple version check - just check if file exists
+      // Full YAML parsing would require js-yaml package
+      const manifestContent = fs.readFileSync(manifestPath, 'utf8');
+      const versionMatch = manifestContent.match(/version:\s*(.+)/);
+      if (versionMatch) {
+        currentVersion = versionMatch[1].trim();
+      }
+      
+      // Get latest version from npm
+      const latestVersion = execSync('npm view bmad-method version', { encoding: 'utf8' }).trim();
+      
+      if (currentVersion === latestVersion) {
+        console.log(`✅ BMad Method is up to date (v${currentVersion})`);
+        console.log('You can use BMad commands to begin your workflow');
+        needsInstall = false;
+      } else {
+        console.log(`🔄 BMad Method update available: v${currentVersion} → v${latestVersion}`);
+      }
+    } catch (error) {
+      console.log('⚠️  Could not verify BMad version, will reinstall');
+    }
+  }
+  
+  if (needsInstall === false) {
+    return;
+  }
+  
+  // Install BMad
+  console.log('🚀 Installing BMad Method...');
+  try {
+    execSync('echo -e "1\\n" | npx bmad-method@latest install -f -d . -i claude-code', {
+      stdio: 'inherit',
+      cwd: process.cwd(),
+      shell: true
+    });
+    
+    console.log('✅ BMad Method installed successfully!');
+    console.log('');
+    console.log('═══════════════════════════════════════════════════════════════');
+    console.log('📌 IMPORTANT: Please restart Claude Code to load BMad agents');
+    console.log('═══════════════════════════════════════════════════════════════');
+    console.log('');
+    console.log('📂 Installation Details:');
+    console.log('   • All agents and task commands are installed in:');
+    console.log('     .claude/commands/BMad/');
+    console.log('');
+    console.log('🔧 Git Configuration (Optional):');
+    console.log('   If you prefer not to commit BMad workflow files, add these to .gitignore:');
+    console.log('     • .bmad-core');
+    console.log('     • .claude/commands/BMad');
+    console.log('     • docs/');
+    console.log('');
+    console.log('🚀 Getting Started:');
+    console.log('   1. Restart Claude Code');
+    console.log('   2. For first-time users, run:');
+    console.log('      /BMad:agents:bmad-orchestrator *help');
+    console.log('      This will start the BMad workflow guidance system');
+    console.log('');
+    console.log('💡 Tip: The BMad Orchestrator will help you choose the right workflow');
+    console.log('       and guide you through the entire development process.');
+    
+  } catch (error) {
+    console.error('❌ Failed to install BMad:', error.message);
+    process.exit(1);
+  }
+}
+
+// Execute
+initBmad();
+```
+
+## Notes
+
+- This command requires npm/npx to be available
+- The installation will download the latest BMad Method package
+- User must restart Claude Code after installation for agents to load properly
+- BMad Method includes its own built-in state tracking system

package/templates/en/workflow/git/commands/git-cleanBranches.md

@@ -0,0 +1,101 @@
+---
+description: Safely find and clean up merged or stale Git branches with dry-run mode and custom base/protected branches support
+allowed-tools: Read(**), Exec(git fetch, git config, git branch, git remote, git push, git for-each-ref, git log), Write()
+argument-hint: [--base <branch>] [--stale <days>] [--remote] [--force] [--dry-run] [--yes]
+# examples:
+#   - /git-cleanBranches --dry-run
+#   - /git-cleanBranches --base release/v2.1 --stale 90
+#   - /git-cleanBranches --remote --yes
+---
+
+# Claude Command: Clean Branches
+
+This command **safely** identifies and cleans up **merged** or **stale** Git branches.
+Runs in **read-only preview (`--dry-run`)** mode by default, requiring explicit instructions to perform deletions.
+
+---
+
+## Usage
+
+```bash
+# [Safest] Preview branches to be cleaned without executing any deletions
+/git-cleanBranches --dry-run
+
+# Clean local branches merged to main and inactive for over 90 days (requires individual confirmation)
+/git-cleanBranches --stale 90
+
+# Clean local and remote branches merged to release/v2.1 (auto-confirm)
+/git-cleanBranches --base release/v2.1 --remote --yes
+
+# [Dangerous] Force delete an unmerged local branch
+/git-cleanBranches --force outdated-feature
+```
+
+### Options
+- `--base <branch>`: Specify the base branch for cleanup (defaults to repository's `main`/`master`).
+- `--stale <days>`: Clean branches with no commits for specified days (disabled by default).
+- `--remote`: Also clean remote merged/stale branches.
+- `--dry-run`: **Default behavior**. Only list branches to be deleted without executing any operations.
+- `--yes`: Skip individual confirmations and delete all identified branches directly (suitable for CI/CD).
+- `--force`: Use `-D` to force delete local branches (even if unmerged).
+
+---
+
+## What This Command Does
+
+1. **Configuration and Safety Checks**
+   - **Update Information**: Automatically executes `git fetch --all --prune` to ensure branch status is current.
+   - **Read Protected Branches**: Reads the list of branches that should not be cleaned from Git config (see "Configuration" below).
+   - **Determine Base**: Uses `--base` parameter or auto-detected `main`/`master` as comparison baseline.
+
+2. **Analysis and Identification (Find)**
+   - **Merged Branches**: Find local (and remote if `--remote` is added) branches fully merged to `--base`.
+   - **Stale Branches**: If `--stale <days>` is specified, find branches with last commit N days ago.
+   - **Exclude Protected Branches**: Remove all configured protected branches from cleanup list.
+
+3. **Report and Preview (Report)**
+   - Clearly list "merged branches to be deleted" and "stale branches to be deleted".
+   - Without `--yes` parameter, **command ends here**, waiting for user confirmation to re-execute (without `--dry-run`).
+
+4. **Execute Cleanup (Execute)**
+   - **Only executed without `--dry-run` and after user confirmation** (or with `--yes`).
+   - Delete identified branches one by one, unless user chooses to skip in interactive confirmation.
+   - Local: `git branch -d <branch>`; Remote: `git push origin --delete <branch>`.
+   - If `--force` is specified, local deletion uses `git branch -D <branch>`.
+
+---
+
+## Configuration (Configure Once, Use Forever)
+
+To prevent accidental deletion of important branches (e.g., `develop`, `release/*`), add protection rules to the repository's Git config. The command reads them automatically.
+
+```bash
+# Protect develop branch
+git config --add branch.cleanup.protected develop
+
+# Protect all branches starting with release/ (wildcard)
+git config --add branch.cleanup.protected 'release/*'
+
+# View all configured protected branches
+git config --get-all branch.cleanup.protected
+```
+
+---
+
+## Best Practices for Embedded Devs
+
+- **Prioritize `--dry-run`**: Develop the habit of previewing before executing.
+- **Leverage `--base`**: When maintaining long-term `release` branches, use it to clean `feature` or `hotfix` branches merged to that release.
+- **Careful with `--force`**: Don't force delete unless you're 100% certain an unmerged branch is useless.
+- **Team Collaboration**: Notify the team channel before cleaning shared remote branches.
+- **Regular Runs**: Run monthly or quarterly to keep the repository clean.
+
+---
+
+## Why This Version Is Better
+
+- ✅ **Safer**: Default read-only preview with configurable protected branch list.
+- ✅ **More Flexible**: Supports custom base branches, perfectly fits `release` / `develop` workflows.
+- ✅ **More Compatible**: Avoids commands with inconsistent behavior across systems like `date -d`.
+- ✅ **More Intuitive**: Condenses complex 16-step checklist into a single command with safety options.
+- ✅ **Consistent Style**: Shares similar parameter design and documentation structure with `/commit` command.

package/templates/en/workflow/git/commands/git-commit.md

@@ -0,0 +1,152 @@
+---
+description: Analyze changes with Git only and auto-generate conventional commit messages with optional emoji; suggests splitting commits when needed, runs local Git hooks by default (use --no-verify to skip)
+allowed-tools: Read(**), Exec(git status, git diff, git add, git restore --staged, git commit, git rev-parse, git config), Write(.git/COMMIT_EDITMSG)
+argument-hint: [--no-verify] [--all] [--amend] [--signoff] [--emoji] [--scope <scope>] [--type <type>]
+# examples:
+#   - /git-commit                           # Analyze current changes, generate commit message
+#   - /git-commit --all                     # Stage all changes and commit
+#   - /git-commit --no-verify               # Skip Git hooks
+#   - /git-commit --emoji                   # Include emoji in commit message
+#   - /git-commit --scope ui --type feat    # Specify scope and type
+#   - /git-commit --amend --signoff         # Amend last commit with signature
+---
+
+# Claude Command: Commit (Git-only)
+
+This command works **without any package manager/build tools**, using only **Git** to:
+- Read changes (staged/unstaged)
+- Determine if changes should be **split into multiple commits**
+- Generate **Conventional Commits** style messages with optional emoji for each commit
+- Execute `git add` and `git commit` as needed (runs local Git hooks by default; use `--no-verify` to skip)
+
+---
+
+## Usage
+
+```bash
+/git-commit
+/git-commit --no-verify
+/git-commit --emoji
+/git-commit --all --signoff
+/git-commit --amend
+/git-commit --scope ui --type feat --emoji
+```
+
+### Options
+- `--no-verify`: Skip local Git hooks (`pre-commit`/`commit-msg` etc.).
+- `--all`: When staging area is empty, automatically `git add -A` to include all changes in the commit.
+- `--amend`: **Amend** the last commit without creating a new one (preserves author and timestamp unless local Git config specifies otherwise).
+- `--signoff`: Add `Signed-off-by` line (use when following DCO process).
+- `--emoji`: Include emoji prefix in commit message (omit for plain text).
+- `--scope <scope>`: Specify commit scope (e.g., `ui`, `docs`, `api`), written to message header.
+- `--type <type>`: Force commit type (e.g., `feat`, `fix`, `docs`), overrides automatic detection.
+
+> Note: If the framework doesn't support interactive confirmation, enable `confirm: true` in front-matter to avoid mistakes.
+
+---
+
+## What This Command Does
+
+1. **Repository/Branch Validation**
+   - Check if in a Git repository using `git rev-parse --is-inside-work-tree`.
+   - Read current branch/HEAD status; if in rebase/merge conflict state, prompt to resolve conflicts first.
+
+2. **Change Detection**
+   - Get staged and unstaged changes using `git status --porcelain` and `git diff`.
+   - If staged files = 0:
+     - If `--all` is passed → Execute `git add -A`.
+     - Otherwise prompt choice: continue analyzing unstaged changes for **suggestions**, or cancel to manually group staging.
+
+3. **Split Suggestions (Split Heuristics)**
+   - Cluster by **concerns**, **file modes**, **change types** (e.g., source code vs docs/tests; different directories/packages; additions vs deletions).
+   - If **multiple independent changesets** or large diff detected (e.g., > 300 lines / across multiple top-level directories), suggest splitting commits with pathspecs for each group (for subsequent `git add <paths>`).
+
+4. **Commit Message Generation (Conventional with Optional Emoji)**
+   - Auto-infer `type` (`feat`/`fix`/`docs`/`refactor`/`test`/`chore`/`perf`/`style`/`ci`/`revert`...) and optional `scope`.
+   - Generate message header: `[<emoji>] <type>(<scope>)?: <subject>` (first line ≤ 72 chars, imperative mood, emoji included only with `--emoji` flag).
+   - Generate message body: bullet points (motivation, implementation details, impact scope, BREAKING CHANGE if any).
+   - Write draft to `.git/COMMIT_EDITMSG` for use with `git commit`.
+
+5. **Execute Commit**
+   - Single commit scenario: `git commit [-S] [--no-verify] [-s] -F .git/COMMIT_EDITMSG`
+   - Multiple commit scenario (if split accepted): Provide clear instructions for `git add <paths> && git commit ...` per group; execute sequentially if allowed.
+
+6. **Safe Rollback**
+   - If mistakenly staged, use `git restore --staged <paths>` to unstage (command provides instructions, doesn't modify file contents).
+
+---
+
+## Best Practices for Commits
+
+- **Atomic commits**: One commit does one thing, easier to trace and review.
+- **Group before committing**: Split by directory/module/feature.
+- **Clear subject**: First line ≤ 72 chars, imperative mood (e.g., "add... / fix...").
+- **Body with context**: Explain motivation, solution, impact scope, risks, and next steps.
+- **Follow Conventional Commits**: `<type>(<scope>): <subject>`.
+
+---
+
+## Type to Emoji Mapping (When --emoji is Used)
+
+- ✨ `feat`: New feature  
+- 🐛 `fix`: Bug fix (includes 🔥 remove code/files, 🚑️ hotfix, 👽️ adapt to external API changes, 🔒️ security fix, 🚨 fix warnings, 💚 fix CI)  
+- 📝 `docs`: Documentation and comments  
+- 🎨 `style`: Code style/formatting (no semantic changes)  
+- ♻️ `refactor`: Refactoring (no new features, no bug fixes)  
+- ⚡️ `perf`: Performance improvements  
+- ✅ `test`: Add/fix tests, snapshots  
+- 🔧 `chore`: Build/tools/misc tasks (merge branches, update configs, release tags, pin dependencies, .gitignore, etc.)  
+- 👷 `ci`: CI/CD configuration and scripts  
+- ⏪️ `revert`: Revert commits  
+- 💥 `feat`: Breaking changes (explained in `BREAKING CHANGE:` section)
+
+> If `--type`/`--scope` is passed, it will **override** auto-detection.
+> Emoji is only included when `--emoji` flag is specified.
+
+---
+
+## Guidelines for Splitting Commits
+
+1. **Different concerns**: Unrelated feature/module changes should be split.  
+2. **Different types**: Don't mix `feat`, `fix`, `refactor` in the same commit.  
+3. **File modes**: Source code vs docs/tests/configs should be grouped separately.  
+4. **Size threshold**: Large diffs (e.g., >300 lines or across multiple top-level directories) should be split.  
+5. **Revertability**: Ensure each commit can be independently reverted.
+
+---
+
+## Examples
+
+**Good (with --emoji)**
+- ✨ feat(ui): add user authentication flow  
+- 🐛 fix(api): handle token refresh race condition  
+- 📝 docs: update API usage examples  
+- ♻️ refactor(core): extract retry logic into helper  
+- ✅ test: add unit tests for rate limiter  
+- 🔧 chore: update git hooks and repository settings  
+- ⏪️ revert: revert "feat(core): introduce streaming API"
+
+**Good (without --emoji)**
+- feat(ui): add user authentication flow  
+- fix(api): handle token refresh race condition  
+- docs: update API usage examples  
+- refactor(core): extract retry logic into helper  
+- test: add unit tests for rate limiter  
+- chore: update git hooks and repository settings  
+- revert: revert "feat(core): introduce streaming API"
+
+**Split Example**
+- `feat(types): add new type defs for payment method`
+- `docs: update API docs for new types`
+- `test: add unit tests for payment types`
+- `fix: address linter warnings in new files` ← (if your repo has hook errors)
+
+---
+
+## Important Notes
+
+- **Git only**: No package manager/build commands (`pnpm`/`npm`/`yarn` etc.).  
+- **Respects hooks**: Executes local Git hooks by default; use `--no-verify` to skip.  
+- **No source code changes**: Command only reads/writes `.git/COMMIT_EDITMSG` and staging area; doesn't directly edit working directory files.  
+- **Safety prompts**: In rebase/merge conflicts, detached HEAD states, prompts to handle/confirm before continuing.  
+- **Auditable and controllable**: If `confirm: true` is enabled, each actual `git add`/`git commit` step requires confirmation.

package/templates/en/workflow/git/commands/git-rollback.md

@@ -0,0 +1,89 @@
+---
+description: Interactively rollback Git branch to historical version; lists branches, versions, then executes reset/revert after confirmation
+allowed-tools: Read(**), Exec(git fetch, git branch, git tag, git log, git reflog, git checkout, git reset, git revert, git switch), Write()
+argument-hint: [--branch <branch>] [--target <rev>] [--mode reset|revert] [--depth <n>] [--dry-run] [--yes]
+# examples:
+#   - /git-rollback                # Full interactive mode, dry-run
+#   - /git-rollback --branch dev   # Select dev directly, other interactive
+#   - /git-rollback --branch dev --target v1.2.0 --mode reset --yes
+---
+# Claude Command: Git Rollback
+
+**Purpose**: Safely and visually rollback a specified branch to an older version.  
+Defaults to **read-only preview (`--dry-run`)**; actual execution requires `--yes` or interactive confirmation.
+
+---
+
+## Usage
+
+```bash
+# Pure interactive: list branches → select branch → list recent 20 versions → select target → choose reset or revert → confirm
+/git-rollback
+
+# Specify branch, other interactive
+/git-rollback --branch feature/calculator
+
+# Specify branch and target commit, execute with hard-reset in one go (dangerous)
+/git-rollback --branch main --target 1a2b3c4d --mode reset --yes
+
+# Generate revert commit only (non-destructive rollback), preview
+/git-rollback --branch release/v2.1 --target v2.0.5 --mode revert --dry-run
+```
+
+### Options
+
+| Option | Description |
+|------|------|
+| `--branch <branch>` | Branch to rollback; interactively selected if omitted. |
+| `--target <rev>` | Target version (commit hash, tag, or reflog reference); interactively selects recent `--depth` entries if omitted. |
+| `--mode reset\|revert` | `reset`: Hard rollback history; `revert`: Generate reverse commits keeping history intact. Prompts by default. |
+| `--depth <n>` | List recent n versions in interactive mode (default 20). |
+| `--dry-run` | **Enabled by default**, only preview commands to be executed. |
+| `--yes` | Skip all confirmations and execute directly, suitable for CI/CD scripts. |
+
+---
+
+## Interactive Flow
+
+1. **Sync remote** → `git fetch --all --prune`
+2. **List branches** → `git branch -a` (local + remote, filter protected branches)
+3. **Select branch** → User input or parameter
+4. **List versions** → `git log --oneline -n <depth>` + `git tag --merged` + `git reflog -n <depth>`
+5. **Select target** → User inputs commit hash / tag
+6. **Select mode** → `reset` or `revert`
+7. **Final confirmation** (unless `--yes`)
+8. **Execute rollback**  
+   * `reset`: `git switch <branch> && git reset --hard <target>`  
+   * `revert`: `git switch <branch> && git revert --no-edit <target>..HEAD`
+9. **Push suggestion** → Prompt whether to `git push --force-with-lease` (reset) or regular `git push` (revert)
+
+---
+
+## Safety Guards
+
+* **Backup**: Automatically records current HEAD in reflog before execution, recoverable with `git switch -c backup/<timestamp>`.  
+* **Protected branches**: If protected branches like `main` / `master` / `production` are detected with `reset` mode enabled, requires additional confirmation.  
+* **--dry-run enabled by default**: Prevents accidental operations.  
+* **--force prohibited**: No `--force` provided; if force push needed, manually enter `git push --force-with-lease`.
+
+---
+
+## Use Case Examples
+
+| Scenario | Command Example |
+|------|---------|
+| Hotfix patch deployed with bug, need to rollback to tag `v1.2.0` | `/git-rollback --branch release/v1 --target v1.2.0 --mode reset` |
+| Ops colleague pushed debug logs by mistake, need to generate reverse commit | `/git-rollback --branch main --target 3f2e7c9 --mode revert` |
+| Research historical bugs, guide newcomers through branch history | `/git-rollback` (full interactive, dry-run) |
+
+---
+
+## Notes
+
+1. **reset vs revert**  
+   * **reset** changes history, requires force push and may affect other collaborators, use with caution.  
+   * **revert** is safer, generates new commits preserving history, but adds one more record.  
+2. **Embedded repositories** often have large binary files; ensure LFS/submodule state consistency before rollback.  
+3. If repository has CI forced validation, rollback may trigger pipelines automatically; confirm control policies to avoid accidental deployment of old versions.
+
+---