ccjk 14.2.2 → 15.0.0

package/templates/common/workflow/essential/zh-CN/feat.md

@@ -1,315 +0,0 @@
----
-description: '功能开发命令 - 智能规划、设计、实施一体化工作流'
-argument-hint: <功能描述> [--plan] [--design] [--execute] [--quick]
-# examples:
-#   - /feat 用户登录功能                    # 完整流程：规划 → 设计 → 实施
-#   - /feat 添加暗色模式 --plan             # 仅生成规划文档
-#   - /feat 购物车功能 --design             # 跳过规划，直接设计
-#   - /feat 修复表单验证 --quick            # 快速模式，简化流程
-#   - /feat --execute                       # 继续执行已有规划
----
-
-# 功能开发命令
-
-> **核心理念**: 规划先行，设计驱动，质量优先
-
-## 使用方法
-
-```bash
-/feat <功能描述> [选项]
-```
-
-### 选项说明
-
-| 选项 | 说明 |
-|------|------|
-| `--plan` | 仅生成规划文档，不执行 |
-| `--design` | 跳过规划，直接进入 UI 设计 |
-| `--execute` | 继续执行已有规划 |
-| `--quick` | 快速模式，简化流程 |
-
----
-
-## 功能描述
-
-$ARGUMENTS
-
----
-
-## 智能工作流程
-
-### 阶段 0：输入分析
-
-每次收到输入时，首先进行**类型识别**并明确告知：
-
-```
-📋 操作类型识别：[需求规划 | 讨论迭代 | 执行实施]
-```
-
-**识别标准**：
-
-| 类型 | 触发条件 | 示例输入 |
-|------|----------|----------|
-| 🆕 需求规划 | 新功能需求、项目构想 | "添加用户认证"、"实现购物车" |
-| 🔄 讨论迭代 | 修改、完善已有规划 | "调整一下方案"、"继续讨论" |
-| ⚡ 执行实施 | 确认开始实施 | "开始执行"、"按计划实施" |
-
----
-
-### 阶段 1：需求规划 🆕
-
-**触发**: 识别为新功能需求
-
-**执行流程**:
-
-0. **环境预检查**
-   - 验证 `.ccjk/plan/current/` 目录是否存在
-   - 检查目录写入权限
-   - 如果目录不存在，自动创建
-   - 如果权限不足，提示用户修复并提供具体命令
-
-1. **启动规划 Agent** - 使用 Task tool 调用规划专家：
-   ```
-   Task tool 参数:
-   - subagent_type: "general-purpose"
-   - description: "功能规划分析"
-   - prompt: 读取 ~/.claude/agents/planner.md 的内容作为 system prompt，
-             然后分析用户的功能需求: $ARGUMENTS
-   ```
-
-2. **生成规划文档** 存储至 `.ccjk/plan/current/`
-3. **文档命名**: `功能名称.md`
-
-**规划文档结构**:
-
-```markdown
-# 功能规划：[功能名称]
-
-## 📋 概述
-- 功能目标
-- 预期价值
-- 影响范围
-
-## 🎯 功能分解
-- [ ] 子功能 1
-- [ ] 子功能 2
-- [ ] 子功能 3
-
-## 📐 技术方案
-- 架构设计
-- 数据模型
-- API 设计
-
-## ✅ 验收标准
-- 功能验收点
-- 性能指标
-- 测试覆盖
-
-## ⏱️ 实施计划
-- 阶段划分
-- 时间估算
-- 依赖关系
-```
-
----
-
-### 阶段 2：讨论迭代 🔄
-
-**触发**: 用户要求修改或完善规划
-
-**执行流程**:
-
-1. **检索上次规划** 从 `.ccjk/plan/current/` 读取
-2. **分析用户反馈** 识别修改点
-3. **启动规划 Agent** - 使用 Task tool 重新规划：
-   ```
-   Task tool 参数:
-   - subagent_type: "general-purpose"
-   - description: "规划迭代更新"
-   - prompt: 读取 ~/.claude/agents/planner.md 的内容作为 system prompt，
-             结合已有规划文档和用户反馈进行迭代优化
-   ```
-4. **版本管理**:
-   - 原文件: `功能名称.md`
-   - 迭代版本: `功能名称-v2.md`, `功能名称-v3.md`
-
-**迭代记录**:
-
-```markdown
-## 📝 迭代历史
-
-### v2 - [时间戳]
-- 修改点 1
-- 修改点 2
-
-### v1 - [时间戳]
-- 初始版本
-```
-
----
-
-### 阶段 3：执行实施 ⚡
-
-**触发**: 用户确认规划完成
-
-**执行流程**:
-
-```
-┌─────────────────────────────────────────────────────────┐
-│  📋 读取规划文档                                         │
-│       ↓                                                 │
-│  🔍 识别子任务类型                                       │
-│       ↓                                                 │
-│  ┌─────────────┬─────────────┬─────────────┐           │
-│  │ 前端任务    │ 后端任务    │ 其他任务    │           │
-│  │     ↓       │     ↓       │     ↓       │           │
-│  │ UI 设计检查 │ 直接实施    │ 直接实施    │           │
-│  │     ↓       │             │             │           │
-│  │ 无设计？    │             │             │           │
-│  │     ↓       │             │             │           │
-│  │ UI-UX Agent │             │             │           │
-│  └─────────────┴─────────────┴─────────────┘           │
-│       ↓                                                 │
-│  ✅ 完成并更新状态                                       │
-└─────────────────────────────────────────────────────────┘
-```
-
-**前端任务特殊处理**:
-
-1. **检查 UI 设计** - 是否存在设计稿
-2. **无设计时** - 使用 Task tool 调用 UI-UX-Designer Agent：
-   ```
-   Task tool 参数:
-   - subagent_type: "general-purpose"
-   - description: "UI/UX 设计"
-   - prompt: 读取 ~/.claude/agents/ui-ux-designer.md 的内容作为 system prompt，
-             为当前前端任务提供 UI/UX 设计规范
-   ```
-3. **设计完成后** - 再进行开发实施
-
----
-
-## 快捷指令
-
-在功能开发过程中，可使用以下快捷指令：
-
-| 指令 | 说明 |
-|------|------|
-| `!plan` | 查看当前规划文档 |
-| `!status` | 查看任务完成状态 |
-| `!next` | 执行下一个子任务 |
-| `!pause` | 暂停执行，保存进度 |
-| `!design` | 调用 UI-UX-Designer Agent (使用 Task tool) |
-| `!test` | 为当前功能生成测试 |
-
----
-
-## 状态管理
-
-### 任务状态追踪
-
-```markdown
-## 📊 执行状态
-
-| 子任务 | 状态 | 进度 |
-|--------|------|------|
-| 数据模型设计 | ✅ 完成 | 100% |
-| API 接口开发 | 🔄 进行中 | 60% |
-| 前端页面实现 | ⏳ 待开始 | 0% |
-| 单元测试编写 | ⏳ 待开始 | 0% |
-```
-
-### 进度可视化
-
-```
-整体进度: [████████░░░░░░░░] 50%
-
-✅ 已完成: 2/4 子任务
-🔄 进行中: 1/4 子任务
-⏳ 待开始: 1/4 子任务
-```
-
----
-
-## 质量保证
-
-### 强制检查点
-
-1. **规划阶段** - 必须包含验收标准
-2. **设计阶段** - 前端任务必须有 UI 设计
-3. **实施阶段** - 每个子任务完成后更新状态
-4. **完成阶段** - 对照验收标准验证
-
-### 代码质量要求
-
-- 遵循项目现有代码风格
-- 添加必要的类型定义
-- 编写单元测试（覆盖率 > 80%）
-- 更新相关文档
-
----
-
-## 输出规范
-
-### 每次响应格式
-
-```
-📋 操作类型：[类型]
-📍 当前阶段：[阶段]
-📊 整体进度：[进度条]
-
----
-
-[具体内容]
-
----
-
-💡 下一步：[建议操作]
-```
-
----
-
-## Plan Mode 上下文同步 🧠
-
-> **重要**: 当规划阶段完成时，自动触发上下文同步
-
-### 规划完成时的操作
-
-当用户确认规划完成（进入执行阶段）时，**必须执行以下步骤**：
-
-1. **保存 Plan 文档**
-   - 将完整规划保存到 `.ccjk/plan/current/[功能名称].md`
-   - 同时备份到全局目录 `~/.ccjk/plans/`
-
-2. **提取关键信息**
-   - 任务列表（用于后续追踪）
-   - 关键决策点（用于上下文恢复）
-   - 涉及文件列表（用于快速定位）
-
-3. **上下文清理建议**
-   - 如果对话已超过 50 条消息，建议用户执行 `/compact`
-   - 提示：「规划已保存，建议清理上下文以获得更好的执行体验」
-
-### 上下文恢复
-
-当用户使用 `--execute` 或 `!plan` 时：
-- 自动从 `.ccjk/plan/current/` 加载最新规划
-- 恢复任务状态和进度
-- 无需用户重复描述需求
-
-### 智能提醒
-
-```
-💡 上下文管理提示：
-- 规划阶段完成后，Plan 文档已自动保存
-- 可随时使用 /compact 清理上下文
-- 使用 /feat --execute 可恢复执行
-```
-
----
-
-## 开始执行
-
-**功能需求**: $ARGUMENTS
-
-正在分析输入类型并启动相应工作流...

package/templates/common/workflow/essential/zh-CN/goal.md

@@ -1,146 +0,0 @@
----
-description: '持久化目标工作流：仓库内目标计划、原生 /goal 协同、可恢复执行'
-argument-hint: <目标描述> [--create] [--run] [--resume] [--status]
----
-
-# 持久化目标工作流
-
-当用户希望一个任务不只存在于当前对话里，而是可以被恢复、检查和继续执行时，使用这个命令。
-真实状态必须写入仓库，而不是只依赖聊天记忆。
-
-## 命令上下文
-
-- 工作流 bundle：`essentialTools`
-- 安装命令文件：`goal.md`
-- Clavue 命令：`/ccjk:goal <目标描述>`
-- Claude Code 命令：`/ccjk:goal <目标描述>`
-- Codex 命令：`/prompts:goal <目标描述>`
-- 原生目标能力：运行时支持时，优先配合 `/goal`
-
-## 用户请求
-
-$ARGUMENTS
-
-## 目标产物
-
-创建或更新一个目标计划目录：
-
-```text
-.agent/goals/<goal-id>/
-  brief.md
-  goals.json
-  ledger.jsonl
-.agent/goals/active
-```
-
-`<goal-id>` 使用简短稳定的名称，例如 `2026-05-05-clavue-goals-runtime` 或
-`feature-durable-goals`。如果无法确认当前日期，就使用任务语义生成 slug，并在记录里说明日期不可用。
-
-## 产物契约
-
-`brief.md` 包含：
-- 用户意图的一段话总结
-- 成功标准
-- 约束与非目标
-- 推荐执行策略
-
-`goals.json` 包含：
-
-```json
-{
-  "version": 1,
-  "id": "goal-id",
-  "status": "ready",
-  "runtime": "clavue|codex|claude-code|unknown",
-  "goals": [
-    {
-      "id": "G1",
-      "title": "明确的目标标题",
-      "status": "ready",
-      "depends_on": [],
-      "acceptance": ["可观察的验收标准"],
-      "evidence": []
-    }
-  ]
-}
-```
-
-`ledger.jsonl` 每行记录一个事件：
-
-```json
-{"ts":"ISO-8601","event":"created","goal_id":"G1","notes":"Plan created"}
-```
-
-## 运行逻辑
-
-1. 识别意图。
-   - `--create`：创建或刷新目标产物，然后停止。
-   - `--run`：按顺序执行 ready 状态的目标。
-   - `--resume`：读取 `.agent/goals/active`，继续下一个 ready 或 running 目标。
-   - `--status`：只汇总当前目标状态，不修改文件。
-   - 无参数：如果没有 active 目标，先创建计划。
-
-2. 实施前先创建持久计划。
-   - 每个目标必须足够小，可以单独完成和验证。
-   - 只有真实依赖才写入 `depends_on`。
-   - 验收标准必须能通过文件、测试、命令或用户可见行为检查。
-
-3. 与原生 `/goal` 协同。
-   - Clavue：优先使用当前运行时的原生 `/goal` 能力。
-   - Codex：当 `[features].goals = true` 已启用时，优先使用原生 `/goal`。
-   - 如果助手侧无法直接设置原生目标，就继续使用产物计划，并告诉用户应手动设置的 `/goal` 文本。
-
-4. 一次只执行一个目标。
-   - 编辑前把目标标记为 `running`。
-   - 做最小但有价值的一步。
-   - 用最窄的相关命令或检查验证。
-   - 只有存在 evidence 时，才把目标标记为 `completed`。
-   - 向 `ledger.jsonl` 追加 `checkpoint` 或 `completed` 事件。
-
-5. 遇到阻塞就停止。
-   - 如果需求不清楚、不安全或缺少访问权限，把目标标记为 `blocked`。
-   - 在 `ledger.jsonl` 记录阻塞点和下一步问题/动作。
-   - 不要静默跳过 blocked 目标。
-
-## 输出格式
-
-创建或查看状态时：
-
-```markdown
-# Goal Plan
-- ID:
-- Status:
-- Active goal:
-
-# Goals
-1. G1 - title - status
-2. G2 - title - status
-
-# Next Action
-- 继续执行所需的命令或动作
-```
-
-执行或恢复时：
-
-```markdown
-# Active Goal
-- ID:
-- Acceptance:
-
-# Work Completed
-- 已修改的文件或行为
-
-# Evidence
-- 测试、检查或人工核验结果
-
-# Next Goal
-- 下一个 ready 目标，或说明已完成
-```
-
-## 约束
-
-- 不要把聊天记忆当作唯一状态。
-- 不要创建类似“完成整个项目”的巨大模糊目标。
-- 没有 evidence 时不要标记完成。
-- 不要覆盖已有目标产物里的有效历史。
-- Clavue、Codex、Claude Code 必须共享同一套产物契约。

package/templates/common/workflow/essential/zh-CN/init-project.md

@@ -1,53 +0,0 @@
----
-description: 初始化项目 AI 上下文，生成/更新根级与模块级 CLAUDE.md 索引
-allowed-tools: Read(**), Write(CLAUDE.md, **/CLAUDE.md)
-argument-hint: <项目摘要或名称>
----
-
-## 用法
-
-`/init-project <项目摘要或名称>`
-
-## 目标
-
-以"根级简明 + 模块级详尽"的混合策略初始化项目 AI 上下文：
-
-- 在仓库根生成/更新 `CLAUDE.md`（高层愿景、架构总览、模块索引、全局规范）。
-- 在识别的各模块目录生成/更新本地 `CLAUDE.md`（接口、依赖、入口、测试、关键文件等）。
-- ✨ **为了提升可读性，会在根 `CLAUDE.md` 中自动生成 Mermaid 结构图，并为每个模块 `CLAUDE.md` 添加导航面包屑**。
-
-## 编排说明
-
-**步骤 1**：调用 `get-current-datetime` 子智能体获取当前时间戳。
-
-**步骤 2**：调用一次 `init-architect` 子智能体，输入：
-
-- `project_summary`: $ARGUMENTS
-- `current_timestamp`: (来自步骤1的时间戳)
-
-## 执行策略（由 Agent 自适应决定，不需要用户传参）
-
-- **阶段 A：全仓清点（轻量）**
-  快速统计文件与目录，识别模块根（package.json、pyproject.toml、go.mod、apps/_、packages/_、services/\* 等）。
-- **阶段 B：模块优先扫描（中等）**
-  对每个模块做"入口/接口/依赖/测试/数据模型/质量工具"的定点读取与样本抽取。
-- **阶段 C：深度补捞（按需）**
-  若仓库较小或模块规模较小，则扩大读取面；若较大，则对高风险/高价值路径分批追加扫描。
-- **覆盖率度量与可续跑**
-  输出"已扫描文件数 / 估算总文件数、已覆盖模块占比、被忽略/跳过原因"，并列出"建议下一步深挖的子路径"。重复运行 `/init-project` 时按上次索引做**增量更新**与**断点续扫**。
-
-## 安全与边界
-
-- 只读/写文档与索引，不改源代码。
-- 默认忽略常见生成物与二进制大文件。
-- 结果在主对话打印"摘要"，全文写入仓库。
-
-## 输出要求
-
-- 在主对话中打印"初始化结果摘要"，包含：
-  - 根级 `CLAUDE.md` 是否创建/更新、主要栏目概览。
-  - 识别的模块数量及其路径列表。
-  - 每个模块 `CLAUDE.md` 的生成/更新情况。
-  - ✨ **明确提及"已生成 Mermaid 结构图"和"已为 N 个模块添加导航面包屑"**。
-  - 覆盖率与主要缺口。
-  - 若未读全：说明"为何到此为止"，并列出**推荐的下一步**（例如"建议优先补扫：packages/auth/src/controllers"）。

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

@@ -1,102 +0,0 @@
----
-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` 命令共享相似的参数设计与文档结构。