SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsyunxiao-requirement-lifecycle

yunxiao-requirement-lifecycle

Deployment & operations

View repository

Updated 10-15 08:51

About this skill

Yunxiao Requirement Lifecycle

Use this as the single entry skill. Load only the internal modules needed for the request. Installing the skill does not change Yunxiao; live transitions start only after an authorized apply and verified test run.

Route to modules

Read each selected file completely before acting:

Request scope Required module
OneOS end-state model,【交付】main task, multiple development subtasks, iterative testing/release, Y01–Y40, A01–A10, legacy rule migration references/oneos-terminal-flow.md
Lifecycle statuses, requirement labels, related tasks, R01–R12, stage entry/completion references/lifecycle-rules.md
Design/development/test task creation, task states, rollups, TK01–TK08 references/task-lifecycle.md
Test plans, case results, failed cases, bugs, retest, TC01–TC03, DF01–DF03 references/test-defect-closure.md
Repositories, dev/develop, branches, commits, MRs, multi-repository gate, CI01 references/codeup-integration.md
test/prod pipelines, Docker callback, release changes, acceptance, CI02–CI03, L01–L02 references/pipeline-release.md
Live audit/apply/test, browser execution, evidence, diagnosis, rollback, governance references/live-operations.md
Everyday colloquial operations, using short commands such as "record requirement, start analysis, arrange development, submit for testing, retest passed, release successful" references/simple-role-commands.md
Unified Operations Management PlatformEveryday "record requirement" accelerated execution (verified ID / API / status three-hop) references/oneos-pc-fast-path.md + assets/oneos-pc-runtime-ids.json
Unified Operations Management Platform"Record requirement to Yunxiao" complete copyable prompt (A/B/C gates + 30 tags) references/oneos-pc-record-requirement-prompt.md
When a requirement enters In Analysis/In Design/Pending Development, automatically create a task with the same name, link the requirement, and carry over the assignee and time references/auto-stage-task.md
Node communication scripts and handover reports for roles such as product, analysis, design, development, review, testing, defects, operations, and acceptance references/role-trigger-prompts.md
Final Chinese report references/report-template.md

Record Requirement · Parameter Gates and Acceleration (Mandatory)

When the command is "record requirement" and the project is the Unified Operations Management Platform (including the PC-side alias):

  1. First read references/oneos-pc-fast-path.md and assets/oneos-pc-runtime-ids.json, execute via the fast path, and do not repeatedly probe the create URL / priority ID.
  2. If the user requests Plan/single-select priority, advance to, and tags: you must first obtain explicit A+B+C；ForbiddenWhen not selected, default to "Medium + In Analysis" and create the ticket. "Approve plan" ≠ A+B+C already selected. For the complete user command, see references/oneos-pc-record-requirement-prompt.md。
  3. Prefer API ticket creation (write at creation time document), same-name task and tagging (PATCH propertyKey=tag); the browser is only used as a fallback when the tag API fails or status jumps consecutively. For the Unified Operations Management Platform, select tags by clicking in the assets/oneos-pc-tag-catalog.md selector; do not auto-map by lines.ts .

AutoPRD Combination (Mandatory · OneOS Product Requirements)

When the request involvescreating product-type requirements, writing/refreshing requirement descriptions, fast-track pending development, improving requirement descriptions/updating content, or when the user command contains "record requirement (with module/prototype)", "requirement already confirmed", "requirement finalized" and is to be entered into Yunxiao:

  1. Firstload and execute the project/global oneos-autoprd skill (do not skip).
  2. Use its output to fill in the Yunxiao requirement description:
    • Requirement Description ← AutoPRD body (product language; do not write table structures/interfaces/code)
    • Update Content ← Entries in Chapter 10 "Feature Change Log" of AutoPRD since the last finalization; if none, "First version finalized" or "No feature/logic increment this round"
    • When there is existing "Update Content": move the old section to Update Content · History(append in reverse order, do not delete)
  3. Prototype release increments are based on the AutoPRD feature change log; the PC full-package release announcement can still separately use AutoVUL。
  4. Object storage links, main task, status advancement, etc. still follow oneos-terminal-flow.md / simple-role-commands.md。

A02 / A02B The default implementation method on the OneOS project is to call AutoPRD; do not write only placeholder text.

Stage Same-Name Task (Mandatory · AI apply)

Whenever a requirement is advanced to In Analysis / In Design / Pending Development(including commands such as "start analysis", "start design", "rapid development", "requirement already confirmed…pending development", etc.), you must first read and execute references/auto-stage-task.md：

Status Task Assignee
Analyzing and requirementsame name; tag分析; formally linked requirement RequirementCreator
Designing and requirementsame name; tag设计; formally linked requirement RequirementCreator
To be developed and requirementsame name; tag交付(or under the phase model开发); formally linked requirement FixedHe Fei

Time: task planned start (and writable creation time)Use requirement's planned start/creation time. Duplicate-check idempotent; duplicate order creation within the same phase is prohibited.

First identify flow_model:

  • stage_tasks: use R01–R12 and TK01–TK08; read the five domain modules plus live-operations.md for a full audit.
  • oneos_delivery: read oneos-terminal-flow.md, codeup-integration.md, test-defect-closure.md, pipeline-release.md, and live-operations.md.

For a narrow diagnosis, read the relevant domain module plus live-operations.md. Do not blend both models in one project or load unrelated modules merely because they exist.

Classify authority

  • audit: inspect and report only.
  • plan: prepare a project profile and change plan only.
  • apply: create or modify only explicitly named projects, labels, rules, and test assets.
  • test: exercise approved rules with isolated artifacts and collect evidence.
  • document: produce a Chinese runbook from verified facts.

Treat ambiguous requests as audit or plan. Documentation never authorizes live changes.

When the user uses a write verb defined in simple-role-commands.md—for example 记录需求、确认需求、开始分析、开始设计、开始开发、提交测试、复测通过、发布成功 or 验收通过—treat it as apply authorization only for the current exact project and named work item. If the project is not exact, ask only for the project before writing. Query verbs such as 查状态、为什么没流转、下一步 and 给我方案 remain audit or plan.

Whenever apply changes a requirement status to 分析中、设计中 or 待开发, also apply references/auto-stage-task.md in the same turn (same-name task, formal link, assignee and time rules) before reporting success.

Build the project profile

  1. Choose exactly one template and copy it outside the skill:
    • stage_tasks: assets/project-profile.template.json.
    • oneos_delivery: assets/oneos-project-profile.template.json.
  2. Keep one independent object in projects for every target project; duplicate the template object when needed.
  3. Replace observed statuses, rule instances, repositories, branches, pipelines, test plans, defect workflows, release evidence, and control dispositions.
  4. Never add usernames, passwords, cookies, tokens, OTPs, Webhook secrets, or private keys.
  5. Validate before applying:
python scripts/profile_tool.py validate <profile.json>
python scripts/profile_tool.py render <profile.json> --output <execution-plan.md>

python scripts/oneos_profile_tool.py validate <oneos-profile.json>
python scripts/oneos_profile_tool.py render <oneos-profile.json> --output <execution-plan.md>

Do not apply while placeholders remain or validation fails.

Completeness contract

For stage_tasks, account for every control for every project independently:

  • R01–R12: requirement lifecycle and manual gates.
  • TK01–TK08: stage-task creation, task-state transitions, requirement rollups, and idempotency.
  • TC01–TC03: test-case execution, failed-case/defect association, and retest result update.
  • DF01–DF03: fixed handoff, tester-pass closure, and tester-fail reopen.
  • CI01–CI03: multi-repository coverage, callback safeguards, and environment/release separation.
  • L01–L02: legacy immediate-close rule disposition.

Record the actual R01–R12 rule_instances, TK01–TK08 task_rule_instances, and all 31 control_coverage entries. Valid modes are manual, native_rule, integration_bridge, disabled_legacy, and not_supported. not_supported needs an owner and fallback and is never equivalent to automated.

Completeness covers the requirement lifecycle, stage-task lifecycle and rollups, Testhub closure, Codeup assets, pipeline/release evidence, and legacy-close controls. Notifications, SLA reminders, generic automatic assignment, and unrelated custom-field synchronization remain outside scope unless explicitly added to adjunct_automations.

For oneos_delivery, account for all 48 controls independently:

  • Y01–Y16, Y20–Y22, Y30–Y35, Y40: native/mirrored lifecycle controls.
  • A01, A02, A02B, A03–A10: AI/Webhook bridge controls.
  • TC01–TC03, DF01–DF03, CI01–CI03, L01–L02: test, defect, code/release separation, and legacy-close controls.

Do not disable the old stage rules until the OneOS migration readiness gate passes: required requirement statuses exist, the main-task identity is filterable or procedurally exclusive, task workflows are ready, bridge owners and idempotency exist, and rollback evidence is saved. L01 and L02 remain disabled because they bypass acceptance.

Global safety rules

  • Reuse the authenticated browser session or approved semantic connector.
  • Preserve unrelated rules and user edits.
  • Never modify an existing production pipeline unless the user authorizes that exact change.
  • Clone a test pipeline before callback experiments and modify only the clone.
  • Require the expected current state in every automatic transition.
  • Separate observed evidence from proposals and inference.
  • Wait 5–30 seconds for asynchronous events and inspect execution logs.
  • Stop at CAPTCHA, OTP, login approval, permission elevation, protected-branch ambiguity, or indistinguishable similarly named resources.

Required outputs

Return only the applicable artifacts:

  1. Observed inventory and current-versus-target matrix.
  2. Per-project R01–R12 and TK01–TK08 rule-instance inventory with a 31-control ledger.
  3. Live change log with reopen verification.
  4. Test result per transition: 通过、异步通过、未触发、误触发 or 阻塞.
  5. Remaining risks, manual gates, and rollback steps.
  6. When requested, a role-and-trigger communication playbook with copyable prompts, required evidence, next owner, and stop conditions.
  7. For daily commands, answer briefly with the work item, actual state change, created/linked asset, blocker if any, and the exact next short command.