create-yss-spec 3.4.8 → 3.4.9

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

@@ -13,10 +13,13 @@ duplicates, join coverage, or source mismatches, use $analyze-data-quality as 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.
 
 ## Workflow
 
+Choose checks from the data grain, intended decision and known risk. Reuse fresh checks already covering the same source/query/transform; do not repeat the catalog. A notebook is needed only when reproducibility or multi-step analysis warrants it. Preserve blocking correctness findings and report material limitations.
+
+
 1. Inventory the artifact and claims.
 
    Identify the report, notebook, spreadsheet, SQL, dashboard, chart, pasted analysis, or recommendation being validated. Inspect source artifacts when a path, link, query, notebook, spreadsheet, or dashboard is referenced. Extract the main question, audience, decision, key claims, headline numbers, data sources, time windows, populations, filters, comparison baselines, and stated caveats. Verify that every metric or KPI requested by the user appears in the analysis or is explicitly marked unavailable, not applicable, or out of scope.
@@ -76,76 +79,9 @@ Mandatory pre-answer gate: Invoke `data-analytics:user-context` in preflight mod
   high-impact decisions, and externally shared analyses as higher-risk validation targets.
 - Select checks that match the artifact and decision. Do not run every possible check mechanically.
 
-### Methodology Checks
-
-- Question framing: the analysis answers the stated business or product question.
-- Data selection: sources are appropriate and current enough for the decision.
-- Population: inclusions, exclusions, eligibility rules, and sampling are explicit.
-- Metric definitions: formulas, units, denominators, and timezones are clear and aligned with stakeholder definitions.
-- Baselines: comparison periods, cohorts, and contexts are comparable.
-- Causality: causal wording is backed by experimental or otherwise credible causal evidence.
-
-### Data Quality Checks
-
-- Freshness: the analysis states or can recover the data "as of" date.
-- Completeness: no unexpected missing partitions, segments, rows, or categories.
-- Null handling: key columns have expected null rates or explicit treatment.
-- Deduplication: primary entities are not double counted.
-- Filter verification: filters and WHERE clauses do not silently exclude the population of interest.
-- Join coverage: dimensions, experiments, and reference tables do not drop or multiply important rows.
-
-### Calculation Checks
-
-- Grain: the aggregation level matches the intended analysis grain.
-- Denominators: rates and percentages use the correct population and non-zero denominators.
-- Period alignment: comparisons use equal or explicitly caveated windows.
-- Weighted metrics: averages are weighted correctly when group sizes differ.
-- Subtotals: parts add to totals where categories are mutually exclusive.
-- Units: currency, token, user, request, account, day/week/month, and timezone units are consistent.
-
-### Reasonableness Checks
-
-- Magnitudes are plausible relative to known dashboards, historical reports, or expected product scale.
-- Percentages fall in expected ranges and segment shares sum to about 100% where expected.
-- Trend jumps, drops, flatlines, exact round numbers, and 0% or 100% rates have an explanation.
-- Results do not perfectly confirm the hypothesis without friction or exceptions.
-- Edge cases such as empty segments, new entities, and boundary dates behave sensibly.
-
-### Common Pitfalls
-
-- Join explosion: many-to-many joins silently multiply rows and inflate counts or sums. Compare row counts and distinct primary entities before and after the join, and check whether the right-hand table has multiple rows per join key.
-  Aggregate the right-hand table to the intended grain before joining when needed, use `COUNT(DISTINCT primary_id)` when counting entities through joins,
-  and comment intentional one-to-many joins.
-- Survivorship bias: the analysis only includes entities that exist today and misses deleted, churned, failed, or otherwise absent entities. Ask who is not in the dataset and whether the missing population changes the conclusion.
-- Incomplete period comparison: a partial period is compared with a complete period. Use complete periods, compare the same number of elapsed days, or label the partial-period caveat prominently.
-- Denominator shifting: the eligible population changes between periods or segments. Validate that conversion, churn, activation, attach, and retention rates use stable definitions across compared groups.
-- Average of averages: pre-computed averages are averaged without weighting for group size. Aggregate from raw numerators and denominators or use a weighted average.
-- Timezone mismatch: sources use different timestamp conventions or daily cutoffs. Confirm the analysis standardizes timestamps or explicitly states the timezone and cutoff.
-- Selection bias in segmentation: segments are defined by the outcome being measured. Define comparison groups by pre-treatment characteristics when making lift, causality, or behavior-difference claims.
-- Other statistical traps: Simpson's paradox where aggregate and segment-level trends conflict, correlation presented as causation, small samples,
-  outlier-dominated averages that need medians or distribution views, multiple testing, cherry-picked time ranges, and look-ahead bias.
-
-### Spot-Check Recipes
-
-- Recompute a key metric from raw numerators and denominators.
-- Trace a few individual records through joins, filters, and final output.
-- Reconcile a key total against a trusted dashboard, prior report, or finance source.
-- Reverse engineer a headline number from component metrics, such as users times per-user revenue.
-- Run a one-day, one-segment, or one-entity boundary check to make sure filters and joins behave sensibly.
-- Compare the same metric through an alternate query path when a claim is surprising or high stakes.
-
-### Visualization Checks
-
-- Bar charts should generally start at zero.
-- Comparison charts should use consistent scales unless the scale difference is explicit and justified.
-- Axes, units, legends, and date ranges should be labeled.
-- Category ordering should match the comparison the reader should make.
-- Truncated axes, dual axes, 3D effects, and inconsistent intervals require explicit justification or redesign.
-- Chart titles and annotations should match exactly what the data supports.
-- Titles should state the finding and include date range or scope when needed.
-- Caveats should be visible near the claims they qualify.
-- Number formatting should use appropriate precision and units.
-- Rendered artifacts should be checked in their final form when available, not only in source form.
+### 按风险选择方法
+
+核验方法、数据质量、计算、合理性或可视化时，按对应风险读取 [方法与抽查示例](references/validation-methods.md)。验证同一证据不重复逐项抄写；影响结论的错误必须修复或阻断，非阻断限制显式随结果交付。
 
 ### Confidence Ratings
 

package/template/.codex/skills/data-analytics/skills/validate-data/references/validation-methods.md

@@ -0,0 +1,70 @@
+### Methodology Checks
+
+- Question framing: the analysis answers the stated business or product question.
+- Data selection: sources are appropriate and current enough for the decision.
+- Population: inclusions, exclusions, eligibility rules, and sampling are explicit.
+- Metric definitions: formulas, units, denominators, and timezones are clear and aligned with stakeholder definitions.
+- Baselines: comparison periods, cohorts, and contexts are comparable.
+- Causality: causal wording is backed by experimental or otherwise credible causal evidence.
+
+### Data Quality Checks
+
+- Freshness: the analysis states or can recover the data "as of" date.
+- Completeness: no unexpected missing partitions, segments, rows, or categories.
+- Null handling: key columns have expected null rates or explicit treatment.
+- Deduplication: primary entities are not double counted.
+- Filter verification: filters and WHERE clauses do not silently exclude the population of interest.
+- Join coverage: dimensions, experiments, and reference tables do not drop or multiply important rows.
+
+### Calculation Checks
+
+- Grain: the aggregation level matches the intended analysis grain.
+- Denominators: rates and percentages use the correct population and non-zero denominators.
+- Period alignment: comparisons use equal or explicitly caveated windows.
+- Weighted metrics: averages are weighted correctly when group sizes differ.
+- Subtotals: parts add to totals where categories are mutually exclusive.
+- Units: currency, token, user, request, account, day/week/month, and timezone units are consistent.
+
+### Reasonableness Checks
+
+- Magnitudes are plausible relative to known dashboards, historical reports, or expected product scale.
+- Percentages fall in expected ranges and segment shares sum to about 100% where expected.
+- Trend jumps, drops, flatlines, exact round numbers, and 0% or 100% rates have an explanation.
+- Results do not perfectly confirm the hypothesis without friction or exceptions.
+- Edge cases such as empty segments, new entities, and boundary dates behave sensibly.
+
+### Common Pitfalls
+
+- Join explosion: many-to-many joins silently multiply rows and inflate counts or sums. Compare row counts and distinct primary entities before and after the join, and check whether the right-hand table has multiple rows per join key.
+  Aggregate the right-hand table to the intended grain before joining when needed, use `COUNT(DISTINCT primary_id)` when counting entities through joins,
+  and comment intentional one-to-many joins.
+- Survivorship bias: the analysis only includes entities that exist today and misses deleted, churned, failed, or otherwise absent entities. Ask who is not in the dataset and whether the missing population changes the conclusion.
+- Incomplete period comparison: a partial period is compared with a complete period. Use complete periods, compare the same number of elapsed days, or label the partial-period caveat prominently.
+- Denominator shifting: the eligible population changes between periods or segments. Validate that conversion, churn, activation, attach, and retention rates use stable definitions across compared groups.
+- Average of averages: pre-computed averages are averaged without weighting for group size. Aggregate from raw numerators and denominators or use a weighted average.
+- Timezone mismatch: sources use different timestamp conventions or daily cutoffs. Confirm the analysis standardizes timestamps or explicitly states the timezone and cutoff.
+- Selection bias in segmentation: segments are defined by the outcome being measured. Define comparison groups by pre-treatment characteristics when making lift, causality, or behavior-difference claims.
+- Other statistical traps: Simpson's paradox where aggregate and segment-level trends conflict, correlation presented as causation, small samples,
+  outlier-dominated averages that need medians or distribution views, multiple testing, cherry-picked time ranges, and look-ahead bias.
+
+### Spot-Check Recipes
+
+- Recompute a key metric from raw numerators and denominators.
+- Trace a few individual records through joins, filters, and final output.
+- Reconcile a key total against a trusted dashboard, prior report, or finance source.
+- Reverse engineer a headline number from component metrics, such as users times per-user revenue.
+- Run a one-day, one-segment, or one-entity boundary check to make sure filters and joins behave sensibly.
+- Compare the same metric through an alternate query path when a claim is surprising or high stakes.
+
+### Visualization Checks
+
+- Bar charts should generally start at zero.
+- Comparison charts should use consistent scales unless the scale difference is explicit and justified.
+- Axes, units, legends, and date ranges should be labeled.
+- Category ordering should match the comparison the reader should make.
+- Truncated axes, dual axes, 3D effects, and inconsistent intervals require explicit justification or redesign.
+- Chart titles and annotations should match exactly what the data supports.
+- Titles should state the finding and include date range or scope when needed.
+- Caveats should be visible near the claims they qualify.
+- Number formatting should use appropriate precision and units.
+- Rendered artifacts should be checked in their final form when available, not only in source form.

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.