AgentSkillsCN

aico-backend-task-breakdown

按照分层架构的顺序,将 PM 故事分解为后端任务:数据模型 → 数据库 → 仓库 → 服务 → API → 验证 → 测试。 独特价值:确保依赖关系的合理顺序与职责的清晰分离。任务按架构层级排序,而非随意排列。 当满足以下条件时,可使用此技能: - 执行 /backend.tasks 命令; - 用户要求“为后端分解故事”、“创建后端任务”、“拆分为后端任务”; - docs/reference/pm/stories/ 中已有故事,需要整理出有序的任务列表; - 需要按架构层级对任务进行排序(而非随意排列); - 开始后端工作,希望获得有序且分层的任务列表。 层级顺序至关重要:类型/实体 → 迁移 → 仓库 → 服务 → API → 验证 → 测试。 输出:始终将任务写入 docs/reference/backend/tasks/{story-name}.md。

SKILL.md
--- frontmatter
name: aico-backend-task-breakdown
description: |
  Break down PM story into backend tasks following LAYERED ARCHITECTURE order: Data Models → Database → Repository → Service → API → Validation → Tests.

  UNIQUE VALUE: Ensures proper dependency order and separation of concerns. Tasks are ordered by architectural layers, not random order.

  Use this skill when:
  - Running /backend.tasks command
  - User asks to "break down story for backend", "create backend tasks", "split into backend tasks"
  - Have story at docs/reference/pm/stories/ and need organized task list
  - Need tasks ordered by architectural layers (not random order)
  - Starting backend work and want organized, layered task list

  Layer order is CRITICAL: Types/Entities → Migrations → Repository → Service → API → Validation → Tests
  Output: ALWAYS write to docs/reference/backend/tasks/{story-name}.md

Task Breakdown

Language Configuration

Before generating any content, check aico.json in project root for language field to determine the output language. If not set, default to English.

Process

  1. Read story/PRD: Load from docs/reference/pm/stories/ or docs/reference/pm/versions/
  2. Identify data entities: What domain objects are needed
  3. Identify API endpoints: What routes are needed
  4. Identify business logic: What services are needed
  5. Break into tasks: Follow layered architecture order
  6. Save output: ALWAYS write to docs/reference/backend/tasks/{story-name}.md

Layered Architecture Order

code
1. Data Models (types, entities, DTOs)
      ↓
2. Database (migrations, schema)
      ↓
3. Repository Layer (data access)
      ↓
4. Service Layer (business logic)
      ↓
5. API Layer (controllers, routes)
      ↓
6. Validation & Error Handling
      ↓
7. Tests (unit, integration, API)

Task File Template

markdown
# [Story Name] - Backend Tasks

> Project: [project-name]
> Created: YYYY-MM-DD
> Last Updated: YYYY-MM-DD
> Source: docs/reference/pm/stories/[story].md
> Status: in_progress

## Progress

| #   | Task                       | Status     | Notes |
| --- | -------------------------- | ---------- | ----- |
| 1   | Define data models         | ⏳ pending |       |
| 2   | Create database migrations | ⏳ pending |       |
| 3   | Implement repository layer | ⏳ pending |       |

## Tasks

### Task 1: Define data models

**Status**: ⏳ pending
**Goal**: Create types for domain entities
**Scope**: Entity types, DTOs, validation schemas
**Acceptance Criteria**:

- [ ] Types match business requirements
- [ ] No type errors
      **Dependencies**: None

Task Types

TypeExamples
Data ModelDefine entities, DTOs, schemas
DatabaseMigrations, indexes, seeds
RepositoryData access layer
ServiceBusiness logic
APIControllers, routes
ValidationInput validation
TestingUnit, integration, API tests

Granularity Rules

  • Each task = independently testable
  • Each task = single responsibility
  • Each task = clear scope (not too big, not too small)

Key Rules

  • ALWAYS follow layered architecture order
  • MUST include test tasks for each layer
  • ALWAYS note dependencies between tasks
  • MUST save to docs/reference/backend/tasks/ directory

Common Mistakes

  • ❌ Tasks too large (entire API) → ✅ Break into layers
  • ❌ Skip data model first → ✅ Types before implementation
  • ❌ Skip repository layer → ✅ Separate data access
  • ❌ Forget validation → ✅ Always include validation task