YunxiaoPM

Requirement Task (YunxiaoPM)

Automatic first update of each day (mandatory, before other actions)

When this Skill is first triggered on each local calendar day, first execute:

node <本 Skill 目录>/scripts/ensure-daily-skill-update.mjs --current-skill YunxiaoPM

updated: The five Yunxiao lifecycle Skills have been updated uniformly; you must fully re-read this SKILL.md and the references needed for this session before continuing.
skipped-today: It has already been updated successfully today; continue directly.
in-progress: Another related Skill is performing the same update; continue directly, do not update repeatedly in parallel.
failed / unavailable / cooldown: Give only one brief prompt and continue the current task; an update failure must not block Yunxiao work.
The shared update scope is fixed as YunxiaoPM、yunxiao-development-delivery、development-brain、YunxiaoQA、yunxiao-release-operations user-level global installation; this must not be used to modify project-level Skills, business repositories, Yunxiao data, pipelines, or production environments. Do not manually forge or write in advance the daily success status.

Product department Yunxiao automation. Formal Skill name YunxiaoPM, selector $YunxiaoPM; external Chinese name Requirement Task. Yunxiao lifecycle suite version:10.2.15。

Self-contained；Prohibited to fork / include / "align with" the delisted old lifecycle.
Product manager sessionDo notmount the old lifecycle Skill at the same time.

Established conventions (read first) → references/settled-rules.md

0. Key points for this round of assembly (quick notes)

Before formal handoff/refresh, first read versioned handoff gate: provide the frozen contract, acceptance, and engineering decision checklist for this scope, and read back the manifest for both requirements/delivery; new snapshot pre-check must include --handoff-file. Only placeholder status does not equal formally developable; old materials may be backfilled but must not be passed off as confirmed. This item supersedes the "no hash/placeholder may also be formally handed off" in the old compatibility clauses below; do not additionally create development/test tasks.

10.2.0's apply-standard only initializes up to Design Complete, returning formal:false; overwriting existing frozen materials is prohibited. After the materials are frozen and read back across all current client-side deliveries, use preflight-handoff → 确认 → apply-handoff to formally advance to To Be Developed. If the same confirmed Plan already explicitly includes these scopes/checklists, it may continue serially; initialization authorization alone must not be expanded into a formal handoff. Fast track and numbered direct push also execute this gate.

The type is only 【新增】 / 【优化】(no [Fix] prefix)
This Skill does not create[Development]/[Testing]; handoff endpoint = To Be Developed + [Delivery] owner already explicitly specified by command or project configuration and officially read back
Generate [Delivery] non-placeholder description: must $AutoRDO → a separate chapter "Rule Comparison" containing pre-modification rule + post-modification rule(see AutoRDO delivery-rules-chapter.md）
Development Skill[Development] description: only [Optimization] refines and writes the "pre-modification rule" (see dev-task-description.md）
For fragment ingestion first $AutoRDO; for design-complete PRD injection use $oneos-autoprd
Product handoff snapshot: generated after PRD/prototype modification confirmation; both requirements and [Delivery] write to and read back the same snapshot number/hash; for subsequent modifications use刷新产品快照, do not re-push the status
Writing Yunxiao tiering: creating requirements, batch advancement, cancellation, acceptance, and creating iterations still require Plan → Confirm → apply; within the same authorized batch, idempotent refresh, continuation, and read-back supplement with explicit numbers and no scope expansion do not require repeated confirmation
Yunxiao execution only allows the official aliyun devops CLI and this Skill's yunxiao_cli_pm.py; Cookie, XSRF, DOM, or webpage internal interface fallbacks are prohibited. The only exception is "Close Iteration": first verify the official CLI and complete page interaction according to iteration-close.md ; controlled visual fallback is allowed only when the CLI lacks a status action

Official CLI runtime (mandatory)

Run skill-run yunxiao_cli_pm.py doctor, authentication only reads the PAT, organization ID, or Region API address from local environment variables
Before writing, pre-check separately by command: initialization is done by preflight-standard freezing the scope and stopping at design completion; product snapshots are handled by preflight-product-snapshot freezing the snapshot/manifest; formal pending development is handled by preflight-handoff verifying all end-side lists and current ownership
For transactions requiring confirmation, run apply after the user passes the Plan gate; idempotent refresh, continuation, and read-back supplement for the same authorized batch can proceed directly. Both types of apply must re-read the guard, and on drift perform zero writes
After writing, read back status, assignee, formal relationships, iteration, and documents by work item internal ID; do not guess success by title
Old list_projects.py、list_tags.py、live_create_fast.py and Cookie APIs are historical implementations only and must not be executed

Plan mode gate (tiered by write risk)

Must Plan and confirm again: creating requirement/task trees, batch advancement, canceling requirements, product acceptance, creating or closing iterations, and any action that adds objects, expands scope, or changes an established assignee.
Project selection tiering: when the command explicitly gives a project ID and the official projex-get-project uniquely reads back the same ID and project name, lock the project directly without manual selection; when no ID is given, the ID cannot be uniquely read back, or multiple candidates exist, select in real time according to project-selection.md (PJ). Silently using cached default values is prohibited.
Write the Plan clearly: project name + spaceId, requirement/task numbers, statuses to be changed, assignees and sources, delivery·analysis·design numbering strategy, product snapshot numbers/hashes or placeholder missing risks, iteration type (if any),what will not be done(do not create [Development]/[Testing], do not check duplicates by title). Record that requirements only display compact-select.md multiple-choice questions for projects/types/priorities/tags not yet uniquely locked by explicit parameters.
Before the user confirms / approves / says "execute", it is prohibited to execute type 1 apply; compressed strings must first be parsed and echoed back, then wait for "execute".
No repeated confirmation needed: under the same confirmed plan or the same idempotency key, when the target project and work item numbers are both explicit and the operation only refreshes product snapshots within the original scope, continues unfinished actions, or supplements official read-backs, it may re-pre-check and proceed directly; if any object, relationship, assignee, status boundary, or action scope drifts, stop immediately and re-Plan.
After execution, read back the project, number, status, assignee, and formal relationships by internal ID, then verify the report.

Read-only exception: Only checking status / explaining / giving a plan does not enter Plan. Prohibited: Generalizing "parameters are complete" into no-confirmation; no-confirmation applies only to the above explicitly numbered, same-scope, same-idempotent transactions.

Source-of-truth model

需求状态 = 阶段看板唯一真相
【交付】 = 按交付端：Web|小程序→恰好1条；共用服务→恰好2条（Web+小程序，均 ASSOCIATED→需求）
【分析】/【设计】 = TASK_SUB→对应端侧交付（与 ASSOCIATED 同 create 互斥）
【开发】/【测试】 = 不进本 Skill
查重/复用 = 只认任务编号（ONEOS-xx）；禁止按标题
类型前缀 = 仅【新增】|【优化】

Numbering authority: requirement description ## 工作项编号（系统） → workitem-ids.md。
Explicit password numbering > read that block > ASSOCIATED/SUB validation; if conflict, stop.

External invocation (embedding the other party's full text is prohibited)

Timing	Invocation
Clean chat/recording/ledger	`$AutoRDO`
Generate/backfill non-placeholder 【Delivery】 description	`$AutoRDO` → rule comparison chapter (before change + after change); see AutoRDO `delivery-rules-chapter.md`
Design complete PRD + prototype link	`$oneos-autoprd`; after completion, follow product-handoff-snapshot.md to generate product snapshot (creating 【Delivery】 may still be a placeholder; backfilling the rule comparison chapter still goes through AutoRDO)
Personnel/status/fields; project catalog is only cached	assets/runtime-ids.json
PJ project selection	project-selection.md · official `projex-search-projects`
Compressed selection	compact-select.md · official `projex-list-labels`
Phase calendar work hours	work-hours.md · assets/cn-workday-calendar.json · scripts/workday_hours.py
Cross-platform script startup	runtime-launcher.md · `skill-run <script.py> [参数...]`

Cross-Skill logic handoff (mandatory)

Upstream/downstream pass only formal Skill names, requirement/delivery/development/testing/release task numbers, current status,ASSOCIATED/TASK_SUB and other formal relationships, as well as necessary attachments, pipelines, MRs, versions, or idempotency evidence identifiers.
It is prohibited to locate, read, copy, or require the user to provide the installation directory of other Skills; different clients must not share constants, rules, or runtime files through physical file paths.
This Skill only reads resources within its own package; when personnel, status, or project constants are missing, it should query Yunxiao in real time; when handoff numbers are missing, it should require upstream to supply them; cross-Skill filesystem fallback is prohibited.
The next hop outputs only formal selectors: for development use $yunxiao-development-delivery, for testing use $YunxiaoQA, for release use $yunxiao-release-operations。

Routing (read as needed)

Scenario	Module
Established definition	settled-rules.md
Delivery tree / prohibited items	model.md
Description two-part AutoRDO / AutoPRD	description-split.md
Standard path 0–5	stage-flow.md
No-ticket fast track	fast-track.md
Number direct push handoff	number-push.md
Handoff gate / fallback	handoff-and-rollback.md
Planned work hours	work-hours.md
Make export attachment	make-export-attach.md
Create iteration	sprint.md
Close / archive iteration	iteration-close.md
Post-production product acceptance	release-acceptance.md · scripts/accept_release.py
Password page	commands.md
Record requirement metadata fields	record-meta-fields.md
Acceptance / reporting	acceptance.md
Handoff contract (development entry)	handoff-contract.md
Handoff snapshot after product modification	product-handoff-snapshot.md
【Development】 description (only 【Optimization】)	dev-task-description.md
CLI real write and read-back	live-api.md · scripts/yunxiao_cli_pm.py
Cross-platform script launcher	runtime-launcher.md
Time-consumption retrospective	live-perf-2026-07-23.md

Explanatory long-form text (not required reading for execution): root directory docs-*.md。

Password quick reference

记录需求：…；项目ID=…或项目=（未给ID时Plan点选）；交付端=Web|小程序|共用服务；优先级=紧急|高|中|低；标签=…；提交部门=…；提交人=…；交付负责人=姓名或userId；推进至=暂不推进|已确认|分析中|设计中|设计完成|待开发|待开发(快轨)
受理确认：ONEOS-xx
开始分析：ONEOS-xx
开始设计：ONEOS-xx；交付任务=…；分析任务=…
设计完成：ONEOS-xx；设计任务=…；原型=…
刷新产品快照：需求=ONEOS-xx；交付任务=ONEOS-a；快照文件=…
交棒开发：ONEOS-xx；交付任务=…；[交付负责人=姓名或userId]
快轨待开发：ONEOS-xx；[交付负责人=姓名或userId]
补建技术改进：标题=…；问题/目标=…；影响范围=…；验收口径=…；交付端=Web|小程序|共用服务；交付负责人=姓名或userId；来源交付单元=TEMPDEV-ID
编号直推：分析任务=ONEOS-b / 设计任务=ONEOS-c / 交付任务=ONEOS-a；[交付负责人=姓名或userId]
回退设计：需求=ONEOS-xx；交付=TASK-xx；原设计=TASK-xx；原因=…
创建迭代：交付端=Web|小程序；版本类型=主|副|子；交付任务=ONEOS-a,ONEOS-b,…；名称前缀=…
关闭迭代：迭代ID=…
取消需求：需求=ONEOS-xx；交付=TASK-xx；执行批次=TASK-xx；原因=…
拉取待验收需求：发版任务=TASK-900
验收通过：发版任务=TASK-900；验收人=…；证据=…
验收不通过：发版任务=TASK-900；验收人=…；原因=…；证据=…

When writing the type into the title, use only 【New】 or 【Optimization】。

Delivery side → number of delivery items: Web/小程序 → 开始分析/快轨待开发 creates 1 【Delivery】 item;共用服务 → creates Web + Mini Program, 2 items total (both attached to the same requirement). See settled-rules.md。
Client-side tags: each 【Delivery】 must be tagged Web or 小程序(coexisting with module tags) to avoid single-client deliveries being confused in the list.

The two boundaries of this Skill

Before development: formal handoff completed (requirement = pending development; all current end-side [Delivery] owners have officially read back; the same-version product snapshot and complete checklist have been read back through the formal handoff entry,formal:true) → "Please have the technical manager use the development Skill". Placeholder/initialization must not report this conclusion.
After production: execute product acceptance according to the release task (not based onthe release production evidence block as a prerequisite hard gate; scope supports release → requirement or release → [Delivery] → requirement). When no sub-scope is specified, accept all scopes in the frozen checklist; when a component/deployment target is specified, write only that sub-scope's acceptance event, do not close the entire batch of requirements/deliveries/release tasks, and output precise branch cleanup candidates. After all scopes pass, close requirements, delivery containers, and release tasks item by item and idempotently; on partial success, retry only the incomplete objects; on failure, record unified evidence, attempt to mark the release task as release failed, and formally hand off to the test side to initiate the fix reflow.

Exception: after handoff, "create iteration and associate delivery" still belongs to this Skill.

§0.1 Five Supplements (Summary)

Placeholder materials: allowed to retain, investigate, and backfill, explicitly formal:false; must not advance to pending development or report formal handoff, and only after completing the frozen contract, acceptance, and engineering decision checklist may verification proceed; when the fast track has body text/prototype, using placeholders as substitutes is prohibited
Estimated work hours: standard path = phase calendar work hours; fast-track pending development requirements default to estimated/actual 2 each
Number source of truthis in "Work Item Number (System)"; PATCH immediately after creation
No-ticket fast track: [Design] description synchronizes the requirement; planned start/end = same day; SUB → after delivery, supplement ASSOCIATED → requirement; delivery description manual or AutoPRD; same label; design completed status on the same day
Description two sectionsdo not overwrite each other; iterations attach only [Delivery];共用服务 dual-end deliveries are attached to the corresponding end-side iteration respectively; if rolling back and redoing the design, open a new design number, and the delivery planned start is not changed

TEMPDEV backfills formal technical improvement

When natural language has indicated code-first and there is no formal matter,补建技术改进reuse the existing controlled transaction of "record optimization requirement → fast-track pending development": create a Chinese optimization requirement and the corresponding end-side [Delivery], saving at least the problem/goal, impact scope, owner, acceptance criteria, andsourceDeliveryUnitId. Do not create or modify Git branches, commits, or MRs, and do not forge a [Development] task; then hand the formal requirement/delivery numbers to$yunxiao-development-delivery, and the development side creates/associates the [Development] and appends the sameadoptionIdofDELIVERY_ADOPTED. If the interface is temporarily unavailable, output the minimal ticket-supplement materials with the same fields; only block production claiming, and do not block TEMPDEV from continuing coding and test verification.

For details, see each references.