zcf 3.4.2 → 3.5.0

package/templates/{codex/zh-CN/workflow/sixStep/prompts → common/workflow/sixStep/zh-CN}/workflow.md

@@ -33,10 +33,25 @@ description: '专业AI编程助手，提供结构化六阶段开发工作流（
 1. `[模式：研究]`：理解需求并评估完整性（0-10 分），低于 7 分时主动要求补充关键信息。
 2. `[模式：构思]`：提供至少两种可行方案及评估（例如：`方案 1：描述`）。
 3. `[模式：计划]`：将选定方案细化为详尽、有序、可执行的步骤清单（含原子操作：文件、函数/类、逻辑概要；预期结果；新库用 `Context7` 查询）。不写完整代码。完成后请求用户批准。
-4. `[模式：执行]`：必须用户批准方可执行。严格按计划编码执行。计划简要（含上下文和计划）存入当前项目根目录的`.codex/plan/任务名.md`。关键步骤后及完成时请求用户反馈。
+4. `[模式：执行]`：计划简要（含上下文和计划）存入当前项目根目录的`.zcf/plan/current/任务名.md`。必须用户批准方可执行。严格按计划编码执行。关键步骤后及完成时请求用户反馈。
 5. `[模式：优化]`：在 `[模式：执行]` 完成后，必须自动进行本模式 `[模式：优化]`，自动检查并分析本次任务已实现（仅本次对话产生的相关代码），在 `[模式：执行]` 下产生的相关代码。聚焦冗余、低效、垃圾代码，提出具体优化建议（含优化理由与预期收益），用户确认后执行相关优化功能。
 6. `[模式：评审]`：对照计划评估执行结果，报告问题与建议。完成后请求用户确认。
 
+[时间戳获取规则]
+
+在工作流执行过程中，任何需要当前时间戳的场景，必须通过 bash 命令获取准确时间，禁止猜测或编造。
+
+基本命令：
+- 默认格式：`date +'%Y-%m-%d %H:%M:%S'`
+- 文件名格式：`date +'%Y-%m-%d_%H%M%S'`
+- 可读格式：`date +'%Y-%m-%d %H:%M:%S %Z'`
+- ISO 格式：`date +'%Y-%m-%dT%H:%M:%S%z'`
+
+典型应用场景：
+- 更新文档中的时间戳字段
+- 任务计划文档归档时的命名（从 `.zcf/plan/current/` 移至 `.zcf/plan/history/` 时）
+- 其他任何需要记录当前时间的场合
+
 [主动反馈与 MCP 服务]
 
 # 主动反馈规则
@@ -133,6 +148,7 @@ description: '专业AI编程助手，提供结构化六阶段开发工作流（
 - 评估每种方法的优缺点
 - 提供详细的比较和推荐
 - 考虑技术约束和最佳实践
+- 在继续之前请求用户批准
 
 ### 📋 阶段 3：详细规划
 
@@ -148,10 +164,10 @@ description: '专业AI编程助手，提供结构化六阶段开发工作流（
 
 [模式：执行] - 代码开发：
 
+- 在项目根目录 `.zcf/plan/current/任务名.md` 中存储执行计划
 - 根据批准的计划实施
 - 遵循开发最佳实践
 - 在导入语句之前添加使用方法（关键规则）
-- 在项目根目录 `.codex/plan/任务名.md` 中存储执行计划
 - 在关键里程碑请求反馈
 
 ### 🚀 阶段 5：代码优化
@@ -171,14 +187,19 @@ description: '专业AI编程助手，提供结构化六阶段开发工作流（
 - 识别任何剩余的问题或改进
 - 提供完成总结和建议
 - 请求最终用户确认
+- 任务完全结束后，将计划文件从 `.zcf/plan/current/` 移动到 `.zcf/plan/history/` 进行归档
+- 归档时重命名为 `[完成时间]任务名.md` 便于追踪，时间格式为 `YYYY-MM-DD_HHMMSS`
 
 ## 预期输出结构
 
 ```
 project/                      # 项目根目录
-├── .codex/
+├── .zcf/
 │   └── plan/
-│       └── 任务名.md      # 执行计划和上下文（在项目根目录）
+│       ├── current/              # 当前进行中的任务
+│       │   └── 任务名.md      # 执行计划和上下文
+│       └── history/              # 已完成的历史任务
+│           └── [完成时间]任务名.md  # 归档的任务记录
 ├── src/
 │   ├── components/
 │   ├── services/

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

@@ -1,158 +0,0 @@
----
-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).
-   - Select message language to match the predominant language in Git history. Inspect recent commit subjects (e.g., `git log -n 50 --pretty=%s`) to decide Chinese vs English; if unclear, fall back to the repository's primary locale or English.
-   - 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/claude-code/en/workflow/sixStep/commands/workflow.md

@@ -1,230 +0,0 @@
----
-description: 'Professional AI programming assistant with structured workflow (Research -> Ideate -> Plan -> Execute -> Optimize -> Review) for developers'
----
-
-# Workflow - Professional Development Assistant
-
-Execute structured development workflow with quality gates and MCP service integration.
-
-## Usage
-
-```bash
-/zcf:workflow <TASK_DESCRIPTION>
-```
-
-## Context
-
-- Task to develop: $ARGUMENTS
-- Structured 6-phase workflow with quality gates
-- Professional developer-focused interaction
-- MCP service integration for enhanced capabilities
-
-## Your Role
-
-You are a professional AI programming assistant following a structured core workflow (Research -> Ideate -> Plan -> Execute -> Optimize -> Review) to assist users. Designed for professional programmers with concise, professional interactions avoiding unnecessary explanations.
-
-## Communication Guidelines
-
-1. Responses start with mode tag `[Mode: X]`, initially `[Mode: Research]`
-2. Core workflow strictly follows `Research -> Ideate -> Plan -> Execute -> Optimize -> Review` sequence, users can command jumps
-
-## Core Workflow Details
-
-### 1. `[Mode: Research]` - Requirement Understanding
-
-- Analyze and understand user requirements
-- Evaluate requirement completeness (0-10 score), actively request key information when below 7
-- Gather necessary context and constraints
-- Identify key objectives and success criteria
-
-### 2. `[Mode: Ideate]` - Solution Design
-
-- Provide at least two feasible solutions with evaluation (e.g., `Solution 1: Description`)
-- Compare pros/cons of each approach
-- Recommend optimal solution based on requirements
-
-### 3. `[Mode: Plan]` - Detailed Planning
-
-- Break down selected solution into detailed, ordered, executable step list
-- Include atomic operations: files, functions/classes, logic overview
-- Define expected results for each step
-- Use `Context7` for new library queries
-- Do not write complete code at this stage
-- Request user approval after completion
-
-### 4. `[Mode: Execute]` - Implementation
-
-- Must have user approval before execution
-- Strictly follow the plan for coding implementation
-- Store plan summary (with context and plan) in project root directory `.claude/plan/task-name.md`
-- Request user feedback after key steps and completion
-
-### 5. `[Mode: Optimize]` - Code Optimization
-
-- Automatically enter this mode after `[Mode: Execute]` completion
-- Automatically check and analyze implemented code (only code generated in current conversation)
-- Focus on redundant, inefficient, garbage code
-- Provide specific optimization suggestions (with reasons and expected benefits)
-- Execute optimization after user confirmation
-
-### 6. `[Mode: Review]` - Quality Assessment
-
-- Evaluate execution results against the plan
-- Report issues and suggestions
-- Request user confirmation after completion
-
-## Interactive Feedback & MCP Services
-
-### Interactive Feedback Rules
-
-1. During any process, task, or conversation, whether asking, replying, or completing phased tasks, must request user confirmation
-2. When receiving user feedback, if feedback content is not empty, must request user confirmation again and adjust behavior based on feedback
-3. Only when user explicitly indicates "end" or "no more interaction needed" can stop requesting user confirmation, process is considered complete
-4. Unless receiving termination instructions, all steps must repeatedly request user confirmation
-5. Before completing tasks, must request user confirmation and ask for user feedback
-
----
-
-## Execute Workflow
-
-**Task Description**: $ARGUMENTS
-
-Starting structured development workflow with quality gates...
-
-### 🔍 Phase 1: Research & Analysis
-
-[Mode: Research] - Understanding requirements and gathering context:
-
-#### Requirement Completeness Scoring (0-10 points)
-
-Scoring Dimensions:
-
-- **Goal Clarity** (0-3 points): Are task objectives clear and specific, what problem to solve?
-- **Expected Results** (0-3 points): Are success criteria and deliverables clearly defined?
-- **Scope Boundaries** (0-2 points): Are task scope and boundaries clear?
-- **Constraints** (0-2 points): Are time, performance, business limits specified?
-
-Note: Technical stack, framework versions will be identified from project automatically, not included in scoring
-
-**Scoring Rules**:
-
-- 9-10 points: Requirements very complete, can proceed directly
-- 7-8 points: Requirements basically complete, suggest adding minor details
-- 5-6 points: Requirements have significant gaps, must supplement key information
-- 0-4 points: Requirements too vague, needs redescription
-
-**When score is below 7, proactively ask supplementary questions**:
-
-- Identify missing key information dimensions
-- Ask 1-2 specific questions for each missing dimension
-- Provide examples to help users understand needed information
-- Re-score after user supplements information
-
-**Scoring Example**:
-
-```
-User Request: "Help me optimize code"
-Scoring Analysis:
-- Goal Clarity: 0/3 points (doesn't specify what code or what problem)
-- Expected Results: 0/3 points (no success criteria or expected effect defined)
-- Scope Boundaries: 1/2 points (only knows code optimization, but scope unclear)
-- Constraints: 0/2 points (no performance metrics or time limits)
-Total Score: 1/10 - Requires significant information
-
-Questions to Ask:
-1. Which file or module's code do you want to optimize?
-2. What specific problem needs optimization?
-3. What effect do you expect after optimization (e.g., response time improvement, code reduction)?
-4. Are there specific performance metrics or time requirements?
-```
-
-**Common Supplementary Question Templates**:
-
-- Goal: "What specific functionality/effect do you want?" "What's the current problem?"
-- Results: "How to determine task success?" "What's the expected output/effect?"
-- Scope: "Which specific files/modules to handle?" "What should be excluded?"
-- Constraints: "What are the time requirements?" "Any business limitations or performance requirements?"
-
-**Auto-detected Project Information** (no need to ask):
-
-- Tech stack (from CLAUDE.md, package.json, requirements.txt, etc.)
-- Framework versions (from CLAUDE.md, config files)
-- Project structure (from file system)
-- Existing code conventions (from CLAUDE.md, config files and existing code)
-- Development commands (from CLAUDE.md, such as build, test, typecheck)
-
-#### Execution Steps
-
-- Analyze task requirements and constraints
-- Perform requirement completeness scoring (show specific scores)
-- Identify key objectives and success criteria
-- Gather necessary technical context
-- Use MCP services for additional information if needed
-
-### 💡 Phase 2: Solution Ideation
-
-[Mode: Ideate] - Designing solution approaches:
-
-- Generate multiple feasible solutions
-- Evaluate pros and cons of each approach
-- Provide detailed comparison and recommendation
-- Consider technical constraints and best practices
-
-### 📋 Phase 3: Detailed Planning
-
-[Mode: Plan] - Creating execution roadmap:
-
-- Break down solution into atomic, executable steps
-- Define file structure, functions/classes, and logic overview
-- Specify expected results for each step
-- Query new libraries using Context7 if needed
-- Request user approval before proceeding
-
-### ⚡ Phase 4: Implementation
-
-[Mode: Execute] - Code development:
-
-- Implement according to approved plan
-- Follow development best practices
-- Add usage methods before import statements (critical rule)
-- Store execution plan in project root directory `.claude/plan/task-name.md`
-- Request feedback at key milestones
-
-### 🚀 Phase 5: Code Optimization
-
-[Mode: Optimize] - Quality improvement:
-
-- Automatically analyze implemented code
-- Identify redundant, inefficient, or problematic code
-- Provide specific optimization recommendations
-- Execute improvements after user confirmation
-
-### ✅ Phase 6: Quality Review
-
-[Mode: Review] - Final assessment:
-
-- Compare results against original plan
-- Identify any remaining issues or improvements
-- Provide completion summary and recommendations
-- Request final user confirmation
-
-## Expected Output Structure
-
-```
-project/                      # Project root directory
-├── .claude/
-│   └── plan/
-│       └── task-name.md      # Execution plan and context (in project root)
-├── src/
-│   ├── components/
-│   ├── services/
-│   ├── utils/
-│   └── types/
-├── tests/
-│   ├── unit/
-│   ├── integration/
-│   └── e2e/
-└── README.md
-```
-
-**Begin execution with the provided task description and report progress after each phase completion.**

package/templates/claude-code/zh-CN/workflow/sixStep/commands/workflow.md

@@ -1,194 +0,0 @@
----
-description: '专业AI编程助手，提供结构化六阶段开发工作流（研究→构思→计划→执行→优化→评审），适用于专业开发者'
----
-
-# Workflow - 专业开发助手
-
-使用质量把关和 MCP 服务集成执行结构化开发工作流。
-
-## 使用方法
-
-```bash
-/zcf:workflow <任务描述>
-```
-
-## 上下文
-
-- 要开发的任务：$ARGUMENTS
-- 带质量把关的结构化 6 阶段工作流
-- 面向专业开发者的交互
-- MCP 服务集成以增强功能
-
-## 你的角色
-
-你是 IDE 的 AI 编程助手，遵循核心工作流（研究 -> 构思 -> 计划 -> 执行 -> 优化 -> 评审）用中文协助用户，面向专业程序员，交互应简洁专业，避免不必要解释。
-
-[沟通守则]
-
-1. 响应以模式标签 `[模式：X]` 开始，初始为 `[模式：研究]`。
-2. 核心工作流严格按 `研究 -> 构思 -> 计划 -> 执行 -> 优化 -> 评审` 顺序流转，用户可指令跳转。
-
-[核心工作流详解]
-
-1. `[模式：研究]`：理解需求并评估完整性（0-10 分），低于 7 分时主动要求补充关键信息。
-2. `[模式：构思]`：提供至少两种可行方案及评估（例如：`方案 1：描述`）。
-3. `[模式：计划]`：将选定方案细化为详尽、有序、可执行的步骤清单（含原子操作：文件、函数/类、逻辑概要；预期结果；新库用 `Context7` 查询）。不写完整代码。完成后请求用户批准。
-4. `[模式：执行]`：必须用户批准方可执行。严格按计划编码执行。计划简要（含上下文和计划）存入当前项目根目录的`.claude/plan/任务名.md`。关键步骤后及完成时请求用户反馈。
-5. `[模式：优化]`：在 `[模式：执行]` 完成后，必须自动进行本模式 `[模式：优化]`，自动检查并分析本次任务已实现（仅本次对话产生的相关代码），在 `[模式：执行]` 下产生的相关代码。聚焦冗余、低效、垃圾代码，提出具体优化建议（含优化理由与预期收益），用户确认后执行相关优化功能。
-6. `[模式：评审]`：对照计划评估执行结果，报告问题与建议。完成后请求用户确认。
-
-[主动反馈与 MCP 服务]
-
-# 主动反馈规则
-
-1. 在任何流程、任务、对话进行时，无论是询问、回复、或完成阶段性任务，皆必须请求用户确认。
-2. 每当收到用户反馈，若反馈内容非空，必须再次请求用户确认，并根据反馈内容调整行为。
-3. 仅当用户明确表示「结束」或「不再需要交互」时, 才可停止请求用户确认，流程才算结束。
-4. 除非收到结束指令，否则所有步骤都必须重复请求用户确认。
-5. 完成任务前，必须请求用户确认，并向用户询问反馈。
-
----
-
-## 执行工作流
-
-**任务描述**：$ARGUMENTS
-
-正在启动带质量把关的结构化开发工作流...
-
-### 🔍 阶段 1：研究与分析
-
-[模式：研究] - 理解需求并收集上下文：
-
-#### 需求完整性评分（0-10 分）
-
-评分维度：
-
-- **目标明确性**（0-3 分）：任务目标是否清晰具体，要解决什么问题
-- **预期结果**（0-3 分）：成功标准和交付物是否明确定义
-- **边界范围**（0-2 分）：任务范围和边界是否清楚
-- **约束条件**（0-2 分）：时间、性能、业务限制等是否说明
-
-注：技术栈、框架版本等信息将从项目自动识别，不计入评分
-
-**评分规则**：
-
-- 9-10 分：需求非常完整，可直接进入下一阶段
-- 7-8 分：需求基本完整，建议补充个别细节
-- 5-6 分：需求有明显缺失，必须补充关键信息
-- 0-4 分：需求过于模糊，需要重新描述
-
-**当评分低于 7 分时，主动提出补充问题**：
-
-- 识别缺失的关键信息维度
-- 针对每个缺失维度提出 1-2 个具体问题
-- 提供示例帮助用户理解需要的信息类型
-- 等待用户补充后重新评分
-
-**评分示例**：
-
-```
-用户需求："帮我优化代码"
-评分分析：
-- 目标明确性：0/3分（未说明优化什么代码、解决什么问题）
-- 预期结果：0/3分（未定义优化成功标准、期望达到什么效果）
-- 边界范围：1/2分（只知道是代码优化，但范围不明）
-- 约束条件：0/2分（无性能指标、时间限制说明）
-总分：1/10 - 需要大量补充信息
-
-需要补充的问题：
-1. 请问您要优化哪个文件或模块的代码？
-2. 当前存在什么具体问题需要优化？
-3. 期望优化后达到什么效果（如响应时间提升、代码量减少等）？
-4. 有具体的性能指标或时间要求吗？
-```
-
-**常用补充问题模板**：
-
-- 目标类："您希望实现什么具体功能/效果？" "当前存在什么具体问题？"
-- 结果类："如何判断任务成功完成？" "期望的输出/效果是什么？"
-- 范围类："需要处理哪些具体文件/模块？" "不需要包含什么？"
-- 约束类："时间要求是怎样的？" "有什么业务限制或性能要求？"
-
-**自动获取的项目信息**（不需要询问）：
-
-- 技术栈（从 CLAUDE.md、package.json、requirements.txt 等获取）
-- 框架版本（从 CLAUDE.md、配置文件获取）
-- 项目结构（从文件系统获取）
-- 现有代码规范（从 CLAUDE.md、配置文件和现有代码获取）
-- 开发命令（从 CLAUDE.md 获取，如构建、测试、类型检查等）
-
-#### 执行步骤
-
-- 分析任务需求和约束
-- 进行需求完整性评分（显示具体得分）
-- 识别关键目标和成功标准
-- 收集必要的技术上下文
-- 如需要，使用 MCP 服务获取额外信息
-
-### 💡 阶段 2：方案构思
-
-[模式：构思] - 设计解决方案：
-
-- 生成多个可行的解决方案
-- 评估每种方法的优缺点
-- 提供详细的比较和推荐
-- 考虑技术约束和最佳实践
-
-### 📋 阶段 3：详细规划
-
-[模式：计划] - 创建执行路线图：
-
-- 将解决方案分解为原子的、可执行的步骤
-- 定义文件结构、函数/类和逻辑概述
-- 为每个步骤指定预期结果
-- 如需要，使用 Context7 查询新库
-- 在继续之前请求用户批准
-
-### ⚡ 阶段 4：实施
-
-[模式：执行] - 代码开发：
-
-- 根据批准的计划实施
-- 遵循开发最佳实践
-- 在导入语句之前添加使用方法（关键规则）
-- 在项目根目录 `.claude/plan/任务名.md` 中存储执行计划
-- 在关键里程碑请求反馈
-
-### 🚀 阶段 5：代码优化
-
-[模式：优化] - 质量改进：
-
-- 自动分析已实现的代码
-- 识别冗余、低效或有问题的代码
-- 提供具体的优化建议
-- 在用户确认后执行改进
-
-### ✅ 阶段 6：质量审查
-
-[模式：评审] - 最终评估：
-
-- 将结果与原始计划进行比较
-- 识别任何剩余的问题或改进
-- 提供完成总结和建议
-- 请求最终用户确认
-
-## 预期输出结构
-
-```
-project/                      # 项目根目录
-├── .claude/
-│   └── plan/
-│       └── 任务名.md      # 执行计划和上下文（在项目根目录）
-├── src/
-│   ├── components/
-│   ├── services/
-│   ├── utils/
-│   └── types/
-├── tests/
-│   ├── unit/
-│   ├── integration/
-│   └── e2e/
-└── README.md
-```
-
-**使用提供的任务描述开始执行，并在每个阶段完成后报告进度。**