create-yss-spec 1.0.0

package/template/.codex/skills/yss-page-module-development/examples/StandardListPage/style.less

@@ -0,0 +1,83 @@
+@import "@/styles/variables.less";
+
+.business-quality-rule {
+  width: 100%;
+  height: 100%;
+  box-sizing: border-box;
+  display: flex;
+  flex-direction: column;
+
+  /** 树面板样式 */
+  .tree-panel {
+    height: 100%;
+    background-color: #fff;
+    overflow: hidden;
+    display: flex;
+    flex-direction: column;
+    border-radius: 8px;
+  }
+
+  /** 内容面板样式 */
+  .content-panel {
+    height: 100%;
+    display: flex;
+    flex-direction: column;
+    overflow: hidden;
+
+    // CRITICAL: YSplitPane 内部不要加 padding-left，改为给 YCard 加 margin
+    .y-card {
+      margin-left: 12px;
+    }
+
+    // CRITICAL: 让 Card 内容区域支持 flex 布局
+    :deep(.ant-card-body) {
+      height: 100%;
+      display: flex;
+      flex-direction: column;
+      flex: 1;
+      overflow: hidden;
+    }
+
+    // 搜索栏（固定高度）
+    .search-bar {
+      display: flex;
+      justify-content: space-between;
+      align-items: center;
+      padding: 16px;
+      gap: 16px;
+      flex-shrink: 0;
+
+      .search-inputs {
+        display: flex;
+        gap: 8px;
+        align-items: center;
+      }
+
+      .action-buttons {
+        display: flex;
+        gap: 8px;
+      }
+    }
+
+    // 表格容器（使用 flex: 1 占据剩余空间）
+    .table-container {
+      flex: 1; // ← CRITICAL: 让表格区域占据剩余空间
+      overflow: hidden; // ← CRITICAL: 防止溢出
+      display: flex;
+      flex-direction: column;
+      min-height: 0; // 关键：允许 flex 子元素收缩
+    }
+
+    // 规则名称链接样式
+    .rule-name-link {
+      color: @primary-color;
+      cursor: pointer;
+      text-decoration: none;
+      transition: color 0.2s;
+
+      &:hover {
+        text-decoration: underline;
+      }
+    }
+  }
+}

package/template/.codex/skills/yss-page-module-development/references/frontend-docs.md

@@ -0,0 +1,11 @@
+# yss-page-module-development Frontend Documentation
+
+Generated: 2026-06-29T16:11:14+00:00
+
+Use these YSS UI documentation entry points as authoritative references when local repo examples are insufficient.
+
+- components: http://192.168.164.27:3200/components
+- hooks: http://192.168.164.27:3200/hooks
+- skills: http://192.168.164.27:3200/skills
+
+When documentation and local code differ, inspect the current project code before editing and prefer established local usage.

package/template/.codex/skills/yss-product-lifecycle/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: yss-product-lifecycle
+description: "Use when starting or continuing a YSS product/module/project through opportunity exploration, discovery, business/functional/system/data architecture artifacts, PRD baseline, product design/prototype/interaction design, PRD calibration, OpenAPI Draft/Freeze, engineering baseline, architecture, design review, vertical slices, YSS frontend/backend delivery, review, release, implementation, or retrospective; or when deciding missing artifacts, lifecycle stage, next prompt, or Matt/YSS skill routing."
+---
+
+# YSS Product Lifecycle
+
+Use this skill as the project-level entrypoint for product-to-engineering flow. It routes work across lifecycle artifacts and specialist skills; it does not replace Matt Pocock Engineering Skills, `yss-router`, `yss-ui`, `yss-domain`, or other specialist skills.
+
+## Core Rule
+
+Determine the current lifecycle stage before proposing work. If implementation is requested but upstream artifacts are missing, identify the gap and route to the right artifact or specialist skill first.
+
+For a small requirement change or iteration on an existing feature, do not restart the full lifecycle. First assess the impact radius, identify the nearest trustworthy stage already covered by current artifacts, then extend only the affected stage and required downstream gates. Re-enter earlier stages only when the change invalidates their assumptions.
+
+## Documentation Language
+
+For this repository, persistent lifecycle artifacts MUST use Chinese body text by default, because the primary users and reviewers are Chinese readers. This includes discovery notes, PRD, product design, architecture, OpenAPI review/freeze notes, vertical slice issues, Matt skill outputs, review reports, release notes, implementation records, retrospectives, and Git checkpoint explanations.
+
+Keep English identifiers unchanged when they are technical names: file paths, commands, class/method names, API paths, schema names, enum values, error codes, frontmatter keys, YAML/JSON keys, and metadata identifiers. If an upstream skill template uses English section titles, convert the persisted project document to Chinese section titles unless the user explicitly asks for English or the document targets an English-speaking audience.
+
+Daily execution uses 8 main stages. The previous 21 stage names are governance gates / responsibility points, not a mandatory step-by-step flow for every request. The authoritative mapping of stages, artifacts, templates, and required / conditional gates is `docs/process/lifecycle-artifact-map.md`.
+
+```text
+intake / lifecycle triage
+-> opportunity and Discovery
+-> business / PRD / functional architecture
+-> product design and requirement freeze
+-> system / data architecture, engineering contract, and Design Review
+-> contract freeze and Issue formalization
+-> vertical slices and TDD implementation
+-> verification, release, and retrospective
+```
+
+## Matt Skills Coordination
+
+Use this lifecycle skill to decide the stage and route to the right workflow. Do not use it as a substitute for specialist skills.
+
+| Layer | Owner | Responsibility | Canonical artifacts |
+|---|---|---|---|
+| Product / requirements | `competitive-intelligence`, `grill-with-docs`, `to-prd` | Clarify market / competitor facts, users, pain, boundaries, acceptance criteria, and PRD scope | `CONTEXT.md`, `docs/adr/`, `docs/discovery/`, `docs/requirements/<feature>-prd.md` |
+| Contract | OpenAPI / YSS API skills, OpenSpec-style Spec Delta | Define and freeze frontend/backend API contracts, plus behavior deltas for medium/high-risk changes | `docs/api/specs/*.yaml`, `docs/specs/<feature>-spec-delta.md`, OpenAPI Draft Review / Freeze records |
+| Delivery planning | `to-issues`, Issue tracker | Split PRD / frozen contract into end-to-end vertical slices | GitLab / GitHub Issues or `docs/requirements/issues/*` |
+| Implementation | `implement`, `tdd`, `diagnosing-bugs`, `code-review` | Build with feedback loops, bug diagnosis, independent review, and fresh verification | tests, review reports, verification records, implementation notes |
+| YSS engineering | `yss-router` and selected YSS skills | Apply YSS DDD, UI, DTO, Repository, Controller, OpenAPI, and component rules | implementation routing record, Build Architecture Checklist, code/test evidence |
+
+Rules:
+
+- Prefer Matt skills for generic engineering workflow: `grill-with-docs`, `to-prd`, `to-issues`, `implement`, `tdd`, `diagnosing-bugs`, `code-review`, `domain-modeling`, `codebase-design`, and `improve-codebase-architecture`.
+- Use `competitive-intelligence` when market, competitor, pricing, positioning, or customer sentiment facts are needed before Discovery / PRD decisions.
+- Preserve OpenAPI 3.1 Draft / Freeze as the API contract gate. Draft is review-only until Freeze.
+- Use OpenSpec-style Spec Delta for API, permission, state-machine, data-model, cross-client, new-module, or high-risk behavior changes. It is a lightweight behavior-delta artifact, not OpenSpec CLI, change-state files, or an extra state machine.
+- After OpenAPI Freeze, route to `to-issues` or an equivalent vertical-slice issue record; do not require extra state-machine artifacts.
+- Before frontend/backend implementation, first decide whether the impacted frontend/backend runtime projects already exist and can be reused. If an impacted side has no reusable project yet, route to `yss-ddd-scaffold-generator` or `yss-frontend-scaffold-generator` before business implementation.
+- Use `yss-router` before frontend/backend implementation when the task crosses multiple YSS areas. The route output becomes implementation guidance inside the current slice.
+- Use `code-review` or an independent review agent before merge/release decisions.
+- Require fresh verification evidence before claiming completion.
+
+## Architecture Artifact Ladder
+
+Architecture artifacts are produced progressively. Do not try to finish every architecture document on day one, but do not enter implementation when the artifact required by the current risk is missing.
+
+| Artifact | Lifecycle timing | Primary question | Typical outputs | Diagram support |
+|---|---|---|---|---|
+| Business architecture | Opportunity exploration / Discovery / product definition | Who gets value, in which workflow, and where the product boundary sits | user journey, value stream, role/ecosystem model, capability map | journey map, swimlane, capability map |
+| Product overview design / Functional architecture | PRD baseline / product design / PRD calibration | Which product capabilities, user flows, modules, pages, APIs, and data impacts support the MVP boundary | product overview, module map, feature list, priority, dependencies, state flow, open questions, PRD gaps | feature/module map, dependency graph, user flow, page map |
+| System overview design / System architecture | Engineering baseline / architecture review | How the product is built, deployed, integrated, operated, and safely evolved | C4/container view, service boundary, integration, deployment, NFR decisions, rollout/rollback decisions | system architecture, sequence, deployment, DFD |
+| Data architecture | Detailed design before persistence and repository work | How domain data, metadata, versions, lineage, and queries are modeled and stored | conceptual/logical/physical model, meta-model, versioning strategy, lineage/query/index strategy | ER, class, lineage graph, DFD |
+
+For data modeling, metadata management, ER design, versioning, or lineage-analysis products, data architecture is a core product design artifact. It must be explicit before persistence implementation and before OpenAPI Freeze when API schemas depend on the meta-model.
+
+Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, data structures, or slice dependencies easier to review. Diagrams support the text artifacts; they do not replace PRD, OpenAPI, ADR, issues, or tests.
+
+## Workflow
+
+1. Inspect existing context before asking questions:
+   - `CONTEXT.md`
+   - `docs/discovery/` and `docs/discovery/reports/`
+   - `docs/requirements/`
+   - `docs/design/`
+   - `docs/api/specs/`
+   - `docs/architecture/` and `docs/adr/`
+   - `docs/requirements/issues/` and current issue tracker state when available
+2. Classify the request into one main stage:
+   - intake / lifecycle triage, opportunity and Discovery, business / PRD / functional architecture, product design and requirement freeze, system / data architecture, engineering contract, and Design Review, contract freeze and Issue formalization, vertical slices and TDD implementation, or verification / release / retrospective.
+3. For small changes or iterations, identify the nearest trustworthy existing stage and only expand from the earliest impacted artifact:
+   - wording / style / local configuration -> direct minimal change, then verify;
+   - UI behavior or page state -> product design / prototype review / PRD calibration as needed;
+   - API request, response, error, permission, pagination, or concurrency -> system / data architecture, engineering contract, and Design Review with API impact analysis / contract draft / OpenAPI Draft Review / Freeze downstream gates;
+   - service boundary, state machine, integration, NFR, rollout, or rollback -> system / data architecture, engineering contract, and Design Review downstream gates;
+   - persistence, metadata, versioning, lineage, query, or index -> system / data architecture, engineering contract, and Design Review downstream gates.
+4. Check whether required upstream artifacts exist.
+   - Before formal vertical slicing, verify PRD, OpenAPI Freeze or no-API-impact record, architecture review as needed, and a clear issue destination.
+   - For medium/high-risk API, permission, state-machine, data-model, cross-client, new-module, or safety-sensitive changes, verify an OpenSpec-style Spec Delta exists or record why it is not needed.
+   - Before frontend/backend implementation, verify vertical slice scope, implementation repo/location, whether the impacted frontend/backend runtime projects already exist and are reusable, YSS skill routing, Build Architecture Checklist, test command, and review strategy.
+5. Output the next action:
+   - artifact to create/update,
+   - specialist skill to invoke,
+   - suggested prompt,
+   - acceptance checklist.
+6. For every completed lifecycle stage, perform a Git checkpoint decision:
+   - identify the exact artifacts created or changed in that stage,
+   - separate product/process artifacts from unrelated workspace changes,
+   - propose or execute a scoped `git add` / `git commit` / `git push` when the user has already authorized committing,
+   - record if a checkpoint is intentionally deferred and why.
+7. Stop before writing business code. For implementation, route through `yss-router` and the selected specialist skills.
+
+## Stage Git Checkpoints
+
+Lifecycle artifacts are part of the product record, not scratch notes. Do not let PRD, design, OpenAPI, architecture, review, issue, or retrospective outputs remain only in the local worktree across multiple stages.
+
+At the end of each stage, report:
+
+```markdown
+### Git Checkpoint
+- Changed artifacts: <files or directories>
+- Excluded changes: <unrelated dirty files or "none">
+- Commit status: <committed / pushed / deferred>
+- Reason if deferred: <why>
+```
+
+When committing, prefer small checkpoint commits by artifact type or stage, for example:
+
+- `docs: add data modeling discovery and prd artifacts`
+- `docs: add data modeling openapi and architecture reviews`
+- `docs: update lifecycle checkpoint rules`
+
+Never stage broad dirty directories by default. Use explicit paths and keep generated environment folders, local tool caches, or unrelated user changes out of lifecycle commits unless the user explicitly asks to include them.
+
+## Specialist Routing
+
+Use these references as needed:
+
+- Lifecycle stage decisions: `references/stage-routing.md`
+- YSS skill selection: `references/yss-skill-routing.md`
+- Artifact checklist: `references/artifact-checklist.md`
+
+Default routing:
+
+| Intent | Next skill / workflow |
+|---|---|
+| Start a new business product/module | intake -> opportunity and Discovery -> `competitive-intelligence` when market / competitor facts are needed -> `grill-with-docs` -> `to-prd` -> business / PRD / functional architecture -> product design and requirement freeze when UI exists |
+| Analyze competitors, substitute workflows, pricing, positioning, or market facts | `competitive-intelligence`; then feed stable findings into `grill-with-docs` and `to-prd` |
+| Design UI flow after PRD baseline | `product-design-prototype`; add `wireframe-prototype`, `component-story-prototype`, or `mock-api-prototype` only when needed |
+| Review prototype before PRD calibration | `prototype-review` |
+| Review contract draft / OpenAPI Draft inside architecture/design review | `yss-openapi-draft-review` |
+| Record behavior deltas for medium/high-risk changes | OpenSpec-style Spec Delta at `docs/specs/<feature>-spec-delta.md` using `docs/templates/spec-delta-template.md` |
+| Clarify architecture artifact timing or gaps | this skill plus `docs/process/lifecycle-artifact-map.md` and `references/artifact-checklist.md` |
+| Create architecture/process/data diagrams | `excalidraw-diagram-generator` as a support skill |
+| Design meta-model / metadata / lineage data architecture | architecture/design workflow plus `yss-domain-modeling` or `yss-domain`; use `excalidraw-diagram-generator` for ER, lineage, DFD, or class diagrams when helpful |
+| Split delivery scope after PRD / OpenAPI Freeze | `to-issues`; record whether impacted frontend/backend projects already exist, and whether scaffold initialization is needed |
+| Implement a slice | first check impacted frontend/backend project existence; route missing backend to `yss-ddd-scaffold-generator`, missing frontend to `yss-frontend-scaffold-generator`, then use `implement` plus `tdd`; use `yss-router` first when multiple YSS areas are touched |
+| Fix a bug or test failure | `diagnosing-bugs` then `tdd` |
+| Review implementation | `code-review` plus YSS-specific review inputs |
+| Build Vue page | `yss-ui` plus related frontend skills chosen by `yss-router` |
+| Build backend module from scratch | `yss-ddd-scaffold-generator` |
+| Model backend domain | `yss-domain` / `yss-backend-scaffold-domain` |
+| Implement persistence | `yss-repository` plus `yss-mybatis` when data architecture and domain metadata are stable |
+| Implement Web adapter | `yss-web-controller` |
+
+## When Not To Use
+
+- For a single YTable height/layout issue, use `yss-use-table-height` directly.
+- For a single Repository / PO / Convertor / GatewayImpl task with stable domain metadata and data architecture, use `yss-repository` directly.
+- For a request that only asks to run a specific Matt skill and already has the needed lifecycle artifacts, use that Matt skill directly.
+
+## Output Contract
+
+When used for planning or routing, respond with:
+
+````markdown
+### 当前阶段
+<one lifecycle stage>
+
+### 阶段判定依据
+- <signals and artifacts used to infer the stage>
+
+### 已有资产
+- <found artifacts>
+
+### 缺失资产
+- <missing artifacts or "无">
+
+### 是否阻塞
+- <blocked / not blocked and why>
+
+### 下一步
+- <one recommended next action>
+
+### 推荐技能
+- <minimal skill list>
+
+### 可直接使用的提示词
+```text
+<prompt>
+```
+````
+
+When the user explicitly asks for a full delivery plan, include stage-by-stage tasks and acceptance checks, but keep each stage tied to concrete project artifacts.
+
+## Guardrails
+
+- Do not skip opportunity exploration for new product/module work; use `competitive-intelligence` when market/competitor facts are needed, or record why it is not needed.
+- Do not treat Discovery outputs as frozen downstream design. Discovery can provide product capability guidance and downstream impact signals, but PRD, functional architecture, OpenAPI, system architecture, and data architecture still require their own gates.
+- Do not start implementation before PRD is calibrated, required architecture artifacts are explicit, product design / prototype / interaction design exists and passes `prototype-review` when UI exists, OpenAPI Freeze decision, engineering baseline, design review, and vertical slice are clear.
+- Do not start implementation before deciding whether the impacted frontend/backend runtime projects already exist and can be reused. Missing or conflicting runtime projects must route back to implementation routing and scaffold initialization first.
+- Do not skip business architecture for new products unless the product boundary, users, ecosystem, and value stream are already captured elsewhere.
+- Do not skip functional architecture before PRD calibration when module boundaries, MVP priority, or cross-module dependencies are still unclear.
+- Do not skip system architecture when services, deployment, integrations, performance, security, reliability, or operations are affected.
+- Do not skip data architecture before persistence / repository work. For data modeling, metadata, versioning, or lineage products, treat it as mandatory before Design Review and OpenAPI Freeze.
+- Do not let Excalidraw diagrams invent requirements or architecture decisions; diagrams must point back to source artifacts and any findings must be written back to PRD, OpenAPI, ADR, or issues.
+- Do not treat an OpenAPI Draft as an implementation or generated-client contract before OpenAPI Freeze. It is review-only until engineering baseline, system/data architecture, Design Review, and Freeze have approved it.
+- Do not treat OpenSpec-style Spec Delta as a replacement for PRD, OpenAPI, Design Review, or vertical slice Issues. It only captures behavior differences, acceptance scenarios, and test / verification mapping.
+- Do not require Spec Delta for small wording, local style, configuration, or low-risk bug fixes unless the change expands into API, permission, state-machine, data-model, cross-client, or security impacts.
+- Do not move an OpenAPI Draft into Engineering Baseline / YSS DDD Review until `yss-openapi-draft-review` or an equivalent persistent review verifies P0 feature coverage, page action to endpoint mapping, YSS response wrappers, error structures, permissions, concurrency, security red lines, and contract test seams.
+- Do not route directly to frontend/backend skills before `yss-router` when the task crosses multiple YSS areas.
+- Do not generate production code from this skill; hand off to the selected specialist skill.
+- Treat TDD as the default for business behavior implementation; generated code, configuration, or throwaway prototypes may use a documented exception with a verification command.
+- Require independent review and fresh verification evidence before calling work complete.
+- Flag security red lines from `AGENTS.md` as human-review items.

package/template/.codex/skills/yss-product-lifecycle/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "YSS Product Lifecycle"
+  short_description: "Route lifecycle work to YSS delivery skills"
+  default_prompt: "使用 $yss-product-lifecycle，帮我从产品全生命周期推进这个需求。"

package/template/.codex/skills/yss-product-lifecycle/references/artifact-checklist.md

@@ -0,0 +1,55 @@
+# YSS Lifecycle Artifact Checklist
+
+Use this checklist to decide whether the current request can move forward or must route back to an earlier lifecycle stage.
+
+## Artifact Readiness
+
+| Artifact | Typical location | Ready when |
+|---|---|---|
+| Domain context | `CONTEXT.md` | Key domain terms, actors, workflows, and invariants are clear enough for PRD / code naming |
+| Discovery | `docs/discovery/<feature>-discovery.md` or issue note | User, pain, why now, MVP, non-goals, and success criteria are explicit |
+| Competitive intelligence | `docs/discovery/reports/<feature>-competitive-intelligence.md`, `<feature>-competitive-matrix.md`, or issue note | Competitors / substitutes, evidence sources, feature / pricing / positioning comparison, confidence, and PRD implications are explicit |
+| PRD | `docs/requirements/<feature>-prd.md` or issue | User stories, acceptance criteria, out of scope, OpenAPI impact, test decisions, and human-review points are clear |
+| Business architecture | `docs/architecture/<feature>-business-architecture.md` or PRD section | User journey, value stream, roles, external systems, and capability map are clear |
+| Functional architecture | `docs/architecture/<feature>-functional-architecture.md` or PRD/design section | Product capabilities, module boundaries, priority, dependencies, and MVP scope are clear |
+| Product overview design | `docs/design/<feature>-product-overview-design.md` | Pages, flows, states, permissions, API candidates, and PRD gaps are clear |
+| Prototype / interaction review | `docs/design/<feature>-prototype-review.md` or issue comment | UI paths, empty/error/loading states, permission states, and API backflow list are reviewed |
+| API impact / OpenAPI Draft | `docs/api/specs/<feature>.yaml`, issue note, or API impact record | Request/response, wrappers, errors, pagination, permissions, concurrency, and contract test seams are reviewable |
+| OpenAPI Freeze | `docs/api/<feature>-openapi-freeze.md` or issue comment | Draft has been reviewed and marked stable for frontend/backend implementation |
+| Engineering baseline | `docs/architecture/<feature>-engineering-baseline-review.md` | YSS DDD module boundary, dependency direction, DTO/VO/CMD/Query conventions, and scaffold constraints are reviewed |
+| System architecture | `docs/architecture/<feature>-system-overview-design.md`, `<feature>-system-architecture.md`, or `<feature>-architecture.md` | Service/module boundaries, deployment, integration, security, performance, reliability, observability, rollout, rollback, and architecture review questions are clear |
+| Data architecture | `docs/architecture/<feature>-data-architecture.md` | Conceptual/logical/physical model, metadata, versioning, lineage, query, index, storage, and migration constraints are clear |
+| Design review | `docs/architecture/<feature>-architecture-review.md` or issue comment | Open questions, risks, safety red lines, and implementation constraints have an explicit review outcome |
+| Vertical slice Issue | GitLab / GitHub Issue or `docs/requirements/issues/<feature>-slice.md` | Slice is end-to-end, independently demoable/verifiable, and not split by technical layer only |
+| Implementation routing | `docs/requirements/issues/<feature>-implementation-routing.md` using `docs/templates/implementation-routing-template.md` or issue note | Required YSS skills, impacted frontend/backend project existence decision, scaffold initialization plan when needed, verification command, review strategy, and rollback points are clear |
+| Build Architecture Checklist | `docs/implementation/<feature>-build-architecture-checklist.md`, implementation plan, or issue note | Architecture constraints are bound to slice IDs and have status/evidence/follow-up |
+| Review report | MR / PR comment or `docs/requirements/issues/<feature>-review.md` | Independent review covers spec fidelity, coding standards, tests, contract alignment, and safety red lines |
+| Fresh verification | `docs/testing/<feature>-verification.md`, issue / MR comment, or release note | Verification command, timestamp, result, failures, and residual risks are recorded |
+| Release / rollout | `docs/releases/`, `docs/implementation/`, issue / MR comment | Release steps, rollback, monitoring, and user-facing notes are clear when applicable |
+| Retrospective | `docs/process/sprint-retros/` or issue note | Process learnings, architecture drift, review findings, and follow-up changes are captured |
+
+## Lifecycle Gate Checks
+
+- Discovery is enough to explain user, pain, MVP, non-goals, success criteria, and downstream UI/API/data/architecture impact.
+- Competitive intelligence uses current public evidence, separates facts from inference, and feeds PRD / MVP decisions instead of becoming requirements by itself.
+- PRD is enough to derive vertical slice acceptance tests and identify OpenAPI impact.
+- UI work with user-facing flows has product design, interaction states, and prototype review evidence.
+- API changes have OpenAPI Draft Review and Freeze evidence before implementation.
+- Persistence, metadata, versioning, lineage, query, or index changes have data architecture before Repository / MyBatis implementation.
+- Service boundary, integration, deployment, reliability, performance, or operations changes have system architecture before implementation.
+- Vertical slice Issues are end-to-end and independently verifiable.
+- Impacted frontend/backend runtime projects are confirmed to exist and be reusable before implementation; otherwise scaffold initialization is recorded and completed first.
+- `yss-router` has selected the minimal YSS implementation skills before frontend/backend implementation when multiple YSS areas are touched.
+- Build Architecture Checklist is established before implementing high-risk or architecture-sensitive slices.
+- Fresh verification evidence exists before any complete / merge / release claim.
+- Excalidraw diagrams, when used, are referenced by the corresponding Discovery, PRD, design, architecture, or issue artifact and do not stand alone as decisions.
+
+## Missing Artifact Response
+
+When an artifact is missing:
+
+1. Identify the earliest impacted lifecycle stage.
+2. State whether the missing artifact blocks implementation or can be lightweight.
+3. Route to the smallest useful skill or artifact.
+4. Give the user a ready-to-use prompt in Chinese.
+5. Record Git checkpoint status if any persistent artifact is created.

package/template/.codex/skills/yss-product-lifecycle/references/stage-routing.md

@@ -0,0 +1,78 @@
+# YSS Lifecycle Stage Routing
+
+Use this reference after reading current repo context. It maps request shape to the earliest useful lifecycle stage and the next skill.
+
+## Stage Routing Table
+
+| Stage | Use when | Inputs to inspect | Output | Next route |
+|---|---|---|---|---|
+| 1. Intake / lifecycle triage | 新需求、继续需求、Bug、小调整、流程不清、缺失资产判断 | User request, `CONTEXT.md`, docs, issues, git state | stage decision, nearest trustworthy artifact, minimal skill list | route to earliest impacted stage |
+| 2. Opportunity and Discovery | 模糊想法、竞品/市场输入、用户痛点尚不清楚 | discovery docs, market/user facts, stakeholder notes | user, pain, why now, MVP, non-goals, success criteria, downstream impact | `competitive-intelligence` when market / competitor facts are needed, then `grill-with-docs` / PRD |
+| 3. Business / PRD / functional architecture | 需要明确用户故事、验收标准、功能边界、模块依赖 | discovery, `CONTEXT.md`, ADRs, existing PRD | PRD, business architecture, functional architecture, PRD review notes | product design or contract design |
+| 4. Product design and requirement freeze | 有 UI、页面、交互、状态矩阵、权限状态、空/错/加载态 | PRD, design system, existing UI, component docs | product overview design, interaction spec, state matrix, prototype review, requirement freeze | contract and architecture review |
+| 5. System / data architecture, engineering contract, and Design Review | 接口、DTO、错误结构、后端新服务、新模块、DDD 分层、服务边界、部署、集成、状态机、权限、NFR、持久化、元模型、版本、血缘 | calibrated requirements, design inputs, API impact decision, engineering impact decision | API impact record; contract sketch or reviewable OpenAPI Draft marked draft-for-review; OpenAPI Draft Review; engineering baseline review; system overview; data architecture when required; ADR candidates; Design Review result | contract freeze and Issue formalization |
+| 6. Contract freeze and Issue formalization | OpenAPI Freeze、无 API 影响记录、正式拆分垂直切片 | Design Review approval, contract draft / OpenAPI Draft, PRD/design/architecture artifacts | OpenAPI Freeze or no API impact record; GitHub/GitLab/local vertical slice Issues | vertical slices and TDD implementation |
+| 7. Vertical slices and TDD implementation | issue、切片、实现、review、清理简化 | frozen contract / no API impact, approved slice, implementation repo/location | implementation routing, YSS skill routing, tests, review, verification evidence | verification, release, and retrospective |
+| 8. Verification, release, and retrospective | 准备合并、发布、归档、复盘、用户手册 | diff, tests, CI, review notes, release notes | fresh verification, release / rollback notes, retrospective, doc updates | next intake |
+
+## Routing Principles
+
+- Treat lifecycle opportunity exploration as product/MVP boundary work. Discovery may produce competitive analysis via `competitive-intelligence`, an opportunity statement, product capability guidance, and downstream impact signals, but it must not freeze PRD, final functional architecture, OpenAPI, data architecture, or technical system design.
+- Small iterations only expand from the earliest affected artifact. Do not rerun Discovery or PRD if a copy/style/config change has no API, state, permission, data, module boundary, or security impact.
+- If a small iteration only changes copy, local style, an existing option value, or documentation without touching API, state, permission, data, module boundary, or security red lines, route to direct minimal change plus verification.
+- API changes route through OpenAPI Draft Review and Freeze, then `to-issues`.
+- For implementation spanning frontend and backend, first check whether the impacted frontend/backend runtime projects already exist and can be reused; if not, route to scaffold initialization before `yss-router`.
+- If multiple PRDs or issues look relevant, ask the user which one to continue before planning work.
+
+## Required Inspection Before Implementation
+
+1. Inspect the relevant PRD, issue, OpenAPI Freeze or no-API-impact record, and architecture/design review when applicable.
+2. Confirm the implementation repo/location.
+3. Confirm whether each impacted frontend/backend runtime project already exists and is reusable; if not, route to `yss-ddd-scaffold-generator` or `yss-frontend-scaffold-generator`.
+4. Confirm `yss-router` output when frontend/backend/YSS areas are involved.
+5. Confirm Build Architecture Checklist and test command.
+6. Confirm review strategy and fresh verification evidence required.
+7. If any item is missing, route to the smallest artifact that fills the gap.
+
+## Prompt Examples
+
+### New feature
+
+```text
+使用 yss-product-lifecycle，判断 <feature> 当前生命周期阶段。
+请先检查现有 Discovery、PRD、设计、OpenAPI、架构和 Issue 资产，
+然后输出缺失资产、是否阻塞、下一步推荐 skill 和可直接使用的提示词。
+```
+
+### Competitive analysis
+
+```text
+使用 yss-product-lifecycle，判断 <topic> 是否需要先进入竞品分析。
+如果需要，请路由到 competitive-intelligence，输出研究问题、竞品范围、证据来源计划、
+竞品矩阵落点、PRD 输入和下一步 grill-with-docs / to-prd 衔接方式。
+```
+
+### API change
+
+```text
+使用 yss-product-lifecycle，评估 <feature> 的 API 影响。
+请判断是否需要 OpenAPI Draft、Draft Review、Freeze、to-issues，
+并列出进入实现前必须补齐的 YSS skill routing、测试命令和审查点。
+```
+
+### Existing slice implementation
+
+```text
+使用 yss-product-lifecycle，检查 <issue-or-feature> 的实现准备度。
+若 PRD、OpenAPI Freeze 或架构清单缺失，请路由回对应阶段；
+若已就绪，请先判断受影响的 frontend/backend 工程是否已存在且可复用；
+若缺失则路由到对应脚手架 skill，否则输出最小 YSS skill 集合、TDD 策略、review 策略和验证命令。
+```
+
+### Bug fix
+
+```text
+使用 yss-product-lifecycle，判断这个 bug 是否只需要 diagnosing-bugs + tdd，
+还是影响 API、权限、数据模型或架构边界。
+请输出最小复现入口、回归测试位置和 fresh verification 命令。
+```

package/template/.codex/skills/yss-product-lifecycle/references/yss-skill-routing.md

@@ -0,0 +1,56 @@
+# YSS Skill Routing Reference
+
+Use this reference after lifecycle stage and slice scope are clear. Pick the minimal set of YSS skills that match the impacted engineering area.
+
+## Common Routing
+
+| Intent / impact | Primary skill | Secondary skills / notes |
+|---|---|---|
+| Decide YSS implementation skills for a slice | `yss-router` | Use before frontend/backend implementation when multiple YSS areas are touched |
+| UI design, tokens, style consistency, Ant Design / YSS UI decisions | `yss-design-system` | Use before product design prototype or UI implementation |
+| Product page / module development | `yss-page-module-development` | Add `yss-ui`, `yss-components`, `api-integration` as needed |
+| YSS UI component usage | `yss-ui` | Use local examples first; then skill references |
+| YSS component selection / patterns | `yss-components` | Useful for tables, forms, buttons, modals, layout |
+| API client integration | `api-integration` | Requires stable API contract or clearly marked mock/prototype exception |
+| OpenAPI generation or review | `yss-openapi`, `yss-openapi-draft-review`, `yss-openapi-governance` | Draft is review-only until Freeze |
+| Backend service from scratch | `yss-ddd-scaffold-generator` | After implementation location decision; then baseline check |
+| Backend scaffold baseline | `yss-backend-scaffold-parent` | Required after generated backend skeleton and before business implementation |
+| Domain modeling / aggregate / state behavior | `yss-domain-modeling`, `yss-domain`, `yss-backend-scaffold-domain` | Use before repository/controller code when domain concepts are unstable |
+| Repository / PO / Convertor / GatewayImpl | `yss-repository` | Add `yss-mybatis` / `yss-backend-scaffold-infrastructure` for mapper/persistence details |
+| Web controller / DTO / VO / Web Convertor | `yss-web-controller`, `yss-dto`, `yss-backend-scaffold-web` | Requires OpenAPI Freeze or no-API-impact record |
+| Java coding style and review | `alibaba-java-code-style` | Treat blockers as review blockers |
+| SQL condition/template/query utilities | `yss-sql-condition`, `yss-sql-tpl` | SQL red line still requires human review for native SQL |
+| Audit log | `yss-audit-log` | Security and traceability impacts must be recorded |
+| Cache | `yss-cache` | Include invalidation and consistency strategy |
+| File upload/download | `yss-file` | Include temporary URL, permission, and cleanup considerations |
+| Distributed ID | `yss-distributed-id` | Use for identifier strategy, not ad hoc ID generation |
+| Dictionary / variable / validation | `yss-dictionary`, `yss-variable`, `yss-validation` | Use for shared business metadata and validation |
+
+## Routing Rules
+
+- Do not route directly to frontend/backend implementation skills before `yss-router` when the task crosses multiple YSS areas.
+- Do not use backend implementation skills before required PRD, OpenAPI Freeze/no-impact record, architecture/data design, and Build Architecture Checklist are ready for the slice.
+- Do not use Repository / MyBatis skills before data architecture and domain metadata are stable enough to review.
+- Do not use Controller / DTO skills before OpenAPI contract is frozen or explicitly marked as no API impact.
+- Do not use UI implementation skills before `yss-design-system` and product design/prototype review when user-facing workflow is affected.
+- For bugs, start with `diagnosing-bugs`; route to YSS skills only after the failing feedback command points to the impacted area.
+
+## Handoff Prompt Template
+
+```text
+请使用 yss-router 为 <slice> 选择最小 YSS skill 集合。
+
+已知资产：
+- PRD / Issue: <path-or-link>
+- OpenAPI Freeze / no API impact: <path-or-link>
+- Architecture / data design: <path-or-link>
+- Build Architecture Checklist: <path-or-link>
+- Implementation repo/location: <repo-or-path>
+
+请输出：
+1. 必须加载的 YSS skills
+2. 可选 skills 与触发条件
+3. TDD / 验证命令
+4. 人审点和 TODO-HUMAN-REVIEW
+5. 不应触碰的范围
+```

package/template/.codex/skills/yss-quality/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: yss-quality
+description: 用于 YSS quality starter、质量任务 Feign、任务执行详情、质量任务查询、YssCloudQualityFeign 和质量组件接入排障。
+---
+
+# yss-quality
+
+Use this skill for YSS 质量组件. Keep implementation grounded in the local project and resolvable YSS backend component source.
+
+中文说明：本技能用于 YSS 质量组件。执行时优先读取源码索引，避免凭记忆猜类名、配置项或接入方式。
+
+## Source Index First
+
+- Backend source location is environment-specific; resolve it with `yss-source-index/references/source-location.md`.
+- Generated index: `references/source-index.md`
+- Component path hints: `yss-microservice-components/yss-component-quality-starter`
+
+Read `references/source-index.md` as a path-hint index whenever the task depends on exact modules, annotations, auto configuration, properties, controllers, clients, repositories, DTOs, handlers, or troubleshooting.
+
+## Workflow
+
+1. Identify whether the task is quality task query, task execution detail, SQL data query, retry, custom config update, Feign integration, or result/log troubleshooting.
+2. Read `references/source-index.md`, then inspect common DTO/VO contracts and `YssCloudQualityFeign`.
+3. For consumers, prefer the Feign module and `YssCloudQualityAutoConfiguration`.
+4. Use common request/response models such as `TaskExecuteDetailReq`, `TaskQuerySqlDataReq`, `TaskRetryReq`, `TaskQueryResp`, and `TaskExecResultVo`.
+5. Keep pagination/result contracts aligned with `Page` and `RetResult`.
+
+## Capability Split
+
+- `yss-component-quality-common`: DTOs, query/command models, result/page VO, status constants.
+- `yss-component-quality-feign`: `YssCloudQualityFeign` and auto-configuration.
+
+## Checklist
+
+- Required dependency or starter module is present.
+- Feign client points to the correct quality service.
+- Retry and custom config updates use existing command models.
+- Task logs/details/SQL data queries use the correct request DTO.
+- Response mapping preserves `RetResult` and pagination semantics.
+
+## Do Not
+
+- Do not invent class names or configuration keys without checking the source index.
+- Do not replace component extension points with business-local framework code.
+- Do not broaden the task into unrelated YSS components unless the user asks.

package/template/.codex/skills/yss-quality/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "yss-quality"
+  short_description: "YSS component skill for yss-quality"
+  default_prompt: "Use yss-quality for this YSS backend component task."

package/template/.codex/skills/yss-quality/references/source-index.md

@@ -0,0 +1,45 @@
+# yss-quality Source Index
+
+Generated: 2026-06-29T16:11:14+00:00
+Indexed source root: resolved at refresh time; set `YSS_SOURCE_ROOT` to reproduce or refresh.
+
+This file is generated by `yss-source-index/scripts/refresh-yss-skill-index.py`. Do not hand-edit generated sections.
+
+Paths below are source path hints captured at refresh time. If they do not exist in the current workspace, locate sources using `YSS_SOURCE_ROOT`, CodeGraph, package/class names, Maven artifact names, or repository search before assuming the source is unavailable.
+
+## Component Path Hints
+
+- `yss-microservice-components/yss-component-quality-starter` (existed when indexed)
+
+## Documentation Files
+
+- No component documentation files found.
+
+## Maven Modules
+
+- `yss-microservice-components/yss-component-quality-starter`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-feign`
+
+## Key Java Entry Points
+
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/constant/DmStatus.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/dto/cmd/CustomConfigUpdateReq.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/dto/cmd/TaskRetryReq.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/dto/query/TaskExecuteDetailReq.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/dto/query/TaskQuerySqlDataReq.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/Page.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/RetResult.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/TaskExecResultVo.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/TaskExecuteDetailResp.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/TaskQueryLogReq.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/TaskQueryResp.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-common/src/main/java/com/yss/cloud/quality/vo/TaskQuerySqlDataResp.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-feign/src/main/java/com/yss/cloud/quality/config/YssCloudQualityAutoConfiguration.java`
+- `yss-microservice-components/yss-component-quality-starter/yss-component-quality-feign/src/main/java/com/yss/cloud/quality/feign/YssCloudQualityFeign.java`
+
+## Recommended Next Reads
+
+- Start with the documentation files above when learning component usage.
+- Search the key Java entry points for annotations, auto configuration, properties, aspects, interceptors, handlers, and result objects before changing application code.
+- Prefer existing component extension points over rewriting framework logic in business modules.