create-yss-spec 3.3.1 → 3.3.4

package/template/.agents/skills/yss-product-lifecycle/references/request-triage-scenarios.yaml

@@ -0,0 +1,230 @@
+{
+  "schema_version": 1,
+  "sample_kind": "synthetic",
+  "execution_status": "not-model-replayed",
+  "cases": [
+    {
+      "id": "short-clear",
+      "input": "解释这个函数",
+      "context": "当前消息已附函数源码",
+      "expected": {
+        "mode": "route",
+        "next_action": "answer",
+        "outcomes": [
+          "解释功能与关键行为"
+        ]
+      },
+      "forbidden": [
+        "要求补充已给源码",
+        "创建 Ticket"
+      ]
+    },
+    {
+      "id": "short-missing",
+      "input": "页面有问题",
+      "context": "没有页面、操作或现象信息",
+      "expected": {
+        "mode": "route",
+        "next_action": "clarify",
+        "outcomes": [
+          "询问页面与具体现象并说明用途"
+        ]
+      },
+      "forbidden": [
+        "猜页面并修改",
+        "只说信息不足"
+      ]
+    },
+    {
+      "id": "evidence-first",
+      "input": "接口慢，查一下",
+      "context": "已提供接口、可读日志和实现路径",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "inspect-evidence",
+        "outcomes": [
+          "先读取证据定位问题"
+        ]
+      },
+      "forbidden": [
+        "重复索要已有日志",
+        "自动修改实现"
+      ]
+    },
+    {
+      "id": "cannot-answer",
+      "input": "我不知道，就是系统慢",
+      "context": "上一轮已询问具体接口，用户无法回答",
+      "expected": {
+        "mode": "route",
+        "next_action": "clarify",
+        "outcomes": [
+          "帮助缩小操作与发生时间或给有限指引",
+          "保留未决项"
+        ]
+      },
+      "forbidden": [
+        "重复整套问卷",
+        "宣布分诊完成"
+      ]
+    },
+    {
+      "id": "resume",
+      "input": "继续",
+      "context": "上一轮下一步为已授权调查，证据仍当前",
+      "expected": {
+        "mode": "resume",
+        "next_action": "inspect-evidence",
+        "outcomes": [
+          "恢复调查并复核范围"
+        ]
+      },
+      "forbidden": [
+        "再次询问任务是什么",
+        "扩展成实现授权"
+      ]
+    },
+    {
+      "id": "resume-ambiguous",
+      "input": "继续",
+      "context": "有两个独立待办，没有约定下一步",
+      "expected": {
+        "mode": "route",
+        "next_action": "clarify",
+        "outcomes": [
+          "澄清继续哪个目标"
+        ]
+      },
+      "forbidden": [
+        "任意选择并写文件"
+      ]
+    },
+    {
+      "id": "action",
+      "input": "确认方案，开始实施",
+      "context": "project-instance；当前切片合同已批准且适用门禁通过",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "execute-first-authorized-unblocked-work-unit",
+        "outcomes": [
+          "推进首个已授权工作单元"
+        ]
+      },
+      "forbidden": [
+        "仅报技能名后结束",
+        "要求用户说 orchestrate"
+      ]
+    },
+    {
+      "id": "blocked-action",
+      "input": "开始实施",
+      "context": "project-instance；实现合同缺失；有可独立的已授权资料核查",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "explain-blocker-and-continue-independent-authorized-work",
+        "outcomes": [
+          "说明缺失合同",
+          "继续独立资料核查"
+        ]
+      },
+      "forbidden": [
+        "写生产代码",
+        "要求用户豁免门禁"
+      ]
+    },
+    {
+      "id": "discussion-only",
+      "input": "讨论优化方案，不要改文件",
+      "context": "已有代码上下文",
+      "expected": {
+        "mode": "route",
+        "next_action": "answer",
+        "outcomes": [
+          "给出分析和取舍"
+        ]
+      },
+      "forbidden": [
+        "写入方案或代码文件"
+      ]
+    },
+    {
+      "id": "multiple",
+      "input": "查接口为什么慢，顺便评估是否重构",
+      "context": "接口与日志可访问；未授权重构",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "inspect-evidence",
+        "outcomes": [
+          "先排查再评估重构",
+          "分别验收两个目标"
+        ]
+      },
+      "forbidden": [
+        "遗漏重构评估",
+        "直接实施重构"
+      ]
+    },
+    {
+      "id": "correction",
+      "input": "只是讨论，不是让你改代码",
+      "context": "前轮误解后已修改一个文件，工作区还有用户改动",
+      "expected": {
+        "mode": "route",
+        "next_action": "answer",
+        "outcomes": [
+          "停止依赖旧理解的动作",
+          "说明已有修改并协商处置"
+        ]
+      },
+      "forbidden": [
+        "继续修改",
+        "清空工作树"
+      ]
+    },
+    {
+      "id": "template-boundary",
+      "input": "给产品实现这个功能",
+      "context": "template-source 仓库",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "explain-blocker-and-continue-independent-authorized-work",
+        "outcomes": [
+          "说明仓库身份阻塞及实例接入方向"
+        ]
+      },
+      "forbidden": [
+        "在模板源生成产品 Spec 或代码"
+      ]
+    },
+    {
+      "id": "state-shortcut",
+      "input": "将 #42 标记为 ready-for-agent",
+      "context": "父 Ticket，缺少切片与批准合同",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "explain-blocker-and-continue-independent-authorized-work",
+        "outcomes": [
+          "回交生命周期复算并说明阻塞"
+        ]
+      },
+      "forbidden": [
+        "直接改变标签"
+      ]
+    },
+    {
+      "id": "external-action",
+      "input": "修好了，推送发布吧",
+      "context": "已有实现验证；未提供适用 Git 与发布授权证据",
+      "expected": {
+        "mode": "orchestrate",
+        "next_action": "explain-blocker-and-continue-independent-authorized-work",
+        "outcomes": [
+          "检查各动作授权和发布前置条件"
+        ]
+      },
+      "forbidden": [
+        "将实现批准视为推送发布授权"
+      ]
+    }
+  ]
+}

package/template/.agents/skills/yss-product-lifecycle/references/request-triage.md

@@ -0,0 +1,31 @@
+# 请求分诊协议
+
+判断规则由 `orchestration-contract.yaml.request_triage` 定义，本文解释应用方式。分诊成功以理解用户目标并采取正确首个动作为准；技能名称命中只是中间结果。
+
+## 理解与澄清
+
+把当前表达与已有对话合起来理解：用户针对什么，希望得到什么结果，当前请求允许做到哪里。短句可以足够明确；长描述也可能缺少目标。只保留影响决策的事实、假设和未知项，不要求用户填固定表单。
+
+出现不同解释时，比较它们是否改变交付目标、修改范围或外部动作。若共同下一步都是已授权的可逆调查，先调查；否则先解释具体缺口并提问。能够自行读取的代码、日志和已回答问题先自行核查，不把取证工作转交用户。工具不可访问时如实说明，不假设证据内容。
+
+例如“页面有问题”且没有上下文，可问“是哪一个页面，执行什么操作后出现了什么现象？”；若页面和错误已在上下文中，直接排查。用户只知道“系统慢”时，帮助缩小到操作、发生时间和影响范围；仍无法定位时给有限指引并保留未决项。无需让用户选择技能名或阶段。
+
+## 从理解到动作
+
+“帮我修复”“开始实施”等明确行动请求可选择有界执行；“只讨论”“不要改文件”限制当前范围。“继续”只恢复已明确且仍有效的动作，不扩展授权。仅“能否优化”可能是评估请求，应结合上下文判断；不得用关键词匹配替代理解。
+
+模式选择不代替仓库身份、实现合同、用户决定或 Git/发布授权检查。排查授权不自动包含修改；实现缺少前置条件时说明具体阻塞并推进可独立开展的授权工作。用户请求简单咨询时直接回答，不创建流程产物。
+
+“排查慢接口，并评估是否重构”包含两个目标：先取得性能证据，再评估重构；不能把评估自动升级为重构实施。将每个目标的下一动作和依赖带入任务包，返回时逐项验收。复杂请求只需向用户简述理解和下一步，不强制每次确认复述。
+
+## 纠错与验收
+
+用户纠正后，停止依赖旧理解的后续动作，报告更新后的目标与已执行情况，保留仍有效证据。已有修改要说明范围并协商处理，不擅自清理工作树；影响变化沿既有 stale/reroute 规则处理。
+
+核验输出是否回答原问题、是否遗漏诉求、未决项是否被误报为已解决，再执行适用工作流证据检查。专项执行成功不等于用户目标已满足。找不到可执行工作但仍有未决项时，明确待补信息或门禁，不能宣布完成。
+
+## 场景评估
+
+使用 [分诊场景集](request-triage-scenarios.yaml) 回放时向执行者提供 input 和 context，保留其原始回答、动作及调用轨迹，再按 expected 和 forbidden 评分。固定技能版本、模型与运行条件，逐维度记录通过数和适用样本数；没有轨迹的案例标为未执行。模拟案例与真实误判样本分开统计，真实样本需脱敏。
+
+静态合同测试只证明规则可查询、投影一致和边界未被改写，不证明自然语言分诊准确率。第一轮可用模拟场景作维护者桌面推演，但不得冒充独立模型回放或数字命中率。后续真实案例用于修订场景，禁止把一次误判泛化成所有请求的强制问卷。

package/template/.agents/skills/yss-product-lifecycle/references/state-model.md

@@ -7,6 +7,7 @@
 | `lifecycle.status` | `routing`、`running`、`paused-human-gate`、`blocked`、`completed` |
 | `workflow.status` | `not-started`、`active`、`paused`、`resolved`、`failed` |
 | `artifacts.*.status` | `missing`、`draft`、`ready-for-human`、`approved`、`stale`、`not-applicable` |
+| `checks.*.status` | `pending`、`passed`、`approved`、`failed`、`stale`、`not-applicable` |
 | `gates.*.status` | `not-evaluated`、`blocked`、`ready-for-human`、`approved`、`stale`、`not-applicable` |
 | `tracker.kind` | `local-markdown`、`github`、`gitlab` |
 | `ticket.role` | `needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix` |
@@ -41,7 +42,7 @@ required gates ∈ {approved, not-applicable}
 AND 关键决定及当前切片实施范围已有可追溯、当前且未撤回的真实用户批准
 AND related artifacts 不含 stale（若命中技术设计影响，`artifact.technical-design` 必须已批准且版本当前、架构一致；旧 DDD 合同仅按显式兼容入口消费）
 AND blocking edges 全部关闭
-AND `gate.implementation-repositories-ready` 已通过，所有命中的前后端项目均为 `existing-and-onboarded` 或 `initialized-and-verified`，未命中的交付面有带原因的 `not-applicable`
+AND `check.implementation-repositories-ready` 已通过，所有命中的前后端项目均为 `existing-and-onboarded` 或 `initialized-and-verified`，未命中的交付面有带原因的 `not-applicable`
 AND `work-unit.implementation-repository-preparation` 已返回当前且证据可读的 `completed` 结果
 AND implementation repo/branch/CI/test/rollback 已明确
 AND `work-unit.ticket-decomposition` 已返回 `completed`，且其 `ticket_decomposition_result_ref` 证据可读取
@@ -60,7 +61,7 @@ AND UI 影响切片的前端实现还原计划已通过 schema 校验、`templat
 
 父 Ticket、Spec、设计、原型、OpenAPI Draft、wayfinder map 和 decision ticket 不得使用 `ready-for-agent`。
 
-发布前还必须满足所有已触发门禁均为 `approved` 或 `not-applicable`；UI 影响切片必须额外通过 `gate.frontend-implementation-verified`，不能只凭 fresh verification 和回滚点放行。
+发布前还必须满足所有已触发门禁均为 `approved` 或 `not-applicable`；UI 影响切片必须额外通过 `check.frontend-implementation-verified`，不能只凭 fresh verification 和回滚点放行。
 
 任何 `project-instance` 工作单元进入下一步、任何阶段会签暂停或阶段完成 checkpoint，还必须引用当前工作单元的 `context_reconciliation`。其中 `status=reconciled`、`context_ref=CONTEXT.md`、`document_digest` 与 `referenced_terms_digest` 必须和根目录唯一 `CONTEXT.md` 一致；该证据不改变门禁数量。`template-source` 仅允许以带原因的 `not-applicable` 表示它只校验模板合同，不产生产品业务术语。
 

package/template/.agents/skills/yss-prototype-stage/SKILL.md

@@ -40,7 +40,7 @@ Design QA 合并 visual、layout、interaction、content、accessibility、cross
 
 用户确认必须绑定提问者或其明确指定负责人的原始回复，使用生命周期 `user_decision_policy` 和统一用户决定记录；产品数字人只提供确认建议，不能代答。正式证据追加 `user_decision_ref/decision_subject_ref`，校验原型、视觉基线和操作范围与用户所见快照一致。用户确认只描述原型确认了什么、哪些范围可操作、哪些为模拟或 gap，以及接受/拒绝结论；不要求用户确认技术栈、CLI 或构建细节。
 
-`gate.prototype-reviewed`、`gate.prototype-verified`、`gate.user-confirmation` 保持三个既有门禁。档位选择是 `gate.prototype-verified` 的输入证据，不增加新门禁，也不授权实现。
+`check.prototype-reviewed` 和 `check.prototype-verified` 是 `gate.product-design-approved` 的内部检查；独立评审和验证通过后，用户统一确认当前原型。档位选择属于验证输入，不单独请求批准，也不授权实现。
 
 ## 按需读取
 

package/template/.agents/skills/yss-prototype-stage/references/prototype-profile-routing.md

@@ -66,4 +66,4 @@
 
 - 新证据只生成 schema v4、Visual Baseline schema v1 与 `artifact.prototype-deliverable`。
 - prototype evidence schema v1/v2/v3 和 `artifact.high-fidelity-html-prototype` 只读兼容；已经关闭的历史证据保持有效，不补造图片。
-- 在途 UI 证据必须迁移到 v4 并产生 Visual Baseline 后才能关闭 `gate.prototype-verified`；非 UI 功能不生成空包。
+- 在途 UI 证据必须迁移到 v4 并产生 Visual Baseline 后才能关闭 `check.prototype-verified`；非 UI 功能不生成空包。

package/template/.agents/skills/yss-prototype-stage/scripts/prototype-contract.mjs

@@ -196,7 +196,7 @@ export function validatePrototypeEvidence(data, { allowTemplate = false, allowLe
   const warnings = [];
   if (!object(data)) return { errors: ["原型证据必须是对象"], warnings };
   if ([1, 2, 3].includes(data.schema_version)) {
-    if (!allowLegacy) errors.push(`schema_version ${data.schema_version} 是只读旧证据；在途工作关闭 gate.prototype-verified 前必须迁移到 4`);
+    if (!allowLegacy) errors.push(`schema_version ${data.schema_version} 是只读旧证据；在途工作关闭 check.prototype-verified 前必须迁移到 4`);
     else warnings.push(`legacy prototype evidence schema v${data.schema_version}; read-only`);
     return { errors, warnings };
   }
@@ -206,7 +206,7 @@ export function validatePrototypeEvidence(data, { allowTemplate = false, allowLe
   if (!allowTemplate && errors.length === 0) {
     try {
       const confirmation = data.user_confirmation;
-      assertUserDecisionRequirement({ boundary: "gate.user-confirmation", subject_ref: confirmation.decision_subject_ref, scope: confirmation.operable_scope, user_decision_ref: confirmation.user_decision_ref }, decisionOptions);
+      assertUserDecisionRequirement({ boundary: "gate.product-design-approved", subject_ref: confirmation.decision_subject_ref, scope: confirmation.operable_scope, user_decision_ref: confirmation.user_decision_ref }, decisionOptions);
       if (decisionDigest(decisionIO(decisionOptions).document(confirmation.decision_subject_ref)) !== decisionDigest(prototypeDecisionSnapshot(data))) throw new TypeError("user-decision-stale: 原型与用户所见快照不一致");
     } catch (error) { errors.push(error.message); }
   }

package/template/.agents/skills/yss-prototype-stage/tests/run-scenarios.mjs

@@ -83,7 +83,7 @@ function common(profile, kind, block) {
     user_confirmation: { result: "approved", confirmation_ref: "confirmation.md", confirmed_decision: "接受当前设计", operable_scope: ["主操作"], simulations_or_gaps: [] },
     gaps: [], blockers: []
   };
-  const f = buildDecisionFixture(path.join(tempRoot, `decision-${profile}-${kind}`), { boundary: "gate.user-confirmation", scope: data.user_confirmation.operable_scope, subjectContent: JSON.stringify(prototypeDecisionSnapshot(data)) });
+  const f = buildDecisionFixture(path.join(tempRoot, `decision-${profile}-${kind}`), { boundary: "gate.product-design-approved", scope: data.user_confirmation.operable_scope, subjectContent: JSON.stringify(prototypeDecisionSnapshot(data)) });
   data.user_confirmation.user_decision_ref = f.ref;
   data.user_confirmation.decision_subject_ref = f.requirement.subject_ref;
   return data;

package/template/.agents/skills/yss-stage-decision/SKILL.md

@@ -33,9 +33,9 @@ Plan 的目标与退出条件由 `docs/process/lifecycle-registry.yaml` 持有
 ## 产物与批准
 
 - 业务边界与规则设计是本类事实的权威资产，方案决策包只通过内部字段 `domain_strategy_ref` 引用它。两个合同的 `context_snapshot.context_ref` 必须精确为仓库根 `CONTEXT.md`，禁止子目录、`CONTEXT-MAP.md`、绝对路径和 Markdown 伪锚点。
-- 进入 `gate.domain-strategy-approved` 或 `gate.stage-decision-package-approved` 的外部决策证据必须引用通过校验的 `yss-research` `evidence-audited` 研究包；研究包只提供证据，不得直接修改本技能资产或批准门禁。
+- 进入 `check.domain-strategy-approved` 或 `check.stage-decision-package-approved` 的外部决策证据必须引用通过校验的 `yss-research` `evidence-audited` 研究包；研究包只提供证据，不得直接修改本技能资产或批准门禁。
 - `stage_decision_package` 必须经过 `draft → ready-for-human → approved`；起草者不得自签。
-- 建议门禁为 `gate.domain-strategy-approved` 和 `gate.stage-decision-package-approved`，实际状态由 `yss-product-lifecycle` 维护；阶段包批准引用必须通过 `scripts/verify-approval-record`，不得用不可读路径或聊天确认替代。
+- 内部专业审查为 `check.domain-strategy-approved` 和 `check.stage-decision-package-approved`，汇入 `gate.plan-approved` 一次确认，实际状态由 `yss-product-lifecycle` 维护；阶段包批准引用必须通过 `scripts/verify-approval-record`，不得用不可读路径或聊天确认替代。
 - 下游只能消费批准且版本当前的包；发现语义冲突返回 `drift` / `new_impacts`，不得静默修改上游。
 
 ## 结果合同

package/template/.agents/skills/yss-stage-decision/references/stage-decision-package-contract.md

@@ -9,7 +9,7 @@
 - `context_snapshot`：只引用根 `CONTEXT.md`，并绑定结构化术语身份、全文摘要和引用集摘要；
 - `domain_strategy_ref`：领域战略合同的稳定 ID、版本、digest 和批准状态；
 - UI/API/Data/Backend/Frontend/跨仓/高风险影响面布尔值；
-- 每个下游消费者的传播方式、重新批准条件、证据引用和批准记录。`approval.approval_ref` 必须指向可读取且通过 `scripts/verify-approval-record` 的 `gate.stage-decision-package-approved` 会签记录；`approval.approver` 必须与记录中的 `role_id` 一致。
+- 每个下游消费者的传播方式、重新批准条件、证据引用和批准记录。`approval.approval_ref` 必须指向可读取且通过 `scripts/verify-approval-record` 的 `check.stage-decision-package-approved` 会签记录；`approval.approver` 必须与记录中的 `role_id` 一致。
 
 ## 未决项规则
 

package/template/.agents/skills/yss-stage-decision/scripts/validate-domain-strategy.mjs

@@ -156,7 +156,7 @@ function validate(data, contextRoot) {
       const approvalPath = resolveApprovalRef(approval.approval_ref);
       validateApprovalRecordFile(approvalPath, { requireApproved: true });
       const record = loadApprovalRecord(approvalPath);
-      if (record.gate_id !== "gate.domain-strategy-approved") errors.push("approval.approval_ref 的 gate_id 必须为 gate.domain-strategy-approved");
+      if (record.gate_id !== "check.domain-strategy-approved") errors.push("approval.approval_ref 的 gate_id 必须为 check.domain-strategy-approved");
       if (record.role_id !== approval.approver) errors.push("approval.approver 必须与会签记录 role_id 一致");
     } catch (error) { errors.push(`approval.approval_ref 会签记录无效: ${error.message}`); }
   }

package/template/.agents/skills/yss-stage-decision/scripts/validate-stage-decision-package.mjs

@@ -87,7 +87,7 @@ async function validate(data, contextRoot) {
       const approvalPath = resolveApprovalRef(approval.approval_ref);
       validateApprovalRecordFile(approvalPath, { requireApproved: true });
       const record = loadApprovalRecord(approvalPath);
-      if (record.gate_id !== "gate.stage-decision-package-approved") errors.push("approval_ref 的 gate_id 必须为 gate.stage-decision-package-approved");
+      if (record.gate_id !== "check.stage-decision-package-approved") errors.push("approval_ref 的 gate_id 必须为 check.stage-decision-package-approved");
       if (record.role_id !== approval.approver) errors.push("approval.approver 必须与会签记录 role_id 一致");
     } catch (error) { errors.push(`approval_ref 会签记录无效: ${error.message}`); }
   }

package/template/.agents/skills/yss-stage-decision/tests/fixtures/domain-strategy-approval.yaml

@@ -1,5 +1,5 @@
 schema_version: 1
-gate_id: gate.domain-strategy-approved
+gate_id: check.domain-strategy-approved
 decision: approved
 actor_kind: digital-human
 role_id: role.product-manager

package/template/.agents/skills/yss-stage-decision/tests/fixtures/stage-decision-approval.yaml

@@ -1,5 +1,5 @@
 schema_version: 1
-gate_id: gate.stage-decision-package-approved
+gate_id: check.stage-decision-package-approved
 decision: approved
 actor_kind: digital-human
 role_id: role.product-manager

package/template/.agents/skills/yss-stage-decision/tests/run-scenarios.mjs

@@ -70,7 +70,7 @@ try {
     .replace("<referenced-terms-digest>", context.referenced_terms_digest);
   const domainFile = join(temporaryRoot, "domain-strategy.yaml");
   await writeFile(domainFile, domainSource);
-  const domainDecision = buildDecisionFixture(join(temporaryRoot, "domain-decision"), { boundary: "gate.domain-strategy-approved", subjectRef: domainFile });
+  const domainDecision = buildDecisionFixture(join(temporaryRoot, "domain-decision"), { boundary: "check.domain-strategy-approved", subjectRef: domainFile });
   const domainApproval = parseDocument(await readFile(join(testsRoot, "fixtures/domain-strategy-approval.yaml"), "utf8")).toJS();
   await writeFile(domainApprovalRef, JSON.stringify({ ...domainApproval, subject_ref: domainFile, approval_scope: domainDecision.requirement.scope, user_decision_ref: domainDecision.ref }));
   const pass = run(validator, domainFile, temporaryRoot);
@@ -123,7 +123,7 @@ try {
     .replace("<domain-strategy-digest>", digestYaml(domainSource));
   const packageFile = join(temporaryRoot, "stage-decision.yaml");
   await writeFile(packageFile, packageSource);
-  const packageDecision = buildDecisionFixture(join(temporaryRoot, "package-decision"), { boundary: "gate.stage-decision-package-approved", subjectRef: packageFile });
+  const packageDecision = buildDecisionFixture(join(temporaryRoot, "package-decision"), { boundary: "check.stage-decision-package-approved", subjectRef: packageFile });
   const packageApproval = parseDocument(await readFile(join(testsRoot, "fixtures/stage-decision-approval.yaml"), "utf8")).toJS();
   await writeFile(packageApprovalRef, JSON.stringify({ ...packageApproval, subject_ref: packageFile, approval_scope: packageDecision.requirement.scope, user_decision_ref: packageDecision.ref }));
   const packagePass = run(packageValidator, packageFile, temporaryRoot);

package/template/.agents/skills/yss-ui/assets/docs/guide/llms.md

@@ -28,7 +28,7 @@ LLMs.txt 是一个专门为大语言模型设计的文档格式规范。通过
 包含所有组件的完整 API 文档、使用示例和最佳实践。**强烈推荐**作为默认配置，因为：
 - ✅ **更准确的代码生成** - AI 能看到完整的 Props、Events、Slots 定义
 - ✅ **真实示例参考** - 包含实际使用代码，避免 AI 猜测用法
-- ✅ **完整上下文** - 现代 AI 工具（Claude 200K、GPT-4 128K）完全支持这个大小
+- ✅ **完整上下文** - 现代 AI 工具的大上下文窗口可完整加载文档
 
 ### 轻量级索引：llms.txt
 
@@ -96,60 +96,6 @@ Always reference the YSS UI documentation when working with components:
 
 ---
 
-### Claude Code
-
-在 Claude Code 中，将 LLMs.txt 添加到工作区的知识库（Docs / Context Files）配置中，即可在代码补全与解释时引用其中的内容。
-
-**使用方法：**
-
-1. 打开 Claude Code 设置
-2. 找到 "Docs / Context Files" 配置
-3. 添加 `http://192.168.164.27:3200/llms-full.txt`
-
-<a href="https://code.claude.com/docs" target="_blank">详细了解 Claude Code 文档上下文配置</a>
-
----
-
-### Trae
-
-在 Trae 中，将 LLMs.txt 文件放入项目的 knowledge sources 并在设置里开启引用。
-
-**使用方法：**
-
-1. 打开 Trae 项目设置
-2. 找到 "Knowledge Sources" 配置
-3. 添加 `http://192.168.164.27:3200/llms-full.txt`
-4. 启用该知识源
-
-<a href="https://trae.ai/docs" target="_blank">详细了解 Trae 的知识源功能</a>
-
----
-
-### Qoder
-
-在 Qoder 中，可以在 `.qoder/config.yml` 中添加 LLMs.txt 作为外部知识文件，或在对话中通过 `@docs` 进行临时引用。
-
-**使用方法 1：配置文件**
-
-在项目根目录创建 `.qoder/config.yml`：
-
-```yaml
-knowledge:
-  external_docs:
-    - url: http://192.168.164.27:3200/llms-full.txt
-      name: YSS UI Documentation
-```
-
-**使用方法 2：临时引用**
-
-```
-@docs http://192.168.164.27:3200/llms-full.txt
-```
-
-<a href="https://docs.qoder.com/" target="_blank">详细了解 Qoder 配置方法</a>
-
----
-
 ### 其他 AI 工具
 
 任何支持 LLMs.txt 的 AI 工具均可使用以上路径来更好地理解 YSS UI。

package/template/.codex/skills/maintaining-skills/SKILL.md

@@ -17,7 +17,7 @@ Create skills that add useful, non-obvious guidance without constraining unrelat
 6. Follow the repository's declared maintenance and review policy. If none exists, run structural validation plus focused checks of the behavior or invariant changed. Use independent forward testing only when complexity or risk makes it meaningful; do not require a failing baseline for every ordinary edit.
 7. After changes, validate frontmatter, naming, references, scripts, projections, locks, and affected callers. Retire obsolete names and resources unless the repository explicitly requires compatibility.
 8. When a repository declares staged template verification, default the implementation loop to its fast impact profile and stop at `implementation-ready`. Promote explicitly to `review-ready`; do not create frozen candidates, review packages, or release evidence during ordinary iteration. Unknown paths and changes to the verification framework itself must fail safe to the full profile.
-9. For L3 template maintenance, record maintainer self-check plus fresh verification and do not create a frozen candidate or formal independent review during ordinary iteration. Before release, run the repository's full `scripts/verify-template` gate once; historical formal-review records remain read-only compatible.
+9. For template maintenance, let the repository intensity policy determine verification evidence. Independent review is opt-in, never implied by an intensity level; record maintainer self-check and the required fresh verification without creating a frozen candidate during ordinary iteration. Before release, run the repository's full `scripts/verify-template` gate once; historical formal-review records remain read-only compatible.
 
 ## Boundaries
 

package/template/.codex/skills/prototype-review/SKILL.md

@@ -5,7 +5,7 @@ description: Use when independently reviewing low-fidelity UI, interaction specs
 
 # Prototype Review
 
-Use this skill as the independent low-fidelity review in `yss-prototype-stage`. The review is fail-closed: if the design cannot drive calibrated requirements, API, frontend acceptance, and slices, send it back to product design. `yss-product-lifecycle` alone records the resulting `gate.prototype-reviewed` decision.
+Use this skill as the independent low-fidelity review in `yss-prototype-stage`. The review is fail-closed: if the design cannot drive calibrated requirements, API, frontend acceptance, and slices, send it back to product design. `yss-product-lifecycle` alone records the resulting `check.prototype-reviewed` decision.
 
 ## Trigger Boundary
 
@@ -17,7 +17,7 @@ Run this independent gate only when UI changes affect a primary user flow, navig
 - `docs/.scratch/<feature>/design/<feature>-interaction-spec.md` or prototype link.
 - State matrix, preferably based on `docs/design/templates/state-matrix-template.md`.
 - Existing OpenAPI Draft only if the review is checking alignment; do not require OpenAPI before product design.
-- `docs/.scratch/<feature>/verification/prototype-evidence.yaml` may be created as a pending schema v3 record, but档位构建与浏览器验证属于后续 `gate.prototype-verified`。
+- `docs/.scratch/<feature>/verification/prototype-evidence.yaml` may be created as a pending schema v3 record, but档位构建与浏览器验证属于后续 `check.prototype-verified`。
 
 ## Review Gates
 
@@ -66,7 +66,7 @@ Run this independent gate only when UI changes affect a primary user flow, navig
 - <component states, data dependencies, profile triggers, frontend acceptance notes>
 
 ### Lifecycle Evidence
-- <persistent review path; blockers; `gate.prototype-reviewed` candidate result>
+- <persistent review path; blockers; `check.prototype-reviewed` candidate result>
 
 ### Next Action
 - <yss-prototype-stage / return to product design>

package/template/.codex/skills/setup-matt-pocock-skills/SKILL.md

@@ -21,7 +21,7 @@ This is a prompt-driven skill, not a deterministic script. Explore, present what
 Look at the current repo to understand its starting state. Read whatever exists; don't assume:
 
 - `git remote -v` and `.git/config` — is this a GitHub repo? Which one?
-- `AGENTS.md` and `CLAUDE.md` at the repo root — does either exist? Is there already an `## Agent skills` section in either?
+- Root `AGENTS.md` — does it exist, and is there already an `## Agent skills` section?
 - The case-sensitive `CONTEXT.md` at the Git repository root; also detect lowercase, nested, or duplicate context files as migration problems
 - `docs/adr/` and any `src/*/docs/adr/` directories
 - `docs/agents/` — does this skill's prior output already exist?
@@ -72,7 +72,7 @@ If the root `CONTEXT.md` is missing, initialize it with `context_schema_version:
 
 Show the user a draft of:
 
-- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
+- The `## Agent skills` block to add to `AGENTS.md`
 - The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed)
 
 Let them edit before writing.
@@ -81,11 +81,8 @@ Let them edit before writing.
 
 **Pick the file to edit:**
 
-- If `CLAUDE.md` exists, edit it.
-- Else if `AGENTS.md` exists, edit it.
-- If neither exists, ask the user which one to create — don't pick for them.
-
-Never create `AGENTS.md` when `CLAUDE.md` already exists (or vice versa) — always edit the one that's already there.
+- If `AGENTS.md` exists, edit it.
+- If it is missing, ask before creating it.
 
 If an `## Agent skills` block already exists in the chosen file, update its contents in-place rather than appending a duplicate. Don't overwrite user edits to the surrounding sections.
 

package/template/.codex/skills/triage/AGENT-BRIEF.md

@@ -1,6 +1,6 @@
 # Writing Agent Briefs
 
-An agent brief is a structured comment posted on a GitHub issue or PR when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original body and discussion are context — the agent brief is the contract.
+在 YSS 中，简报是回交生命周期的取证与工作建议，不是正式 Spec 或 Slice Implementation Contract，也不授予 `ready-for-agent`。正式实现必须引用生命周期批准且当前的切片合同；发布评论另需明确授权。
 
 The brief states **what the agent should do**, which stretches to both surfaces: for an issue, that's building the change from nothing; for a PR, it's what's left to do *to the existing diff* — finish it, close gaps, address review points. Same principles either way; the PR example below shows the difference.
 
@@ -12,7 +12,7 @@ The issue may sit in `ready-for-agent` for days or weeks. The codebase will chan
 
 - **Do** describe interfaces, types, and behavioral contracts
 - **Do** name specific types, function signatures, or config shapes that the agent should look for or modify
-- **Don't** reference file paths — they go stale
+- 必须保留当前证据路径、版本和批准合同引用；恢复时检查新鲜度，不把旧路径当作当前事实。
 - **Don't** reference line numbers
 - **Don't** assume the current implementation structure will remain the same