020-tasks-workflow

A task-tracking system that spreads project work across multiple files in a tasks/ folder. A separate index records the task ranges and overall counts.

In plain words
What is it for?
Use it to maintain task files, update the central task index, and track task IDs and statuses. It is intended for projects whose work is divided across several task documents.
Why use it?
It keeps large task lists organized instead of putting every task in one file. The summaries make it easier to see what is pending or complete across the project.

Cursor rule for Cursor

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/aiurda/devcontext/020-tasks-workflow
Clone the repo
git clone --depth 1 https://github.com/aiurda/devcontext

Made for: Cursor.

Per session 2,230 This file is loaded in full into every session.
When invoked 2,230 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.02230 $0.02230
Opus 5 $0.01115 $0.01115
Sonnet 5 $0.00446 $0.00446
Haiku 4.5 $0.00223 $0.00223

Measured 2d ago against content hash 1b8ba1a4d25d, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

020-tasks-workflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.cursor/rules/020-tasks-workflow.mdc · 186 lines

How it starts

The opening of the file, as written. The whole thing — 186 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Task Workflow System (Multi-File in tasks/ Directory)

  • Purpose: Standardize task implementation with proper tracking and status updates across a distributed task list.
  • Implementation: Tasks are distributed across tasks/tasks-N.md files, indexed by tasks/tasks-index.md.

Overall Task Management Structure

  • Index File (tasks/tasks-index.md):

    • Contains the Overall Project Task Summary (Total Tasks, Pending, Complete for the entire project).

    • Contains the Task File Index, mapping Task ID ranges to specific tasks/tasks-N.md files.

      ## Overall Project Task Summary
      
      - **Total Tasks**: {Total for project}
      - **Pending**: {Pending for project}
      - **Complete**: {Complete for project}
      
      ## Task File Index
      
      - `tasks/tasks-1.md`: Contains Tasks {start_id_1} - {end_id_1} ({task_count_1} tasks)
      - `tasks/tasks-2.md`: Contains Tasks {start_id_2} - {end_id_2} ({task_count_2} tasks)
      - ...
      
  • Task Files (tasks/tasks-N.md):

    • Each file starts with its own local summary:

      ## Summary (tasks-N.md) // Clarify which task file this summary is for
      
      - **Tasks in this file**: {Count for this file}
      - **Task IDs**: {start_id_N} - {end_id_N} // e.g., 001 - 030
      
    • Followed by the ## Tasks section containing individual tasks.

  • Task Structure (within tasks/tasks-N.md)

    • Tasks are defined with:

      ### Task ID: {ID}
      
      - **Title**: Example title
      - **File**: example/file/path (relative to project root, excluding project root dir)
      - **Complete**: [ ]
      
      #### Prompt:
      
      ```markdown
      DETAILED PROMPT INCLUDING TARGET FILE PATH AND CONTEXT
      ```
      

Task Management Workflow

1. Locating a Task

  • When user requests "next task":
    1. Open and consult tasks/tasks-index.md to understand the overall project status and identify the sequence of task files.
    2. Iterate through tasks/tasks-1.md, tasks/tasks-2.md, etc., in numerical order as listed in the index.
    3. Within each tasks/tasks-N.md file, find the first task where Complete: [ ]. This is the next task.
    4. Note the tasks/tasks-N.md file this task resides in.
  • When user specifies a Task ID (e.g., "Task 042"):
    1. Open and consult tasks/tasks-index.md.
    2. Read the "Task File Index" to determine which tasks/tasks-N.md file contains that Task ID.
    3. Open the identified tasks/tasks-N.md file (e.g., if Task 042 is in tasks-2.md, open tasks/tasks-2.md).
    4. Locate the task with the specified ### Task ID: {ID}.

Read the full file on GitHub · 186 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 186 lines · 2,230 tokens per session scan A 1b8ba1a4d25d

Subscribe to this mod's changes

020-tasks-workflow is a cursor rule published in the GitHub repository aiurda/devcontext (47 stars, last pushed 1y ago), licensed MIT. It adds 2,230 tokens to every session, about $0.0112 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.