create-yss-spec 3.3.1 → 3.3.4

package/template/.trae/skills/setup-matt-pocock-skills/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Setup Matt Pocock Skills"
-  short_description: "Configure a repo for the skills"
-policy:
-  allow_implicit_invocation: false

package/template/.trae/skills/setup-matt-pocock-skills/domain.md

@@ -1,37 +0,0 @@
-# Domain Docs
-
-How the engineering skills should consume this repo's domain documentation when exploring the codebase.
-
-## Before exploring, read these
-
-- **`CONTEXT.md`** — the single case-sensitive glossary at the Git repository root. Its `context_schema_version` must be supported. A missing root file, lowercase or nested replacement, duplicate, or map-based layout is `blocked` / `migration-required`, not an optional omission.
-- **`docs/adr/`** — if it exists, read ADRs that touch the area you're about to work in. This directory is created lazily when the first qualifying decision is accepted.
-
-When the repository exposes `scripts/verify-context-contract`, run it before creating or changing stable domain, product, architecture, implementation, review, release, or retrospective assets.
-
-## File structure
-
-Every YSS Git repository:
-
-```
-/
-├── CONTEXT.md
-├── docs/adr/
-│   ├── 0001-event-sourced-orders.md
-│   └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-Multiple business responsibility areas do not create additional glossary files. Each stable business term records its approved PascalCase `适用业务责任区`, and consumers reference it as `<ContextId>/<EnglishIdentifier>`. Use `Global/<EnglishIdentifier>` only for language that is genuinely shared across responsibility areas.
-
-## Use the glossary's vocabulary
-
-When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term and stable reference defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
-
-If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
-
-## Flag ADR conflicts
-
-If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
-
-> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_

package/template/.trae/skills/setup-matt-pocock-skills/issue-tracker-github.md

@@ -1,45 +0,0 @@
-# Issue tracker: GitHub
-
-Issues and specs for this repo live as GitHub issues. Use the `gh` CLI for all operations.
-
-## Conventions
-
-- **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
-- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
-- **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
-- **Comment on an issue**: `gh issue comment <number> --body "..."`
-- **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
-- **Close**: `gh issue close <number> --comment "..."`
-
-Infer the repo from `git remote -v` — `gh` does this automatically when run inside a clone.
-
-## Pull requests as a triage surface
-
-**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature requests; `/triage` reads this flag.)_
-
-When set to `yes`, PRs run through the same labels and states as issues, using the `gh pr` equivalents:
-
-- **Read a PR**: `gh pr view <number> --comments` and `gh pr diff <number>` for the diff.
-- **List external PRs for triage**: `gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments` then keep only `authorAssociation` of `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, or `NONE` (drop `OWNER`/`MEMBER`/`COLLABORATOR`).
-- **Comment / label / close**: `gh pr comment`, `gh pr edit --add-label`/`--remove-label`, `gh pr close`.
-
-GitHub shares one number space across issues and PRs, so a bare `#42` may be either — resolve with `gh pr view 42` and fall back to `gh issue view 42`.
-
-## When a skill says "publish to the issue tracker"
-
-Create a GitHub issue.
-
-## When a skill says "fetch the relevant ticket"
-
-Run `gh issue view <number> --comments`.
-
-## Wayfinding operations
-
-Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
-
-- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `gh issue create --label wayfinder:map`.
-- **Child ticket**: an issue linked to the map as a GitHub sub-issue (`gh api` on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
-- **Blocking**: GitHub's **native issue dependencies** — the canonical, UI-visible representation. Add an edge with `gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>`, where `<blocker-db-id>` is the blocker's numeric **database id** (`gh api repos/<owner>/<repo>/issues/<n> --jq .id`, _not_ the `#number` or `node_id`). GitHub reports `issue_dependencies_summary.blocked_by` (open blockers only — the live gate). Where dependencies aren't available, fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every blocker is closed.
-- **Frontier query**: list the map's open children (`gh issue list --state open`, scoped to the map's sub-issues / task list), drop any with an open blocker (`issue_dependencies_summary.blocked_by > 0`, or an open issue in the `Blocked by` line) or an assignee; first in map order wins.
-- **Claim**: `gh issue edit <n> --add-assignee @me` — the session's first write.
-- **Resolve**: `gh issue comment <n> --body "<answer>"`, then `gh issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.

package/template/.trae/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md

@@ -1,46 +0,0 @@
-# Issue tracker: GitLab
-
-Issues and specs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
-
-## Conventions
-
-- **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
-- **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
-- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
-- **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
-- **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
-- **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
-- **Merge requests**: GitLab calls PRs "merge requests". Use `glab mr create`, `glab mr view`, `glab mr note`, etc. — the same shape as `gh pr ...` with `mr` in place of `pr` and `note`/`--message` in place of `comment`/`--body`.
-
-Infer the repo from `git remote -v` — `glab` does this automatically when run inside a clone.
-
-## Merge requests as a triage surface
-
-**MRs as a request surface: no.** _(Set to `yes` if this repo treats external merge requests as feature requests; `/triage` reads this flag.)_
-
-When set to `yes`, MRs run through the same labels and states as issues, using the `glab mr` equivalents:
-
-- **Read an MR**: `glab mr view <number> --comments` and `glab mr diff <number>` for the diff.
-- **List external MRs for triage**: `glab mr list -F json`, then keep only MRs whose author is not a project member/owner (a contributor's MR, not a maintainer's in-flight work).
-- **Comment / label / close**: `glab mr note`, `glab mr update --label`/`--unlabel`, `glab mr close`.
-
-Unlike GitHub, GitLab numbers issues and MRs separately, so `#42` is unambiguous once you know which surface the maintainer means.
-
-## When a skill says "publish to the issue tracker"
-
-Create a GitLab issue.
-
-## When a skill says "fetch the relevant ticket"
-
-Run `glab issue view <number> --comments`.
-
-## Wayfinding operations
-
-Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
-
-- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `glab issue create --label wayfinder:map`. (On GitLab tiers with native epics, an epic may hold the map instead; a labelled issue works everywhere.)
-- **Child ticket**: an issue carrying `Part of #<map>` at the top of its description and labels `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
-- **Blocking**: GitLab's **native blocking link** — the canonical, UI-visible representation. Add it with the `/blocked_by #<n>` quick action, posted as a note (`glab issue note <child> --message "/blocked_by #<blocker>"`). Native blocking links are a Premium/Ultimate feature; on the free tier (or where unavailable) fall back to a `Blocked by: #<n>, #<n>` line at the top of the description. A ticket is unblocked when every blocker is closed.
-- **Frontier query**: `glab issue list -F json` scoped to the map's children, drop any with an open blocker — a native `blocked_by` link to an open issue (`glab api projects/:id/issues/:iid/links`), or an open issue in the `Blocked by` line — or an assignee; first in map order wins.
-- **Claim**: `glab issue update <n> --assignee @me` — the session's first write.
-- **Resolve**: `glab issue note <n> --message "<answer>"`, then `glab issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.

package/template/.trae/skills/setup-matt-pocock-skills/issue-tracker-local.md

@@ -1,66 +0,0 @@
----
-tracker:
-  platform: local-markdown
-  root: docs/.scratch
-  legacy_roots:
-    - .scratch
-    - docs/requirements/tickets
-  remote_mirror: false
----
-
-# Issue tracker: Local Markdown
-
-Issues and specs for this repo live as markdown files in `docs/.scratch/`.
-
-The persisted tracker configuration above is authoritative. A Git remote is a code host only; do not switch to GitHub or GitLab unless the project configuration is explicitly changed.
-
-The legacy roots above are read-only migration sources. New Local Markdown output must use `docs/.scratch/`; if legacy and canonical assets coexist, return `conflict` instead of overwriting either side.
-
-## Conventions
-
-- One feature per directory: `docs/.scratch/<feature-slug>/`
-- The spec is `docs/.scratch/<feature-slug>/spec.md`
-- Implementation issues are one file per ticket at `docs/.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` — never a single combined tickets file
-- Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
-- Comments and conversation history append to the bottom of the file under a `## Comments` heading
-
-## YSS lifecycle extension
-
-When `yss-product-lifecycle` is active, the same `docs/.scratch/<feature-slug>/` directory is the complete local feature package. Keep the Matt files above and use these lifecycle evidence directories:
-
-```text
-docs/.scratch/<feature-slug>/
-├── map.md
-├── plan/
-├── spec.md
-├── spec-delta/
-├── parent-ticket.md
-├── design/
-├── api/
-├── architecture/
-├── gates/
-├── verification/
-└── issues/01-<slug>.md
-```
-
-`parent-ticket.md` is the local functional parent Ticket. The lifecycle does not require a remote issue when `local-markdown` is the configured primary tracker. GitHub / GitLab URLs may be recorded as optional mirrors without changing local authority.
-
-## When a skill says "publish to the issue tracker"
-
-Create a new file under `docs/.scratch/<feature-slug>/` (creating the directory if needed).
-
-## When a skill says "fetch the relevant ticket"
-
-Read the file at the referenced path. The user will normally pass the path or the issue number directly.
-
-## Wayfinding operations
-
-Used by `/wayfinder`. The **map** is a file with one **child** file per ticket.
-
-- **Map**: `docs/.scratch/<effort>/map.md` — the Notes / Decisions-so-far / Fog body.
-- **Child ticket**: `docs/.scratch/<effort>/issues/NN-<slug>.md`, numbered from `01`, with the question in the body. A `Type:` line records the ticket type (`research`/`prototype`/`grilling`/`task`); a `Status:` line records `claimed`/`resolved`.
-- Wayfinder's `Status: claimed/resolved` is a temporary work state, not one of the five triage roles. Promote a child ticket to a canonical triage `Status:` before using it as a delivery Ticket.
-- **Blocking**: a `Blocked by: NN, NN` line near the top. A ticket is unblocked when every file it lists is `resolved`.
-- **Frontier**: scan `docs/.scratch/<effort>/issues/` for files that are open, unblocked, and unclaimed; first by number wins.
-- **Claim**: set `Status: claimed` and save before any work.
-- **Resolve**: append the answer under an `## Answer` heading, set `Status: resolved`, then append a context pointer (gist + link) to the map's Decisions-so-far in `map.md`.

package/template/.trae/skills/setup-matt-pocock-skills/triage-labels.md

@@ -1,15 +0,0 @@
-# Triage Labels
-
-The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
-
-| Label in mattpocock/skills | Label in our tracker | Meaning                                  |
-| -------------------------- | -------------------- | ---------------------------------------- |
-| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
-| `needs-info`               | `needs-info`         | Waiting on reporter for more information |
-| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
-| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
-| `wontfix`                  | `wontfix`            | Will not be actioned                     |
-
-When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
-
-Edit the right-hand column to match whatever vocabulary you actually use.

package/template/.trae/skills/tdd/SKILL.md

@@ -1,38 +0,0 @@
----
-name: tdd
-description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
----
-
-# Test-Driven Development
-
-TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.
-
-When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
-
-## What a good test is
-
-Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — "user can checkout with valid cart" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.
-
-See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
-
-## Seams — where tests go
-
-A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
-
-**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
-
-Ask: "What's the public interface, and which seams should we test?"
-
-When the shape of that interface is itself in question — how deep the module is, where the seam belongs, what the interface should expose — use the `/codebase-design` skill for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
-
-## Anti-patterns
-
-- **Implementation-coupled** — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
-- **Tautological** — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.
-- **Horizontal slicing** — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead — one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.
-
-## Rules of the loop
-
-- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
-- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
-- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.

package/template/.trae/skills/tdd/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "TDD"
-  short_description: "Test-driven red-green-refactor"

package/template/.trae/skills/tdd/mocking.md

@@ -1,59 +0,0 @@
-# When to Mock
-
-Mock at **system boundaries** only:
-
-- External APIs (payment, email, etc.)
-- Databases (sometimes - prefer test DB)
-- Time/randomness
-- File system (sometimes)
-
-Don't mock:
-
-- Your own classes/modules
-- Internal collaborators
-- Anything you control
-
-## Designing for Mockability
-
-At system boundaries, design interfaces that are easy to mock:
-
-**1. Use dependency injection**
-
-Pass external dependencies in rather than creating them internally:
-
-```typescript
-// Easy to mock
-function processPayment(order, paymentClient) {
-  return paymentClient.charge(order.total);
-}
-
-// Hard to mock
-function processPayment(order) {
-  const client = new StripeClient(process.env.STRIPE_KEY);
-  return client.charge(order.total);
-}
-```
-
-**2. Prefer SDK-style interfaces over generic fetchers**
-
-Create specific functions for each external operation instead of one generic function with conditional logic:
-
-```typescript
-// GOOD: Each function is independently mockable
-const api = {
-  getUser: (id) => fetch(`/users/${id}`),
-  getOrders: (userId) => fetch(`/users/${userId}/orders`),
-  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
-};
-
-// BAD: Mocking requires conditional logic inside the mock
-const api = {
-  fetch: (endpoint, options) => fetch(endpoint, options),
-};
-```
-
-The SDK approach means:
-- Each mock returns one specific shape
-- No conditional logic in test setup
-- Easier to see which endpoints a test exercises
-- Type safety per endpoint

package/template/.trae/skills/tdd/tests.md

@@ -1,77 +0,0 @@
-# Good and Bad Tests
-
-## Good Tests
-
-**Integration-style**: Test through real interfaces, not mocks of internal parts.
-
-```typescript
-// GOOD: Tests observable behavior
-test("user can checkout with valid cart", async () => {
-  const cart = createCart();
-  cart.add(product);
-  const result = await checkout(cart, paymentMethod);
-  expect(result.status).toBe("confirmed");
-});
-```
-
-Characteristics:
-
-- Tests behavior users/callers care about
-- Uses public API only
-- Survives internal refactors
-- Describes WHAT, not HOW
-- One logical assertion per test
-
-## Bad Tests
-
-**Implementation-detail tests**: Coupled to internal structure.
-
-```typescript
-// BAD: Tests implementation details
-test("checkout calls paymentService.process", async () => {
-  const mockPayment = jest.mock(paymentService);
-  await checkout(cart, payment);
-  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
-});
-```
-
-Red flags:
-
-- Mocking internal collaborators
-- Testing private methods
-- Asserting on call counts/order
-- Test breaks when refactoring without behavior change
-- Test name describes HOW not WHAT
-- Verifying through external means instead of interface
-
-```typescript
-// BAD: Bypasses interface to verify
-test("createUser saves to database", async () => {
-  await createUser({ name: "Alice" });
-  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
-  expect(row).toBeDefined();
-});
-
-// GOOD: Verifies through interface
-test("createUser makes user retrievable", async () => {
-  const user = await createUser({ name: "Alice" });
-  const retrieved = await getUser(user.id);
-  expect(retrieved.name).toBe("Alice");
-});
-```
-
-**Tautological tests**: Expected value restates the implementation, so the test passes by construction.
-
-```typescript
-// BAD: Expected value is recomputed the way the code computes it
-test("calculateTotal sums line items", () => {
-  const items = [{ price: 10 }, { price: 5 }];
-  const expected = items.reduce((sum, i) => sum + i.price, 0);
-  expect(calculateTotal(items)).toBe(expected);
-});
-
-// GOOD: Expected value is an independent, known literal
-test("calculateTotal sums line items", () => {
-  expect(calculateTotal([{ price: 10 }, { price: 5 }])).toBe(15);
-});
-```

package/template/.trae/skills/theme-token-usage/SKILL.md

@@ -1,123 +0,0 @@
----
-name: theme-token-usage
-description: 指导 Vue3 YSS UI 微应用业务页面、公共组件、原型还原和主题修复使用可动态换肤的 CSS/Ant Design Token，覆盖主色、hover/active/selected/focus、状态色、中性色、透明色派生和暗色模式；当新增或修改 .vue、style.less、内联样式、TS 渲染配置、SVG 色值，或审查硬编码 #hex/rgb/渐变时使用。
----
-
-# YSS UI 主题 Token 使用 Skill
-
-## 触发条件
-
-- 新增、重构或按原型实现 Vue3 业务页面、公共组件、布局、卡片、树、表格、表单、抽屉和详情页。
-- 修改 `.vue`、`.less`、`.css`、`.scss`、TS/TSX 渲染配置或 SVG 中的颜色、背景、边框、阴影、渐变。
-- 页面需要跟随主应用主题、JSP 预设主题、暗色模式或运行时主色切换。
-- 评审或修复 `#1677ff`、`#3371ff`、`rgb/rgba/hsl` 等硬编码色值。
-
-## 不适用场景
-
-- 只维护主题源文件中的默认值或主题预设，例如 `variables.less`、`store/theme.ts`、`config/themes.ts`。
-- 用户明确要求不可换肤的品牌插画、数据可视化固定色板或第三方资产原色；仍需在代码中注明固定色语义。
-- 只修改与视觉无关的类型、接口或纯业务逻辑。
-
-## 开发前检查
-
-1. 读取当前微应用的 `packages/src/styles/variables.less`、主题 store/config 和相近页面，确认真实 Token 名称与运行时同步逻辑。
-2. 确认主应用传入的 `colorPrimary` 最终是否同步到 Ant Design ConfigProvider、YSS CSS 变量和 VXE 变量。
-3. 搜索本次改动涉及的硬编码色值，覆盖 SFC style、`style.less`、内联 `style`、`:style`、TS 配置、SVG `fill/stroke`。
-4. 区分“主题消费代码”和“主题定义代码”；禁止机械替换主题源文件中的合法默认色板。
-
-> 变量在 `:root` 中声明，不代表它会随运行时主题更新。必须同时检查主题同步代码是否写入该变量。
-
-## Token 选择
-
-按以下优先级选值：
-
-| 语义 | 优先使用 | 兼容选择 |
-| --- | --- | --- |
-| 主色 | `var(--primary-color, #3371ff)` | `var(--yss-color-primary-6, #3371ff)` |
-| hover | `var(--primary-color-hover, #4096ff)` | `var(--yss-color-primary-5, #4096ff)` |
-| active | `var(--primary-color-active, #0958d9)` | `var(--yss-color-primary-7, #0958d9)` |
-| 成功/警告/错误/信息 | `--success-color` / `--warning-color` / `--error-color` / `--info-color` | 对应 `--yss-color-*-6` |
-| 正文/次要文字 | `--text-color` / `--text-color-secondary` | 使用项目已有语义 Token |
-| 容器/页面背景 | `--bg-color-container` / `--bg-color` | 使用项目已有语义 Token |
-| 边框/分割线 | `--border-color` / `--border-color-split` | 使用项目已有语义 Token |
-| 反色文字 | `--text-color-inverse` | 不直接写 `#fff` |
-
-需要主色透明背景、focus ring 或阴影时，从真实主色动态派生：
-
-```less
-background: color-mix(in srgb, var(--primary-color, #3371ff) 10%, transparent);
-box-shadow: 0 0 0 3px color-mix(in srgb, var(--primary-color, #3371ff) 15%, transparent);
-```
-
-仅当主题同步逻辑明确维护 `--primary-1` 时才可使用 `var(--primary-1)`。禁止用带蓝色 fallback 的 `var(--primary-1, rgba(...))` 冒充动态主题；变量未同步时，红色等主题仍会回落为蓝色。
-
-## 硬约束（禁止/必须）
-
-- 必须优先让 `YButton`、`YTable`、`YTree`、`YFormily` 和 Ant Design Vue 组件消费 ConfigProvider 主题；非必要不覆盖其主色样式。
-- 业务消费代码禁止直接写品牌蓝、主题红及其 hover/active/selected/focus 色阶，包括十六进制、`rgb/rgba/hsl`、渐变和阴影。
-- 必须使用语义 Token；禁止仅按“颜色长得接近”替换，例如把错误态改成主色。
-- `var()` fallback 必须与项目默认 Token 一致；fallback 只负责兼容，不得成为实际换肤来源。
-- 禁止在页面局部随意发明 `--primary-light` 等新变量。确需新增时，必须在统一主题源声明，并在运行时主题同步链路中更新。
-- 禁止对 CSS 变量使用 Less 编译期颜色函数，例如 `fade(@primary-color, 10%)`；`@primary-color` 指向 `var()` 时无法可靠计算。
-- 禁止写 `rgba(var(--primary-color), 0.1)`；十六进制 CSS 变量不能直接作为 `rgba()` 通道参数。
-- 固定数据可视化色板、品牌资产原色或遮罩色允许保留，但必须与换肤语义无关，并添加中文说明。
-- 新增交互样式时必须覆盖 default、hover、active、selected、focus、disabled 中实际存在的状态。
-
-## 标准代码骨架
-
-```less
-@import url('@/styles/variables.less');
-
-.module-card {
-  color: var(--text-color, rgba(0, 0, 0, 0.88));
-  background: var(--bg-color-container, #fff);
-  border: 1px solid var(--border-color-split, #f0f0f0);
-
-  &__link {
-    color: var(--primary-color, #3371ff);
-
-    &:hover {
-      color: var(--primary-color-hover, #4096ff);
-    }
-  }
-
-  &.is-selected {
-    color: var(--primary-color, #3371ff);
-    background: color-mix(in srgb, var(--primary-color, #3371ff) 10%, transparent);
-    border-color: var(--primary-color, #3371ff);
-  }
-
-  &:focus-visible {
-    outline: none;
-    box-shadow: 0 0 0 3px color-mix(in srgb, var(--primary-color, #3371ff) 15%, transparent);
-  }
-}
-```
-
-仅在 JS、图表或 Canvas 必须读取计算后色值时，优先使用 Ant Design Vue `theme.useToken()`；若消费微应用 CSS 变量，则通过 `getComputedStyle(document.documentElement)` 读取，不复制默认色板到业务常量。
-
-## 验证流程
-
-1. 扫描本次变更中的 `#hex`、`rgb/rgba`、`hsl/hsla`、渐变和 SVG 色值，逐项说明保留理由或替换为 Token。
-2. 至少使用默认主色和一个明显不同的主色（例如红色）验证页面。
-3. 检查文字、链接、图标、边框、背景、阴影以及 hover/active/selected/focus 状态是否同步变化。
-4. 项目支持暗色模式时，再验证正文、次要文字、容器背景和边框；不得只验证主色。
-5. 有原型截图时，主题适配与视觉还原必须同时通过，不能为像素接近而写死色值。
-
-## 交付检查清单
-
-- [ ] 已检查项目真实主题入口、Token 声明与运行时同步链路。
-- [ ] 业务页面未硬编码品牌色及其交互态色阶。
-- [ ] 主色透明态来自可动态更新的 Token，不依赖未同步的 `--primary-1` fallback。
-- [ ] 状态色、中性色、容器背景和边框使用正确语义 Token。
-- [ ] 已检查 SFC、Less、内联样式、TS 配置和 SVG，不只检查 `style.less`。
-- [ ] 已用至少两种差异明显的主题色验证实际效果。
-- [ ] 项目支持暗色模式时已完成暗色验收。
-- [ ] 保留的固定色值均有明确、合理的非换肤语义。
-
-## 失败兜底策略
-
-- 找不到 Token 时，先查项目 `variables.less`、主题 store/config 和 `llms-full.txt`；禁止猜测变量名。
-- 只有颜色值但没有语义 Token 时，先在统一主题源补充语义变量和运行时同步，再在页面消费。
-- 第三方组件不跟随主题时，优先通过 ConfigProvider/component token 或其官方 CSS 变量桥接；最后才使用受控的深度样式覆盖。
-- 浏览器目标不支持 `color-mix()` 时，在主题层生成并同步明确的透明态变量；不要在各页面散落固定透明色。

package/template/.trae/skills/theme-token-usage/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "YSS UI 主题 Token 使用"
-  short_description: "约束业务页面使用可动态换肤的主题 Token，禁止硬编码品牌色"
-  default_prompt: "使用 $theme-token-usage 检查并实现页面样式，确保主题色、状态色和明暗模式可动态切换。"

package/template/.trae/skills/to-questionnaire/SKILL.md

@@ -1,53 +0,0 @@
----
-name: to-questionnaire
-description: Turn a decision you can't fully answer into a questionnaire for someone else to fill in.
-disable-model-invocation: true
----
-
-Turn something the user can't answer alone into a **questionnaire** — a Markdown document they hand to one person to fill in async, or fill out together over a meeting. The recipient holds knowledge the user lacks; the questionnaire pulls it out of them.
-
-**Grill the send, not the subject.** Interview the user only about the _send_, which they can always answer: who it goes to, and what they need back. The questions in the document then target the **gap** between what the recipient knows and what the user needs.
-
-1. **Who is it going to?** Ask, in one exchange, the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
-
-2. **What do you need back?** Ask, in one exchange, the specific decisions or facts the user can't resolve alone and needs from this person. Done when you have a concrete list of what the user must walk away able to do or decide.
-
-3. **Write the questionnaire.** Draft questions aimed at the gap from steps 1–2, following the Document structure below. Write it to `to-questionnaire-<slug>.md` in the current directory (slug from the topic) and report the path. Done when the file exists and every item the user named in step 2 is covered by a question.
-
-## Document structure
-
-Frame the document as a **discovery questionnaire**: the user lacks context, the recipient holds it. Order questions most-important-first — async means you may only get one pass — and group them under `##` headings by theme once there are more than a handful. Write it using the template below.
-
-<questionnaire-template>
-
-# <Questionnaire title>
-
-**Purpose:** why this questionnaire exists and the decision riding on it.
-
-**From:** <the user> — **To:** <the recipient> — **How your answers will be used:** <where they go>
-
-## Context
-
-One paragraph orienting a recipient who wasn't in the user's head. Enough to answer well, not a page.
-
-## How to answer
-
-Deadline and rough effort. Partial answers and "I don't know" are useful — flag anything you're unsure of rather than skipping it.
-
-## <Theme heading>
-
-One `##` section per theme. Under each, its questions, most-important-first. Every question is one idea — never compound — with an answer stub directly beneath, and a one-line _why this matters_ only where the question could be misread or invite a throwaway answer.
-
-<question-example>
-### What load is the system expected to handle at launch?
-
-_Why this matters: it decides whether we provision for burst traffic now or defer it._
-
->
-</question-example>
-
-## Anything else?
-
-A closing catch-all: anything we didn't ask that we should know?
-
-</questionnaire-template>

package/template/.trae/skills/to-questionnaire/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "To Questionnaire"
-  short_description: "Front-load questions into a doc for someone to answer"
-policy:
-  allow_implicit_invocation: false