SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdevdocs-dev-tasks

devdocs-dev-tasks

Coding & development

View repository

Updated 10-15 08:12

About this skill

Development Tasks

Break the system design into executable, traceable development tasks.

Language Rules

  • Support questions in Chinese and English
  • Always reply in Chinese
  • Generate documents in Chinese

Trigger Conditions

  • The user has completed the system design and test cases
  • The user requests splitting development tasks
  • The user needs iteration/Sprint planning
  • From /devdocs-feature、/devdocs-bugfix、/devdocs-insights incremental requirements

Prerequisites

  • Requirements document:docs/devdocs/01-requirements.md
  • System design document:docs/devdocs/02-system-design.md
  • Test case document:docs/devdocs/03-test-cases.md
  • If it does not exist, it is recommended to run the prerequisite stage first

Run Mode

/devdocs-dev-tasks              → 标准模式（逐步确认）
/devdocs-dev-tasks --fast       → 跳过逐步确认，直接生成，仅最终确认

--fast mode

  • Use reasonable defaults (do not ask about task granularity preferences, etc.)
  • Keep only 1 confirmation before the final write
  • Default behavior remains unchanged,--fast is opt-in

Workflow

  1. Read Documents: Load all prerequisite-stage documents
  2. Identify Components: Map system modules to tasks
  3. TDD Layering: Classify the layer of each task (🔴🟡🟢⚪), according toTask Layeringrules marked
  4. Define Dependencies: Establish the task execution order
  5. Assess Scope: Ensure task granularity is appropriate
  6. Generate Task Documents: Output grouped by layer, and each task must include the corresponding TDD execution steps:
    • 🔴 Core logic: red→green→refactor three steps (must include the TDD 执行步骤 block)
    • 🟡 Interface layer: red→green two steps (TDD 执行步骤（推荐） block)
    • 🟢 UI layer: implement→verify→add tests (ordinary execution steps)
    • ⚪ Infrastructure: implement→integration test verification (ordinary execution steps)
    • Refer to templates/task-template.md examples for each layer
  7. User Confirmation: Obtain approval
  8. Load into TodoWrite: Optional, add tasks to the tracking list

Context Management

Batching Principle

Design tasks in batches by feature point (F-XXX), completing the full task breakdown of one feature point in each batch.

Quality Anchor

  • Use the task list of the first feature point as thequality anchor
  • Before starting each new feature point, review the level of detail of the first batch of tasks (completeness of TAR fields, specificity of file paths, clarity of dependencies)
  • If the level of detail of the current batch is clearly lower than the anchor, supplement it immediately

Consistency Self-Check

After the task design for each feature point is completed, compare and check:

  • Whether the three TAR fields are consistent with the first batch (no missing items)
  • Whether file paths are specific to file names (not vague descriptions such as "related files")
  • Whether task granularity is consistent (no task exceeding 4 hours)

Output Files

Main File：docs/devdocs/04-dev-tasks.md

Document Splitting Rules

When the following conditions are met, the document should be split:

  • More than 20 tasks
  • The document exceeds 300 lines
  • Involves multiple independent modules

Splitting approach：

docs/devdocs/
├── 04-dev-tasks.md              # 主文档：任务概览、依赖图、执行检查清单
├── 04-dev-tasks-infra.md        # 基础设施任务
├── 04-dev-tasks-core.md         # 核心逻辑任务
├── 04-dev-tasks-api.md          # 接口层任务
└── 04-dev-tasks-test.md         # 测试任务

Task archiving

When there are too many completed tasks, archive to 04-dev-tasks-archive.md。

See templates/archive-rules.md

Task design principles

Each task must satisfy the TAR principles：

Principle Description Required content
Testable (Testable) Can be verified through automated or manual testing Test methods and expected results
Acceptable (Acceptable) Has clear acceptance criteria Specific, quantifiable completion criteria
Reviewable (Reviewable) Can be independently code reviewed Review points

Task layering

Layer according to task type to determine the TDD mode:

Layer TDD mode Description
Core logic (Service/Domain) 🔴 Mandatory Tests first
Interface layer (Controller/API) 🟡 Recommended Tests first is recommended
UI layer (Component/View) 🟢 Optional Can be added after implementation
Infrastructure (DB/Config) ⚪ Not applicable Integration test verification

Constraints

Phase boundary constraints (highest priority)

  • This Skill only produces documents; writing or generating any implementation code (source code, scripts, configuration changes) is strictly prohibited
  • The Write tool is only used to write docs/devdocs/ Markdown documents under
  • The Bash tool is only used for read-only operations (such as viewing directory structure) and must not execute code modifications
  • Code implementation is the responsibility of /devdocs-dev-workflow and is not covered by this Skill

Basic constraints

  • A single task must be completable within 4 hours
  • Task dependencies must be specified
  • Must be ordered by dependencies, with no circular dependencies
  • File paths must be specific; do not write "related files"
  • A dependency graph must be provided
  • Priority: P0 (blocking), P1 (important), P2 (minor)
  • Task numbering format: T-XX (sequential numbering)
  • The level of detail for later batches of tasks must not be lower than that of the first batch (TAR completeness, path specificity, granularity consistency)
  • Perform a consistency self-check after each feature point is completed

Requirement traceability constraints

  • Each task must be associated with feature points (F-XXX) and acceptance criteria (AC-XXX)
  • Each task must be associated with test cases (UT/IT/E2E-XXX)
  • Test cases come from the 03-test-*.md document
  • TDD execution steps must explicitly reference AC numbers and the corresponding test numbers

TAR principle constraints

  • Each task must include test methods(how to verify)
  • Each task must include acceptance criteria(quantifiable completion criteria)
  • Each task must include Review points(code review focus areas)
  • Test methods must be executable (not vague descriptions)
  • Acceptance criteria must be quantifiable
  • Review points must target the task type

Layered Constraints

  • Core logic tasks must be marked 🔴 and include complete TDD execution steps(Red🔴→Green🟢→Refactor🔵)
  • Interface layer tasks must be marked 🟡 and include recommended TDD execution steps(Red🔴→Green🟢)
  • UI layer tasks are marked 🟢 with optional TDD; execution steps are: implement→verify→add tests
  • Infrastructure tasks are marked ⚪ with TDD not applicable; execution steps are: implement→integration test verification
  • Test assertions must reference ACs; inferring tests from implementation code is prohibited
  • Task documents must be output grouped by layer(Infrastructure→Core Logic→Interface Layer→UI Layer)
  • Each task's attribute table must include the TDD 模式 row

Execution Constraints

  • Task execution must use /devdocs-dev-workflow
  • Writing code directly while skipping dev-workflow is prohibited (it causes traceability to fail)
  • After a task is completed, you must execute /devdocs-sync

Incremental Task Management

Source

Source Skill Trigger Scenario Action
/devdocs-feature New feature requirement Append task to the list
/devdocs-bugfix Bug fix requirement Insert a high-priority task
/devdocs-insights Improvement suggestion confirmed Append task to the list

Incremental Operations

  • Add task: Append to the end of the task list and renumber
  • Insert task: Insert high-priority tasks at an appropriate position
  • Update dependencies: Adjust the dependency relationships of affected tasks
  • Update status: Mark tasks as completed/in progress

Post-Completion Operations

After the user confirms the task document:

  1. Ask the user whether to start development
  2. If yes, use TodoWrite to add all tasks to the tracking list
  3. It is recommended to start from the first task, or use batch mode:/devdocs-dev-workflow T-01~T-XX
  4. When executing tasks, you must use /devdocs-dev-workflow
  5. Supports batch execution by feature point (F-XXX) or user story (US-XXX)

Important: Writing code directly without using dev-workflow will cause the code to lack @satisfies/@verifies annotations, making /devdocs-sync unable to automatically trace, breaking the document↔code closed loop.

References

Sub-Agent Summary Format

When this Skill runs as a sub-agent, return the following structured summary:

skill: devdocs-dev-tasks
tasks_created: X
task_range: "T-01~T-10"
layers:
  core: X      # 🔴
  api: X       # 🟡
  ui: X        # 🟢
  infra: X     # ⚪
status: completed
output_files:
  - docs/devdocs/04-dev-tasks.md

Next Steps

After completion, it is recommended to use /devdocs-dev-workflow to execute development tasks.

Tip: When the document changes significantly, it is recommended to run /agent-memory to synchronize the memory file.

Collaborating Skills

Scenario Skill
Execute development tasks /devdocs-dev-workflow
Synchronize document status /devdocs-sync
New feature requirement /devdocs-feature
Fix Bug /devdocs-bugfix