---
name: yunxiao-requirement-task-lifecycle
description: Use when pulling or implementing a Yunxiao requirement, especially when the user says 拉取需求, 完成需求, 提交代码, 拆分任务, 填计划时间, 预计工时, 实际工时, 修改需求状态, or asks to handle a VWCG requirement end to end. It requires creating a child task, filling plan fields and estimated effort before development, then filling actual effort and updating task/requirement statuses after code delivery.
version: 0.1.0
---

# Yunxiao Requirement Task Lifecycle

## Purpose

Make Yunxiao requirement implementation reproducible:

1. A product requirement must be split into a development task before coding.
2. The child task must have plan start date, plan finish date, and estimated effort filled before or during implementation planning.
3. Code commits and Codeup MR titles must associate the child task.
4. After development and code submission, actual effort and final statuses must be written back to Yunxiao.

Layer this skill on top of:

- `yunxiao-cli-interaction` for all Yunxiao reads/writes.
- `yunxiao-codeup-pr-association` for branch, commit, push, and MR association.

For the complete zhct submission loop, read `../../../prompt/governance/YUNXIAO_CODEUP_SUBMISSION_PROCESS.md` before push, MR creation, Yunxiao writeback, or completion reporting.

Never use browser UI as the default write path. Do not print or commit tokens.

## Trigger Criteria

Use this skill whenever:

- The user asks to pull, read, or implement a Yunxiao requirement, especially a `VWCG-*` requirement.
- The user provides a Yunxiao requirement URL and asks to create a branch or complete development.
- The task involves submitting code for a Yunxiao requirement.
- The user asks for requirement/task status updates or work-hour fields.

## Intake Workflow

1. Read the requirement through CLI/OpenAPI and record:
   - requirement identifier and serial number
   - subject, description, assignee, priority, status, type, project
2. Create one child `任务` work item for the actual development slice unless a suitable child task already exists.
   - For 智慧营养健康餐厅, default project ID is `dd2f708d1702891ff45b6f5d99`.
   - Default task work item type ID is `ba102e46bc6a8483d9b7f25c`.
   - Link it to the requirement with `parentId`.
   - Title format: `开发：<需求核心动作>`.
   - Assignee defaults to the requirement assignee unless the user explicitly names another assignee.
3. Fill the child task planning fields:
   - Plan start date: field `79`, format `yyyy-MM-dd`.
   - Plan finish date: field `80`, format `yyyy-MM-dd`.
   - Estimated effort: create an estimated effort record or otherwise update field `101586`.
4. Estimate hours as if no AI was used.
   - Small route/config/UI text changes: usually `1-2h`.
   - UI + SQL/menu/permission changes: usually `2-4h`.
   - Backend/API/DB workflow changes: usually `4-8h`.
   - Larger cross-module changes: split into multiple tasks or ask before inventing a large estimate.
5. Read back the child task and confirm `79`, `80`, `101586` or estimated effort summary.

## Development Workflow

1. Create a branch from the latest target base in the target repo.
   - Branch should include the parent requirement or child task serial number, for example `codex/VWCG-947-<slug>-<date>`.
2. Implement the smallest safe code change and run task-relevant verification before committing.
   - Development being "done" is not enough to commit.
   - Run the changed-surface tests/checks first and record the output.
   - If verification cannot run, record the blocker and safe substitute evidence, then continue to commit only with explicit user approval.
   - For `store`, keep generated requirement/context/evidence docs in `zhctprompt/work_store/<ticket-or-topic>/`; do not include `store/prompt/**` or `store/docs/**` in the code MR unless explicitly requested.
3. Use the child task serial number for code association:
   - Git commit subject starts with `#<child-task-serial> `.
   - Codeup MR title starts with `#<child-task-serial> `.
4. Push the branch and create or update a Codeup MR.
   - For zhct local上线 code, first-stage target branch is `release`; use `test` only when the task evidence or user explicitly says this project/customer uses `test`.
   - Read back MR title, source branch, target branch, and reviewable status.
5. Add a Yunxiao comment to the child task with branch, commit, MR URL, and validation summary.

## Completion Workflow

After implementation, validation, commit, push, and MR creation:

1. Fill actual effort on the child task based on the real AI-assisted elapsed work.
   - Use the actual time spent with AI, not the non-AI estimate.
   - Prefer the standard OpenAPI effort record endpoint when available:
     - `POST /oapi/v1/projex/organizations/{org}/workitems/{taskId}/effortRecords`
     - Body includes `actualTime`, `gmtStart`, `gmtEnd`, and a concise description.
   - Read back `effortRecords` and the task fields `101587` / `sumActualLaborHour`.
2. Update the child task status according to its own workflow.
   - Always read workflow metadata first when uncertain.
   - If the child task workflow has `待测试`, move it there after local validation.
   - If the child task workflow is the simple task workflow with statuses `待处理 -> 处理中 -> 开发完成 -> 已完成`, move it to `开发完成` after code delivery and MR creation.
3. Update the parent requirement status.
   - After code is submitted and ready for QA, move the requirement to `待测试`.
   - For this project, product requirement `待测试` status ID is `1dec9023be7be6cf79e6bde901`.
4. Add comments on both parent requirement and child task explaining:
   - final branch, commit, MR
   - validation performed
   - planned effort vs actual effort
   - final statuses
5. Read back both parent requirement and child task. Confirm serial numbers, subjects, final statuses, plan dates, estimated effort, and actual effort before reporting completion.

## Known Field And Endpoint Notes

- Plan start date field: `79`.
- Plan finish date field: `80`.
- Estimated effort field: `101586`; preferred write path is estimated effort record.
- Actual effort field: `101587`; preferred write path is effort record.
- Estimated effort standard endpoint:
  - `POST /oapi/v1/projex/organizations/{org}/workitems/{taskId}/estimatedEfforts`
  - Use `spentTime`; omit `workType` unless the allowed work types have been read back.
- Actual effort standard endpoint:
  - `POST /oapi/v1/projex/organizations/{org}/workitems/{taskId}/effortRecords`
  - Use `actualTime`; omit `workType` unless the allowed work types have been read back.
- Direct update of `101586` may be rejected as non-editable; prefer effort records and verify summary fields.

## Stop Conditions

Stop and report a blocker when:

- The requirement cannot be read through CLI/OpenAPI.
- A child task cannot be created or linked to the requirement.
- Plan date or estimated effort writes fail and there is no verified alternate endpoint.
- The workflow does not allow the intended status and no valid intermediate/final status can be inferred from workflow metadata.
- Branch push or MR creation fails.
- Readback cannot confirm the task, effort, MR, or status updates.

## Final Response

Keep the final response short and include:

- parent requirement serial number and final status
- child task serial number and final status
- plan start/finish dates, estimated effort, actual effort
- branch, commit, MR URL
- any blocker or test gap