AgentSkillsCN

aico-frontend-task-breakdown

按照 UI 开发顺序,将 PM 故事分解为前端任务:设置 → 静态 UI → 动态逻辑 → 交互 → 测试。 独特价值:确保依赖关系的合理顺序。任务按 UI 开发层级排序,而非随意排列。 当满足以下条件时,可使用此技能: - 执行 /frontend.tasks 命令; - 用户要求“分解故事”、“创建前端任务”、“拆分为任务”; - docs/reference/pm/stories/ 中已有故事,需要整理出有序的任务列表; - 需要按 UI 开发层级对任务进行排序(而非随意排列); - 开始前端工作,希望获得有序的任务列表。 任务顺序至关重要:设置 → 静态 UI → 动态 → 交互 → 测试。 输出:始终将任务写入 docs/reference/frontend/tasks/{story-name}.md。

SKILL.md
--- frontmatter
name: aico-frontend-task-breakdown
description: |
  Break down PM story into frontend tasks following UI DEVELOPMENT order: Setup → Static UI → Dynamic Logic → Interactions → Testing.

  UNIQUE VALUE: Ensures proper dependency order. Tasks are ordered by UI development layers, not random order.

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

  Task order is CRITICAL: Setup → Static UI → Dynamic → Interactions → Tests
  Output: ALWAYS write to docs/reference/frontend/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. Read design (if exists): Load from docs/reference/frontend/designs/
  3. Identify components: What UI elements are needed
  4. Identify interactions: What logic and events are needed
  5. Break into tasks: Independently testable, single responsibility
  6. Order by dependencies: Setup → Static UI → Dynamic → Tests
  7. Save output: ALWAYS write to docs/reference/frontend/tasks/{story-name}.md

Task File Template

markdown
# [Story Name] - Frontend Tasks

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

## Progress

| Task                         | Status         | Notes |
| ---------------------------- | -------------- | ----- |
| 1. Setup component structure | ✅ completed   |       |
| 2. Implement header section  | 🔄 in_progress |       |
| 3. Implement content section | ⏳ pending     |       |

## Tasks

### Task 1: [Task Name]

**Status**: ⏳ pending
**Goal**: What this task achieves
**Scope**: Files to create/modify
**Acceptance Criteria**:

- [ ] Criterion 1
- [ ] Criterion 2
      **Dependencies**: Task X (if any)

Task Types

TypeExamples
SetupCreate component structure, setup state
UIImplement section/component layout
LogicAdd form validation, API integration
InteractionImplement hover, click, animations
TestingUnit tests, integration tests

Granularity Rules

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

Ordering Rules

  1. Setup tasks first
  2. Static UI before dynamic
  3. Core functionality before edge cases
  4. Tests after implementation

Key Rules

  • ALWAYS include test tasks at the end
  • MUST note dependencies between tasks
  • ALWAYS save to docs/reference/frontend/tasks/ directory
  • Keep tasks focused - not too big, not too small

Common Mistakes

  • ❌ Tasks too large (full page) → ✅ Break into sections
  • ❌ Tasks too small (add one button) → ✅ Group related work
  • ❌ Skip dependencies → ✅ Note which tasks depend on others
  • ❌ Forget testing → ✅ Always include test tasks