task-management（任务管理）

Task Management

Overview

Task management converts approved plans into bite-sized, trackable tasks and orchestrates their execution with progress reporting and checkpoint reviews. Each task is a single action that takes 2-5 minutes. The skill provides structured progress tracking, regular checkpoints, and integration with code review to maintain quality throughout execution.

Announce at start: "I'm using the task-management skill to break this plan into tracked tasks."

Trigger Conditions

• An approved plan document needs to be converted into executable tasks
• Multi-step implementation needs structured progress tracking
• Work needs checkpoint reviews at regular intervals
• /execute command used with a plan that needs task breakdown
• Transition from planning skill with an approved plan

Phase 1: Plan Parsing

Goal: Extract all tasks from the approved plan with correct ordering and dependencies.

1. Read the approved plan document from start to finish
2. Extract every implementation step as a discrete task
3. Identify dependencies between tasks (what must complete first)
4. Order tasks by dependency — independent tasks first
5. Confirm task list with the user before beginning execution

Task Granularity Rules

Task Specification Template

Task N: [Clear, specific description]
Files: [Exact paths to create/modify/test]
Depends on: [Task numbers that must complete first, or "none"]
Verification: [Exact command to confirm completion]

STOP — Do NOT proceed to Phase 2 until:

• Every plan step has been converted to 2-5 minute tasks
• Dependencies are mapped (no circular dependencies)
• Every task has a verification command
• Task list is confirmed with user

Phase 2: Task Execution

Goal: Execute tasks one at a time with verification after each.

Per-Task Workflow

1. Announce — Report which task is starting: [N/Total] Starting: <description>
2. Set status — Mark task as in_progress
3. Execute — Perform the task (follow TDD if writing code)
4. Verify — Run the verification command
5. Read output — Confirm verification matches success criteria
6. Report — Show completion: [N/Total] Completed: <description>
7. Set status — Mark task as completed

Execution Rules

Task Status Flow

pending → in_progress → completed
                     → blocked (needs user input)
                     → failed (invoke resilient-execution)

Status Decision Table

Do NOT proceed to next task until current task verification passes.

Phase 3: Checkpoint Review

Goal: Pause every 3 tasks to assess progress and quality.

Checkpoint Trigger Table

Checkpoint Steps

1. Show progress summary
2. Run full test suite (not just new tests)
3. Run lint, type-check, build as applicable
4. Dispatch code-review skill if significant code was written
5. Ask user if direction is still correct

Progress Report Format

After each task:

[3/15] Task completed: Write failing test for UserService.create
       Files: tests/services/user.test.ts
       Verification: npm test -- --grep "UserService.create" — PASS

After each checkpoint:

── Checkpoint [6/15] ──
Completed: 6 | Remaining: 9 | Blocked: 0
Tests: 12 passing, 0 failing
Lint: clean | Build: passing
Next batch: Tasks 7-9 (API endpoint implementation)
Continue? [yes / adjust plan / stop here]

STOP — Do NOT proceed to next batch until:

• Full test suite passes
• Checkpoint report presented to user
• User has confirmed to continue

Phase 4: Batch Review

Goal: After completing a logical group of tasks, perform quality review.

1. Dispatch code-reviewer agent to review the batch
2. Fix any Critical or Important issues before proceeding
3. Commit the batch with a descriptive conventional commit message
4. Update the plan document with completed status

Review Issue Handling

STOP — Do NOT start next batch until:

• Review issues at Critical severity are resolved
• Batch is committed
• Plan document is updated

Phase 5: Completion

Goal: Verify all tasks are done and report final status.

1. Confirm all tasks have completed status
2. Run final full test suite
3. Run all verification commands
4. Present final summary to user
5. Invoke verification-before-completion skill

Final Summary Format

── FINAL SUMMARY ──
Total tasks: 15 | Completed: 15 | Failed: 0
Tests: 42 passing, 0 failing
Build: passing | Lint: clean
Commits: 5 (conventional format)

All tasks from plan docs/plans/2026-03-15-feature.md are complete.
Verification-before-completion: PASS

Anti-Patterns / Common Mistakes

Anti-Rationalization Guards

If you catch yourself thinking:

• "The code looks right, I don't need to run it..." — Run it. Always.
• "I'll batch the verifications..." — No. Verify each task individually.
• "This task is trivial, it obviously works..." — Prove it with verification.

Integration Points

Concrete Examples

Example: Task Extraction from Plan

Plan step: "Add user registration endpoint with validation"

Extracted tasks:

Task 1: Write failing test for POST /api/users input validation
  Files: tests/api/users.test.ts
  Depends on: none
  Verification: npm test -- --grep "POST /api/users validation" → FAIL (expected)

Task 2: Implement input validation schema
  Files: src/schemas/user.ts
  Depends on: Task 1
  Verification: npm test -- --grep "POST /api/users validation" → PASS

Task 3: Write failing test for POST /api/users success case
  Files: tests/api/users.test.ts
  Depends on: Task 2
  Verification: npm test -- --grep "POST /api/users creates user" → FAIL (expected)

Task 4: Implement registration endpoint handler
  Files: src/routes/users.ts
  Depends on: Task 3
  Verification: npm test -- --grep "POST /api/users" → ALL PASS

Task 5: Commit registration endpoint
  Files: none (git operation)
  Depends on: Task 4
  Verification: git log --oneline -1 → shows conventional commit

Example: Blocked Task Report

BLOCKED: Task 7 — Write integration test for payment webhook
Reason: Stripe test API key not configured in .env.test
Impact: Tasks 7-9 (payment flow) cannot proceed
Non-blocked tasks: Tasks 10-12 (profile page) can continue

Options:
A. User provides Stripe test key → unblocks Tasks 7-9
B. Skip payment tasks, continue with profile → revisit later
C. Mock Stripe entirely → reduces test fidelity

Awaiting direction.

Key Principles

• One task at a time — Do not parallelize unless tasks are truly independent
• Verify after each task — Run the verification command before marking complete
• Checkpoint regularly — Every 3 tasks, pause and assess
• Track everything — No task without a status
• Small commits — Commit after each logical batch

Skill Type

RIGID — Follow this process exactly. Every task gets verified. Every 3 tasks get a checkpoint. No exceptions.