# 将 Markdown 文档转换为任务 ## 命令调用直接对所有命令使用 `dex`： dex <命令> 如果 `dex` 不在 PATH 上，请改用 `npx @zeeg/dex `。开始时检查一次：命令 -v dex &>/dev/null && echo "use: dex" || echo“使用：npx@zeeg/dex” 使用 /dex-plan 将任何 Markdown 计划文档转换为可跟踪的 dex 任务。 ## 何时使用 * 在计划模式下完成计划后 * 将规范文档转换为可跟踪的任务 * 将设计文档转化为实施任务 * 从路线图或里程碑文档创建任务 * 跟踪任何 Markdown 规划或设计内容 ## 支持的文档任何包含规划或设计内容的 Markdown 文件： * 计划模式下的计划文件 (`~/.claude/plans/*.md`) * 规范文件（`SPEC.md`、`REQUIREMENTS.md`） * 设计文档（`DESIGN.md`、`ARCHITECTURE.md`） * 路线图和里程碑文档 (`ROADMAP.md`) * 功能提案和技术 RFC ## 用法 /dex-plan ### 示例 **从计划模式：** /dex-plan /home/user/.claude/plans/moonlit-brewing-lynx.md **来自规范文件：** /dex-plan @SPEC.md **来自设计文件：** /dex-plan 文档/AUTHENTICATION_DESIGN.md **来自路线图：** /dex-plan ROADMAP.md ## 它的作用 1.读取markdown文件 2. 从第一个“#”标题中提取标题（或使用文件名作为后备） 3. 删除“Plan:”前缀（如果存在）（不区分大小写） 4. 创建 dex 任务，以完整的 markdown 内容作为上下文 5. 分析潜在子任务细分的计划结构 6. 适当时自动创建子任务 7.返回任务ID和细分摘要 ## 示例 **来自计划模式文件：** # 计划：添加 JWT 身份验证 ## 总结 ... → 任务描述：“添加 JWT 身份验证”（注意：删除“计划：”前缀） **来自规范文件：** # 用户认证规范 ## 要求 ... → 任务描述：“用户认证规范” ## 自动子任务分解创建主要任务后，该技能会分析计划结构，以确定将其分解为子任务是否会增加价值。 ### 层次结构级别该技能最多支持 3 个级别（最大深度由 dex 强制执行）：水平|名称 |示例 ---|---|--- L0 | **史诗** | “添加用户认证系统” L1 | **任务** | “实施 JWT 中间件” L2 | **子任务** | “添加token验证功能” ### 当发生故障时当计划具有以下特征时，技能会创建子任务： * 3-7 个可明确分开的工作项目（编号步骤、不同部分、实施阶段） * 跨多个文件或组件（不同模块、层或区域）的实现 * 清除顺序依赖性（步骤 1 在步骤 2 之前） * 受益于单独跟踪的独立项目 **史诗级分解**（创建任务，而不是子任务），当： * 计划有主要阶段/部分及其自己的子项目 * 5+个不同的工作领域 * 计划跨越多个系统或组件 * 工作需要多次会议 ### 当故障没有发生时该技能在以下情况下保留单个任务： * 计划描述了一项有凝聚力的任务（即使有多个段落详细说明） * 仅存在 1-2 个步骤（不足以保证故障） * 工作项紧密耦合（无法进行有意义的分离） * 计划是探索性或调查性的（研究、分析、发现） * 分解会产生不反映自然工作单位的人为界限 ### 每个子任务包含什么当发生故障时，每个子任务包括： * 描述：从列表项、标题或部分中提取的简短摘要 * 上下文：该部分的相关详细信息以及对父任务的引用 * 父链接：通过 `--parent` 自动链接到主任务 ### 示例：有故障 **输入计划** (`auth-plan.md`): # 计划：添加身份验证系统 ## 实施 1. 为用户/令牌创建数据库模式 2. 使用端点实现身份验证控制器 3.添加JWT中间件进行路由保护 4. 构建前端登录/注册表单 5.添加集成测试 **输出**：根据计划创建任务 abc123 分析计划结构：发现 5 个不同的实施步骤创建了 5 个子任务： - abc124：为用户/令牌创建数据库模式 - abc125：使用端点实现身份验证控制器 - abc126：添加 JWT 中间件以进行路由保护 - abc127：构建前端登录/注册表单 - abc128：添加集成测试查看完整结构：dex show abc123 ### 示例：没有故障 **输入计划** (`bugfix-plan.md`): # 计划：修复登录验证错误 ## 问题用户名有空格时登录失败 ## 解决方案更新 auth.ts 第 42 行中的验证正则表达式以允许空格 **输出**：根据计划创建任务 xyz789 计划描述了一个有凝聚力的单一任务。无需细分子任务。查看任务：dex show xyz789 ### 示例：史诗级分解（两级层次结构） **输入计划** (`full-auth-plan.md`): # 计划：完整的用户认证系统 ## 第一阶段：后端基础设施 1. 为用户和会话创建数据库架构 2.使用bcrypt实现密码哈希 3.添加JWT令牌生成和验证 ## 第 2 阶段：API 端点 1. POST /auth/register——用户注册 2. POST /auth/login - 用户登录 3. POST /auth/logout - 会话失效 4. POST /auth/reset-password - 密码重置流程 ## 第三阶段：前端集成 1. 登录/注册表格并进行验证 2. 受保护的路由组件 3. 使用刷新令牌保持会话持久性 **输出**：根据计划创建了史诗般的 abc123 分析计划结构：发现 3 个主要阶段和子项目创建为史诗，有 3 个任务： - def456：后端基础设施（3 个子任务） - ghi789：API 端点（4 个子任务） - jkl012：前端集成（3 个子任务）查看完整结构：dex list abc123 ## 选项 /dex-plan <文件> --priority 2 # 设置优先级 /dex-plan --parent abc123 # 创建为子任务 ## 创建后创建后，您可以： * 查看任务：`dex show ` * 创建额外的子任务： `dex create "..." --parent --description "..."` * 跟踪实施进度 * 完成任务：`dex Complete --result "..."` 运行“dex show ”以查看完整的任务结构，包括任何自动创建的子任务。 ## 何时不使用 * 文档不完整或探索性（只是草稿注释） * 内容不可行或无法实施 * 文件尚未保存到磁盘 * 文件不包含有意义的规划/设计内容 ** ** ## 技能实施说明 **这些说明适用于技能代理执行`/dex-plan`。** 严格遵循此工作流程： ### 第 1 步：创建主要任务使用提供的 markdown 文件执行“dex plan”命令： dex plan [选项] 这将创建父任务并返回其 ID。捕获此 ID 以用于后续步骤。 ### 第 2 步：阅读并分析计划创建主任务后，读回它来分析它的结构： dex 显示 <任务 ID> 检查上下文字段（包含完整的降价）是否有潜在的故障。 ### 第 3 步：应用细分决策逻辑 **分析计划结构并决定**：是否应该将其分解为子任务？ #### 寻找这些故障指标： 1. 编号或项目符号实施列表（3-7 项）： ## 实施 1.创建数据库模式→SUBTASK 2. 构建API端点→SUBTASK 3.添加前端组件→SUBTASK 2. 明确实施/任务/步骤下的小节： ### 1. 后端更改 - 修改server.ts - 添加身份验证 → 子任务：在此上下文中“后端更改” ### 2. 前端更新 - 更新登录表单 - 添加错误处理 → 子任务：“前端更新”与此上下文 3. 文件特定部分： ### `src/auth.ts` - 添加 JWT 验证【变更详情】 → 子任务：“将 JWT 验证添加到 auth.ts” ### `src/middleware.ts` - 创建身份验证中间件【变更详情】 → 子任务：“创建身份验证中间件” 4. 连续阶段： ## 执行顺序 **阶段 1：数据库层** [详细信息] → 子任务 **阶段 2：API 层** [详细信息] → 子任务 **阶段 3：前端层** [详细信息] → 子任务 #### 在以下情况下不要崩溃： * 仅存在 1-2 个步骤/项目 * 计划是一个单一的有凝聚力的修复或小的改变 * 内容是探索性的（“调查”、“研究”、“探索”） * 工作项是不可分割的（紧密耦合的实现） * 打破界限会产生人为的界限 * 计划很短（<10行有意义的内容） ### 步骤 4：提取子任务（如果发生故障）对于每个已识别的子任务： 1. 提取描述：使用列表项文本、标题或部分标题 * 删除编号和项目符号：“1. 添加身份验证”→“添加身份验证” * 保持简洁（1-10个字） * 使用命令形式：“添加”、“创建”、“更新”、“修复” 2. 提取上下文：包括该部分的相关详细信息 * 复制该子任务的完整部分内容 * 添加参考：“这是[父任务描述]的一部分” * 包括代码片段、文件路径、具体要求 3. 创建子任务： dex create "<子任务描述>" \ --parent <父任务 ID> \ --description "<带有父引用的提取上下文>" ### 第 5 步：报告结果如果创建了子任务：已根据计划创建任务分析计划结构：发现个不同的实施步骤创建了个子任务： - <子任务-id-1>：<描述-1> - <子任务 ID-2>: <描述-2> - <子任务 ID-3>: <描述-3> ... 查看完整结构： dex show 如果没有发生故障：已根据计划创建任务计划描述了一个有凝聚力的单一任务。无需细分子任务。查看任务：dex show ### 子任务提取示例示例 1：编号列表 ## 实施步骤 1. 创建包含电子邮件、密码字段的用户模型 2. 添加 POST /api/auth/register 端点 3. 实现JWT令牌生成提取的子任务： dex create“使用电子邮件、密码字段创建用户模型”\ --父 abc123 \ --description “使用电子邮件和密码字段创建用户模型。这是‘添加身份验证系统’的一部分。” dex 创建“添加 POST /api/auth/register 端点”\ --父 abc123 \ --description “添加 POST /api/auth/register 端点来处理用户注册。这是‘添加身份验证系统’的一部分。” dex create“实现 JWT 令牌生成”\ --父 abc123 \ --description “为经过身份验证的会话实现 JWT 令牌生成。这是‘添加身份验证系统’的一部分。” 示例 2：包含详细信息的小节 ### 前端：登录表单组件在 `src/components/LoginForm.tsx` 创建一个新的 React 组件： - 电子邮件和密码输入 - 带有加载状态的提交按钮 - 错误信息显示 - 提交时验证 ### 后端：身份验证路由添加到`src/routes/auth.ts`： - POST /登录端点 - 使用 bcrypt 进行密码验证 - 成功生成 JWT 代币提取的子任务： dex 创建“前端：登录表单组件”\ --父 abc123 \ --description “在 src/components/LoginForm.tsx 中创建一个新的 React 组件，其中包含电子邮件/密码输入、带有加载状态的提交按钮、错误消息显示以及提交验证。这是“添加身份验证系统”的一部分。” dex 创建“后端：身份验证路由”\ --父 abc123 \ --description “添加到 src/routes/auth.ts：POST /login 端点，使用 bcrypt 进行密码验证，成功时生成 JWT 令牌。这是“添加身份验证系统”的一部分。” 示例 3：不应崩溃 # 计划：修复错误消息中的拼写错误 ## 问题错误消息显示“成功”而不是“成功” ## 解决方案修复 src/messages.ts 第 42 行中的拼写错误决策：单一的有凝聚力的任务，只有一个改变。不要创建子任务。 ### 关键原则 1. 代理判断至关重要：利用情报来确定故障是否会增加价值 2.宁可不崩溃：只在明显有帮助时才进行崩溃 3. 每个子任务必须有意义：不仅仅是单行更改 4. 上下文至关重要：每个子任务都应该有足够的上下文才能独立执行 5. 保留计划语义：不要强制使用与计划意图不相符的结构

德克斯计划

包含技能