AgentSkillsCN

sift-backlog

对积压任务进行分类与整理，制定切实可行的行动计划。当您被要求审查积压任务、为任务排序优先级、根据积压事项制定计划，或把积压任务移至“待办”状态时，此方案将助您高效完成工作。它完整覆盖了积压任务的全流程：列出积压任务、将相关任务归类为不同计划、设定优先级与依赖关系、激活计划，并将任务状态从“积压”更改为“待办”。

SKILL.md
--- frontmatter
name: sift-backlog
description: Triage and organize backlog tasks into actionable plans. Use when asked to review the backlog, prioritize tasks, create plans from backlog items, or move tasks from backlog to open status. Handles the full workflow of listing backlog tasks, grouping related tasks into plans, setting priorities and dependencies, activating plans, and changing task status from backlog to open.

Sift Backlog

Triage backlog tasks: prioritize, group into plans, set dependencies, and activate.

Overview

  1. •List backlog tasks (el task backlog)
  2. •Clarify and enrich each task (titles, descriptions)
  3. •Identify groupings and create draft plans
  4. •Add tasks to plans and set dependencies
  5. •Activate plans
  6. •Set task status to open

Workflow

Step 1: List Backlog Tasks

bash
el task backlog

Step 2: Clarify and Enrich Tasks

Backlog tasks often have only a brief title with no description. Before organizing, ensure each task is well-defined.

For each task, evaluate:

  • •Is the title clear and actionable?
  • •Is there a description? Check with el task describe <task-id> --show
  • •Is the scope unambiguous?

If the title is unclear, update it:

bash
el update <task-id> --title "Clear, actionable title"

Add a description with context, scope, and acceptance criteria:

bash
el task describe <task-id> --content "Description with:
- What needs to be done
- Why it matters
- Acceptance criteria
- Any relevant context"

Use your best judgment to interpret tasks and make reasonable decisions about scope, grouping, and priority. You have context about the codebase, project patterns, and typical development practices—leverage this knowledge rather than deferring to the user for routine decisions.

Only ask the user for clarity when absolutely necessary:

  • •The task is fundamentally ambiguous (multiple mutually exclusive interpretations)
  • •Critical business logic or user-facing behavior that could go wrong in meaningful ways
  • •External dependencies or integrations you cannot verify

Do NOT ask about:

  • •Implementation details you can reasonably infer
  • •Priority or grouping decisions—use your judgment
  • •Standard development practices (testing, code style, etc.)
  • •Tasks where a reasonable interpretation exists

Step 3: Create Draft Plans

Group related tasks into plans using your best judgment. Plans start as drafts (tasks won't be dispatched until activated).

Grouping guidance:

  • •Group tasks that share a common theme, feature area, or goal
  • •Consider technical dependencies when grouping (tasks that touch the same files/modules)
  • •Separate unrelated work into distinct plans for parallel execution
  • •Don't over-group—if tasks are truly independent, separate plans enable better parallelism
  • •Don't under-group—related tasks benefit from shared context and coordinated execution
bash
el plan create --title "Plan Name"

Example:

bash
el plan create --title "Authentication Improvements"
# Output: Created plan el-abc123

Step 4: Add Tasks to Plans

bash
el plan add-task <plan-id> <task-id>

Example:

bash
el plan add-task el-abc123 el-task1
el plan add-task el-abc123 el-task2

Step 5: Set Dependencies Between Tasks

Use blocks dependency when one task must complete before another can start.

bash
el dependency add <blocked-id> <blocker-id> --type blocks

Semantics: The first ID is blocked BY the second ID. The blocker must complete first.

Example: Task 2 can't start until Task 1 completes:

bash
el dependency add el-task2 el-task1 --type blocks

Step 6: Update Priorities

Set priorities based on your assessment of impact, urgency, and dependencies. Use your judgment—you don't need user confirmation for routine prioritization.

Priority guidance:

  • •Critical (1): Blocking issues, security vulnerabilities, production bugs
  • •High (2): Important features with deadlines, significant user impact
  • •Medium (3): Standard feature work, most tasks default here
  • •Low (4): Nice-to-haves, minor improvements, tech debt
  • •Minimal (5): Backlog cleanup, documentation, exploratory work
bash
el update <task-id> --priority <1-5>
ValueLevel
1Critical
2High
3Medium
4Low
5Minimal

Step 7: Activate Plans

Once tasks are organized with dependencies set, activate plans to enable dispatch.

bash
el plan activate <plan-id>

Step 8: Set Task Status to Open

Move tasks from backlog to open so they become ready for work.

bash
el update <id> --status open

Other Actions

Close obsolete tasks:

bash
el task close <id> --reason "Won't do: <reason>"

Defer tasks:

bash
el task defer <id> --until <date>

View existing plans:

bash
el plan list

View tasks in a plan:

bash
el plan tasks <plan-id>

Tips

  • •Use your best judgment for grouping, prioritization, and task interpretation—don't defer routine decisions to the user
  • •Only escalate to the user when ambiguity is fundamental and could lead to wasted work (mutually exclusive interpretations, critical business decisions)
  • •Make reasonable inferences about implementation details, scope, and priority based on codebase context
  • •Create plans before setting dependencies to avoid dispatch race conditions
  • •Always activate plans after dependencies are set
  • •Focus on oldest backlog items first (sorted by creation date)
  • •Every task should have a clear title and description before activation
  • •When uncertain about a minor detail, make a reasonable choice and document it in the task description—workers can ask if needed