ccjk 14.2.2 → 15.1.0

package/dist/templates/common/workflow/sixStep/en/workflow.md

@@ -1,83 +0,0 @@
----
-description: 'Structured six-stage development workflow for research, planning, implementation, optimization, and review'
-argument-hint: <task description> [--skip-research] [--quick] [--focus <stage>]
----
-
-# Structured Development Workflow
-
-Use this workflow when the user wants a broader staged execution loop rather than planning alone.
-
-## Command context
-
-- Workflow bundle: `sixStepsWorkflow`
-- Installed command file: `workflow.md`
-- Claude Code command: `/ccjk:workflow <task description>`
-- Codex command: `/prompts:workflow <task description>`
-
-## User request
-
-$ARGUMENTS
-
-## Workflow stages
-
-1. **Research**
-   - understand the request, current codebase constraints, and success criteria
-   - identify missing context or important risks
-
-2. **Ideate**
-   - generate realistic solution directions
-   - compare trade-offs and recommend a path
-
-3. **Plan**
-   - break the chosen direction into concrete implementation steps
-   - name affected files, logic areas, and validation steps
-
-4. **Execute**
-   - implement the approved plan
-   - stay within scope and keep progress visible
-
-5. **Optimize**
-   - improve the new implementation where there is clear payoff
-   - avoid unrelated cleanup
-
-6. **Review**
-   - verify the result against the plan
-   - summarize what shipped and what remains unverified
-
-## How to respond
-
-- Start in the stage that best matches the user request.
-- If the request is underspecified, stay in research until the task is clear enough.
-- If the user already has a clear approach, move quickly into planning and execution.
-- Ask for approval before meaningful implementation when the task requires planning.
-- Keep the workflow grounded in the actual repository and runtime.
-
-## Output shape
-
-Structure the response in this form when useful:
-
-```markdown
-# Current stage
-- Research / Ideate / Plan / Execute / Optimize / Review
-
-# Goal
-- What is being solved
-
-# Findings or options
-- Key context, trade-offs, or chosen approach
-
-# Next steps
-1. Step one
-2. Step two
-3. Step three
-
-# Verification
-- Tests, build, or checks to run
-```
-
-## Behavioral guardrails
-
-- Do not overclaim automation.
-- Do not describe capabilities that are not actually wired into the shipped runtime.
-- Prefer concise, implementation-oriented output.
-- Keep recommendations tied to the current project instead of generic process theater.

package/dist/templates/common/workflow/sixStep/zh-CN/workflow.md

@@ -1,359 +0,0 @@
----
-description: '专业AI编程助手，提供结构化六阶段开发工作流（研究→构思→计划→执行→优化→评审），适用于专业开发者'
-argument-hint: <任务描述> [--skip-research] [--quick] [--focus <阶段>]
-# examples:
-#   - /workflow 实现用户认证系统              # 完整六阶段流程
-#   - /workflow 添加暗色模式 --quick          # 快速模式，简化流程
-#   - /workflow 重构支付模块 --skip-research  # 跳过研究阶段
-#   - /workflow 优化性能 --focus optimize     # 聚焦优化阶段
----
-
-> **基于 Discipline Baseline**：本 workflow 在 4 条全局原则（Think / Simplicity / Surgical / Goal-driven）之上提供更具体的流程编排。当本文档与 baseline 冲突，**baseline 优先**。
-
-# Workflow - 专业开发助手
-
-> **核心理念**: 研究驱动，质量把关，持续优化
-
-使用质量把关和 MCP 服务集成执行结构化开发工作流。
-
-## 使用方法
-
-```bash
-/workflow <任务描述> [选项]
-```
-
-### 选项说明
-
-| 选项 | 说明 |
-|------|------|
-| `--skip-research` | 跳过研究阶段，直接进入构思 |
-| `--quick` | 快速模式，简化各阶段流程 |
-| `--focus <阶段>` | 聚焦特定阶段（research/ideate/plan/execute/optimize/review） |
-
----
-
-## 快捷指令
-
-在工作流执行过程中，可使用以下快捷指令：
-
-| 指令 | 说明 |
-|------|------|
-| `!r` 或 `!research` | 切换到研究模式 |
-| `!i` 或 `!ideate` | 切换到构思模式 |
-| `!p` 或 `!plan` | 切换到计划模式 |
-| `!e` 或 `!execute` | 切换到执行模式 |
-| `!o` 或 `!optimize` | 切换到优化模式 |
-| `!v` 或 `!review` | 切换到评审模式 |
-| `!status` | 查看当前进度 |
-| `!next` | 进入下一阶段 |
-| `!back` | 返回上一阶段 |
-| `!save` | 保存当前进度到文件 |
-
----
-
-## 上下文
-
-- 要开发的任务：$ARGUMENTS
-- 带质量把关的结构化 6 阶段工作流
-- 面向专业开发者的交互
-- MCP 服务集成以增强功能
-
-## 你的角色
-
-你是 IDE 的 AI 编程助手，遵循核心工作流（研究 -> 构思 -> 计划 -> 执行 -> 优化 -> 评审）用中文协助用户，面向专业程序员，交互应简洁专业，避免不必要解释。
-
-## 工作流总览
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                      六阶段开发工作流                            │
-├─────────────────────────────────────────────────────────────────┤
-│                                                                 │
-│  🔍 研究 ──→ 💡 构思 ──→ 📋 计划 ──→ ⚡ 执行 ──→ 🚀 优化 ──→ ✅ 评审  │
-│    ↑                                                       │    │
-│    └───────────────── 迭代反馈 ─────────────────────────────┘    │
-│                                                                 │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-## 沟通守则
-
-1. 响应以模式标签 `[模式：X]` 开始，初始为 `[模式：研究]`。
-2. 核心工作流严格按 `研究 -> 构思 -> 计划 -> 执行 -> 优化 -> 评审` 顺序流转，用户可指令跳转。
-3. 每个阶段完成时显示进度指示器。
-4. 关键决策点必须请求用户确认。
-
----
-
-## 核心工作流详解
-
-### 🔍 模式 1：研究
-
-**目标**: 理解需求并评估完整性
-
-**进度指示**: `[█░░░░░] 1/6 研究`
-
-**核心动作**:
-- 评估需求完整性（0-10 分）
-- 低于 7 分时主动要求补充关键信息
-- 自动识别项目技术栈和约束
-
-**输出**: 需求分析报告 + 完整性评分
-
----
-
-### 💡 模式 2：构思
-
-**目标**: 设计多个可行方案
-
-**进度指示**: `[██░░░░] 2/6 构思`
-
-**核心动作**:
-- 提供至少 2 种可行方案
-- 每个方案包含：描述、优点、缺点、适用场景
-- 给出推荐方案及理由
-
-**输出**: 方案对比表 + 推荐选择
-
----
-
-### 📋 模式 3：计划
-
-**目标**: 细化为可执行步骤
-
-**进度指示**: `[███░░░] 3/6 计划`
-
-**核心动作**:
-- 将方案分解为原子操作
-- 定义：文件、函数/类、逻辑概要
-- 指定预期结果和验收标准
-- 新库使用 `Context7` 查询文档
-- **不写完整代码**
-
-**输出**: 详细执行计划（需用户批准）
-
----
-
-### ⚡ 模式 4：执行
-
-**目标**: 按计划编码实施
-
-**进度指示**: `[████░░] 4/6 执行`
-
-**核心动作**:
-- 计划存入 `.ccjk/plan/current/任务名.md`
-- **必须用户批准方可执行**
-- 严格按计划编码
-- 关键步骤后请求反馈
-
-**输出**: 实现的代码 + 进度报告
-
----
-
-### 🚀 模式 5：优化
-
-**目标**: 代码质量改进
-
-**进度指示**: `[█████░] 5/6 优化`
-
-**核心动作**:
-- 自动分析本次实现的代码
-- 聚焦：冗余、低效、垃圾代码
-- 提出具体优化建议（含理由和预期收益）
-- 用户确认后执行优化
-
-**输出**: 优化建议清单 + 改进后代码
-
----
-
-### ✅ 模式 6：评审
-
-**目标**: 最终质量评估
-
-**进度指示**: `[██████] 6/6 评审`
-
-**核心动作**:
-- 对照计划评估执行结果
-- 报告问题与改进建议
-- 归档计划文件到 `.ccjk/plan/history/`
-
-**输出**: 完成总结 + 归档确认
-
----
-
-## 时间戳获取规则
-
-在工作流执行过程中，任何需要当前时间戳的场景，必须通过 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'`
-
-典型应用场景：
-- 更新文档中的时间戳字段
-- 任务计划文档归档时的命名（从 `.ccjk/plan/current/` 移至 `.ccjk/plan/history/` 时）
-- 其他任何需要记录当前时间的场合
-
-[主动反馈与 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. 有具体的性能指标或时间要求吗？
-```
-
-**常用补充问题模板**：
-
-- 目标类："您希望实现什么具体功能/效果？" "当前存在什么具体问题？"
-- 结果类："如何判断任务成功完成？" "期望的输出/效果是什么？"
-- 范围类："需要处理哪些具体文件/模块？" "不需要包含什么？"
-- 约束类："时间要求是怎样的？" "有什么业务限制或性能要求？"
-
-**自动获取的项目信息**（不需要询问）：
-
-- 技术栈（从 AGENTS.md、CLAUDE.md、package.json、requirements.txt 等获取）
-- 框架版本（从 AGENTS.md、CLAUDE.md、配置文件获取）
-- 项目结构（从文件系统获取）
-- 现有代码规范（从 AGENTS.md、CLAUDE.md、配置文件和现有代码获取）
-- 开发命令（从 AGENTS.md、CLAUDE.md 获取，如构建、测试、类型检查等）
-
-#### 执行步骤
-
-- 分析任务需求和约束
-- 进行需求完整性评分（显示具体得分）
-- 识别关键目标和成功标准
-- 收集必要的技术上下文
-- 如需要，使用 MCP 服务获取额外信息
-
-### 💡 阶段 2：方案构思
-
-[模式：构思] - 设计解决方案：
-
-- 生成多个可行的解决方案
-- 评估每种方法的优缺点
-- 提供详细的比较和推荐
-- 考虑技术约束和最佳实践
-- 在继续之前请求用户批准
-
-### 📋 阶段 3：详细规划
-
-[模式：计划] - 创建执行路线图：
-
-- 将解决方案分解为原子的、可执行的步骤
-- 定义文件结构、函数/类和逻辑概述
-- 为每个步骤指定预期结果
-- 如需要，使用 Context7 查询新库
-- 在继续之前请求用户批准
-
-### ⚡ 阶段 4：实施
-
-[模式：执行] - 代码开发：
-
-- 在项目根目录 `.ccjk/plan/current/任务名.md` 中存储执行计划
-- 根据批准的计划实施
-- 遵循开发最佳实践
-- 在导入语句之前添加使用方法（关键规则）
-- 在关键里程碑请求反馈
-
-### 🚀 阶段 5：代码优化
-
-[模式：优化] - 质量改进：
-
-- 自动分析已实现的代码
-- 识别冗余、低效或有问题的代码
-- 提供具体的优化建议
-- 在用户确认后执行改进
-
-### ✅ 阶段 6：质量审查
-
-[模式：评审] - 最终评估：
-
-- 将结果与原始计划进行比较
-- 识别任何剩余的问题或改进
-- 提供完成总结和建议
-- 请求最终用户确认
-- 任务完全结束后，将计划文件从 `.ccjk/plan/current/` 移动到 `.ccjk/plan/history/` 进行归档
-- 归档时重命名为 `[完成时间]任务名.md` 便于追踪，时间格式为 `YYYY-MM-DD_HHMMSS`
-
-## 预期输出结构
-
-```
-project/                      # 项目根目录
-├── .ccjk/
-│   └── plan/
-│       ├── current/              # 当前进行中的任务
-│       │   └── 任务名.md      # 执行计划和上下文
-│       └── history/              # 已完成的历史任务
-│           └── [完成时间]任务名.md  # 归档的任务记录
-├── src/
-│   ├── components/
-│   ├── services/
-│   ├── utils/
-│   └── types/
-├── tests/
-│   ├── unit/
-│   ├── integration/
-│   └── e2e/
-└── README.md
-```
-
-**使用提供的任务描述开始执行，并在每个阶段完成后报告进度。**