AgentSkillsCN

task-master-planner

根据仓库规范与 .context 文档生成系统工程任务计划，涵盖后端与前端分离、分阶段冲刺、依赖关系以及工时预估。适用于被要求基于 DesignSpec.md、ProjectArchitecture.md 或 .context 文件，制定任务分解、冲刺计划或工程工作计划时使用。

SKILL.md
--- frontmatter
name: task-master-planner
description: Generate system-engineering task plans from repo specs and .context docs, including backend/frontend separation, phased sprints, dependencies, and hour estimates. Use when asked to create a task breakdown, sprint plan, or engineering workplan from DesignSpec.md, ProjectArchitecture.md, or .context.

Task Master Planner

Follow this workflow to produce a task-master style JSON plan from repo specs.

Inputs to load (minimum)

  • •DesignSpec.md
  • •ProjectArchitecture.md
  • •.context/architecture/overview.md
  • •.context/architecture/patterns.md
  • •.context/auth/overview.md
  • •.context/testing.md
  • •.context/workflows.md
  • •.context/errors.md
  • •.context/api/headers.md
  • •.context/feature-flags.md
  • •.context/performance.md
  • •.context/monitoring.md
  • •.context/ui/patterns.md

If the request mentions “process all files in .context”, enumerate files with rg --files .context and skim any additional files that define requirements or constraints.

Output format

Produce JSON following the template in assets/task-master-template.json. Keep valid JSON and stable IDs.

Required properties per task:

  • •id (string, stable)
  • •title (short, action-oriented)
  • •area (frontend|backend|data|infra|qa|product)
  • •owner_role (e.g., Frontend Eng, Backend Eng, DevOps, QA)
  • •est_hours (number)
  • •dependencies (array of task ids)
  • •deliverable (1 sentence)
  • •acceptance (1 sentence, testable)

Task planning rules

  1. •Separate backend and frontend responsibilities clearly via area and owner_role.
  2. •Use phases with sprints; each sprint has a clear focus and 10–16 tasks.
  3. •Produce 80–100 tasks total unless user specifies otherwise.
  4. •Include work for: auth/RBAC, database schema + RLS, edge functions, API routes, realtime, pages from DesignSpec, shared UI components, tests (unit/integration/e2e), monitoring/logging, performance, security, deployment.
  5. •Respect architecture principles (real-time, event sourcing, API-driven, RBAC).
  6. •Add dependencies where sequencing matters (e.g., schema before API, API before UI).
  7. •Ensure task hours are realistic (4–16 hours typical).
  8. •Include assumptions and risks in top-level metadata.

Optional helpers

Use scripts/collect_context.sh <repo> to bundle a lightweight context manifest if needed.

Use scripts/generate_task_plan.py <repo> --mode initial --output task_master_plan.json to generate the initial plan.

Use scripts/generate_task_plan.py <repo> --mode evolve --baseline task_master_plan.json --output task_master_plan.evolve.json to append an evolution phase after the first delivery.