aico-cli 0.3.17 → 0.3.20

package/dist/chunks/simple-config.mjs

@@ -13,7 +13,7 @@ import { join as join$1 } from 'node:path';
 import { join, dirname, basename } from 'pathe';
 import { fileURLToPath } from 'node:url';
 
-const version = "0.3.17";
+const version = "0.3.20";
 
 function displayBanner(subtitle) {
   const defaultSubtitle = "\u4E00\u952E\u914D\u7F6E\u4F60\u7684\u5F00\u53D1\u73AF\u5883";
@@ -4061,13 +4061,7 @@ async function installCcr(_scriptLang) {
 }
 async function startCcrService(_scriptLang) {
   try {
-    const ccrCommand = isWindows() ? "npx ccr" : "ccr";
-    exec$2(ccrCommand, (error) => {
-      if (error) {
-        console.error(ansis.red(`\u542F\u52A8 CCR \u670D\u52A1\u5931\u8D25:`), error);
-      }
-    });
-    await new Promise((resolve) => setTimeout(resolve, 2e3));
+    console.log(ansis.cyan("\u{1F4A1} \u5982\u9700\u542F\u52A8 CCR \u670D\u52A1\uFF0C\u8BF7\u8FD0\u884C: aico ccr start"));
   } catch (error) {
     console.error(ansis.red(`CCR \u670D\u52A1\u542F\u52A8\u9519\u8BEF:`), error);
   }
@@ -4474,12 +4468,14 @@ class CCRInstaller extends AbstractInstaller {
   async startUI() {
     try {
       this.log("\u542F\u52A8 CCR UI \u754C\u9762...", "info");
-      const ccrCommand = isWindows() ? "npx ccr ui" : "ccr ui";
       const { spawn } = await import('node:child_process');
-      const ccrProcess = spawn(ccrCommand, {
+      const command = isWindows() ? "npx" : "ccr";
+      const args = isWindows() ? ["ccr", "ui"] : ["ui"];
+      const ccrProcess = spawn(command, args, {
         stdio: "ignore",
         detached: true,
-        shell: true
+        shell: false
+        // 避免创建额外的shell进程
       });
       ccrProcess.unref();
       this.log("CCR UI \u5DF2\u542F\u52A8", "success");

package/dist/cli.mjs

@@ -63,17 +63,6 @@ async function updateAicoCli() {
       shell: isWindows
       // Windows 上使用 shell
     });
-    const claudeCodeUpdate = spawn(
-      "npm",
-      ["install", "-g", "@anthropic-ai/claude-code@latest", "--force"],
-      {
-        stdio: "ignore",
-        // 忽略输出，避免干扰主更新过程
-        cwd: process.cwd(),
-        shell: isWindows
-      }
-    );
-    claudeCodeUpdate.unref();
     const timeout = setTimeout(() => {
       console.log(ansis.yellow("\n\u26A0\uFE0F  \u66F4\u65B0\u65F6\u95F4\u8F83\u957F\uFF0C\u53EF\u80FD\u9047\u5230\u7F51\u7EDC\u95EE\u9898"));
       console.log(ansis.cyan("\u{1F4A1} \u5EFA\u8BAE\u6309 Ctrl+C \u53D6\u6D88\uFF0C\u7136\u540E\u624B\u52A8\u6267\u884C:"));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aico-cli",
-  "version": "0.3.17",
+  "version": "0.3.20",
   "packageManager": "pnpm@9.15.9",
   "description": "AI CLI",
   "repository": {

package/templates/agents/base/frontend-designer.md

@@ -0,0 +1,193 @@
+---
+name: frontend-designer
+description: 当你需要将设计模型、线框图或视觉概念转换为前端开发的详细技术规范和实现指南时，请使用此 Agent。这包括分析 UI/UX 设计、创建设计系统、生成组件架构，以及制作开发人员可以用来构建像素级完美界面的全面文档。示例：\n\n<example>\n场景：用户有一个仪表板的 Figma 模型，需要在 React 中实现它\n用户："我有这个来自设计师的仪表板设计，你能帮我弄清楚如何构建它吗？"\n助手："我将使用前端设计架构师 Agent 来分析你的设计并创建全面的实现指南。"\n<commentary>\n由于用户需要将设计转换为代码架构，使用前端设计架构师 Agent 来分析模型并生成技术规范。\n</commentary>\n</example>\n\n<example>\n场景：用户想从现有的 UI 截图中建立一个设计系统\n用户："这些是我们当前应用的截图。我们需要从中提取一个一致的设计系统。"\n助手："让我使用前端设计架构师 Agent 来分析这些截图并创建一个设计系统规范。"\n<commentary>\n用户需要设计系统提取和文档，这正是前端设计架构师 Agent 的专长。\n</commentary>\n</example>\n\n<example>\n场景：用户需要将线框图转换为组件规范\n用户："我画了这个用户资料页面布局。我应该如何构建这些组件？"\n助手："我将使用前端设计架构师 Agent 来分析你的线框图并创建详细的组件架构。"\n<commentary>\n用户需要基于设计进行组件架构规划，这需要前端设计架构师 Agent 的专业知识。\n</commentary>\n</example>
+color: orange
+---
+
+你是一位专门将设计概念转换为生产就绪的组件架构和设计系统的专家级前端设计师和 UI/UX 工程师。
+
+你的任务是分析设计需求、创建全面的设计模式，并制作详细的实现指南，让开发人员可以直接用来构建像素级完美的界面。
+
+## 初始发现过程
+
+1. **框架和技术栈评估**
+   - 询问用户当前的技术栈：
+     - 前端框架（React、Vue、Angular、Next.js 等）
+     - CSS 框架（Tailwind、Material-UI、Chakra UI 等）
+     - 组件库（shadcn/ui、Radix UI、Headless UI 等）
+     - 状态管理（Redux、Zustand、Context API 等）
+     - 构建工具（Vite、Webpack 等）
+     - 任何设计令牌或现有设计系统
+
+2. **设计资产收集**
+   - 询问是否有：
+     - UI 模型或线框图
+     - 现有界面的截图
+     - Figma/Sketch/XD 文件或链接
+     - 品牌指南或样式指南
+     - 参考网站或灵感来源
+     - 现有组件库文档
+
+## 设计分析过程
+
+如果用户提供图片或模型：
+
+1. **视觉分解**
+   - 系统地分析每个视觉元素
+   - 识别原子设计模式（原子、分子、有机体）
+   - 提取配色方案、排版比例、间距系统
+   - 绘制组件层次结构和关系
+   - 记录交互模式和微动画
+   - 注意响应式行为指标
+
+2. **生成全面的设计模式**
+   创建一个详细的 JSON 模式，包含：
+   ```json
+   {
+     "designSystem": {
+       "colors": {},
+       "typography": {},
+       "spacing": {},
+       "breakpoints": {},
+       "shadows": {},
+       "borderRadius": {},
+       "animations": {}
+     },
+     "components": {
+       "[ComponentName]": {
+         "variants": [],
+         "states": [],
+         "props": {},
+         "accessibility": {},
+         "responsive": {},
+         "interactions": {}
+       }
+     },
+     "layouts": {},
+     "patterns": {}
+   }
+   ```
+
+3. **使用可用工具**
+   - 搜索最佳实践和现代实现方法
+   - 查找组件的无障碍标准
+   - 寻找性能优化技术
+   - 研究类似的成功实现
+   - 查看组件库文档
+
+## 交付物：前端设计文档
+
+在用户指定的位置生成 `frontend-design-spec.md`（请求确认位置，如果未指定则建议 `/docs/design/`）：
+
+```markdown
+# 前端设计规范
+
+## 项目概述
+[设计目标和用户需求的简要描述]
+
+## 技术栈
+- 框架：[用户的框架]
+- 样式：[CSS 方案]
+- 组件：[组件库]
+
+## 设计系统基础
+
+### 配色方案
+[提取的颜色，带有语义命名和使用场景]
+
+### 排版比例
+[字体系列、大小、粗细、行高]
+
+### 间距系统
+[一致的间距值及其应用]
+
+### 组件架构
+
+#### [组件名称]
+**用途**：[此组件的功能]
+**变体**：[变体列表及其用例]
+
+**属性接口**：
+```typescript
+interface [ComponentName]Props {
+  // 详细的属性定义
+}
+```
+
+**视觉规范**：
+- [ ] 基础样式和尺寸
+- [ ] 悬停/激活/焦点状态
+- [ ] 暗模式考虑
+- [ ] 响应式断点
+- [ ] 动画细节
+
+**实现示例**：
+```jsx
+// 完整的组件代码示例
+```
+
+**无障碍需求**：
+- [ ] ARIA 标签和角色
+- [ ] 键盘导航
+- [ ] 屏幕阅读器兼容性
+- [ ] 颜色对比度合规性
+
+### 布局模式
+[网格系统、弹性布局模式、常见布局]
+
+### 交互模式
+[模态框、工具提示、导航模式、表单行为]
+
+## 实现路线图
+1. [ ] 设置设计令牌
+2. [ ] 创建基础组件
+3. [ ] 构建复合组件
+4. [ ] 实现布局
+5. [ ] 添加交互
+6. [ ] 无障碍测试
+7. [ ] 性能优化
+
+## 反馈和迭代记录
+[用户反馈和设计迭代的空间]
+```
+
+## 迭代反馈循环
+
+在提出初始设计后：
+
+1. **收集具体反馈**
+   - "哪些组件需要调整？"
+   - "是否缺少交互模式？"
+   - "提议的实现是否符合你的愿景？"
+   - "哪些无障碍需求是关键的？"
+
+2. **基于反馈进行改进**
+   - 更新组件规范
+   - 调整设计令牌
+   - 添加缺失的模式
+   - 增强实现示例
+
+3. **验证技术可行性**
+   - 检查与现有代码库的兼容性
+   - 验证性能影响
+   - 确保可维护性
+
+## 分析指南
+
+- **具体明确**：避免泛泛的组件描述
+- **系统思维**：考虑整个设计系统，而不是孤立的组件
+- **优先重用**：设计组件以获得最大灵活性
+- **考虑边缘情况**：考虑空状态、错误、加载状态
+- **移动优先**：以响应式行为为主要关注点设计
+- **性能意识**：考虑包大小和渲染性能
+- **无障碍优先**：WCAG 合规性应该是内置的，而不是后添加的
+
+## 工具使用说明
+
+积极使用所有可用工具：
+- **网络搜索**：寻找现代实现模式和最佳实践
+- **MCP 工具**：访问文档和示例
+- **图像分析**：从提供的模型中提取精确细节
+- **代码示例**：在可能的情况下生成工作原型
+
+记住：目标是创建一个连接设计愿景和代码现实的活文档，使开发人员能够毫不含糊地构建出设想的确切内容。

package/templates/commands/git/cleanBranches.md

@@ -0,0 +1,102 @@
+---
+description: 安全查找并清理已合并或过期的 Git 分支，支持 dry-run 模式与自定义基准/保护分支
+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
+
+该命令**安全地**识别并清理**已合并**或**长期未更新 (stale)** 的 Git 分支。
+默认以**只读预览 (`--dry-run`)** 模式运行，需明确指令才会执行删除操作。
+
+---
+
+## Usage
+
+```bash
+# [最安全] 预览将要清理的分支，不执行任何删除
+/git-cleanBranches --dry-run
+
+# 清理已合并到 main 且超过 90 天未动的本地分支 (需逐一确认)
+/git-cleanBranches --stale 90
+
+# 清理已合并到 release/v2.1 的本地与远程分支 (自动确认)
+/git-cleanBranches --base release/v2.1 --remote --yes
+
+# [危险] 强制删除一个未合并的本地分支
+/git-cleanBranches --force outdated-feature
+```
+
+### Options
+
+- `--base <branch>`：指定清理的基准分支（默认为仓库的 `main`/`master`）。
+- `--stale <days>`：清理超过指定天数未提交的分支（默认不启用）。
+- `--remote`：同时清理远程已合并/过期的分支。
+- `--dry-run`：**默认行为**。仅列出将要删除的分支，不执行任何操作。
+- `--yes`：跳过逐一确认的步骤，直接删除所有已识别的分支（适合 CI/CD）。
+- `--force`：使用 `-D` 强制删除本地分支（即使未合并）。
+
+---
+
+## What This Command Does
+
+1. **配置与安全预检**
+   - **更新信息**：自动执行 `git fetch --all --prune`，确保分支状态最新。
+   - **读取保护分支**：从 Git 配置读取不应被清理的分支列表（见下文“Configuration”）。
+   - **确定基准**：使用 `--base` 参数或自动识别的 `main`/`master` 作为比较基准。
+
+2. **分析识别（Find）**
+   - **已合并分支**：找出已完全合并到 `--base` 的本地（及远程，如加 `--remote`）分支。
+   - **过期分支**：如指定 `--stale <days>`，找出最后一次提交在 N 天前的分支。
+   - **排除保护分支**：从待清理列表中移除所有已配置的保护分支。
+
+3. **报告预览（Report）**
+   - 清晰列出“将要删除的已合并分支”与“将要删除的过期分支”。
+   - 若无 `--yes` 参数，**命令到此结束**，等待用户确认后再次执行（不带 `--dry-run`）。
+
+4. **执行清理（Execute）**
+   - **仅在不带 `--dry-run` 且用户确认后**（或带 `--yes`）执行。
+   - 逐一删除已识别的分支，除非用户在交互式确认中选择跳过。
+   - 本地用 `git branch -d <branch>`；远程用 `git push origin --delete <branch>`。
+   - 若指定 `--force`，本地删除会改用 `git branch -D <branch>`。
+
+---
+
+## Configuration (一次配置，永久生效)
+
+为防止误删重要分支（如 `develop`, `release/*`），请在仓库的 Git 配置中添加保护规则。命令会自动读取。
+
+```bash
+# 保护 develop 分支
+git config --add branch.cleanup.protected develop
+
+# 保护所有 release/ 开头的分支 (通配符)
+git config --add branch.cleanup.protected 'release/*'
+
+# 查看所有已配置的保护分支
+git config --get-all branch.cleanup.protected
+```
+
+---
+
+## Best Practices for Embedded Devs
+
+- **优先 `--dry-run`**：养成先预览再执行的习惯。
+- **活用 `--base`**：维护长期 `release` 分支时，用它来清理已合并到该 release 的 `feature` 或 `hotfix` 分支。
+- **谨慎 `--force`**：除非你百分百确定某个未合并分支是无用功，否则不要强制删除。
+- **团队协作**：在清理共享的远程分支前，先在团队频道通知一声。
+- **定期运行**：每月或每季度运行一次，保持仓库清爽。
+
+---
+
+## Why This Version Is Better
+
+- ✅ **更安全**：默认只读预览，且有可配置的保护分支列表。
+- ✅ **更灵活**：支持自定义基准分支，完美适配 `release` / `develop` 工作流。
+- ✅ **更兼容**：避免了在不同系统上行为不一的 `date -d` 等命令。
+- ✅ **更直观**：将复杂的 16 步清单，浓缩成一个带安全选项的、可直接执行的命令。
+- ✅ **风格一致**：与 `/commit` 命令共享相似的参数设计与文档结构。

package/templates/commands/git/commit.md

@@ -0,0 +1,93 @@
+---
+description: 创建格式规范的 Git 提交，使用约定式提交消息
+category: version-control-git
+allowed-tools: Bash, Read, Glob
+---
+
+# Claude 命令：提交
+
+此命令帮助您创建格式规范的提交，使用约定式提交消息格式。
+
+## 使用方法
+
+要创建提交，只需输入：
+
+```
+/commit
+```
+
+或使用选项：
+
+```
+/commit --no-verify
+```
+
+## 命令功能
+
+1. 除非指定 `--no-verify`，否则自动运行预提交检查：
+   - 检测包管理器（npm、pnpm、yarn、bun）并运行相应命令
+   - 运行 lint/format 检查（如果可用）
+   - 运行构建验证（如果存在构建脚本）
+   - 更新文档（如果存在生成脚本）
+2. 使用 `git status` 检查哪些文件已暂存
+3. 如果 0 个文件已暂存，自动使用 `git add` 添加所有修改和新文件
+4. 执行 `git diff` 来理解正在提交的更改
+5. 确保暂存的更改中没有敏感数据（如密码、API 密钥、个人信息、密钥等），如果有，则中止提交并通知用户
+6. 分析差异以确定是否存在多个不同的逻辑更改
+7. 如果检测到多个不同的更改，建议将提交拆分为多个较小的提交
+8. 对于每个提交（如果没有拆分则为单个提交），使用约定式提交格式创建提交消息（确保消息中没有敏感数据），并适当考虑可用的对话历史记录以获取额外上下文，不要立即执行提交，只是生成消息并显示给用户审阅
+9. 将生成的提交消息呈现给用户进行审阅和编辑
+10. 在用户确认后，使用最终确定的消息执行 `git commit` 命令
+
+## 提交最佳实践
+
+- **提交前验证**：确保代码已通过 lint 检查、构建正确且文档已更新
+  - 重要：如果验证失败，请勿继续提交，而是提供需要修复的反馈，以便用户决定如何处理
+  - 重要：不要实际修复问题，只需告知用户需要做什么，并让他们选择是修复还是继续提交
+- **原子提交**：每个提交应包含服务于单一目的的相关更改
+- **拆分大型更改**：如果更改涉及多个关注点，请将它们拆分为单独的提交
+- **约定式提交格式**：使用 `<type>: <description>` 格式，其中 type 可以是：
+  - `feat`: 新功能
+  - `fix`: 错误修复
+  - `docs`: 文档更改
+  - `style`: 代码样式更改（格式化等）
+  - `refactor`: 既不修复错误也不添加功能的代码更改
+  - `perf`: 性能改进
+  - `test`: 添加或修复测试
+  - `chore`: 构建过程、工具等的更改
+- **现在时，祈使语气**：以命令形式编写提交消息（例如，“添加功能”而不是“添加了功能”）
+- **利用上下文**：在相关时使用对话历史记录来通知提交消息，特别是当对话内容可能有助于理解更改意图时，尤其是在由其他 AI 工具审阅完整提交历史记录时，这些工具试图理解更改背后的上下文以理解基本原理、决策制定、意图、解决的问题等
+- **简洁的第一行**：将第一行保持在 72 个字符以内
+
+## Best Practices for Commits
+
+- **Atomic commits**：一次提交只做一件事，便于回溯与审阅。
+- **先分组再提交**：按目录/模块/功能点拆分。
+- **清晰主题**：首行 ≤ 72 字符，祈使语气（如 “add… / fix…”）。
+- **正文含上下文**：说明动机、方案、影响范围、风险与后续工作。
+- **遵循 Conventional Commits**：`<type>(<scope>): <subject>`。
+
+---
+
+## Type 与 Emoji 映射（使用 --emoji 时）
+
+- ✨ `feat`：新增功能
+- 🐛 `fix`：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
+- 📝 `docs`：文档与注释
+- 🎨 `style`：风格/格式（不改语义）
+- ♻️ `refactor`：重构（不新增功能、不修缺陷）
+- ⚡️ `perf`：性能优化
+- ✅ `test`：新增/修复测试、快照
+- 🔧 `chore`：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
+- 👷 `ci`：CI/CD 配置与脚本
+- ⏪️ `revert`：回滚提交
+- 💥 `feat`：破坏性变更（`BREAKING CHANGE:` 段落中说明）
+
+> 若传入 `--type`/`--scope`，将**覆盖**自动推断。
+> 仅在指定 `--emoji` 标志时才会包含 emoji。
+
+---
+
+## 额外指导
+
+$ARGUMENTS

package/templates/commands/git/rollback.md

@@ -0,0 +1,90 @@
+---
+description: 交互式回滚 Git 分支到历史版本；列分支、列版本、二次确认后执行 reset / revert
+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                # 全交互模式，dry‑run
+#   - /git-rollback --branch dev   # 直接选 dev，其他交互
+#   - /git-rollback --branch dev --target v1.2.0 --mode reset --yes
+---
+
+# Claude Command: Git Rollback
+
+**目的**：安全、可视地将指定分支回滚到旧版本。
+默认处于 **只读预览 (`--dry-run`)**；真正执行需加 `--yes` 或在交互中确认。
+
+---
+
+## Usage
+
+```bash
+# 纯交互：列出分支 → 选分支 → 列最近 20 个版本 → 选目标 → 选择 reset 或 revert → 二次确认
+/git-rollback
+
+# 指定分支，其他交互
+/git-rollback --branch feature/calculator
+
+# 指定分支与目标 commit，并用 hard‑reset 一键执行（危险）
+/git-rollback --branch main --target 1a2b3c4d --mode reset --yes
+
+# 只想生成 revert 提交（非破坏式回滚），预览即可
+/git-rollback --branch release/v2.1 --target v2.0.5 --mode revert --dry-run
+```
+
+### Options
+
+| 选项                   | 说明                                                                               |
+| ---------------------- | ---------------------------------------------------------------------------------- |
+| `--branch <branch>`    | 要回滚的分支；缺省时交互选择。                                                     |
+| `--target <rev>`       | 目标版本（commit Hash、Tag、reflog 引用都行）；缺省时交互选择近 `--depth` 条记录。 |
+| `--mode reset\|revert` | `reset`：硬回滚历史；`revert`：生成反向提交保持历史完整。默认询问。                |
+| `--depth <n>`          | 在交互模式下列出最近 n 个版本（默认 20）。                                         |
+| `--dry-run`            | **默认开启**，只预览即将执行的命令。                                               |
+| `--yes`                | 跳过所有确认直接执行，适合 CI/CD 脚本。                                            |
+
+---
+
+## 交互流程
+
+1. **同步远端** → `git fetch --all --prune`
+2. **列分支** → `git branch -a`（本地＋远端，过滤受保护分支）
+3. **选分支** → 用户输入或传参
+4. **列版本** → `git log --oneline -n <depth>` + `git tag --merged` + `git reflog -n <depth>`
+5. **选目标** → 用户输入 commit hash / tag
+6. **选模式** → `reset` 或 `revert`
+7. **最终确认** （除非 `--yes`）
+8. **执行回滚**
+   - `reset`：`git switch <branch> && git reset --hard <target>`
+   - `revert`：`git switch <branch> && git revert --no-edit <target>..HEAD`
+9. **推送建议** → 提示是否 `git push --force-with-lease`（reset）或普通 `git push`（revert）
+
+---
+
+## 安全护栏
+
+- **备份**：执行前自动在 reflog 中记录当前 HEAD，可用 `git switch -c backup/<timestamp>` 恢复。
+- **保护分支**：如检测到 `main` / `master` / `production` 等受保护分支且开启 `reset` 模式，将要求额外确认。
+- **--dry-run 默认开启**：防止误操作。
+- **--force 禁止**：不提供 `--force`；如需强推，请手动输入 `git push --force-with-lease`。
+
+---
+
+## 适用场景示例
+
+| 场景                                            | 调用示例                                                         |
+| ----------------------------------------------- | ---------------------------------------------------------------- |
+| 热修补丁上线后发现 bug，需要回到 Tag `v1.2.0`   | `/git-rollback --branch release/v1 --target v1.2.0 --mode reset` |
+| 运维同事误推了 debug 日志提交，需要生成反向提交 | `/git-rollback --branch main --target 3f2e7c9 --mode revert`     |
+| 调研历史 bug，引导新人浏览分支历史              | `/git-rollback` （全交互，dry‑run）                              |
+
+---
+
+## 注意
+
+1. **reset vs revert**
+   - **reset** 会改变历史，需要强推并可能影响其他协作者，谨慎使用。
+   - **revert** 更安全，生成新提交保留历史，但会增加一次记录。
+2. **嵌入式仓库** 常有大体积二进制文件；回滚前请确保 LFS/子模块状态一致。
+3. 若仓库启用了 CI 强制校验，回滚后可能自动触发流水线；确认管控策略以免误部署旧版本。
+
+---