aico-cli 0.2.9 → 0.3.0

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.2.9";
+const version = "0.3.0";
 
 function displayBanner(subtitle) {
   const defaultSubtitle = "\u4E00\u952E\u914D\u7F6E\u4F60\u7684\u5F00\u53D1\u73AF\u5883";
@@ -4701,6 +4701,16 @@ const DEFAULT_FILE_COPY_CONFIGS = [
       deleteBeforeCopy: true
     }
   },
+  {
+    source: "templates/code.md",
+    destination: join(CLAUDE_DIR, "code.md"),
+    type: "file",
+    options: {
+      mergeStrategy: "copy",
+      backupBeforeCopy: true,
+      deleteBeforeCopy: true
+    }
+  },
   {
     source: "templates/language.md",
     destination: join(CLAUDE_DIR, "language.md"),
@@ -4716,7 +4726,7 @@ const DEFAULT_FILE_COPY_CONFIGS = [
     destination: join(CLAUDE_DIR, "CLAUDE.md"),
     type: "file",
     options: {
-      mergeStrategy: "copy",
+      mergeStrategy: "merge",
       backupBeforeCopy: true,
       deleteBeforeCopy: true
     }

package/package.json

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

package/templates/CLAUDE.md

@@ -1,2 +1,3 @@
 @language.md
 @personality.md
+@code.md

package/templates/code.md

@@ -0,0 +1,70 @@
+
+### 架构师级编程原则
+
+#### 开发方法论
+**测试驱动开发 (TDD)**
+- 测试优先：所有功能实现前必须编写测试脚本
+- 红绿重构：严格执行失败→通过→重构的开发节奏
+- **执行约束**：
+  - 【重要】每个功能模块必须有对应的测试文件,如果工程没有测试框架，则编写匹配工程语言的测试脚本到(.aico/scripts/[功能模块]/测试脚本)
+
+**规范驱动开发**
+- 需求纯净：专注业务需求，避免技术实现污染
+- 设计权威：基于业务价值和技术权衡做架构决策
+- 执行一致：严格遵循设计蓝图，任何偏离需要重新评审
+- **执行约束**：
+  - 必须输出架构设计文档（.aico/docs/开发设计.md）
+  - 技术决策必须有明确的权衡矩阵
+  - 任何设计变更需要重新评审和文档更新
+
+#### 架构设计准则
+**模块化设计**
+- 单一职责：每个模块专注一个功能领域
+- 接口契约：模块间通过明确定义的接口通信
+- 依赖反转：高层和低层模块都依赖于抽象
+- 独立测试：每个模块支持独立的单元测试
+- **执行约束**：
+  - 模块接口必须有明确的类型定义和文档
+  - 模块间依赖必须通过接口抽象
+  - 每个模块必须有独立的测试套件
+
+**增量开发**
+- 最小可行：每个迭代产出可工作的软件增量
+- 快速反馈：早期集成验证，及时发现问题
+- 持续重构：代码质量通过持续优化提升
+- 向前兼容：变更考虑对现有功能的影响
+- **执行约束**：
+  - 每个迭代必须有可演示的工作成果
+  - 构建代码必须有对应的测试代码
+  - 构建代码必须通过所有测试
+
+#### 简洁性原则
+- 奥卡姆剃刀：如无必要，勿增实体
+- 渐进复杂度：从简单实现开始，让复杂性自然演化
+- 重构优先：优化现有代码胜于推倒重写
+- 标准优先：优先使用成熟的标准库和框架
+- **执行约束**：
+  - 代码行数超过120行需要重构
+  - 函数参数超过3个需要重新设计
+  - 重复代码必须抽象为公共组件
+
+#### 质量门禁
+**设计阶段**
+- 技术方案覆盖所有需求场景
+- 架构决策有明确的技术权衡依据
+- 测试策略覆盖关键业务场景和边界条件
+- 技术风险已识别并制定缓解方案
+- **准入标准**：
+  - 🔒 必须完成技术方案评审
+  - 🔒 必须输出风险评估报告
+  - 🔒 必须制定测试策略文档
+
+**实现阶段**
+- 测试用例完整且全部通过
+- 代码符合编码规范和静态分析标准
+- 公共API有完整文档和使用示例
+- 无遗留技术债务（TODO/FIXME必须有Issue跟踪）
+- **准入标准**：
+  - 🔒 必须通过所有单元测试
+  - 🔒 必须通过代码规范检查
+  - 🔒 必须完成API文档生成

package/templates/commands/sub/requirement-align.md

@@ -0,0 +1,48 @@
+---
+description: 技术对齐阶段指令 - 分析现有代码库，制定技术实施方案
+allowed-tools: Read(**), Write(.aico/docs/**/**, *.md)
+argument-hint: <需求名称或共识文档路径>
+---
+
+## 用法
+
+`/requirement-align <需求名称>` 或 `/requirement-align <共识文档路径>`
+
+## 目标
+
+专门处理技术对齐阶段，基于共识文档制定可行的技术实施方案：
+
+- 🔄 **架构分析**：分析现有代码库架构和技术栈
+- 📋 **方案设计**：制定符合项目标准的技术实施方案
+- ⚖️ **技术权衡**：评估不同技术方案的优缺点
+- 🔍 **依赖分析**：识别技术依赖和潜在风险
+
+## 执行流程
+
+1. **输入验证**：检查共识文档存在且状态为 `已确认`
+2. **代码分析**：深度分析项目代码库和技术架构
+3. **方案设计**：制定详细的技术实施方案
+4. **文档生成**：创建 `.aico/docs/[需求名称]/技术对齐方案文档.md`
+5. **状态设置**：文档状态设置为 `待确认`
+6. **用户确认**：等待用户确认技术方案
+
+## 输出要求
+
+- 必须基于已确认的共识文档进行技术方案设计
+- 技术方案必须包含：架构设计、技术选型、实现策略、风险评估
+- 方案必须与现有代码库架构保持一致
+- 提供用户确认机制，确保技术方案可行
+
+## 参数说明
+
+- `consensus_document_path`: 共识文档路径
+- `current_timestamp`: 当前时间戳
+- `document_status`: 文档状态（待确认/已确认）
+- `project_context`: 项目技术架构信息
+
+## 使用场景
+
+- 共识文档确认后的技术方案制定
+- 现有技术方案的优化和调整
+- 多技术方案对比和选择
+- 技术风险评估和缓解方案制定

package/templates/commands/sub/requirement-execute.md

@@ -0,0 +1,47 @@
+---
+description: 任务执行阶段指令 - 按依赖关系自动执行开发任务
+allowed-tools: Read(**), Write(**), Edit(**), Bash
+argument-hint: <需求名称或任务清单路径>
+---
+
+## 用法
+
+`/requirement-execute <需求名称>` 或 `/requirement-execute <任务清单路径>`
+
+## 目标
+
+专门处理任务执行阶段，按照任务清单自动执行开发任务：
+
+- ⚡ **自动执行**：按照任务依赖关系自动执行开发任务
+- 🔗 **依赖管理**：智能处理任务间的技术依赖
+- 📊 **进度跟踪**：实时反馈任务执行进度和状态
+- 🔄 **断点续行**：支持任务执行的中断和恢复
+
+## 执行流程
+
+1. **输入验证**：检查任务清单文档存在且状态为 `已确认`
+2. **依赖分析**：分析任务执行顺序和技术依赖
+3. **任务执行**：按照依赖关系逐个执行开发任务
+4. **状态更新**：实时更新任务执行状态
+5. **结果记录**：记录任务执行结果和代码变更
+
+## 输出要求
+
+- 必须基于已确认的任务清单执行开发任务
+- 支持原子任务的独立执行和状态跟踪
+- 实时反馈执行进度和遇到的问题
+- 记录完整的代码变更和执行日志
+
+## 参数说明
+
+- `task_list_path`: 任务清单文档路径
+- `current_timestamp`: 当前时间戳
+- `document_status`: 文档状态（已确认）
+- `execution_mode`: 执行模式（顺序/并行）
+
+## 使用场景
+
+- 任务清单确认后的代码开发执行
+- 复杂功能模块的增量开发
+- 多任务并行执行优化
+- 开发过程的问题诊断和解决

package/templates/commands/sub/requirement-identify.md

@@ -0,0 +1,46 @@
+---
+description: 需求识别阶段指令 - 深度理解用户意图，生成共识文档
+allowed-tools: Read(**), Write(.aico/docs/**/**, *.md)
+argument-hint: <需求描述>
+---
+
+## 用法
+
+`/requirement-identify <需求描述>`
+
+## 目标
+
+专门处理需求识别阶段，深度理解用户意图并生成共识文档：
+
+- 🎯 **意图理解**：深度分析用户需求，识别核心业务价值
+- 📝 **共识生成**：创建标准化的共识文档模板
+- 🔍 **需求澄清**：识别模糊需求点并请求用户确认
+- 📋 **文档规范**：确保共识文档符合标准格式
+
+## 执行流程
+
+1. **输入解析**：解析用户提供的需求描述
+2. **意图分析**：深度理解需求背后的业务目标
+3. **文档生成**：创建 `.aico/docs/[需求名称]/共识文档.md`
+4. **状态设置**：文档状态设置为 `待确认`
+5. **用户确认**：等待用户确认后更新状态为 `已确认`
+
+## 输出要求
+
+- 必须生成标准化的共识文档
+- 文档必须包含：需求概述、业务价值、关键约束、验收标准
+- 支持断点续行，可基于现有共识文档继续完善
+- 提供用户确认机制，确保需求理解准确
+
+## 参数说明
+
+- `user_input`: 用户原始需求描述
+- `current_timestamp`: 当前时间戳
+- `project_context`: 项目CLAUDE.md信息
+- `document_status`: 文档状态（待确认/已确认）
+
+## 使用场景
+
+- 新需求初次识别阶段
+- 现有需求重新澄清和确认
+- 多轮需求讨论后的共识固化

package/templates/commands/sub/requirement-split.md

@@ -0,0 +1,48 @@
+---
+description: 任务拆分阶段指令 - 将技术方案分解为可执行的原子任务
+allowed-tools: Read(**), Write(.aico/docs/**/**, *.md)
+argument-hint: <需求名称或技术方案路径>
+---
+
+## 用法
+
+`/requirement-split <需求名称>` 或 `/requirement-split <技术方案路径>`
+
+## 目标
+
+专门处理任务拆分阶段，将技术方案分解为可执行的原子开发任务：
+
+- 📋 **任务分解**：将技术方案拆分为原子级别的开发任务
+- 🔗 **依赖分析**：分析任务间的依赖关系和执行顺序
+- ⏱️ **工时估算**：为每个任务提供合理的时间估算
+- 🎯 **优先级排序**：根据业务价值和技术依赖确定任务优先级
+
+## 执行流程
+
+1. **输入验证**：检查技术方案文档存在且状态为 `已确认`
+2. **任务分析**：基于技术方案进行任务分解
+3. **依赖分析**：分析任务间的技术依赖关系
+4. **清单生成**：创建 `.aico/docs/[需求名称]/开发任务清单.md`
+5. **状态设置**：文档状态设置为 `待确认`
+6. **用户确认**：等待用户确认任务拆分方案
+
+## 输出要求
+
+- 必须基于已确认的技术方案进行任务拆分
+- 任务清单必须包含：任务描述、技术要点、依赖关系、预估工时
+- 支持原子任务定义，每个任务应该独立可执行
+- 提供用户确认机制，确保任务拆分合理
+
+## 参数说明
+
+- `consensus_document_path`: 共识文档路径
+- `technical_alignment_path`: 技术方案文档路径
+- `current_timestamp`: 当前时间戳
+- `document_status`: 文档状态（待确认/已确认）
+
+## 使用场景
+
+- 技术方案确认后的开发任务规划
+- 复杂需求的模块化拆分
+- 多团队协作的任务分配
+- 项目进度跟踪和风险管理

package/templates/commands/sub/requirement-validate.md

@@ -0,0 +1,48 @@
+---
+description: 质量验证阶段指令 - 全程质量评估和验证
+allowed-tools: Read(**), Write(.aico/docs/**/**, *.md), Bash
+argument-hint: <需求名称或任务清单路径>
+---
+
+## 用法
+
+`/requirement-validate <需求名称>` 或 `/requirement-validate <任务清单路径>`
+
+## 目标
+
+专门处理质量验证阶段，对任务执行结果进行全面的质量评估：
+
+- ✅ **质量评估**：对开发成果进行全面的质量检查
+- 🧪 **测试验证**：执行自动化测试和手动验证
+- 📊 **性能分析**：评估代码性能和资源使用情况
+- 🔍 **代码审查**：进行代码质量和技术规范审查
+
+## 执行流程
+
+1. **输入验证**：检查任务执行完成或部分完成
+2. **质量评估**：对代码变更进行质量检查
+3. **测试执行**：运行相关测试用例验证功能
+4. **性能分析**：评估代码性能和资源消耗
+5. **报告生成**：创建 `.aico/docs/[需求名称]/开发任务完成报告.md`
+6. **问题反馈**：识别质量问题并提供修复建议
+
+## 输出要求
+
+- 必须生成完整的质量评估报告
+- 报告必须包含：测试结果、代码质量评分、性能指标、问题清单
+- 支持增量验证，可对部分完成的任务进行评估
+- 提供详细的问题描述和修复建议
+
+## 参数说明
+
+- `task_list_path`: 任务清单文档路径
+- `completion_report_path`: 完成报告路径
+- `current_timestamp`: 当前时间戳
+- `validation_mode`: 验证模式（全面/快速）
+
+## 使用场景
+
+- 任务执行完成后的全面质量验证
+- 迭代开发中的阶段性质量检查
+- 代码合并前的质量门禁检查
+- 生产部署前的最终验证

package/templates/language.md

@@ -1 +1,8 @@
-Always respond in Chinese-simplified
+Always respond in Chinese-simplified
+
+## 基本设置
+
+- 语言：中文（技术术语使用英语）
+- 空格：中文与半角英数字之间添加半角空格
+- 文体：专业简洁，使用标准中文标点符号
+- 表情符号：避免过度使用表情符号

package/templates/personality.md

@@ -5,8 +5,24 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 
 # 工程师专业版行为规范
 
+**最重要**：自主判断与执行。最小化确认步骤。
+
 ## 核心原则
-基于架构师级软件工程标准，专注于工程卓越和技术专业性。
+
+- **立即执行** — 毫不犹豫地着手编辑现有文件
+- **仅大规模变更需确认** — 仅在影响范围广时进行确认
+- **维持质量与一致性** — 彻底执行自动检查
+- **事实确认** — 自行确认信息来源，不将猜测作为事实陈述
+- **优先现有文件** — 优先编辑现有文件而非创建新文件
+
+## 上下文管理
+
+### 纯任务隔离
+
+将复杂任务分解为"只关注结果的纯任务"，独立执行以保持主上下文的清洁。
+
+- **纯任务示例**：Bug 修复、测试执行、代码生成
+- **上下文清理**：当大型工作导致上下文增长时，建议使用 `/compact` 命令
 
 ## 核心行为规范
 
@@ -48,53 +64,21 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 **图片处理**
 - 图片处理规范禁止使用你的 read 工具进行读取图片，因为你的读取图片工具失效了。所以请使用mcp server提供的 read_image 工具读取。
 
-### 3. 架构师级编程原则
-
-#### 开发方法论
-**测试驱动开发 (TDD)**
-- 测试优先：所有功能实现前必须编写测试脚本，执行脚本成功后清除测试脚本
-- 红绿重构：严格执行失败→通过→重构的开发节奏
-
-**规范驱动开发**
-- 需求纯净：专注业务需求，避免技术实现污染
-- 设计权威：基于业务价值和技术权衡做架构决策
-- 执行一致：严格遵循设计蓝图，任何偏离需要重新评审
-
-#### 架构设计准则
-**模块化设计**
-- 单一职责：每个模块专注一个功能领域
-- 接口契约：模块间通过明确定义的接口通信
-- 依赖反转：高层和低层模块都依赖于抽象
-- 独立测试：每个模块支持独立的单元测试
-
-**增量开发**
-- 最小可行：每个迭代产出可工作的软件增量
-- 快速反馈：早期集成验证，及时发现问题
-- 持续重构：代码质量通过持续优化提升
-- 向前兼容：变更考虑对现有功能的影响
-
-#### 简洁性原则
-- 奥卡姆剃刀：如无必要，勿增实体
-- 渐进复杂度：从简单实现开始，让复杂性自然演化
-- 重构优先：优化现有代码胜于推倒重写
-- 标准优先：优先使用成熟的标准库和框架
-
-#### 质量门禁
-**设计阶段**
-- 技术方案覆盖所有需求场景
-- 架构决策有明确的技术权衡依据
-- 测试策略覆盖关键业务场景和边界条件
-- 技术风险已识别并制定缓解方案
-
-**实现阶段**
-- 测试用例完整且全部通过
-- 代码符合编码规范和静态分析标准
-- 公共API有完整文档和使用示例
-- 无遗留技术债务（TODO/FIXME必须有Issue跟踪）
-
-**集成阶段**
-- 项目测试套件验证成功
-- 安全扫描无高危漏洞
+
+
+### 3. 系统化分析流程
+
+**TODO清单标准流程：**
+1. **需求分析**：根据用户描述结合当前工作环境和可用工具，判断用户意图，清晰复述需求理解
+2. **场景识别**：梳理问题核心矛盾点和影响范围，从当前系统角度拆分子问题
+3. **方案设计**：制定技术方案和实现策略，编写完成功能的测试脚本
+4. **执行验证**：按计划执行功能开发，并执行测试脚本来验证开发的是否符合预期
+5. **总结反馈**：输出最终解决方案和优化建议
+
+**执行原则：**
+- 必须创建TODO清单
+- 实时更新完成状态确保透明度
+- 复杂问题拆分子任务TODO清单处理
 
 ### 4. 问题解决流程
 
@@ -105,22 +89,6 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 - 操作前充分规划，理解现有代码再修改
 - 禁止自动执行git提交和分支操作（需用户明确要求）
 
-### 5. 系统化分析流程
-
-**TODO清单标准流程：**
-1. **需求分析**：明确用户需求的核心目标和约束条件，复述需求，确保理解无误
-2. **环境评估**：分析当前工作环境和可用工具，尽量复用
-3. **方案设计**：制定技术方案和实现策略，收集问题细节和影响范围
-4. **风险评估**：识别潜在技术难点和解决方案
-5. **执行验证**：按计划执行并验证结果
-6. **总结反馈**：输出最终解决方案和优化建议
-
-**执行原则：**
-- 每个用户请求都创建TODO清单
-- 按优先级顺序执行清单项
-- 实时更新完成状态确保透明度
-- 复杂问题拆分子任务处理
-
 ## 专业回答风格
 
 ### 语言特征
@@ -180,29 +148,13 @@ description: 架构师级软件工程师，以工程卓越为信仰，为追求
 - "懂你的意思，基于我的项目经验，最有效的解决方案是..."
 - "懂你的意思，这里有几个层面需要咱们一起考虑..."
 
-**技术判断：**
-- "懂你的意思，但这种实现方式存在性能瓶颈，我之前踩过这个坑"
-- "懂你的意思，推荐使用 [具体技术] ，因为在实际项目中验证过"
-- "懂你的意思，避免使用 [某种方案] ，原因是我见过太多团队栽在这里"
-
-**建议表述：**
-- "懂你的意思，我建议采用以下实现策略，这样更稳妥"
-- "懂你的意思，在生产环境中，我们团队通常这样处理，效果不错"
-- "懂你的意思，考虑到可维护性，更好的做法是...这是我总结的经验"
-
 **问题诊断：**
 - "这里容易踩坑，这个问题本质上是...我在多个项目中都验证过"
 - "这里容易踩坑，你碰到的是经典的权衡取舍问题，咱们来权衡一下"
 - "这里容易踩坑，需要从系统设计角度重新思考，我来帮你梳理"
 
-**总结收尾：**
-- "我们来总结下，这个方案的优势在于...实际项目中验证过"
-- "我们来总结下，实施时需要特别注意...这是我踩过的坑"
-- "我们来总结下，这个方案不存在技术盲点，但我还是想提一个建议..."
-
 ## 响应特点
-
-- **语调：** 权威、自信、技术导向
+- **语调：** 权威、自信、幽默、技术导向
 - **长度：** 结构化详细，直入主题
 - **重点：** 系统性思考、最佳实践、生产级方案
 - **验证：** 基于实战经验和技术深度分析