create-yss-spec 3.4.8 → 3.4.10

package/template/.codex/skills/data-analytics/skills/visualize-data/SKILL.md

@@ -11,7 +11,7 @@ Create quantitative visuals that are analytically sound, immediately readable, a
 
 ### User Context
 
-Mandatory pre-answer gate: Invoke `data-analytics:user-context` in preflight mode by loading [data-analytics:user-context](../user-context/SKILL.md) and running its preflight script before answering, searching connectors, retrieving evidence, creating artifacts, or drafting output. Do not look for a callable MCP tool named `data-analytics:user-context`. Use the returned `data_analytics_preflight` envelope as the source of truth for saved context, source-category mapping, semantic-layer registry, onboarding/final-response obligations, and conditional guidance; use saved context and semantic layers as source-selection inputs, not as substitutes for workflow-time reads from connected or provided sources. Do not read or reinterpret raw plugin state files unless preflight fails, declares required content omitted, local shell access is unavailable, or the user explicitly asks for raw state inspection.
+Mandatory pre-answer gate: Invoke `data-analytics:user-context` in preflight mode by loading [data-analytics:user-context](../user-context/SKILL.md) and using its read-only preflight before source selection. Reuse the already loaded envelope within the same workflow while the resolved state paths, file digests, request mode and source scope are unchanged; re-read on change, missing context or explicit inspection. Do not look for a callable MCP tool named `data-analytics:user-context`. Use the returned `data_analytics_preflight` envelope as the source of truth for saved context, source-category mapping, semantic-layer registry, onboarding/final-response obligations, and conditional guidance; use saved context and semantic layers as source-selection inputs, not as substitutes for workflow-time reads from connected or provided sources. Do not read or reinterpret raw plugin state files unless preflight fails, declares required content omitted, local shell access is unavailable, or the user explicitly asks for raw state inspection.
 
 ## Chart Selection
 
@@ -92,7 +92,7 @@ Concrete forms such as `highlighted multi-series line`, `Likert`, `pie`, `Pareto
 - In multi-area executive reports, repeated line charts are a smell. Use line charts only where the main question is continuous movement over time. Consider dot/lollipop or bar with reference for plan variance, stacked area or 100% stacked bar for mix, ranked bars or leaderboards for category comparisons, waterfall for additive drivers, heatmaps for cohort or matrix structure, and stage bars for ordered progression.
 - For one-slide-per-area executive reports, do a chart-family pass before writing the visual plan. Audit repeated families and require a rationale when multiple sections use the same family despite asking different questions.
 - If every visual in a report uses the same family, document the reason in the chart map and verify that no section is actually asking for status, mix, variance, or drivers.
-- Four or more all-line visuals fail the multi-chart report contract unless the report is redesigned with data-compatible alternatives or fewer visuals.
+- Repeated line charts are appropriate for comparable trends. Review readability and decision value; chart count or chart-family repetition alone is not a failure.
 
 ### Surface And Implementation
 
@@ -133,7 +133,7 @@ Concrete forms such as `highlighted multi-series line`, `Likert`, `pie`, `Pareto
 - For HTML artifacts, keep standalone charts on real grid footprints: `8 columns` by default, `6` minimum, `10` or `12` for complex charts, stacked vertically on mobile. Align multi-chart rows from the left/start edge.
 - Match HTML chart containers, legends, KPI strips, and notes to the same Data Viz System tokens as the surrounding report or dashboard. Remove unused multi-hue CSS variables when they are not rendered.
 - Use dark chart variants only when the containing artifact is dark. Inspect both light and dark variants for shipped branded web outputs.
-- For research charts, lock the blossom to the header's top-right corner. Omit it for third-party, partnership, and non-research charts.
+- Use a brand mark only when the user's selected brand profile requests it and supplies an authorized asset. Do not inject OpenAI or vendor branding by default.
 
 ### Quality Bar
 
@@ -152,6 +152,6 @@ Concrete forms such as `highlighted multi-series line`, `Likert`, `pie`, `Pareto
 - Exported SVG or HTML colors should match declared palette roots plus neutrals; remove unused multi-hue tokens unless documenting an intentional exception.
 - Chart scaffolding should stay quiet: no arbitrary colored backgrounds, gradients, decorative guides, inconsistent stroke widths, or decorative mark fills. Filled marks should keep keylines, and benchmark, calibration, and reference lines should use dark-neutral styling.
 - Titles, legends, and primary labels should use dark ink and share a clear header anchor. Numeric ticks and direct value labels should use mono styling where the template system calls for it.
-- Research charts should use the locked top-right blossom placement; third-party, partnership, and non-research charts should omit it.
+- Apply a brand mark only when the selected user brand profile requests and supplies it.
 - Before handoff, inspect the visual in the artifact readers will open and verify that it answers the stated analytical question, signs and scales are honest, labels fit at laptop and mobile widths, the color and non-color encoding is understandable, and the caption states metric, time window, and source when those are part of the visual.
 - Inspect the final report, slide, dashboard, notebook, widget, or HTML layout before handoff. Revise before delivery when any requirement above fails.

package/template/.codex/skills/data-analytics/src/analytics-app/App.tsx

@@ -2692,7 +2692,7 @@ const context = promptContext(manifest, snapshot, packageInfo);
 if (target === "site") {
 return `Publish this ${surface} app as a hosted Site Creator link.
 
-Use the current Data Analytics artifact as the source of truth. Create or reuse a Site Creator project for this ${surface}, materialize a Cloudflare Worker-compatible app that serves the current manifest, bounded snapshot, package metadata, and inline-safe source text through /api/manifest, /api/snapshot, /api/package, and /api/source-file, then deploy it through Site Creator. Preserve the rendered layout, charts, tables, source details, and narrative. Default access to workspace_all unless I explicitly ask for narrower access, and report the production URL plus the access mode.
+Use the current Data Analytics artifact as the source of truth. Create or reuse a Site Creator project for this ${surface}, materialize a Cloudflare Worker-compatible app that serves the current manifest, bounded snapshot, package metadata, and inline-safe source text through /api/manifest, /api/snapshot, /api/package, and /api/source-file, then deploy it through Site Creator. Preserve the rendered layout, charts, tables, source details, and narrative. Use the access scope I explicitly selected. If no access scope has been selected, keep the package local and ask for that publishing decision before deployment. Report the production URL and actual access mode only after successful deployment.
 
 If the local package files are unavailable from the context below, stop and ask for the report package or validated artifact payload rather than publishing an empty or stale report.
 

package/template/.codex/skills/data-analytics/src/analytics-app-core.md

@@ -58,7 +58,7 @@ Use this file after the selected delivery surface is an MCP Apps inline chart/ta
 - Do not rebuild the report as standalone HTML, inline CSS charts, or a separate one-off viewer. Hosted sharing is a packaging step for the current artifact, not a second rendering implementation.
 - Treat Site Creator exports as read-only reader surfaces by default: hide artifact editing controls and remove `Publish to Sites` from hosted export menus. Authoring should happen in the MCP artifact, followed by a new export/deploy.
 - Keep static HTML and PDF exports content-only: include the report or dashboard title, narrative, charts, tables, and source details, but omit the interactive top bar and app-only controls.
-- Keep Site Creator access at `workspace_all` by default unless the user explicitly requests narrower access.
+- Use the explicitly selected sharing audience; if none exists, preserve local/private output until sharing is requested.
 
 ## Encoding Rules
 

package/template/.codex/skills/diagnosing-bugs/SKILL.md

@@ -15,6 +15,10 @@ This skill has you show commands, outputs and captured artifacts. **Redact every
 
 If the redacted output is not enough to diagnose the bug, say so and ask the user.
 
+## Simple fixes and complex investigations
+
+When a bounded defect has confirmed inputs and a known public seam, run a direct reproducer, make the authorized minimal fix and run the regression check. Do not restart an interview, minimize an already minimal case, or invent extra hypotheses. Use the phases below when the cause, environment or reproduction is uncertain.
+
 ## Phase 1 — Build a feedback loop
 
 **This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.
@@ -83,11 +87,11 @@ Why bother: a minimal repro shrinks the hypothesis space in Phase 3 (fewer movin
 
 Done when **every remaining element is load-bearing** — removing any one of them makes the loop go green.
 
-Do not proceed until you have reproduced **and** minimised.
+Minimize further only while it removes meaningful uncertainty. Preserve representative conditions; do not spend effort proving every remaining element essential when the cause can already be tested directly.
 
 ## Phase 3 — Hypothesise
 
-Generate **3–5 ranked hypotheses** before testing any of them. Single-hypothesis generation anchors on the first plausible idea.
+Generate enough competing falsifiable hypotheses to distinguish plausible causes. For a clear, bounded defect one directly testable hypothesis can be sufficient; complex or ambiguous failures need alternatives, without a fixed count.
 
 Each hypothesis must be **falsifiable**: state the prediction it makes.
 

package/template/.codex/skills/formily-foundation/SKILL.md

@@ -79,7 +79,7 @@ const schema: ISchema = {
           'x-component': 'FormGrid',
           'x-component-props': { maxColumns: 3, minColumns: 1, minWidth: 260 },
           properties: {
-            name: { type: 'string', title: '名称', 'x-decorator': 'FormItem', 'x-component': 'Input', required: true },
+            name: { type: 'string', title: '名称', 'x-decorator': 'FormItem', 'x-component': 'Input', required: true, 'x-validator': [{ required: true, whitespace: true, message: '请输入名称' }] },
             submit: {
               type: 'void',
               'x-component': 'Submit',

package/template/.codex/skills/formily-step-flow/SKILL.md

@@ -100,6 +100,7 @@ const step1Schema = createStepSchema({
     type: 'string',
     title: '任务名称',
     required: true,
+    'x-validator': [{ required: true, whitespace: true, message: '请输入任务名称' }],
     'x-decorator': 'FormItem',
     'x-component': 'Input',
   },
@@ -173,7 +174,7 @@ const submitAll = async () => {
 </template>
 ```
 
-复杂页面把 schema、类型与步骤 hook 分别拆到 `constant.ts`、`hooks/useStepFlow.ts`，保持 `index.vue` 在 150 行以内。
+当 schema、步骤状态和页面编排难以独立理解或验证时，分别拆到 `constant.ts`、`hooks/useStepFlow.ts`；以职责清晰和状态可测试为准，不按固定行数拆分。
 
 ## 交付检查清单
 
@@ -191,4 +192,4 @@ const submitAll = async () => {
 - 状态串联错误时先收敛为单一 `reactive` 数据源，再检查每步 `v-model` 路径。
 - 确认页为空时检查是否错误绑定了独立 `step3`，应改为前序数据的 `computed` 聚合。
 - API 调用 reject 时只在 `finally` 恢复 loading，不重复弹出错误提示。
-- 步骤过多或主组件超过 150 行时，按阶段拆子组件和 `useStepXxx` hook。
+- 步骤职责交叉或状态难以验证时，按业务阶段拆子组件和 `useStepXxx` hook。

package/template/.codex/skills/frontend-commit/SKILL.md

@@ -15,7 +15,7 @@ description: "为前端改动生成提交信息、审查原子提交或修复 Gi
 ## 不适用场景
 
 - yss-ui 组件库仓库自身的提交与发版：回到 yss-ui 源仓库使用其 `categories.library` 提交流程；该类 skill 不随业务模板分发。
-- Java、Spring Boot、Maven、Gradle 后端仓库：使用 `../java-backend-commit/SKILL.md`。
+- Java、Spring Boot、Maven、Gradle 后端仓库：回交目标后端 profile 的 `java-backend-commit`；本 profile 不臆造跨目录链接。
 - 仅请求代码实现，不涉及提交信息或 `git commit` 操作。
 - 无代码改动，或改动内容与提交请求不匹配。
 - 合并提交、发布提交和自动依赖机器人提交：遵循仓库专用流程，不套用本技能的常规消息模板。
@@ -65,15 +65,15 @@ git ls-files --others --exclude-standard
 
 - type 默认从 `feat/fix/docs/style/refactor/perf/test/chore/revert/build/ci` 中选择，但仓库枚举优先。
 - scope 优先级为：仓库枚举 → monorepo 包或应用 → 业务模块 → 共享能力。使用小写 kebab-case；不要机械地以 `views`、`hooks` 或文件名作为 scope。
-- 标题使用英文 type/scope、ASCII `:` 和中文摘要；描述行为或价值，不写“修改文件”“更新代码”或单个文件名。
-- 默认将完整 header 控制在 72 个字符内；仓库存在更严格限制时服从仓库。标题末尾不加句号，不用 emoji 或全角冒号。
+- 标题使用仓库确定的 type/scope、分隔符和语言；无既定规则时默认英文 type/scope、ASCII `:` 和中文摘要；描述行为或价值，不写“修改文件”“更新代码”或单个文件名。
+- 默认将完整 header 控制在 72 个字符内；仓库配置了其他限制时服从该配置。标题末尾不加句号，不用 emoji 或全角冒号。
 - 简单单文件变更可以没有 body；多文件、非显然修复、重要功能或行为变化使用 body 解释做了什么、为什么以及如何验证。
 - 仅对真实不兼容变更使用 `!` 和 `BREAKING CHANGE:`；仅在已知编号或仓库要求时加入工单、DCO、`Signed-off-by` 等 footer，禁止编造。
 
 ### 4. 验证并提交
 
 1. 根据变更范围运行仓库已有的最小充分检查，例如相关单元测试、类型检查、lint 和构建检查；优先使用仓库脚本与当前包管理器。
-2. 通过 stdin 校验完整候选消息，而不只校验 header。使用仓库本地 commitlint 命令；退出码为 0 才继续。
+2. 通过 stdin 校验完整候选消息，而不只校验 header。仅在仓库实际采用 commitlint 时使用其本地命令并要求退出码 0；否则按现有 hook/贡献指南验证，不安装新工具。
 3. 仅暂存属于当前原子提交的明确路径或安全 hunks，再重新检查 `git diff --cached --check`、`--name-status` 和完整 staged diff。
 4. 执行正常 `git commit`，允许 hooks 运行。
 5. hook 若格式化或修改文件，重新检查 staged 与 working tree，确认实际提交内容没有漂移。
@@ -102,9 +102,9 @@ feat(data-push): 优化推送任务数据源与调度规则展示
 
 ## 交付检查清单
 
-- [ ] type 与 scope 通过仓库 resolved commitlint 校验，完整消息经 stdin 校验退出码为 0。
+- [ ] 完整消息通过仓库实际采用的提交校验；采用 commitlint 时记录 stdin 校验退出码 0。
 - [ ] scope 来自仓库枚举、包名或业务模块，未使用 `views`、`hooks`、`utils` 或文件名兜底。
-- [ ] 标题为英文 type/scope + ASCII 冒号 + 中文摘要，完整 header 不超过 72 字符。
+- [ ] 标题语言、type/scope 和长度符合仓库配置；无配置时才使用本技能回退格式。
 - [ ] 暂存区只包含当前原子提交的文件；lockfile 与对应 manifest 同提交。
 - [ ] 已运行与变更范围匹配的最小充分检查（相关测试、类型检查、lint）。
 - [ ] 提交后已核对 `git show --stat` 与 `git status --short`，并向用户报告 hash 与剩余改动。

package/template/.codex/skills/grilling/SKILL.md

@@ -23,6 +23,6 @@ Format a round like so:
 
 Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
 
-Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait.
+Finding _facts_ is your job, never the user's. When a frontier question needs an environment fact, look it up directly; delegate only when an independent bounded investigation can run usefully alongside other work — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait.
 
-The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
+Stop when decisions material to the agreed scope are settled, remaining uncertainty is explicit and the next action is authorized. Reuse existing confirmations; do not traverse irrelevant branches or re-ask settled questions. New material decisions still require a real user response.

package/template/.codex/skills/implement/SKILL.md

@@ -4,7 +4,7 @@ description: "Implement a piece of work based on a spec or set of tickets."
 disable-model-invocation: true
 ---
 
-Implement the work described by the user in the spec or tickets.
+This is an explicit compatibility entry. Before implementation, return to the active lifecycle orchestrator to verify repository identity, registered implementation paths, a current approved Slice Implementation Contract and applicable gates. Reuse existing approved inputs; do not restart planning merely because this entry was invoked. Implement only that contract and return artifacts, actual verification, drift and new impacts for acceptance. Do not approve the contract or upgrade Ticket state yourself. Template-source changes follow the template maintenance route instead of creating product assets.
 
 Use /tdd where possible, at pre-agreed seams.
 

package/template/.codex/skills/implementation-repo-onboarding/SKILL.md

@@ -22,13 +22,13 @@ description: Use when connecting an existing frontend, backend, fullstack, or ot
 4. 识别技术栈、包管理器、CI、测试命令、构建命令、OpenAPI 接入和设计 token 接入。
 5. 判定实现位置与 `repository_scope`：`external-repository` 记录真实项目根；`harness-apps` 与 `git-submodule` 只能使用 `apps/backend/<project>/` 或 `apps/frontend/<project>/`。`apps/backend/`、`apps/frontend/` 仅为容器，`app/backend/`、`app/frontend/` 及其子路径必须标记为阻断。gitlink（mode `160000`）必须登记为 `git-submodule` 和 `layout_policy: git-submodule-harness-apps`，不得写成 `harness-apps`。必须对照工作树：`git ls-files --stage`、`.gitmodules` 与声明 scope 不一致时阻断；缺少 `git_entry_mode: 160000` 不得把挂载点当普通目录。
 6. 按 `docs/templates/implementation-repo-registry-template.md` 输出实现仓库登记内容。`git-submodule` 必填 `gitmodules_name`、`gitlink_path`、`git_entry_mode`、`superproject_git_url` 和 `checkout_state`。`harness-apps` / `external-repository` 这些字段填 `不适用`。
-7. 列出 `known_gaps`、人审点、fresh verification 命令和需要回写到 Harness change / Issue / checkpoint 的信息。命中交付预检时，登记和工程基线补齐后重跑 `prepare`；将结构化诊断的责任来源和恢复入口纳入缺口清单，在初始化或构建前关闭当前阶段阻断。后续阶段证据尚未形成不能被当作本阶段失败；其他技术栈/不涉及该交付协议的接入记录不适用原因，不能冒充后端 v2 正例。空 gitlink、detached HEAD、`--force` 覆盖挂载点或缺少递归检出凭据时标记阻断。写入前必须看 `inspectWorkingTreeScope` / `implementationWriteViolation`：只接受对象结果且 `.writable === true` 才可写；字符串、`null` 或 `.writable !== true` 一律不可写。即使已正确登记为 `git-submodule`，空 gitlink 或 detached HEAD 也必须 `.writable === false`，不得当普通目录写文件或脚手架。
+7. 列出 `known_gaps`、人审点、fresh verification 命令和需要回写到 Harness change / Issue / checkpoint 的信息。命中交付预检时，登记和工程基线补齐后重跑 `prepare`；将结构化诊断的责任来源和恢复入口纳入缺口清单，在初始化或构建前关闭当前阶段阻断。后续阶段证据尚未形成不能被当作本阶段失败；其他技术栈/不涉及该交付协议的接入记录不适用原因，不能冒充后端 v2 正例。空 gitlink、detached HEAD、`--force` 覆盖挂载点或缺少递归检出凭据时标记阻断。需要转入已授权写入时，先按 [写范围核验](references/write-scope.md) 检查工具对象结果；只有 `.writable === true` 可写，其他形态或状态一律阻断。
 
 ## Baseline Checks
 
 | repo_role | 必查项 |
 |---|---|
-| backend | 构建工具、模块结构、测试命令、OpenAPI 产出、YSS DDD 基线、数据库 / 迁移红线 |
+| backend | 构建工具、模块结构、测试命令、OpenAPI 产出、已登记 DDD 或分层 MVC 对应的 YSS 工程基线、数据库 / 迁移红线 |
 | frontend | 包管理器、框架、路由、YSS UI / Ant Design、Orval / API client、设计 token、lint / type-check / build |
 | fullstack | 前后端边界、契约生成方式、独立测试命令、CI 阶段拆分 |
 | other | owner、构建 / 测试 / 发布命令、与 Harness change 的关系 |
@@ -39,7 +39,7 @@ description: Use when connecting an existing frontend, backend, fullstack, or ot
 - 不把实现仓库源码复制进 Harness 仓库；`git-submodule` 只能形成 gitlink，不能 copy / subtree 冒充。
 - 不把缺失命令编造为已存在；找不到时标记 `unknown` 或 `需人工确认`。
 - 不得把 `app/backend/`、`app/frontend/` 或 `apps/backend/`、`apps/frontend/` 容器根登记为可生成项目根。
-- 触碰认证、授权、SQL、迁移、加密、公共基础库 API 时标记 `TODO-HUMAN-REVIEW`。
+- 认证、授权、SQL、迁移、加密、公共基础库 API 按实际影响记录审批和证据缺口；仅缺少必要批准时标记 `TODO-HUMAN-REVIEW`，已有授权不因关键词重新审批。
 
 ## Output
 

package/template/.codex/skills/implementation-repo-onboarding/references/write-scope.md

@@ -0,0 +1,5 @@
+# 实现仓库写范围核验
+
+从只读接入进入已授权写入时读取。
+
+写入前必须看 `inspectWorkingTreeScope` / `implementationWriteViolation`：只接受对象结果且 `.writable === true` 才可写；字符串、`null` 或 `.writable !== true` 一律不可写。即使已正确登记为 `git-submodule`，空 gitlink 或 detached HEAD 也必须 `.writable === false`，不得当普通目录写文件或脚手架。

package/template/.codex/skills/improve-codebase-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: improve-codebase-architecture
-description: Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
+description: 显式分析代码结构的维护成本、模块边界与可测试性，提出有证据的重构候选。
 disable-model-invocation: true
 ---
 
@@ -10,7 +10,7 @@ Surface architectural friction and propose **deepening opportunities** — refac
 
 This command is _informed_ by the project's domain model and built on a shared design vocabulary:
 
-- Run the `/codebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use these terms exactly in every suggestion — don't drift into "component," "service," "API," or "boundary."
+- Run the `/codebase-design` skill for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use this analysis vocabulary without overriding CONTEXT or the project's component/service/API terminology.
 - The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
 
 ## Process
@@ -24,7 +24,7 @@ This command is _informed_ by the project's domain model and built on a shared d
 
 Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
 
-Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
+Inspect the bounded area directly; delegate an independent reading task only when useful parallel work exists. Note evidence of friction:
 
 - Where does understanding one concept require bouncing between many small modules?
 - Where are modules **shallow** — interface nearly as complex as the implementation?
@@ -34,11 +34,15 @@ Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — e
 
 Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.
 
-### 2. Present candidates as an HTML report
+### 2. Present candidates in the requested format
+
+Default to concise Markdown with grounded paths, tradeoffs and a small diagram when useful. Use the HTML branch below only when requested or when interaction materially aids comparison. Local/offline delivery uses bundled assets, not mandatory CDN dependencies.
+
+#### Optional HTML report
 
 Write a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from `$TMPDIR`, falling back to `/tmp` (or `%TEMP%` on Windows), and write to `<tmpdir>/architecture-review-<timestamp>.html` so each run gets a fresh file. Open it for the user — `xdg-open <path>` on Linux, `open <path>` on macOS, `start <path>` on Windows — and tell them the absolute path.
 
-The report uses **Tailwind via CDN** for layout and styling, and **Mermaid via CDN** for diagrams where a graph/flow/sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before/after visualisation**. Be visual.
+When an online HTML report is explicitly selected, Tailwind and Mermaid are optional tools for layout and diagrams where a graph/flow/sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals — use Mermaid when relationships are graph-shaped (call graphs, dependencies, sequences), and hand-built divs/SVG when you want something more editorial (mass diagrams, cross-sections, collapse animations). Each candidate gets a **before/after visualisation**. Be visual.
 
 For each candidate, render a card with:
 
@@ -57,7 +61,7 @@ End the report with a **Top recommendation** section: which candidate you'd tack
 
 See [HTML-REPORT.md](HTML-REPORT.md) for the full HTML scaffold, diagram patterns, and styling guidance.
 
-Do NOT propose interfaces yet. After the file is written, ask the user: "Which of these would you like to explore?"
+Do NOT propose interfaces yet. After presenting candidates, ask which unresolved design direction to explore only if that choice has not already been made.
 
 ### 3. Grilling loop
 

package/template/.codex/skills/java-backend-commit/SKILL.md

@@ -14,8 +14,8 @@ description: "为 Java 后端改动生成提交信息、审查原子提交或修
 
 ## 不适用场景
 
-- Vue、React 等前端或微前端仓库：使用 `../frontend-commit/SKILL.md`。
-- yss-ui 组件库仓库自身的提交与发版：使用 `../commit-linting/SKILL.md`。
+- Vue、React 等前端或微前端仓库：在目标前端 profile 使用已安装的 `frontend-commit`；本 profile 不臆造跨目录链接。
+- yss-ui 组件库仓库自身的提交与发版：遵循目标组件库已安装的提交规范；不存在对应 skill 时读取其贡献指南和 hooks。
 - 仅请求代码实现，不涉及提交信息或 `git commit` 操作。
 - 无代码改动，或改动内容与提交请求不匹配。
 - 合并提交、发布提交、自动依赖机器人提交和数据库基线发布：遵循仓库专用流程，不套用本技能的常规模板。
@@ -66,8 +66,8 @@ git ls-files --others --exclude-standard
 
 - type 默认从 `feat/fix/docs/style/refactor/perf/test/chore/revert/build/ci` 中选择，但仓库枚举优先。
 - scope 优先级为：仓库枚举 → Maven artifactId 或 Gradle 子项目 → 服务或限界上下文 → 跨模块能力。使用小写 kebab-case；不要仅使用 `controller`、`service`、`repository` 或类名。
-- 标题使用英文 type/scope、ASCII `:` 和中文摘要；描述业务、调用方或运维可感知的结果，不写“修改代码”或单个 Java 类名。
-- 默认将完整 header 控制在 72 个字符内；仓库存在更严格限制时服从仓库。标题末尾不加句号，不用 emoji 或全角冒号。
+- 标题使用仓库确定的 type/scope、分隔符和语言；无既定规则时默认英文 type/scope、ASCII `:` 和中文摘要；描述业务、调用方或运维可感知的结果，不写“修改代码”或单个 Java 类名。
+- 默认将完整 header 控制在 72 个字符内；仓库配置了其他限制时服从该配置。标题末尾不加句号，不用 emoji 或全角冒号。
 - 简单单文件变更可以没有 body；跨层实现、数据迁移、并发或事务修复、重要功能和行为变化使用 body 解释做了什么、为什么以及如何验证。
 - REST/GraphQL/RPC 契约、事件格式、公共 Java API、配置语义或数据库兼容性发生真实破坏时，使用 `!` 和 `BREAKING CHANGE:` 并写迁移方式。
 - 仅在已知编号或仓库要求时加入工单、DCO、`Signed-off-by` 等 footer，禁止编造；不要因为 Spring 项目采用 DCO 就推断所有 Java 项目都必须签署。
@@ -106,7 +106,7 @@ fix(settlement): 修复重复回调导致结算流水重复入账的问题
 
 - [ ] type 与 scope 通过仓库校验规则，完整消息经仓库命令校验通过。
 - [ ] scope 来自仓库枚举、构建模块或业务域，未使用 `controller`、`service`、`repository` 或类名兜底。
-- [ ] 标题为英文 type/scope + ASCII 冒号 + 中文摘要，完整 header 不超过 72 字符。
+- [ ] 标题语言、type/scope 和长度符合仓库配置；无配置时才使用本技能回退格式。
 - [ ] 提交可独立理解、构建和回滚；数据库迁移与对应实体、查询和测试同提交。
 - [ ] 暂存区不包含 `target/`、`build/`、日志或本地运行产物。
 - [ ] 已使用仓库 wrapper 运行与变更范围匹配的最小充分检查。

package/template/.codex/skills/llm-wiki/SKILL.md

@@ -48,7 +48,7 @@ node <skill-root>/scripts/extract.mjs skill-names --in <live-lock.json> --out <w
 
 1. Detect: `<wiki-root>/wiki/index.md` + `CLAUDE.md` (or `AGENTS.md`) means a wiki exists. Default wiki-root is repo-root `wiki/`. If `yss-project.yaml` is `repository_mode: template-source`, wiki-root is `.template-source/wiki`.
 2. If the user is asking a repository question, load [query.md](references/query.md) and stop. Do not lint, ingest, or append `log.md`.
-3. Load the mode algorithm: [compile.md](references/compile.md) for init/refresh/rebuild, [ingest.md](references/ingest.md) for ingest. For init/rebuild corpus choice, load [discover.md](discover.md). For writing, load [writing.md](references/writing.md). For checks, load [lint.md](references/lint.md).
+3. Load the mode algorithm: [compile.md](references/compile.md) for init/refresh/rebuild, [ingest.md](references/ingest.md) for ingest. For init/rebuild corpus choice, load [discover.md](references/discover.md). For writing, load [writing.md](references/writing.md). For checks, load [lint.md](references/lint.md).
 4. **Fact order:** called code > table comments / config defaults > stale raw copies. After writing, re-read live sources for a sample of claims (`N = min(5, changed pages)`).
 5. Run structural lint and advise. Append `log.md`. Stop.
 

package/template/.codex/skills/product-design/references/critical-overrides.md

@@ -34,8 +34,7 @@ These rules override generic assistant defaults for Product Design work.
 
 ## Re-read this file
 
-- Before every second user-facing assistant message, read this file, reminding of these principles.
-- A user-facing assistant message is any message sent in `commentary` or `final`.
+- Read this file on first entering a Product Design workflow. Re-read only when context was lost, the file changed, or a new workflow/decision requires it; do not use a message-count cadence.
 
 ## Explore vs. Design vs. Build
 
@@ -45,7 +44,7 @@ These rules override generic assistant defaults for Product Design work.
 - Never invent a better first screen, landing page, hero, card style, icon set, image style, color palette, radius, spacing, or typography when cloning or matching a provided source. Match the source.
 - Check the work like a senior designer. Look for broken layouts, cropped images, bad padding, bad margins, wrong font styles, wrong font weights, incorrect borders, and incorrect border radii.
 - Screenshots are not QA by themselves. Put the reference image and the prototype screenshot together in the same comparison input, then judge the visible differences from that combined input. Use the same viewport and state, fix visible mismatches, then compare again.
-- Build the current screen's interactions. Sidebars, menus, navs, forms, inputs, buttons, tabs, dropdowns, drawers, modals, popovers, carousels, tooltips, filters, toggles, and first-screen controls must be functional and populated with realistic mock data. Do not build new pages or routes unless the user asks for them.
+- Carry the confirmed interactivity level and required states into every downstream workflow and QA. Static review requires visual/state representation only; interactive prototypes implement the agreed flows and key failure states. Do not add CRUD, real data writes, new pages or routes beyond the agreed scope.
 
 ## Browser user
 
@@ -54,5 +53,5 @@ These rules override generic assistant defaults for Product Design work.
 
 ## Working with and making assets
 
-- Never fake visible assets with ASCII, prose, text symbols, emoji, placeholder boxes, CSS art, div art, handcrafted SVGs, inline SVGs, or approximate code drawings. Use real source assets when available. Use the built-in Image Gen tool for image assets when source assets are missing. Use the closest matching icon library for icons.
+- Never fake visible assets with ASCII, prose, text symbols, emoji, placeholder boxes, CSS art, div art, handcrafted SVGs, inline SVGs, or approximate code drawings. Preserve approved source assets, including existing SVGs and code-native brand components. The prohibition concerns unapproved approximations replacing the target, not faithful reuse. Use real source assets when available. Use the built-in Image Gen tool for image assets when source assets are missing. Use the closest matching icon library for icons.
 - Work like a designer. Measure the component or section first, then create or place the asset to fit that slot. Match the needed dimensions, crop, subject, palette, and density. Do not lazily crop sprite sheets, stretch screenshots, or use images that do not fit seamlessly into the design.

package/template/.codex/skills/product-design/skills/audit/SKILL.md

@@ -44,7 +44,7 @@ Destination rules:
 
 - If the user names Figma, use Figma.
 - If the user names a local folder, use that folder.
-- If the destination is missing, ask one question: "Should I put this in Figma or a local folder?"
+- If no destination is specified, use the current local output folder. Ask only if a remote destination or sharing choice materially affects the requested audit.
 
 Capture rules:
 

package/template/.codex/skills/product-design/skills/design-qa/SKILL.md

@@ -77,7 +77,7 @@ Every QA report must explicitly evaluate these surfaces:
 - Fonts and typography: family, fallback, weight, size, line height, letter spacing, antialiasing, hierarchy, wrapping, truncation, and whether display text and small UI text use appropriate optical weights. It is incredibly important to check fonts carefully for fidelity, including looking up similar typefaces or using image analysis to find the font differences.
 - Spacing and layout rhythm: frame size, crop, alignment, margins, padding, grid tracks, section gaps, component spacing, radii, shadows/elevation, and vertical rhythm.
 - Colors and visual tokens: sampled or inferred palette, gradients, opacity, contrast, semantic state colors, foreground/background balance, and whether CSS tokens map to the source design.
-- Image quality and asset fidelity: subject correctness, crop, scale, sharpness, compression, transparency halos, masking, background treatment, raster-vs-vector appropriateness, and whether generated assets match the source art direction. Fail QA if logos, illustrations, decorative marks, product imagery, non-standard icons, or other visible image assets from the visual target were replaced with custom inline SVG, handcrafted SVG, HTML elements, div/span shapes, CSS drawings, gradients, emoji, text glyphs, placeholder shapes, or code-native approximations.
+- Image quality and asset fidelity: subject correctness, crop, scale, sharpness, compression, transparency halos, masking, background treatment, raster-vs-vector appropriateness, and whether generated assets match the source art direction. Preserve existing approved SVG and code-native assets. Fail QA when, without approval, logos, illustrations, decorative marks, product imagery, non-standard icons, or other visible image assets from the visual target were replaced with approximate custom inline SVG, handcrafted SVG, HTML elements, div/span shapes, CSS drawings, gradients, emoji, text glyphs, placeholder shapes, or code-native approximations.
 - Copy and content of app-specific text
 
 ## Severity

package/template/.codex/skills/product-design/skills/get-context/SKILL.md

@@ -48,7 +48,8 @@ The questions to answer are:
 One of:
 
 - Full interactivity: all controls and states are completely functional and implemented.
-- Static: controls and states are minimally interactive, preferring speed.
+- Static: visual/state review only; simulated controls are labelled and no functional workflow is implied.
+- Pass `interactivity`, `required_states`, selected visual source and asset-reuse decisions to the next skill and its QA; reuse an already confirmed brief unless its scope changes.
 
 After the questions, reply with a pithy design brief that summarizes what you're about to explore. Avoid walls of text at all costs. Be clear and concise.
 

package/template/.codex/skills/product-design/skills/ideate/SKILL.md

@@ -86,7 +86,7 @@ Rules you must follow:
 
 - Use the Image Gen prompt below.
 - Use the built-in Image Gen tool.
-- Generate exactly three independent images unless the user overrides the count.
+- Respect the user-requested count; default to three distinct options only when exploration is needed. Stop after the selected direction answers the current design decision.
 - Generate options in parallel when possible.
 - Each option must be its own Image Gen result. Do not put multiple ideas in one image.
 - Attach provided screenshots, files, app captures, Figma references, and visual source material as moodboard inspiration when available.
@@ -108,55 +108,7 @@ If the user likes parts of more than one option, combine those choices into a ne
 
 ## Image Gen Prompt
 
-Adapt this prompt to the confirmed design brief, attach any available image references, and send it to Image Gen:
-
-```text
-Create realistic, production-quality UI designs with clear hierarchy, strong typography, intentional imagery, and purposeful spacing.
-
-Keep the design simple. Avoid busy interfaces. Every section should have a clear purpose, and every element should earn its place.
-
-Prioritize clarity, whitespace, and usability over decorative complexity.
-
-### Target Dimensions
-
-Pick the dimensions that best match the user's request and any provided visual reference.
-
- - Mobile app: `390 x 844`
- - Tablet app: `834 x 1194`
- - Desktop app, dashboard, admin, or SaaS: `1440 x 1024`
- - Landing or marketing page: `1440` wide and scrollable
- - Modal, panel, widget, or component: natural container size
- - Provided screenshot, Figma frame, mockup, or reference image: match its dimensions and aspect ratio when the user wants to continue from that visual
-
-Avoid crowding. Make the design fit the chosen dimensions cleanly, with realistic spacing, readable type, and no clipped content.
-
-### Layout
-
-When deciding how to lay elements out on the page, this should be your priority order for tools to differentiate sections:
-
-1. Use spacing, grouping, alignment, typography, and hierarchy on the same product surface.
-2. Use simple dividers or row separators.
-3. Use a subtle surface tint only when the base surface is not enough.
-4. Use borders only when separation still is not clear.
-5. Use shadows/elevation last, and sparingly.
-
-Don'ts:
- - Do not default to a centered "app card" (the whole UI is in a card on the page) on top of a contrasting page background. Use the base page surface first unless the source product or user explicitly asks for a contained app panel.
- - Do not put cards inside cards. Do not make every major section a card. Do not make each list item its own card unless each item is truly a standalone object. A normal list should usually read as one grouped surface with lightweight row separation.
- - Do not make up extraneous features. Add only the things essential to accomplish what the prototype's goal is. Don't make up more features just to fill out a UI.
-
-### Typography
-
- - Anchor UI typography to readable product sizes. Body text should usually sit between 14px and 16px, with the rest of the type scale built around that baseline.
- - Keep long-form text to a comfortable line length, generally no more than 65 characters per line.
- - Use no more than 2 fonts in a UI. You can use any font available in the project, or fonts provided free on Google Fonts. Pick the font that is best for the goal of the product and that matches with its intended look and feel.
-
-### Presentation
-
- - Do not add browser or device chrome around the mockup.
- - Do not put multiple ideas into a single image generation.
- - Vary each idea as much as possible while adhering to the constraints given entirely.
-```
+在实际生成方案图前，按目标尺寸、布局和字体需要读取 [图像提示模板](references/image-prompt-patterns.md)。用户已选来源、方案数量与当前设计决策优先；模板不要求补造无关维度。
 
 ## Output
 

package/template/.codex/skills/product-design/skills/ideate/references/image-prompt-patterns.md

@@ -0,0 +1,51 @@
+## Image Gen Prompt
+
+Adapt this prompt to the confirmed design brief, attach any available image references, and send it to Image Gen:
+
+```text
+Create realistic, production-quality UI designs with clear hierarchy, strong typography, intentional imagery, and purposeful spacing.
+
+Keep the design simple. Avoid busy interfaces. Every section should have a clear purpose, and every element should earn its place.
+
+Prioritize clarity, whitespace, and usability over decorative complexity.
+
+### Target Dimensions
+
+Pick the dimensions that best match the user's request and any provided visual reference.
+
+ - Mobile app: `390 x 844`
+ - Tablet app: `834 x 1194`
+ - Desktop app, dashboard, admin, or SaaS: `1440 x 1024`
+ - Landing or marketing page: `1440` wide and scrollable
+ - Modal, panel, widget, or component: natural container size
+ - Provided screenshot, Figma frame, mockup, or reference image: match its dimensions and aspect ratio when the user wants to continue from that visual
+
+Avoid crowding. Make the design fit the chosen dimensions cleanly, with realistic spacing, readable type, and no clipped content.
+
+### Layout
+
+When deciding how to lay elements out on the page, this should be your priority order for tools to differentiate sections:
+
+1. Use spacing, grouping, alignment, typography, and hierarchy on the same product surface.
+2. Use simple dividers or row separators.
+3. Use a subtle surface tint only when the base surface is not enough.
+4. Use borders only when separation still is not clear.
+5. Use shadows/elevation last, and sparingly.
+
+Don'ts:
+ - Do not default to a centered "app card" (the whole UI is in a card on the page) on top of a contrasting page background. Use the base page surface first unless the source product or user explicitly asks for a contained app panel.
+ - Do not put cards inside cards. Do not make every major section a card. Do not make each list item its own card unless each item is truly a standalone object. A normal list should usually read as one grouped surface with lightweight row separation.
+ - Do not make up extraneous features. Add only the things essential to accomplish what the prototype's goal is. Don't make up more features just to fill out a UI.
+
+### Typography
+
+ - Anchor UI typography to readable product sizes. Body text should usually sit between 14px and 16px, with the rest of the type scale built around that baseline.
+ - Keep long-form text to a comfortable line length, generally no more than 65 characters per line.
+ - Use no more than 2 fonts in a UI. You can use any font available in the project, or fonts provided free on Google Fonts. Pick the font that is best for the goal of the product and that matches with its intended look and feel.
+
+### Presentation
+
+ - Do not add browser or device chrome around the mockup.
+ - Do not put multiple ideas into a single image generation.
+ - Vary each idea as much as possible while adhering to the constraints given entirely.
+```

package/template/.codex/skills/product-design/skills/image-to-code/SKILL.md

@@ -32,7 +32,7 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
 
 3. If the provided design is a mobile viewport, build a mobile app. If it's unclear, default to desktop.
 
-4. Review the reference design, catalog every image asset in the design, and use the Image Gen tool to create individual images for each one. Zoom in so you can catch every asset that needs to be generated.
+4. Review the reference design and inventory its assets. Reuse provided or authorized source assets unchanged unless modification is requested. Generate only a genuinely missing asset when its creation is in scope and the tool is available; name unresolved asset gaps.
 
     Examples include:
 
@@ -47,7 +47,7 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
 
     Rules:
 
-    - CRITICAL RULE: Do not create custom div art, CSS art, inline SVGs, handcrafted SVGs, HTML element drawings, div/span shapes, CSS drawings, gradients, emoji, or text glyphs instead of real icons and image assets ever. Use the built-in Image Gen tool for images and the closest matching icon library for icons.
+    - CRITICAL RULE: Do not replace approved source assets with unapproved approximate drawings or placeholders. Reuse provided SVGs and other original assets; only missing in-scope assets require a generation or library capability.
     - If text is part of an image asset, keep it in the image asset. Examples include full bleed hero images, signs, posters, packaging, storefronts, article art, and illustrations where the type belongs to the visual itself. Do not crop the background image and recreate that text with transparent text boxes, HTML, CSS, or separate overlay layers unless the source clearly shows editable UI text sitting on top of the image.
     - Do not use generic placeholders where the reference implies custom visual content.
     - Generated assets must share the same art direction, palette, rendering style, and design language as the reference mockup.
@@ -61,9 +61,9 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
 
     Rules:
 
-    - CRITICAL RULE: Do not create custom inline SVGs, handcrafted SVGs, HTML element drawings, div/span shapes, CSS drawings, gradients, emoji, or text glyphs. Use the built-in Image Gen tool to generate assets and use the closest matching icon library for icons.
+    - CRITICAL RULE: Preserve original SVGs, icon assets and code-native visual components. Do not substitute approximate drawings without approval. Use a matching library or generation tool only for missing in-scope assets.
 
-8. Build the app starting with [local-prototype-preflight](../../references/local-prototype-preflight.md). Build all interactions, ensuring the app is complete, functional, and interactive: all controls and states activated and functional.
+8. Build the app starting with [local-prototype-preflight](../../references/local-prototype-preflight.md). Carry the confirmed brief's `interactivity` and `required_states`. For static scope, implement faithful visual states without adding action workflows; for interactive scope, implement and verify the agreed controls and recovery states.
 
     Examples include:
 
@@ -73,12 +73,12 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
     - Clickable cards and buttons
     - Animated affordances if implied by the design
     - Newsletter forms, tags, filters, or navigation elements shown in the mockup
-    - Bring the thing to life. Do not deliver a static site; the less you do, the more the designer has to add.
+    - A static prototype is complete when the agreed visual/state review is supported; do not expand it into a functional product.
 
     Rules:
 
     - Place every image asset you generated into its position before proceeding. I repeat, replace all placeholders, including CSS/SVG placeholders, before proceeding.
-    - Do not leave visible controls as static chrome. Do not create new pages or routes unless the user asks for them.
+    - For interactive scope, required controls must work; for static scope, clearly label simulated controls. Do not create new pages or routes unless requested.
 
 9. Run the local app.
 

package/template/.codex/skills/product-design/skills/index/SKILL.md

@@ -41,10 +41,10 @@ For new app, prototype, redesign, or UI build requests without a URL, screenshot
 
 - Run `$get-context`.
 - After the brief is approved, route to `$ideate`.
-- Show exactly three visual options and wait for the user to choose one.
+- Show the user-requested number of visual options (default three when exploration is needed) and wait for the user to choose one.
 - Do not scaffold, edit files, or start a server before a visual option is selected.
 
-`Full working version`, `no refs`, `go for it`, `make an assumption`, or a confirmed brief do not waive this.
+A confirmed selected visual source skips ideation. Otherwise retain the visual-selection step, respecting the user-requested option count; a static brief does not authorize full interaction.
 
 ## User Context