Back to Details

create-tasks

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Tasks

创建任务

Creates well-formed tasks that provide large amounts of contexts so that engineers that weren't in conversations can implement the task without any prior knowledge and without asking questions.
Tasks should be created using the tools and documentation conventions in the project the skills is being applied to. If the conventions are not clear, ask the user to clarify and then document them.
创建信息完整的规范任务，确保即使未参与前期沟通的工程师也能无需前置知识、无需额外提问即可落地实现。
任务创建需遵循当前项目所使用的工具和文档规范。若规范不明确，请先询问用户确认并记录规范内容。

What Engineers Need

工程师所需信息

Every task must provide:
  • What they're building (deliverable)
  • Why it matters (context)
  • Key decisions and principles they must follow
  • Acceptance criteria
  • Dependencies
  • Related code/patterns
  • How to verify it works
每个任务必须包含以下内容：
  • 需开发的内容（交付物）
  • 任务的重要性（背景）
  • 必须遵循的关键决策与原则
  • 验收准则
  • 依赖项
  • 参考代码/实现模式
  • 验证方法

Before Creating Tasks: Slice First

创建任务前：先切片拆分

🚨 NEVER create a task without validating its size first. A PRD deliverable is NOT automatically a task—it may be an epic that needs splitting.
🚨 绝对不要在未验证任务规模的情况下直接创建任务。PRD中的交付物并非天然就是可执行任务——它可能是一个需要拆分的史诗（Epic）。

Example Mapping Discovery

示例映射法（Example Mapping）

🚨 Never copy PRD bullets verbatim. Use Example Mapping to transform them into executable specifications.
CardWhat You Do
🟡 StoryState the deliverable in one specific sentence
🔵 RulesList every business rule/constraint (3-4 max per task)
🟢 ExamplesFor EACH rule: happy path + edge cases + error cases
🔴 QuestionsSurface unknowns → resolve or spike first
The Examples (🟢) ARE your acceptance criteria. Write them in Given-When-Then format:
Given [context/precondition]
When [action/trigger]
Then [expected outcome]
Edge case checklist — for each rule, systematically consider:
CategoryCheck For
InputEmpty, null, whitespace, boundaries, invalid format, special chars, unicode, too long
StateConcurrent updates, race conditions, invalid sequences, already exists, doesn't exist
ErrorsNetwork failure, timeout, partial failure, invalid permissions, quota exceeded
Example: PRD says "User can search products"
Rules identified: (1) Search by title, (2) Pagination, (3) Empty state
For Rule 1 alone, edge case thinking yields:
  • Given products exist → When search → Then results (happy path)
  • Given no matches → When search → Then empty set
  • Given empty search term → When submit → Then validation error OR all products? (🔴 Question!)
  • Given special chars in search → When search → Then handled safely
🚨 切勿直接复制PRD中的条目。使用示例映射法将PRD内容转化为可执行的规范。
卡片类型操作说明
🟡 用户故事用一句具体的话描述交付物
🔵 规则列出所有业务规则/约束（每个任务最多3-4条）
🟢 示例针对每条规则：覆盖正常场景 + 边界场景 + 异常场景
🔴 疑问提出未知问题 → 先解决或做技术调研
🟢示例即为验收准则。需采用Given-When-Then格式编写：
Given [前置条件/背景]
When [操作/触发事件]
Then [预期结果]
边界场景检查清单 —— 针对每条规则，系统地考虑以下类别：
类别检查项
输入空值、Null、空白字符、边界值、无效格式、特殊字符、Unicode、过长内容
状态并发更新、竞态条件、无效序列、已存在、不存在
错误网络故障、超时、部分失败、权限不足、配额超限
示例： PRD要求“用户可搜索商品”
提炼出的规则：(1) 按标题搜索，(2) 分页，(3) 空状态
仅针对规则1，边界场景分析可得到：
  • Given 存在商品 → When 执行搜索 → Then 返回结果（正常场景）
  • Given 无匹配结果 → When 执行搜索 → Then 返回空集合
  • Given 搜索词为空 → When 提交搜索 → Then 显示验证错误还是返回全部商品？（🔴 疑问！）
  • Given 搜索词含特殊字符 → When 执行搜索 → Then 安全处理

Splitting Signals (Task Too Big)

任务过大的判断信号

If ANY of these are true, STOP and split:
  • ❌ Can't describe in a specific, action-oriented title
  • ❌ Would take more than 1 day
  • ❌ Title requires "and" or lists multiple things
  • ❌ Has multiple clusters of acceptance criteria
  • ❌ Cuts horizontally (all DB, then all API, then all UI)
  • ❌ PRD calls it "full implementation" or "complete system"
若出现以下任意一种情况，立即停止并拆分任务：
  • ❌ 无法用具体的、面向动作的标题描述
  • ❌ 预计耗时超过1天
  • ❌ 标题中包含“和”或列出多项内容
  • ❌ 存在多组验收准则
  • ❌ 横向拆分（先做所有DB开发，再做所有API，最后做所有UI）
  • ❌ PRD中称为“完整实现”或“全系统”

SPIDR Splitting Techniques

SPIDR拆分技巧

When you need to split, use these techniques:
TechniqueSplit ByExample
PathsDifferent user flows"Pay with card" vs "Pay with PayPal"
InterfacesDifferent UIs/platforms"Desktop search" vs "Mobile search"
DataDifferent data types"Upload images" vs "Upload videos"
RulesDifferent business rules"Basic validation" vs "Premium validation"
SpikesUnknown areas"Research payment APIs" before "Implement payments"
需要拆分任务时，可采用以下技巧：
技巧拆分维度示例
Paths（流程）不同用户流程“银行卡支付” vs “PayPal支付”
Interfaces（界面）不同UI/平台“桌面端搜索” vs “移动端搜索”
Data（数据）不同数据类型“上传图片” vs “上传视频”
Rules（规则）不同业务规则“基础校验” vs “高级校验”
Spikes（调研）未知领域“调研支付API” 先于 “实现支付功能”

Vertical Slices Only

仅采用垂直切片

Every task must be a vertical slice—cutting through all layers needed for ONE specific thing:
✅ VERTICAL (correct):
"Add search by title" → touches UI + API + DB for ONE search type

❌ HORIZONTAL (wrong):
"Build search UI" → "Build search API" → "Build search DB"
每个任务必须是垂直切片——覆盖完成某一具体功能所需的所有层级：
✅ 垂直切片（正确）：
“为商品搜索添加价格区间筛选” → 涉及UI + API + DB，针对单一搜索类型

❌ 横向切片（错误）：
“开发搜索UI” → “开发搜索API” → “开发搜索DB”

Task Naming

任务命名

Formula

命名公式

[Action verb] [specific object] [outcome/constraint]
[动作动词] [具体对象] [结果/约束]

Good Names

优秀命名示例

  • "Add price range filter to product search"
  • "Implement POST /api/users endpoint with email validation"
  • "Display product recommendations on home page"
  • "Enable CSV export for transaction history"
  • "Validate required fields on checkout form"
  • “为商品搜索添加价格区间筛选”
  • “实现带邮箱校验的POST /api/users接口”
  • “在首页展示商品推荐”
  • “启用交易记录的CSV导出功能”
  • “校验结账表单的必填字段”

Rejected Patterns

禁用命名模式

🚨 NEVER use these—they signal an epic, not a task:
PatternWhy It's Wrong
"Full implementation of X"Epic masquerading as task
"Build the X system"Too vague, no specific deliverable
"Complete X feature"Undefined scope
"Implement X" (alone)Missing specificity
"X and Y"Two tasks combined
"Set up X infrastructure"Horizontal slice
If you catch yourself writing one of these, STOP and apply SPIDR.
🚨 绝对不要使用以下命名——它们代表的是史诗（Epic），而非任务：
模式问题所在
“完整实现X功能”以任务伪装的史诗
“构建X系统”过于模糊，无具体交付物
“完成X功能”范围不明确
“实现X”（单独使用）缺乏具体性
“X和Y”合并了两个任务
“搭建X基础设施”横向切片
若发现自己使用了上述命名，立即停止并应用SPIDR技巧拆分。

Task Size Validation (INVEST)

任务规模验证（INVEST原则）

Every task MUST pass INVEST before creation:
CriterionQuestionFail = Split
IndependentDoes it deliver value alone?Depends on other incomplete tasks
NegotiableCan scope be discussed?Rigid, all-or-nothing
ValuableDoes user/stakeholder see benefit?Only technical benefit
EstimableCan you size it confidently?"Uh... maybe 3 days?"
SmallFits in 1 day?More than 1 day
TestableHas concrete acceptance criteria?Vague or missing criteria
创建任务前，必须通过INVEST原则验证：
准则验证问题不通过则需拆分
Independent（独立）能否独立交付价值？依赖其他未完成的任务
Negotiable（可协商）范围是否可讨论？僵化，要么全做要么不做
Valuable（有价值）用户/利益相关者能否看到收益？仅具备技术价值
Estimable（可估算）能否自信地评估工作量？“呃...大概3天？”
Small（小粒度）能否在1天内完成？耗时超过1天
Testable（可测试）是否有明确的验收准则？准则模糊或缺失

Hard Limits

硬性限制

  • Max 1 day of work — if longer, split it
  • Must be vertical — touches all layers for ONE thing
  • Must be demoable — when done, you can show it working
  • 最大工作量为1天 —— 若超过，必须拆分
  • 必须是垂直切片 —— 覆盖某一功能的所有层级
  • 必须可演示 —— 完成后可展示功能运行效果

Task Template

任务模板

markdown
undefined
markdown
undefined

Deliverable: [What user/stakeholder sees]

交付物: [用户/利益相关者可见的内容]

Context

背景

[Where this came from and why it matters. PRD reference, bug report, conversation summary—whatever helps engineer understand WHY. You MUST provide the specific file path or URL for any referenced files like a PRD of bug report - don't assume the engineer knows where things are stored]
[任务来源及重要性。PRD参考链接、Bug报告、沟通摘要——任何能帮助工程师理解WHY的信息。必须提供PRD或Bug报告等参考文件的具体文件路径或URL，不要假设工程师知道文件存储位置]

Key Decisions and principles

关键决策与原则

  • [Decision/Principle] — [rationale]
  • [决策/原则] —— [理由]

Delivers

交付内容

[Specific outcome in user terms]
[用户视角的具体结果]

Acceptance Criteria

验收准则

  • Given [context] When [action] Then [outcome]
  • Given [背景] When [操作] Then [结果]

Dependencies

依赖项

  • [What must exist first]
  • [需先完成的前置内容]

Related Code

参考代码

  • path/to/file
    — [what pattern/code to use]
  • path/to/file
    —— [可复用的模式/代码]

Verification

验证方法

[Specific commands/tests that prove it works]
undefined
[可证明功能正常的具体命令/测试]
undefined

Process

流程

  1. Slice first — Apply Example Mapping. If task has >3-4 rules or fails splitting signals, use SPIDR to break it down.
  2. Discover acceptance criteria — For each rule: generate happy path, edge cases, error cases using the checklist. Write as Given-When-Then. Surface questions.
  3. Name it — Write a specific, action-oriented title. If you can't, the task isn't clear enough.
  4. Validate size — Must pass INVEST. Max 1 day. Must be vertical slice.
  5. Gather context (from PRD, conversation, bug report, etc.)
  6. Identify key decisions that affect implementation
  7. Find related code/patterns in the codebase
  8. Specify verification commands
  9. Output task using template
  1. 先切片拆分 —— 应用示例映射法。若任务包含超过3-4条规则或符合任务过大的判断信号，使用SPIDR技巧拆分。
  2. 确定验收准则 —— 针对每条规则：利用检查清单生成正常场景、边界场景、异常场景的示例。采用Given-When-Then格式编写。提出疑问。
  3. 命名任务 —— 编写具体的、面向动作的标题。若无法做到，说明任务不够明确。
  4. 验证规模 —— 必须通过INVEST原则验证。最大工作量1天。必须是垂直切片。
  5. 收集背景信息（来自PRD、沟通记录、Bug报告等）
  6. 识别影响实现的关键决策
  7. 在代码库中找到可参考的代码/模式
  8. 明确验证命令
  9. 使用模板输出任务

Checkpoint

检查点

Before finalizing any task, verify ALL of these:
CheckQuestionIf No
SizeIs this ≤1 day of work?Split using SPIDR
NameIs the title specific and action-oriented?Rewrite using formula
VerticalDoes it cut through all layers for ONE thing?Restructure as vertical slice
INVESTDoes it pass all 6 criteria?Fix the failing criterion
ContextCan an engineer implement without asking questions?Add what's missing
🚨 If the PRD says "full implementation" or similar, you MUST split it. Creating such a task is a critical failure.
最终确定任务前，需验证以下所有项：
检查项验证问题若否则需
规模工作量是否≤1天？用SPIDR拆分
命名标题是否具体且面向动作？用公式重写
垂直切片是否覆盖某一功能的所有层级？重构为垂直切片
INVEST是否通过所有6项准则？修复不通过的准则
背景信息工程师能否无需提问即可实现？补充缺失信息
🚨 若PRD中提到“完整实现”等类似表述，必须拆分任务。直接创建此类任务属于严重错误。