Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计异常

dex-plan德克斯计划

Agent Skill

dex-plan 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

9,229

周安装

377

GitHub Stars

297

下载量

2,956
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:dex-plan(德克斯计划)
来源仓库:https://github.com/dcramer/dex
仓库路径:skills/dex-plan
安装命令:
npx skills add https://github.com/dcramer/dex --skill dex-plan
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/dcramer/dex --skill dex-plan

简介

dex-plan 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词或任务场景快速定位候选结果时使用。

  • 适用于计划文档转换、规格说明拆解为可追踪任务,以及设计稿转实现步骤等需要结构化梳理的场景。
  • 通过 /dex-plan 命令将 Markdown 规划文档转为可跟踪的 dex 任务,支持直接调用 dex 或通过 npx @zeeg/dex 执行。
  • 安装前需确认权限范围和维护状态,注意是否会触发联网、命令执行或文件读写操作。
  • dex-plan 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Converting Markdown Documents to Tasks

Command Invocation

Use dex directly for all commands:

dex <command>

If dex is not on PATH, use npx @zeeg/dex <command> instead. Check once at the start:

command -v dex &>/dev/null && echo "use: dex" || echo "use: npx @zeeg/dex"

Use /dex-plan to convert any markdown planning document into a trackable dex task.

When to Use

  • After completing a plan in plan mode
  • Converting specification documents to trackable tasks
  • Converting design documents to implementation tasks
  • Creating tasks from roadmap or milestone documents
  • Tracking any markdown planning or design content

Supported Documents

Any markdown file containing planning or design content:

  • Plan files from plan mode (~/.claude/plans/*.md)
  • Specification documents (SPEC.md, REQUIREMENTS.md)
  • Design documents (DESIGN.md, ARCHITECTURE.md)
  • Roadmaps and milestone documents (ROADMAP.md)
  • Feature proposals and technical RFCs

Usage

/dex-plan <markdown-file-path>

Examples

From plan mode:

/dex-plan /home/user/.claude/plans/moonlit-brewing-lynx.md

From specification document:

/dex-plan @SPEC.md

From design document:

/dex-plan docs/AUTHENTICATION_DESIGN.md

From roadmap:

/dex-plan ROADMAP.md

What It Does

  1. Reads the markdown file
  2. Extracts title from first # heading (or uses filename as fallback)
  3. Strips "Plan: " prefix if present (case-insensitive)
  4. Creates dex task with full markdown content as context
  5. Analyzes plan structure for potential subtask breakdown
  6. Automatically creates subtasks when appropriate
  7. Returns task ID and breakdown summary

Examples

From plan mode file:

# Plan: Add JWT Authentication

## Summary

...

→ Task description: "Add JWT Authentication" (note: "Plan: " prefix stripped)

From specification document:

# User Authentication Specification

## Requirements

...

→ Task description: "User Authentication Specification"

Automatic Subtask Breakdown

After creating the main task, the skill analyzes the plan structure to determine if breaking it into subtasks adds value.

Hierarchy Levels

The skill supports up to 3 levels (maximum depth enforced by dex):

LevelNameExample
L0Epic"Add user authentication system"
L1Task"Implement JWT middleware"
L2Subtask"Add token verification function"

When Breakdown Happens

The skill creates subtasks when the plan has:

  • 3-7 clearly separable work items (numbered steps, distinct sections, implementation phases)
  • Implementation across multiple files or components (different modules, layers, or areas)
  • Clear sequential dependencies (step 1 before step 2)
  • Independent items that benefit from separate tracking

Epic-level breakdown (creates tasks, not subtasks) when:

  • Plan has major phases/sections with their own sub-items
  • 5+ distinct areas of work
  • Plan spans multiple systems or components
  • Work will require multiple sessions

When Breakdown Does NOT Happen

The skill keeps a single task when:

  • Plan describes one cohesive task (even if detailed with multiple paragraphs)
  • Only 1-2 steps present (not enough to warrant breakdown)
  • Work items are tightly coupled (can't be separated meaningfully)
  • Plan is exploratory or investigative (research, analysis, discovery)
  • Breaking down would create artificial boundaries that don't reflect natural work units

What Each Subtask Contains

When breakdown occurs, each subtask includes:

  • Description: Brief summary extracted from list item, heading, or section
  • Context: Relevant details from that section plus reference to parent task
  • Parent link: Automatically linked to main task via --parent

Example: With Breakdown

Input plan (auth-plan.md):

# Plan: Add Authentication System

## Implementation

1. Create database schema for users/tokens
2. Implement auth controller with endpoints
3. Add JWT middleware for route protection
4. Build frontend login/register forms
5. Add integration tests

Output:

Created task abc123 from plan

Analyzed plan structure: Found 5 distinct implementation steps
Created 5 subtasks:
- abc124: Create database schema for users/tokens
- abc125: Implement auth controller with endpoints
- abc126: Add JWT middleware for route protection
- abc127: Build frontend login/register forms
- abc128: Add integration tests

View full structure: dex show abc123

Example: Without Breakdown

Input plan (bugfix-plan.md):

# Plan: Fix Login Validation Bug

## Problem

Login fails when username has spaces

## Solution

Update validation regex in auth.ts line 42 to allow spaces

Output:

Created task xyz789 from plan

Plan describes a cohesive single task. No subtask breakdown needed.

View task: dex show xyz789

Example: Epic-Level Breakdown (Two-Level Hierarchy)

Input plan (full-auth-plan.md):

# Plan: Complete User Authentication System

## Phase 1: Backend Infrastructure

1. Create database schema for users and sessions
2. Implement password hashing with bcrypt
3. Add JWT token generation and validation

## Phase 2: API Endpoints

1. POST /auth/register - User registration
2. POST /auth/login - User login
3. POST /auth/logout - Session invalidation
4. POST /auth/reset-password - Password reset flow

## Phase 3: Frontend Integration

1. Login/register forms with validation
2. Protected route components
3. Session persistence with refresh tokens

Output:

Created epic abc123 from plan

Analyzed plan structure: Found 3 major phases with sub-items
Created as epic with 3 tasks:
- def456: Backend Infrastructure (3 subtasks)
- ghi789: API Endpoints (4 subtasks)
- jkl012: Frontend Integration (3 subtasks)

View full structure: dex list abc123

Options

/dex-plan <file> --priority 2              # Set priority
/dex-plan <file> --parent abc123           # Create as subtask

After Creating

Once created, you can:

  • View the task: dex show <task-id>
  • Create additional subtasks: dex create "..." --parent <task-id> --description "..."
  • Track progress through implementation
  • Complete the task: dex complete <task-id> --result "..."

Run dex show <task-id> to see the full task structure including any automatically created subtasks.

When NOT to Use

  • Document is incomplete or exploratory (just draft notes)
  • Content isn't actionable or ready for implementation
  • File hasn't been saved to disk yet
  • File doesn't contain meaningful planning/design content

Implementation Instructions for Skill

These instructions are for the skill agent executing /dex-plan. Follow this workflow exactly:

Step 1: Create Main Task

Execute the dex plan command with the provided markdown file:

dex plan <markdown-file> [options]

This creates the parent task and returns its ID. Capture this ID for subsequent steps.

Step 2: Read and Analyze the Plan

After creating the main task, read it back to analyze its structure:

dex show <task-id>

Examine the context field (which contains the full markdown) for breakdown potential.

Step 3: Apply Breakdown Decision Logic

Analyze the plan structure and decide: Should this be broken down into subtasks?

Look for these breakdown indicators:

  1. Numbered or bulleted implementation lists (3-7 items): ## Implementation 1. Create database schema → SUBTASK 2. Build API endpoints → SUBTASK 3. Add frontend components → SUBTASK
  2. Clear subsections under implementation/tasks/steps: ### 1. Backend Changes - Modify server.ts - Add authentication → SUBTASK: "Backend Changes" with this context ### 2. Frontend Updates - Update login form - Add error handling → SUBTASK: "Frontend Updates" with this context
  3. File-specific sections: ` ### src/auth.ts - Add JWT validation [Details about changes] → SUBTASK: "Add JWT validation to auth.ts" ### src/middleware.ts - Create auth middleware [Details about changes] → SUBTASK: "Create auth middleware" `
  4. Sequential phases: ## Implementation Sequence **Phase 1: Database Layer** [Details] → SUBTASK **Phase 2: API Layer** [Details] → SUBTASK **Phase 3: Frontend Layer** [Details] → SUBTASK

Do NOT break down when:

  • Only 1-2 steps/items present
  • Plan is a single cohesive fix or small change
  • Content is exploratory ("investigate", "research", "explore")
  • Work items are inseparable (tightly coupled implementation)
  • Breaking down creates artificial boundaries
  • Plan is very short (< 10 lines of meaningful content)

Step 4: Extract Subtasks (If Breaking Down)

For each identified subtask:

  1. Extract description: Use the list item text, heading, or section title

- Strip numbering and bullets: "1. Add auth" → "Add auth" - Keep it concise (1-10 words) - Use imperative form: "Add", "Create", "Update", "Fix"

  1. Extract context: Include relevant details from that section

- Copy the full section content for that subtask - Add reference: "This is part of [parent task description]" - Include code snippets, file paths, specific requirements

  1. Create the subtask: dex create "<subtask-description>" \ --parent <parent-task-id> \ --description "<extracted-context-with-parent-reference>"

Step 5: Report Results

If subtasks were created:

Created task <id> from plan

Analyzed plan structure: Found <N> distinct implementation steps
Created <N> subtasks:
- <subtask-id-1>: <description-1>
- <subtask-id-2>: <description-2>
- <subtask-id-3>: <description-3>
...

View full structure: dex show <parent-id>

If no breakdown occurred:

Created task <id> from plan

Plan describes a cohesive single task. No subtask breakdown needed.

View task: dex show <id>

Examples of Subtask Extraction

Example 1: Numbered list

## Implementation Steps

1. Create User model with email, password fields
2. Add POST /api/auth/register endpoint
3. Implement JWT token generation

Extracted subtasks:

dex create "Create User model with email, password fields" \
  --parent abc123 \
  --description "Create a User model with email and password fields. This is part of 'Add Authentication System'."

dex create "Add POST /api/auth/register endpoint" \
  --parent abc123 \
  --description "Add POST /api/auth/register endpoint to handle user registration. This is part of 'Add Authentication System'."

dex create "Implement JWT token generation" \
  --parent abc123 \
  --description "Implement JWT token generation for authenticated sessions. This is part of 'Add Authentication System'."

Example 2: Subsections with details

### Frontend: Login Form Component

Create a new React component at `src/components/LoginForm.tsx`:

- Email and password inputs
- Submit button with loading state
- Error message display
- Validation on submit

### Backend: Auth Routes

Add to `src/routes/auth.ts`:

- POST /login endpoint
- Password verification using bcrypt
- JWT token generation on success

Extracted subtasks:

dex create "Frontend: Login Form Component" \
  --parent abc123 \
  --description "Create a new React component at src/components/LoginForm.tsx with email/password inputs, submit button with loading state, error message display, and validation on submit. This is part of 'Add Authentication System'."

dex create "Backend: Auth Routes" \
  --parent abc123 \
  --description "Add to src/routes/auth.ts: POST /login endpoint, password verification using bcrypt, JWT token generation on success. This is part of 'Add Authentication System'."

Example 3: Should NOT break down

# Plan: Fix Typo in Error Message

## Problem

Error message says 'Sucessful' instead of 'Successful'

## Solution

Fix typo in src/messages.ts line 42

Decision: Single cohesive task, only one change. Do NOT create subtasks.

Key Principles

  1. Agent judgment is critical: Use intelligence to determine if breakdown adds value
  2. Err on the side of NOT breaking down: Only break down when it clearly helps
  3. Each subtask must be meaningful: Not just a single line change
  4. Context is essential: Each subtask should have enough context to be actionable independently
  5. Preserve plan semantics: Don't force a structure that doesn't match the plan's intent

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

31.4%
按下载量换算928

OpenCode

22.7%
按下载量换算671

Codex

19.86%
按下载量换算587

Cursor

11.62%
按下载量换算343

Gemini CLI

7.6%
按下载量换算225

Antigravity

3.18%
按下载量换算94

安全审计

Gen Agent Trust Hub

未通过

Socket

通过

Snyk

未通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。

来源信息

继续浏览同类 Skills