story-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: Planificar tarea de historia de usuario

Skill：用户故事任务规划

Guía para crear o actualizar tareas

TK-XXX

bajo una historia de usuario existente.

Alcance de un TK: La tarea es un documento de especificación técnica. Describe qué lograr, cómo implementarlo y sus dependencias dentro de la unidad de trabajo. No implementa código, no ejecuta pruebas, no crea ADRs. Lo que no está acordado va en Observaciones o se pregunta al usuario — nunca se inventa.

La plantilla canónica está en

assets/task-template.md

(léela antes de escribir cualquier TK).

本指南用于创建或更新现有用户故事下的

TK-XXX

任务。

TK任务范围：任务是一份技术规格文档。描述要达成的目标、实现方式及其在工作单元内的依赖关系。不涉及代码实现、测试执行或ADR创建。未达成共识的内容需放在备注中或向用户确认——绝不能自行编造。

标准模板位于

assets/task-template.md

（编写任何TK前请先阅读）。

Subagente requerido

所需子Agent

Este skill debe ejecutarse bajo el agente/subagente
docs-specialist
(

agents/docs-specialist.md

; en el proyecto destino instalar como

.cursor/agents/docs-specialist.md

). No ejecutar el flujo normativo de TK sin ese contexto.

本Skill必须在
docs-specialist
Agent/子Agent下执行（对应

agents/docs-specialist.md

；在目标项目中需安装为

.cursor/agents/docs-specialist.md

）。若无该上下文，请勿执行TK的常规流程。

Cómo preguntar al usuario

如何向用户提问

Cuando este skill indique preguntar, pedir, confirmar, validar o sugerir algo al usuario, hacerlo mediante la herramienta de preguntas estructuradas que ofrezca el cliente (la que renderiza opciones tappables o un selector de respuesta) en lugar de redactar la pregunta como prosa libre. Reglas:

Opciones cortas y mutuamente excluyentes (2–4 por pregunta) cuando la respuesta admita categorías; usar entrada libre solo si no hay forma razonable de enumerar opciones (p. ej. el objetivo breve de un stub).
No repreguntar lo que ya está respondido en el contexto, en
```
.agents/MEMORY.md
```
, en el
```
README.md
```
de la US o en las
```
TK-*.md
```
existentes de su carpeta.
Recopilación inicial (modo A, antes de redactar): una sola tanda con hasta tres preguntas por bloque; no ir descubriendo huecos turno a turno.
Modo B — confirmación de stubs (paso 6): una pregunta por turno con opciones
```
Confirmar stubs
```
/
```
Ajustar alcance
```
/
```
Cancelar
```
; no crear archivos antes de confirmación.
Fallback: si el cliente no expone esta herramienta, formular la pregunta en prosa con opciones enumeradas (1, 2, 3…).

Cada sección posterior que diga preguntar al usuario, validar con el usuario, confirmar o sugerir al usuario asume este mecanismo; no se vuelve a repetir.

当本Skill指示需询问、请求、确认、验证或建议用户时，需使用客户提供的结构化提问工具（可渲染可点击选项或响应选择器），而非以自由文本形式提问。规则如下：

当答案可分类时，提供简短且互斥的选项（每个问题2-4个选项）；仅当无法合理枚举选项时才使用自由输入（例如：占位任务的简短目标）。
不要重复提问上下文、
```
.agents/MEMORY.md
```
、用户故事的
```
README.md
```
或其目录下现有
```
TK-*.md
```
中已明确的内容。
初始收集（模式A，编写前）：单次批量提问，每组最多3个问题；不要逐轮发现信息缺口。
模式B — 占位任务确认（步骤6）：每次仅提一个问题，选项为
```
确认占位任务
```
/
```
调整范围
```
/
```
取消
```
；确认前请勿创建文件。
备选方案：若客户未提供该工具，则以自由文本形式提问并列出选项（1、2、3…）。

后续每个提及询问用户、与用户验证、确认或向用户建议的章节均默认遵循此机制，不再重复说明。

Resolución de idioma

语言优先级

Orden canónico compartido con el resto del ciclo de historias. Detenerse en el primer paso que aplique:

.agents/MEMORY.md
(raíz del repo) → línea
```
preferred language: <ISO 639-1>
```
(p. ej.
```
es
```
,
```
en
```
). Si no existe esa línea pero hay claves legacy (
```
language:
```
,
```
idioma:
```
,
```
Project language:
```
), usarlas solo como fallback al leer MEMORY antiguo.
Idioma del turno del usuario (mensaje actual).
Preguntar al usuario qué idioma prefiere y persistir la respuesta en
```
.agents/MEMORY.md
```
con
```
preferred language: <código>
```
.

与用户故事生命周期共享标准优先级顺序，按以下步骤依次判断，满足即停止：

.agents/MEMORY.md
（仓库根目录）→ 查找
```
preferred language: <ISO 639-1>
```
行（例如：
```
es
```
、
```
en
```
）。若该行不存在但存在旧版标识（
```
language:
```
、
```
idioma:
```
、
```
Project language:
```
），仅在读取旧版MEMORY时作为备选使用。
用户当前对话的语言（当前消息）。
询问用户偏好语言，并将答案以
```
preferred language: <代码>
```
格式保存到
```
.agents/MEMORY.md
```
中。

Modos de invocación

触发模式

El skill reconoce dos modos según lo que entregue el usuario. El modo determina el flujo a aplicar.

Modo	Disparador	Flujo a aplicar
A. Tarea específica	El usuario describe una tarea concreta (objetivo, unidad, alcance) o pide editar una `TK-XXX` existente.	Flujo: Crear stub, Flujo: Crear TK completa o Flujo: Actualizar una TK existente según corresponda.
B. Stubs desde US	El usuario entrega solo una referencia a una historia (p. ej. «US-004», «crea las tareas para US-007», «planifica esta historia») sin describir tareas específicas.	Flujo: Sugerir stubs desde una US — propósito por defecto: proponer un conjunto de stubs agrupados por unidad de trabajo que cubra los SC y considere las BR de la US.

En caso de duda entre A y B: preguntar al usuario antes de continuar. No combinar ambos modos en una misma ejecución.

本Skill根据用户输入识别两种模式，模式决定后续执行的流程。

模式	触发条件	执行流程
A. 特定任务	用户描述具体任务（目标、工作单元、范围）或请求编辑现有 `TK-XXX` 。	根据情况执行创建占位任务流程、创建完整TK任务流程或更新现有TK任务流程。
B. 基于用户故事生成占位任务	用户仅提供用户故事的引用（例如：«US-004»、«为US-007创建任务»、«规划此用户故事»），未描述具体任务。	执行基于用户故事建议占位任务流程——默认目标：按工作单元分组提出一组占位任务，覆盖用户故事的场景（SC）并考虑其业务规则（BR）。

若无法区分模式A和B：请先询问用户再继续。请勿在单次执行中混合两种模式。

Ubicación de archivos

文件位置

Artefacto	Ruta
Tarea	`docs/specs/user-stories/US-XXX-[nombre-corto]/TK-XXX-[kebab-case].md`
Unidades de trabajo	`docs/specs/work-units.md`
ADR	`docs/adr/`
Documentación técnica	`docs/specs/technical-docs/`
Glosario	`docs/specs/glossary.md`

工件	路径
任务	`docs/specs/user-stories/US-XXX-[nombre-corto]/TK-XXX-[kebab-case].md`
工作单元	`docs/specs/work-units.md`
ADR	`docs/adr/`
技术文档	`docs/specs/technical-docs/`
术语表	`docs/specs/glossary.md`

Convenciones del nombre de archivo

文件命名规范

Formato:
```
TK-XXX-[nombre-descriptivo].md
```
con
```
TK-XXX
```
en mayúsculas.
```
XXX
```
: número secuencial por historia (no global); tres dígitos con cero a la izquierda.
Nombre descriptivo: minúsculas, kebab-case, corto y descriptivo.

Ejemplos:

TK-001-modelo-dominio-receta.md

TK-002-endpoint-crear-receta.md

格式：
```
TK-XXX-[nombre-descriptivo].md
```
，其中
```
TK-XXX
```
为大写。
```
XXX
```
：按用户故事递增的序号（非全局序号）；三位数字，不足补零。
描述性名称：小写、kebab-case格式，简短且清晰。

示例：

TK-001-modelo-dominio-receta.md

、

TK-002-endpoint-crear-receta.md

。

Información requerida antes de redactar

编写前需确认的信息

Antes de crear o editar cualquier TK, el agente debe tener clara la siguiente información. No inventar nada — si algún dato no es explícito, preguntar al usuario.

Dato	Cómo obtenerlo	Si no está disponible
US padre	Indicada por el usuario	Sin `README.md` de US existente no se puede crear el TK
Modo de invocación	Inferir del mensaje: ¿tarea específica (A) o solo referencia a US (B)?	Si es ambiguo, preguntar al usuario
Intención (solo modo A)	Del mensaje del usuario	Preguntar: ¿solo anclaje (stub) o TK completa lista para Ready?
Objetivo del TK (solo modo A)	Del mensaje del usuario	Para stub: basta un objetivo breve. Para TK completa: preguntar hasta tener contexto suficiente
BR y SC de la US (solo modo B)	Leer la sección Criterios de aceptación del `README.md` de la US padre (subsecciones Reglas de negocio y Escenarios)	Si faltan BR-XX o SC-XX explícitos: bloquear modo B y reportar — no crear stubs
Unidad de trabajo	Inferir del repo o indicada por el usuario	Stub: puede quedar `Por definir` . TK completa: obligatoria; sin ella el estado no puede ser `Ready`
Contexto técnico (solo TK completa)	ADRs existentes, technical-docs, descripción del usuario	Si falta decisión técnica relevante: sugerir ADR al usuario, no crearlo
Referencia de UI (solo TK de interfaz)	Figma, wireframe o imagen de alta fidelidad aportados por el usuario	Obligatoria para `Ready` ; sin ella el TK de UI no puede salir de `Draft`
Idioma de preferencia	Ver Resolución de idioma	Preguntar y persistir en `.agents/MEMORY.md` con `preferred language: <código>`

Leer siempre el
README.md
de la US y todas las
TK-*.md
existentes en la carpeta antes de crear o editar cualquier tarea. Detectar solapamientos y resolverlos con el usuario antes de continuar.

创建或编辑任何TK前，Agent必须明确以下信息。请勿自行编造——若任何数据不明确，请询问用户。

数据	获取方式	不可用时处理方式
父用户故事	用户指定	若无现有用户故事的 `README.md` ，则无法创建TK任务
触发模式	从用户消息推断：是特定任务（A）还是仅用户故事引用（B）？	若模糊不清，询问用户
意图（仅模式A）	用户消息	询问：仅创建占位任务（stub）还是创建可进入Ready状态的完整TK任务？
TK任务目标（仅模式A）	用户消息	占位任务：只需简短目标。完整TK任务：需询问至获取足够上下文
用户故事的BR和SC（仅模式B）	读取父用户故事 `README.md` 的验收标准章节（业务规则和场景子章节）	若缺少明确的BR-XX或SC-XX：阻止模式B执行并报告——请勿创建占位任务
工作单元	从仓库推断或用户指定	占位任务：可填 `待定义` 。完整TK任务：必填；无工作单元则无法进入Ready状态
技术上下文（仅完整TK任务）	现有ADR、技术文档、用户描述	若缺少关键技术决策：向用户建议创建ADR，请勿自行创建
UI参考（仅UI类TK任务）	用户提供的Figma、线框图或高保真图像	进入Ready状态必填；若无则UI类TK任务无法脱离Draft状态
偏好语言	参考语言优先级	询问用户并以 `preferred language: <代码>` 格式保存到 `.agents/MEMORY.md`

编写或编辑任何任务前，请务必阅读用户故事的
README.md
及其目录下所有现有
TK-*.md
文件。检测到范围重叠时，请先与用户解决再继续。

Validación antes de crear

创建前验证

Antes de crear archivos, verificar las siguientes condiciones. Si alguna falla, no crear — informar al usuario y resolver primero.

¿Qué verificar?

US padre existe y está Ready: la carpeta
```
US-XXX-[nombre-corto]/
```
tiene
```
README.md
```
con
```
Estado: Ready
```
. No se pueden crear TKs sobre una US en Draft.
ID disponible: el número
```
TK-XXX
```
propuesto no existe ya en la carpeta.
Solapamiento de alcance: leer todas las
```
TK-*.md
```
de la carpeta de la US padre y comparar su objetivo con el de la nueva tarea. Si alguna ya cubre el mismo alcance: informar al usuario indicando cuál es el conflicto y preguntar si prefiere actualizar la existente o ajustar el alcance de la nueva.
Unidad definida (solo TK completa): si la unidad sigue siendo
```
Por definir
```
tras preguntar, publicar como stub en Draft, no como TK completa. Si hay conflicto:

⚠️ No es posible crear la tarea todavía:
- <razón concreta>
- [TK-XXX: Título](TK-XXX-nombre.md) — <razón del solapamiento, si aplica>

创建文件前，请验证以下条件。若任何条件不满足，请勿创建——告知用户并先解决问题。

需验证内容？

父用户故事已存在且处于Ready状态：
```
US-XXX-[nombre-corto]/
```
目录下存在
```
README.md
```
且标注
```
Estado: Ready
```
。无法为处于Draft状态的用户故事创建TK任务。
ID可用：拟使用的
```
TK-XXX
```
编号在目录中尚未存在。
范围无重叠：读取父用户故事目录下所有
```
TK-*.md
```
文件，将其目标与新任务目标对比。若已有任务覆盖相同范围：告知用户冲突任务，并询问用户偏好更新现有任务还是调整新任务范围。
工作单元已定义（仅完整TK任务）：若询问后工作单元仍为
```
待定义
```
，则发布为Draft状态的占位任务，而非完整TK任务。 若存在冲突：

⚠️ 暂时无法创建任务：
- <具体原因>
- [TK-XXX: 标题](TK-XXX-nombre.md) — <重叠原因（若适用）>

Flujo: Crear stub (anclaje de ID)

流程：创建占位任务（ID预留）

Un stub reserva el ID y el vínculo a la US. No requiere contexto técnico completo.

Inferir el siguiente
```
TK-XXX
```
libre listando archivos
```
TK-*.md
```
en la carpeta de la US.
Crear
```
TK-XXX-[nombre-descriptivo].md
```
con:
- ```
Estado: Draft
```
- ```
Historia
```
  : enlace a la US
```
[US-XXX](./README.md)
```
  .
- ```
Unidad de trabajo
```
  : la conocida o
```
Por definir
```
  .
- ```
Asignado a
```
  : indicado por el usuario; si no, inferir con
```
git config user.name
```
  ; omitir la línea si no aplica.
- Descripción: objetivo breve acordado — el qué, sin el cómo.
- Plan de implementación: vacío o ausente si no hay pasos definidos.
- Observaciones: pendientes reales; no rellenar con texto genérico.
Actualizar
```
work-units.md
```
solo si la unidad del stub no es
```
Por definir
```
(ver paso 2 del flujo de TK completa).
Parar aquí. No continuar con los pasos de TK completa.
Handoff: stub en
```
Draft
```
— completar a
```
Ready
```
con Flujo: Crear TK completa (modo A) antes de story-implement
.

占位任务用于预留ID及与用户故事的关联，无需完整技术上下文。

列出用户故事目录下的
```
TK-*.md
```
文件，推断下一个可用的
```
TK-XXX
```
编号。
创建
```
TK-XXX-[nombre-descriptivo].md
```
文件，包含：
- ```
Estado: Draft
```
- ```
Historia
```
  : 指向用户故事的链接
```
[US-XXX](./README.md)
```
  。
- ```
工作单元
```
  : 已知内容或
```
待定义
```
  。
- ```
Asignado a
```
  : 用户指定；若无则通过
```
git config user.name
```
  推断；不适用则省略该行。
- 描述: 已确认的简短目标——仅说明要做什么，无需说明怎么做。
- 实施计划: 空或省略（若无明确步骤）。
- 备注: 实际待办事项；请勿填充通用文本。
仅当占位任务的工作单元不是
```
待定义
```
时，更新
```
work-units.md
```
（参考完整TK任务流程的步骤2）。
到此为止。请勿继续执行完整TK任务的步骤。
交接: 处于Draft状态的占位任务——需通过创建完整TK任务流程（模式A）将其完善至Ready状态，之后才能执行**
```
story-implement
```
**。

Flujo: Crear TK completa

流程：创建完整TK任务

Una TK completa puede alcanzar

Estado: Ready

si cumple todas las condiciones del checklist.

Inferir el siguiente
TK-XXX
libre en la carpeta de la US.
Gestionar
work-units.md
:
- Crear desde
```
assets/work-units-template.md
```
  si el archivo no existe.
- Si la unidad es nueva: añadir sección
```
## <nombre-unidad>
```
  con párrafo de alcance. Si el alcance no está claro, preguntar antes de añadirla.
- No listar TKs, DTOs ni technical-docs dentro de
```
work-units.md
```
  ; solo nombre de unidad y párrafo de alcance.
Redactar el TK siguiendo
```
assets/task-template.md
```
:
- Metadatos:
```
Historia
```
  con enlace
```
[US-XXX](./README.md)
```
  ;
```
Asignado a
```
  indicado por el usuario, o inferido con
```
git config user.name
```
  , u omitido si no aplica.
- Descripción: qué lograr — objetivo claro, tono imperativo y verificable; sin «podría», «quizá», «tal vez».
- Dependencias: solo piezas dentro de la unidad de trabajo — componentes, servicios, modelos, librerías. No incluir aquí ADRs, technical-docs, contratos ni referencias de diseño; esos van exclusivamente en Referencias.
- Referencias: ADRs existentes, technical-docs, diseño. No crear ADRs; si falta una decisión, sugerirlo al usuario en Observaciones.
- Plan de implementación: pasos concretos acordados o derivados de fuentes citadas en Referencias. Si los pasos no se conocen aún, no inventar — indicar en Observaciones qué información falta para poder redactarlos.
- Observaciones: solo si hay pendientes reales (prerrequisitos no cumplidos, información pendiente, decisiones por tomar). Si no hay nada pendiente, omitir la sección. Si el equipo lo exige, una línea Sin pendientes documentados. Con pendientes reales:
```
Estado: Draft
```
  .
Actualizar technical-docs y glossary si aplica (entradas breves; glossary no es sustituto de ADR ni technical-doc).
Verificar el checklist antes de asignar
```
Estado: Ready
```
.
Handoff: si todas las TK del alcance acordado están
```
Ready
```
, sugerir story-implement
. Si otras TK siguen en
```
Draft
```
, listar cuáles completar antes de implementar.

完整TK任务若满足检查表所有条件，可进入

Estado: Ready

状态。

推断用户故事目录下下一个可用的
TK-XXX
编号。
管理
work-units.md
:
- 若文件不存在，从
```
assets/work-units-template.md
```
  创建。
- 若为新工作单元：添加
```
## <nombre-unidad>
```
  章节及范围描述段落。若范围不明确，请先询问用户再添加。
- 请勿在
```
work-units.md
```
  中列出TK任务、DTO或技术文档；仅需包含工作单元名称及范围描述段落。
按照
assets/task-template.md
编写TK任务:
- 元数据:
```
Historia
```
  包含链接
```
[US-XXX](./README.md)
```
  ；
```
Asignado a
```
  由用户指定，或通过
```
git config user.name
```
  推断，不适用则省略。
- 描述: 明确的目标，使用命令式、可验证的语气；避免使用「可能」「也许」等词汇。
- 依赖: 仅包含工作单元内的组件、服务、模型、库等。请勿在此处包含ADR、技术文档、契约或设计参考；这些内容需放在参考资料中。
- 参考资料: 现有ADR、技术文档、设计资料。请勿创建ADR；若缺少决策，请在备注中向用户建议创建。
- 实施计划: 已确认的具体步骤，或来自参考资料中引用的来源。若步骤尚不明确，请勿编造——在备注中说明缺少哪些信息才能编写步骤。
- 备注: 仅在存在实际待办事项时添加（未满足的前置条件、待确认信息、待决策事项）。若无待办事项，省略该章节。若团队要求，可添加一行无已记录待办事项。若存在实际待办事项：
```
Estado: Draft
```
  。
若适用，更新技术文档和术语表（简短条目；术语表不能替代ADR或技术文档）。
分配
Estado: Ready
前验证检查表。
交接: 若所有约定范围内的TK任务均处于Ready状态，建议执行**
```
story-implement
```
**。若其他TK任务仍处于Draft状态，列出需完善的任务后再执行实现流程。

Flujo: Actualizar una TK existente

流程：更新现有TK任务

Identificar el archivo — por número, nombre o título.
Leer el contenido actual completo antes de editar.
Leer el
README.md
de la US y las demás TKs para detectar solapamientos con los cambios propuestos.
Aplicar los cambios solicitados por el usuario. Reglas invariantes:
- Si hay conflicto entre el TK y el
```
README.md
```
  de la US: la US prevalece. Corregir el TK, no la historia.
- Si el usuario cambia el estado a Ready: verificar todas las condiciones del checklist antes de guardar.
- Si se añaden pasos al Plan: mantener tono imperativo y verificable; sin supuestos no acordados.
Confirmar mostrando las secciones modificadas.

识别文件——通过编号、名称或标题。
编辑前完整读取当前内容。
读取用户故事的
README.md
及其他TK任务，检测拟修改内容是否存在范围重叠。
应用用户请求的修改。不变规则：
- 若TK任务与用户故事的
```
README.md
```
  存在冲突：用户故事优先级更高。修改TK任务，而非用户故事。
- 若用户将状态改为Ready：保存前验证检查表所有条件。
- 若为实施计划添加步骤：保持命令式、可验证的语气；避免未达成共识的假设。
通过展示修改的章节向用户确认。

Flujo: Sugerir stubs desde una US

流程：基于用户故事建议占位任务

Aplica cuando el input es solo una referencia a una historia (modo B). El propósito es proponer un conjunto coherente de stubs que cubra los SC y considere las BR, sin redactar TKs completas.

Precondiciones de bloqueo — si alguna falla, no crear archivos e informar al usuario indicando la condición incumplida:

La carpeta

US-XXX-[nombre-corto]/

existe y su

README.md

tiene

Estado: Ready

El
```
README.md
```
contiene la sección Criterios de aceptación con al menos una regla de negocio (
```
BR-XX
```
) en la subsección Reglas de negocio.
El mismo bloque contiene al menos un escenario (
```
SC-XX
```
) en la subsección Escenarios.

Pasos:

Leer el
README.md
de la US completo y todas las
```
TK-*.md
```
existentes en su carpeta.
Verificar las precondiciones de bloqueo. Si alguna falla, no continuar: reportar al usuario qué falta y sugerir el skill correspondiente (
```
story-define
```
para alinear la US, etc.).
Identificar unidades de trabajo a partir del alcance de la US, los SC y las BR. Una unidad puede ser un módulo, servicio, paquete, componente UI, etc. No inventar unidades no soportadas por la US; lo no claro queda
```
Por definir
```
o se pregunta.
Cubrir los SC y considerar las BR. Asegurar que cada
```
SC-XX
```
queda cubierto por al menos un stub propuesto. Las
```
BR-XX
```
se consideran como restricciones que condicionan el alcance de los stubs (validaciones, invariantes, autorizaciones); no se replican literalmente en el TK.
Presentar la propuesta de stubs al usuario, agrupada por unidad de trabajo. Por cada stub incluir:
```
TK-XXX
```
tentativo (siguiente libre en secuencia), nombre de archivo, unidad de trabajo (o
```
Por definir
```
), objetivo breve y qué
```
SC-XX
```
cubre. No es 1 stub por SC: varios SC pueden caer en un mismo stub si comparten unidad y alcance; un SC amplio puede dividirse si abarca varias unidades. No crear archivos en este turno — dejar explícito al final del mensaje.
Confirmar con el usuario mediante la herramienta de preguntas estructuradas:
```
Confirmar stubs
```
/
```
Ajustar alcance
```
/
```
Cancelar
```
. Si elige ajustar, revisar la propuesta y repetir pasos 5–6. No continuar sin confirmación explícita, salvo que el mensaje inicial ya describiera la descomposición con detalle suficiente para considerarla aprobada.
Crear cada stub de la propuesta confirmada siguiendo el Flujo: Crear stub (Estado: Draft, descripción breve sin referenciar identificadores
```
SC-XX
```
/
```
BR-XX
```
en el documento, plan vacío).
Reportar al usuario la lista de stubs creados, agrupados por unidad de trabajo, indicando brevemente qué
```
SC-XX
```
cubre cada uno.
Handoff: si los stubs quedaron en
```
Draft
```
, indicar al usuario que debe completar cada TK a
```
Estado: Ready
```
con story-plan
(modo A) antes de invocar story-implement
. No sugerir implementación mientras las TK del alcance sigan en Draft.

Reglas invariantes:

No redactar Plan de implementación, ni Dependencias detalladas, ni Referencias técnicas: son stubs, no TKs completas.
No incluir identificadores
```
SC-XX
```
/
```
BR-XX
```
dentro de los archivos
```
TK-XXX.md
```
. La consideración es del agente, no del documento.
No crear archivos
TK-*.md
antes de la confirmación del paso 6. La traza SC/BR → stub vive en la propuesta (paso 5) y en el reporte (paso 8), no dentro de los archivos.
Si la US es ambigua respecto a unidades de trabajo: preguntar al usuario antes de crear stubs; no inferir unidades por cuenta propia.
Si dos stubs se solapan: consolidarlos en la propuesta (paso 5) o preguntar al usuario antes de confirmar.

适用于输入仅为用户故事引用的场景（模式B）。目标是提出一组连贯的占位任务，覆盖场景（SC）并考虑业务规则（BR），无需编写完整TK任务。

阻止前置条件——若任何条件不满足，请勿创建文件并告知用户未满足的条件：

US-XXX-[nombre-corto]/

目录存在，且其

README.md

标注

Estado: Ready

。

```
README.md
```
包含验收标准章节，且在业务规则子章节中至少有一条业务规则（
```
BR-XX
```
）。
同一章节的场景子章节中至少有一个场景（
```
SC-XX
```
）。

步骤：

完整读取用户故事的
README.md
及其目录下所有现有
TK-*.md
文件。
验证阻止前置条件。若任何条件不满足，请勿继续：告知用户缺少的内容，并建议使用对应Skill（例如：使用
```
story-define
```
对齐用户故事）。
基于用户故事范围、场景（SC）和业务规则（BR）识别工作单元。工作单元可以是模块、服务、包、UI组件等。请勿编造用户故事未支持的工作单元；不明确的内容填
```
待定义
```
或询问用户。
覆盖场景（SC）并考虑业务规则（BR）。确保每个
```
SC-XX
```
至少被一个拟议的占位任务覆盖。
```
BR-XX
```
作为限制条件影响占位任务的范围（验证、不变量、授权等）；无需在TK任务中逐字复制。
向用户展示分组的占位任务提案，按工作单元分组。每个占位任务需包含：暂定
```
TK-XXX
```
编号（序列中下一个可用编号）、文件名、工作单元（或
```
待定义
```
）、简短目标及覆盖的
```
SC-XX
```
。并非1个占位任务对应1个场景：若多个场景共享工作单元和范围，可合并为一个占位任务；若单个场景范围较广且涉及多个工作单元，可拆分。本回合请勿创建文件——在消息末尾明确说明。
通过结构化提问工具向用户确认：
```
确认占位任务
```
/
```
调整范围
```
/
```
取消
```
。若用户选择调整，修改提案并重复步骤5-6。无明确确认请勿继续，除非初始消息已详细描述拆分方式且可视为已批准。
按照创建占位任务流程创建每个已确认的占位任务（状态：Draft，简短描述，不包含
```
SC-XX
```
/
```
BR-XX
```
标识，实施计划为空）。
向用户报告已创建的占位任务列表，按工作单元分组，简要说明每个任务覆盖的
```
SC-XX
```
。
交接: 若占位任务处于Draft状态，告知用户需通过**
```
story-plan
```
（模式A）将每个TK任务完善至
Estado: Ready
状态，之后才能调用
```
story-implement
```
**。若范围内的TK任务仍处于Draft状态，请勿建议执行实现流程。

不变规则：

请勿编写实施计划、详细依赖或技术参考资料：这些是占位任务，而非完整TK任务。
请勿在
```
TK-XXX.md
```
文件中包含
```
SC-XX
```
/
```
BR-XX
```
标识。场景/业务规则与占位任务的对应关系仅体现在提案（步骤5）和报告（步骤8）中，无需写入文件。
步骤6确认前请勿创建
TK-*.md
文件。
若用户故事对工作单元描述模糊：创建占位任务前询问用户；请勿自行推断工作单元。
若两个占位任务范围重叠：在提案（步骤5）中合并，或确认前询问用户。

Checklist antes de redactar

编写前检查表

Información:

```
README.md
```
de la US leído
Todas las
```
TK-*.md
```
de la carpeta leídas; solapamientos resueltos
Modo de invocación identificado (A o B)
Modo A: intención clara: stub vs TK completa
Modo B: BR-XX y SC-XX identificados en Criterios de aceptación del
```
README.md
```
; US en
```
Estado: Ready
```
Modo B: propuesta presentada al usuario (paso 5) sin archivos creados
Modo B: confirmación estructurada recibida (paso 6) antes del primer
```
TK-*.md
```
Idioma de preferencia determinado y
```
.agents/MEMORY.md
```
actualizado si fue necesario Validación:
Carpeta de la US existe con
```
README.md
```
ID
```
TK-XXX
```
libre en la carpeta
Sin solapamiento de alcance con TKs existentes Condiciones para
Estado: Ready
:
Unidad de trabajo definida (no
```
Por definir
```
) y sección en
```
work-units.md
```
Descripción con objetivo claro y verificable
Si es TK de UI: referencia a Figma, wireframe o imagen de alta fidelidad presente en Referencias
Dependencias listadas dentro del alcance de la unidad
Plan de implementación con pasos concretos
Observaciones sin pendientes abiertos — sección omitida o con Sin pendientes documentados
Referencias a ADRs y technical-docs con rutas relativas válidas Formato:
Plantilla
```
assets/task-template.md
```
leída
Nombre de archivo en kebab-case, secuencial por historia
Sin código de aplicación en el archivo
Sin párrafos instructivos de plantilla en el TK publicado

信息确认：

已读取用户故事的
```
README.md
```
已读取目录下所有
```
TK-*.md
```
文件；范围重叠已解决
已识别触发模式（A或B）
模式A：意图明确：占位任务 vs 完整TK任务
模式B：已在
```
README.md
```
的验收标准中识别BR-XX和SC-XX；用户故事处于
```
Estado: Ready
```
状态
模式B：已向用户展示提案（步骤5）且未创建文件
模式B：已收到步骤6的结构化确认，才创建第一个
```
TK-*.md
```
文件
已确定偏好语言，必要时更新了
```
.agents/MEMORY.md
```
验证：
用户故事目录存在且包含
```
README.md
```
```
TK-XXX
```
编号在目录中可用
与现有TK任务无范围重叠进入
Estado: Ready
的条件：
工作单元已定义（非
```
待定义
```
）且在
```
work-units.md
```
中有对应章节
描述包含明确、可验证的目标
若为UI类TK任务：参考资料中包含Figma、线框图或高保真图像的引用
依赖列出了工作单元范围内的内容
实施计划包含具体步骤
备注无未完成待办事项——章节已省略或标注无已记录待办事项
ADR和技术文档的引用使用有效的相对路径 格式：
已读取
```
assets/task-template.md
```
模板
文件名采用kebab-case格式，按用户故事递增编号
文件中无应用代码
发布的TK任务中无模板说明段落

Ejemplos

示例

Ejemplo 1 — Stub

Entrada: «Solo quiero reservar TK-003, sin diseño técnico todavía.»
Salida:
```
TK-003-[nombre-corto].md
```
en Draft, unidad
```
Por definir
```
, descripción mínima del objetivo, Plan vacío, Observaciones con los pendientes reales.
```
work-units.md
```
sin cambios.

Ejemplo 2 — TK completa

Entrada: «TK para el diálogo de selección de ítem usando Material; la US tiene criterios; el ADR de UI está en
```
docs/adr/
```
.»
Salida: TK con unidad concreta, Plan con pasos verificables, referencias al ADR con ruta relativa,
```
work-units.md
```
actualizado si la unidad es nueva.
```
Estado: Ready
```
si Observaciones está limpia;
```
Draft
```
si quedan pendientes.

Ejemplo 3 — Información incompleta

Entrada: «TK-005 para la API Z.»
Comportamiento: El agente identifica que faltan contratos, endpoints y DTOs para redactar una TK completa. Pregunta al usuario antes de continuar. Si el usuario solo quiere reservar el ID: crea un stub en Draft. No redacta TK completa con supuestos.

Ejemplo 4 — Stubs desde una US (modo B)

Entrada: «Crea las tareas necesarias para implementar US-004.» (sin describir tareas específicas).
Comportamiento — turno 1: El agente activa el Flujo: Sugerir stubs desde una US. Verifica que
```
US-004/README.md
```
está en
```
Ready
```
y contiene BR y SC en Criterios de aceptación. Lee la US completa, identifica unidades de trabajo, y presenta la propuesta agrupada por unidad (paso 5) con
```
TK-XXX
```
tentativo, nombre de archivo, objetivo breve y cobertura de SC por stub. Pregunta con opciones
```
Confirmar stubs
```
/
```
Ajustar alcance
```
/
```
Cancelar
```
. No crea archivos.
Comportamiento — turno 2: Tras confirmación, crea cada stub en
```
Estado: Draft
```
sin referencias a
```
SC-XX
```
/
```
BR-XX
```
en el archivo (paso 7) y reporta rutas creadas con cobertura SC (paso 8).
Salida: Stubs
```
TK-001-...md
```
a
```
TK-NNN-...md
```
en Draft;
```
work-units.md
```
actualizado solo si alguna unidad es nueva y su alcance está claro. Handoff: completar cada TK a
```
Ready
```
con
```
story-plan
```
antes de
```
/story-implement
```
.

Ejemplo 5 — US no Ready o sin BR/SC

Entrada: «Tareas para US-009.» — pero
```
US-009/README.md
```
está en
```
Draft
```
o no tiene SC documentados en Criterios de aceptación.
Comportamiento: El agente bloquea, no crea ningún stub. Reporta al usuario qué falta (estado, BR, SC) y sugiere usar
```
story-define
```
para alinear la US antes de planificar tareas.

示例1 — 占位任务

输入: «我只想预留TK-003，暂时不需要技术设计。»
输出:
```
TK-003-[nombre-corto].md
```
处于Draft状态，工作单元为
```
待定义
```
，包含简短目标描述，实施计划为空，备注中列出实际待办事项。
```
work-units.md
```
无修改。

示例2 — 完整TK任务

输入: «使用Material组件实现选择项对话框的TK任务；用户故事有验收标准；UI的ADR位于
```
docs/adr/
```
。»
输出: 包含具体工作单元的TK任务，实施计划包含可验证步骤，引用ADR的相对路径，若为新工作单元则更新
```
work-units.md
```
。若备注无待办事项则
```
Estado: Ready
```
；若有待办事项则
```
Estado: Draft
```
。

示例3 — 信息不完整

输入: «为API Z创建TK-005。»
行为: Agent识别到缺少契约、端点和DTO，无法编写完整TK任务。继续前询问用户。若用户仅需预留ID：创建Draft状态的占位任务。请勿基于假设编写完整TK任务。

示例4 — 基于用户故事生成占位任务（模式B）

输入: «为实现US-004创建所需任务。»（未描述具体任务）。
行为 — 第一回合: Agent触发基于用户故事建议占位任务流程。验证
```
US-004/README.md
```
处于
```
Ready
```
状态且在验收标准中包含BR和SC。完整读取用户故事，识别工作单元，按工作单元分组展示提案（步骤5），包含暂定
```
TK-XXX
```
编号、文件名、简短目标及每个占位任务覆盖的SC。提问选项为
```
确认占位任务
```
/
```
调整范围
```
/
```
取消
```
。不创建文件。
行为 — 第二回合: 确认后，创建每个Draft状态的占位任务，文件中不包含
```
SC-XX
```
/
```
BR-XX
```
引用（步骤7），并向用户报告已创建的路径及SC覆盖情况（步骤8）。
输出: Draft状态的
```
TK-001-...md
```
至
```
TK-NNN-...md
```
占位任务；若有新工作单元且范围明确则更新
```
work-units.md
```
。交接：需通过
```
story-plan
```
将每个TK任务完善至Ready状态，之后才能调用
```
/story-implement
```
。

示例5 — 用户故事未处于Ready状态或缺少BR/SC

输入: «为US-009创建任务。»——但
```
US-009/README.md
```
处于
```
Draft
```
状态或验收标准中未记录SC。
行为: Agent阻止执行，不创建任何占位任务。告知用户缺少的内容（状态、BR、SC），并建议使用
```
story-define
```
对齐用户故事后再规划任务。

Anti-patterns

反模式

Implementar features, migraciones o tests mientras se redacta el TK.
Crear ADRs sin pedido explícito del usuario; solo referenciar existentes o sugerir su creación.
Publicar
```
Estado: Ready
```
en un stub sin criterios ni contexto técnico.
Publicar
```
Estado: Ready
```
con pendientes en Observaciones.
Ignorar las TKs existentes en la carpeta; duplicar o contradecir su alcance.
Meter listas de TKs, DTOs o technical-docs largos en
```
work-units.md
```
.
Inventar flujos, entidades o integraciones en lugar de preguntar.
Usar
```
glossary.md
```
como especificación técnica o sustituto de ADR.
Rellenar secciones con supuestos o ejemplos genéricos; dejar pendientes reales sin listar en Observaciones.
Narrar el trabajo realizado en el mensaje al usuario («leí la US», «creé el TK», «actualicé work-units»); solo reportar resultados y pendientes.
Modo B: crear stubs desde una US en
```
Draft
```
, o sin
```
BR-XX
```
/
```
SC-XX
```
explícitos en Criterios de aceptación de su
```
README.md
```
— debe bloquear y reportar.
Modo B: incluir identificadores
```
SC-XX
```
/
```
BR-XX
```
dentro del archivo
```
TK-XXX.md
```
; la cobertura se reporta al usuario, no se documenta en el TK.
Modo B: forzar un mapeo 1 stub = 1 SC; los stubs se agrupan por unidad de trabajo, no por escenario.
Modo B: redactar Plan de implementación, Dependencias o Referencias detalladas en stubs propuestos desde una US — son stubs, no TKs completas.
Modo B: crear stubs sin haber presentado la propuesta (paso 5) y recibido confirmación (paso 6).
Lanzar preguntas al usuario como prosa libre cuando el cliente expone una herramienta de preguntas estructuradas; o ir descubriendo huecos turno a turno en lugar de agrupar las preguntas pendientes en una sola tanda al inicio.

编写TK任务时同时实现功能、迁移或测试。
未收到用户明确请求时创建ADR；仅可引用现有ADR或建议创建。
为无标准或技术上下文的占位任务标记
```
Estado: Ready
```
。
备注有待办事项时标记
```
Estado: Ready
```
。
忽略目录下现有TK任务；重复或违背其范围。
在
```
work-units.md
```
中添加冗长的TK任务、DTO或技术文档列表。
编造流程、实体或集成而非询问用户。
将
```
glossary.md
```
用作技术规格或ADR的替代。
使用假设或通用示例填充章节；未在备注中列出实际待办事项。
向用户描述工作过程（«我已读取用户故事»、«我已创建TK任务»、«我已更新work-units»）；仅需报告结果和待办事项。
模式B：为处于Draft状态的用户故事，或
```
README.md
```
的验收标准中无明确
```
BR-XX
```
/
```
SC-XX
```
的用户故事创建占位任务——必须阻止并报告。
模式B：在
```
TK-XXX.md
```
文件中包含
```
SC-XX
```
/
```
BR-XX
```
标识；覆盖情况仅向用户报告，无需写入TK任务。
模式B：强制1个占位任务对应1个场景；占位任务按工作单元分组，而非场景。
模式B：为基于用户故事生成的占位任务编写实施计划、详细依赖或参考资料——这些是占位任务，而非完整TK任务。
模式B：未展示提案（步骤5）且未收到确认（步骤6）就创建占位任务。
当客户提供结构化提问工具时，仍以自由文本形式提问；或逐轮发现信息缺口，而非在初始阶段批量提问。

Notas

备注

Handoffs del ciclo

生命周期交接

Posición: planificación — entre

story-define

story-implement


Entrada	US con `Estado: Ready` y Criterios de aceptación ( `BR-XX` , `SC-XX` ) en su `README.md` . Si la US está en Draft o faltan BR/SC: bloquear y devolver handoff a `story-define` .
Salida mínima (modo B)	Stubs `TK-XXX-*.md` en `Draft` + cobertura SC reportada al usuario.
Salida para implementar	Cada TK del alcance acordado en `Estado: Ready` (Plan, Dependencias y Referencias según checklist). Stubs en Draft no habilitan `story-implement` .
Siguiente paso	`story-implement` — solo cuando US Ready y las TK a ejecutar están Ready. Sugerir `/story-implement` al cerrar la última TK Ready del alcance.
Regreso desde define	Cambio funcional en la US → releer `README.md` y actualizar TKs afectadas antes de continuar.
Regreso desde implement	TK fuera de alcance o ambigüedad técnica → ajustar el TK aquí; no modificar el `README.md` de la US. Si el conflicto es funcional, escalar a `story-define` .

位置：规划阶段——位于

story-define

与

story-implement

之间。


输入	处于 `Estado: Ready` 状态且 `README.md` 包含验收标准（ `BR-XX` 、 `SC-XX` ）的用户故事。若用户故事处于Draft状态或缺少BR/SC：阻止并将交接返回至 `story-define` 。
最小输出（模式B）	Draft状态的 `TK-XXX-*.md` 占位任务 + 向用户报告SC覆盖情况。
可执行实现的输出	约定范围内的每个TK任务均处于 `Estado: Ready` 状态（符合检查表的实施计划、依赖和参考资料）。Draft状态的占位任务无法触发 `story-implement` 。
下一步	`story-implement` ——仅当用户故事处于Ready状态且待执行的TK任务处于Ready状态时触发。完成范围内最后一个Ready状态的TK任务时，建议调用 `/story-implement` 。
从define返回	用户故事功能变更 → 重新读取 `README.md` 并更新受影响的TK任务后再继续。
从implement返回	TK任务超出范围或技术模糊 → 在此处调整TK任务；请勿修改用户故事的 `README.md` 。若为功能冲突，升级至 `story-define` 处理。

work-units.md

Cada sección

## <nombre-unidad>

contiene solo el nombre de la unidad y una descripción corta — lo estrictamente necesario para entender su alcance: qué cubre y, si reduce ambigüedad, qué queda fuera. No es un índice de tareas ni un inventario de artefactos técnicos. Cuando la unidad de un stub es

Por definir

, no es obligatorio crear la sección hasta que se concrete.

每个

## <nombre-unidad>

章节仅包含工作单元名称和简短描述——仅需包含理解范围所需的内容：覆盖的内容，若能减少歧义可说明未覆盖的内容。这不是任务索引或技术工件清单。若占位任务的工作单元为

待定义

，无需创建对应章节直至明确。

Mensaje al usuario

用户消息

Solo resultados y lo que el usuario debe saber o decidir. No incluir razonamiento interno, cadenas de pensamiento ni narración del trabajo en curso. Si hay pendientes o aclaraciones, listarlos en viñetas agrupadas por TK.

仅包含结果及用户需了解或决策的内容。请勿包含内部推理、思维链或工作过程描述。若有待办事项或需澄清的内容，按TK任务分组以项目符号列出。