aico-cli 0.1.5 → 0.1.6

package/templates/en/memory/mcp.md

@@ -1,6 +0,0 @@
-### 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

@@ -1 +0,0 @@
-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

@@ -1,45 +0,0 @@
-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

@@ -1,97 +0,0 @@
-# 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

@@ -1,103 +0,0 @@
-# /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/common/agents/get-current-datetime.md

@@ -1,29 +0,0 @@
----
-name: get-current-datetime
-description: Execute date command and return ONLY the raw output. No formatting, headers, explanations, or parallel agents.
-tools: Bash, Read, Write
-color: cyan
----
-
-Execute `date` and return ONLY the command output.
-
-```bash
-date
-```
-
-DO NOT add any text, headers, formatting, or explanations.
-DO NOT add markdown formatting or code blocks.
-DO NOT add "Current date and time is:" or similar phrases.
-DO NOT use parallel agents.
-
-Just return the raw bash command output exactly as it appears.
-
-Example response: `Mon 28 Jul 2025 23:59:42 CST`
-
-Format options if requested:
-
-- Filename: Add `+"%Y-%m-%d_%H%M%S"`
-- Readable: Add `+"%Y-%m-%d %H:%M:%S %Z"`
-- ISO: Add `+"%Y-%m-%dT%H:%M:%S%z"`
-
-Use the get-current-datetime agent to get accurate timestamps instead of manually writing time information.

package/templates/en/workflow/common/agents/init-architect.md

@@ -1,114 +0,0 @@
----
-name: init-architect
-description: Adaptive initialization: concise at root + detailed at module level; staged traversal with coverage reporting
-tools: Read, Write, Glob, Grep
-color: orange
----
-
-# Initialization Architect (Adaptive Version)
-
-> No exposed parameters; internal adaptive three levels: quick summary / module scanning / deep supplementation. Ensures incremental updates and resumable runs with coverage reporting and next-step recommendations.
-
-## I. General Constraints
-
-- Do not modify source code; only generate/update documentation and `.claude/index.json`.
-- **Ignore Rules Retrieval Strategy**:
-  1. Prioritize reading the `.gitignore` file from the project root directory
-  2. If `.gitignore` does not exist, use the following default ignore rules: `node_modules/**,.git/**,.github/**,dist/**,build/**,.next/**,__pycache__/**,*.lock,*.log,*.bin,*.pdf,*.png,*.jpg,*.jpeg,*.gif,*.mp4,*.zip,*.tar,*.gz`
-  3. Merge ignore patterns from `.gitignore` with default rules
-- For large files/binaries, only record paths without reading content.
-
-## II. Staged Strategy (Automatic Intensity Selection)
-
-1. **Stage A: Repository Census (Lightweight)**
-   - Use multiple `Glob` calls in batches to get file inventory (avoid single-call limits), doing:
-     - File counting, language proportions, directory topology, module candidate discovery (package.json, pyproject.toml, go.mod, Cargo.toml, apps/_, packages/_, services/_, cmd/_, etc.).
-   - Generate `Module Candidate List`, annotating each candidate module with: language, entry file guesses, test directory existence, config file existence.
-2. **Stage B: Module Priority Scanning (Medium)**
-   - For each module, try reading in the following order (batched, paginated):
-     - Entry and startup: `main.ts`/`index.ts`/`cmd/*/main.go`/`app.py`/`src/main.rs`, etc.
-     - External interfaces: routes, controllers, API definitions, proto/openapi
-     - Dependencies and scripts: `package.json scripts`, `pyproject.toml`, `go.mod`, `Cargo.toml`, config directories
-     - Data layer: `schema.sql`, `prisma/schema.prisma`, ORM models, migration directories
-     - Testing: `tests/**`, `__tests__/**`, `*_test.go`, `*.spec.ts`, etc.
-     - Quality tools: `eslint/ruff/golangci` configurations
-   - Form "module snapshots", extracting only high-signal fragments and paths, not pasting large code blocks.
-3. **Stage C: Deep Supplementation (Triggered As Needed)**
-   - Trigger conditions (any one suffices):
-     - Repository overall small (fewer files) or single module small file count;
-     - After Stage B, still cannot determine key interfaces/data models/testing strategies;
-     - Root or module `CLAUDE.md` missing information items.
-   - Action: **Additional paginated reading** for target directories, filling gaps.
-
-> Note: If pagination/attempts reach tool or time limits, must **write partial results early** and explain in summary "why stopped here" and "next-step recommended directory list".
-
-## III. Artifacts and Incremental Updates
-
-1.  **Write Root-level `CLAUDE.md`**
-    - If exists, insert/update `Change Log (Changelog)` at the top.
-    - Root structure (concise yet global):
-      - Project Vision
-      - Architecture Overview
-      - **✨ New: Module Structure Diagram (Mermaid)**
-        - Above the "Module Index" table, generate a Mermaid `graph TD` tree diagram based on identified module paths.
-        - Each node should be clickable and link to the corresponding module's `CLAUDE.md` file.
-        - Example syntax:
-
-          ```mermaid
-          graph TD
-              A["(Root) My Project"] --> B["packages"];
-              B --> C["auth"];
-              B --> D["ui-library"];
-              A --> E["services"];
-              E --> F["audit-log"];
-
-              click C "./packages/auth/CLAUDE.md" "View auth module docs"
-              click D "./packages/ui-library/CLAUDE.md" "View ui-library module docs"
-              click F "./services/audit-log/CLAUDE.md" "View audit-log module docs"
-          ```
-
-      - Module Index (table format)
-      - Running and Development
-      - Testing Strategy
-      - Coding Standards
-      - AI Usage Guidelines
-      - Change Log (Changelog)
-
-2.  **Write Module-level `CLAUDE.md`**
-    - Place in each module directory, suggested structure:
-      - **✨ New: Relative Path Breadcrumbs**
-        - At the **top** of each module `CLAUDE.md`, insert a relative path breadcrumb line linking to parent directories and root `CLAUDE.md`.
-        - Example (located at `packages/auth/CLAUDE.md`):
-          `[Root Directory](../../CLAUDE.md) > [packages](../) > **auth**`
-      - Module Responsibilities
-      - Entry and Startup
-      - External Interfaces
-      - Key Dependencies and Configuration
-      - Data Models
-      - Testing and Quality
-      - Frequently Asked Questions (FAQ)
-      - Related File List
-      - Change Log (Changelog)
-3.  **`.claude/index.json`**
-    - Record: current timestamp (provided via parameters), root/module lists, entry/interface/test/important paths for each module, **scan coverage**, ignore statistics, whether truncated due to limits (`truncated: true`).
-
-## IV. Coverage and Resumability
-
-- Calculate and print each run:
-  - Estimated total files, scanned file count, coverage percentage;
-  - Coverage summary and gaps for each module (missing interfaces, tests, data models, etc.);
-  - Top ignored/skipped directories and reasons (ignore rules/large files/time or call limits).
-- Write "gap list" to `index.json`, prioritize filling gaps on next run (**breakpoint resumable scanning**).
-
-## V. Result Summary (Print to Main Dialog)
-
-- Root/module `CLAUDE.md` creation or update status;
-- Module list (path + one-sentence responsibility);
-- Coverage and major gaps;
-- If not fully read: explain "why stopped here" and list **recommended next steps** (e.g., "suggest priority supplemental scanning: packages/auth/src/controllers, services/audit/migrations").
-
-## VI. Time Format and Usage
-
-- Use relative paths;
-- Time information: Use the timestamp provided via command parameters and write in ISO-8601 format in `index.json`.
-- Do not manually write time information; use the provided timestamp parameter to ensure time accuracy.

package/templates/en/workflow/common/commands/init-project.md

@@ -1,53 +0,0 @@
----
-description: Initialize project AI context, generate/update root-level and module-level CLAUDE.md indexes
-allowed-tools: Read(**), Write(CLAUDE.md, **/CLAUDE.md)
-argument-hint: <PROJECT_SUMMARY_OR_NAME>
----
-
-## Usage
-
-`/init-project <PROJECT_SUMMARY_OR_NAME>`
-
-## Objective
-
-Initialize project AI context using a mixed strategy of "concise at root + detailed at module level":
-
-- Generate/update `CLAUDE.md` at repository root (high-level vision, architecture overview, module index, global standards).
-- Generate/update local `CLAUDE.md` in identified module directories (interfaces, dependencies, entry points, tests, key files, etc.).
-- ✨ **For improved readability, automatically generate Mermaid structure diagrams in the root `CLAUDE.md` and add navigation breadcrumbs to each module `CLAUDE.md`**.
-
-## Orchestration Instructions
-
-**Step 1**: Call the `get-current-datetime` sub-agent to obtain the current timestamp.
-
-**Step 2**: Call the `init-architect` sub-agent once, with input:
-
-- `project_summary`: $ARGUMENTS
-- `current_timestamp`: (timestamp from step 1)
-
-## Execution Strategy (Agent adapts automatically, no user parameters needed)
-
-- **Stage A: Repository Census (Lightweight)**
-  Quickly count files and directories, identify module roots (package.json, pyproject.toml, go.mod, apps/_, packages/_, services/\*, etc.).
-- **Stage B: Module Priority Scanning (Medium)**
-  For each module, perform targeted reading and sampling of "entry/interfaces/dependencies/tests/data models/quality tools".
-- **Stage C: Deep Supplementation (As Needed)**
-  If repository is small or module scale is small, expand reading scope; if large, perform batch supplemental scanning on high-risk/high-value paths.
-- **Coverage Measurement and Resumability**
-  Output "scanned files / estimated total files, covered module ratio, ignored/skipped reasons" and list "recommended next-step deep-dive sub-paths". When running `/init-project` repeatedly, perform **incremental updates** and **breakpoint resumable scanning** based on previous index.
-
-## Security and Boundaries
-
-- Only read/write documentation and indexes, do not modify source code.
-- Ignore common generated artifacts and binary large files by default.
-- Print "summary" in main dialog, write full content to repository.
-
-## Output Requirements
-
-- Print "Initialization Result Summary" in main dialog, including:
-  - Whether root-level `CLAUDE.md` was created/updated, major section overview.
-  - Number of identified modules and their path list.
-  - Generation/update status of each module's `CLAUDE.md`.
-  - ✨ **Explicitly mention "Generated Mermaid structure diagram" and "Added navigation breadcrumbs for N modules"**.
-  - Coverage and major gaps.
-  - If not fully read: explain "why stopped here" and list **recommended next steps** (e.g., "suggest priority supplemental scanning: packages/auth/src/controllers").

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

@@ -1,101 +0,0 @@
----
-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.