openyida 2026.10.21 → 2026.10.22

package/yida-skills/skills/yida-density/SKILL.md

@@ -68,7 +68,11 @@ const DENSITY_CONFIG = {
 
 ## React Hooks 实现
 
-在 Canvas 中用 `matchMedia` + hooks 管设备变化。不要在首次渲染时读一次宽度后永不更新。
+在 Canvas 中分别处理密度选择和布局宽度：
+
+- `matchMedia` + hooks 监听浏览器视口或输入方式的变化。下方示例用视口宽度切换密度；触控能力按对应媒体条件判断。
+- 页面分栏、筛选栏和主辅面板按实际内容容器宽度重排，iframe、侧栏或抽屉均读取自身可用空间。
+- 按 [共享响应式规则](../yida-design/references/responsive-layout.md#复用模板与-cli-诊断) 优先用 CSS 重排。需要参考时执行 `openyida sample openyida-page-template canvas-responsive-layout`，按需复用布局片段；组件需要读取实际宽度时，再复用带清理的测量 Hook，持续响应容器变化。
 
 ```jsx
 import React, { useEffect, useMemo, useState } from 'react';
@@ -155,3 +159,4 @@ export function didMount() {
 - 移动端固定 `spacious` 且隐藏切换 UI。
 - 所有密度相关值来自统一 token。
 - `matchMedia` 监听或其他响应式副作用有 cleanup。
+- 桌面宽视口中的窄 iframe、侧栏和抽屉按自身宽度重排；分别验证设备对应的密度和容器对应的布局。

package/yida-skills/skills/yida-design/SKILL.md

@@ -20,7 +20,7 @@ description: >
 
 所有页面按[任务驱动的视觉设计](references/task-driven-visual-design.md)从主要任务和信息关系推导表达、构图与视觉重点，主动判断图片的识别、解释和氛围价值，再确定密度与降级。
 
-自定义页面按 [响应式布局](references/responsive-layout.md) 明确容器宽度变化后的换行、堆叠、控件对齐和局部滚动；等高只用于宽屏下需要成组展示的面板，窄屏恢复自然高度。
+自定义页面按 [响应式布局](references/responsive-layout.md) 先明确任务和需要同时看见的信息，再安排宽屏、窄容器和触屏下的内容与操作。结果写入已有首屏焦点、布局、主操作、响应式和验收字段。宽屏中需要成组展示的面板可等高，窄屏随内容自然增长。
 
 **阅读无障碍是页面设计的基本要求。** 导航、正文、表单、详情、报表及抽屉等浮层都要让用户看得清、读得懂，放大或使用读屏时仍能获取完整信息。不能为风格、密度或装饰牺牲阅读；按 [阅读无障碍门禁](references/page-quality-gates.md#阅读无障碍门禁) 将具体要求写入页面设计与验收。
 

package/yida-skills/skills/yida-design/references/responsive-layout.md

@@ -1,15 +1,44 @@
 # 自定义页面响应式布局
 
-设计、Canvas、历史 JSX 和已有页面美化共用本规则。响应式先保证内容与操作在当前容器中可用；等高只用于宽屏下需要成组展示的面板，不要求所有区块一样高。保留项目主题和密度，规则适用于门户、工作台、列表、详情以及抽屉中的自定义内容。
+设计、Canvas、历史 JSX 和已有页面美化共用本规则。让内容和操作适应当前容器，保留项目主题和密度。门户、工作台、列表、详情和抽屉中的自定义内容均按下文设计、实现和验收。
 
-## 先确定可用宽度和重排方式
+## 先确定任务与各场景的呈现
 
-在已有 `design.md` 的布局、响应式和验收段落写清：哪些区域并排、何时换行或堆叠、堆叠后的顺序、表格如何滚动、哪些面板需要等高。不新增一份设计文件，不用“支持移动端”代替具体行为。
+Fast、Plan 和单页设计共用以下五步。先读 PRD 中的用户、页面任务、必要信息和操作，再决定各场景的布局。结果统一写入下方已有设计字段。
 
-- 按内容容器的实际宽度设计，考虑平台侧栏展开/收起、拖拽调宽、抽屉和 iframe；不能只按设备名或屏幕宽度判断。宽屏中的窄抽屉也可能需要单列。
-- 根据控件最小可用宽度、文字长度、列间距和主内容阅读宽度决定重排点。复用已有项目断点；断点未定义时按实际内容确定并记录，不把固定的手机/平板分界当作所有页面的标准。
+1. **明确任务和必要信息**：判断本页主要用于识别、比较、分析、逐条处理还是录入，列出行动前需要同时看见的信息。根据已有需求说明选择依据；断点和组件由 Agent 判断。仅在缺失事实会改变任务或范围时向用户澄清。
+2. **安排首屏与主操作**：写清宽屏和窄容器中首先展示的业务内容、主操作位置。为核心内容保留首屏空间，按实际需要分配标题、装饰和筛选区的高度。筛选较多时，可外露常用条件，将低频条件放入展开区，并保留展开入口、已选条件和清除方式。主按钮随操作路径放置，固定底部只用于适合的场景。
+3. **按信息关系选择形式**：跨记录比较优先使用对齐表格并保留记录标识；逐条处理可使用摘要列表与详情，写清摘要字段和完整信息入口。趋势图随空间调整图例、标签密度和注释，完整数据保持可查。表格转摘要、筛选收纳均按本页任务选择。
+4. **分别处理空间和输入方式**：按容器宽度决定并排、堆叠和比例，按触控、键盘、悬停能力及可用高度调整操作。桌面窄抽屉和手机可以共用单列布局，各自保留适用的交互；触屏空间充足时也可并排。手机操作提供直接点击的入口，并检查软键盘、安全区域、可见焦点和触控间距。
+5. **保持风格和操作状态**：各场景沿用文字层级、色彩用途、形状和分组，按任务调整密度与比例。正文和表单限制阅读宽度，比较型工作区利用可用宽度，辅助面板按内容确定宽度。返回列表或放宽容器后，恢复筛选、页码、选中项、草稿和焦点。
+
+### 写入已有设计字段
+
+| 已有字段 / design.md 要点 | 写入内容 |
+| --- | --- |
+| `firstScreenFocus` / 首屏焦点 | 首先看到的业务对象、判断信息及强调方式；窄屏如何保持重点 |
+| `layout` / 布局 | 区块主次、需同时可见的信息、宽度依据，以及内容变多或文字变长时的排列方式 |
+| `primaryAction` / 主操作 | 主次动作位置、收纳入口、反馈与返回路径 |
+| `responsive` / 响应式 | 宽屏、窄容器、触屏的实际变化和理由；重排条件、信息入口及状态保留 |
+| `acceptanceChecks` / 验收 | 具体操作和预期结果，覆盖核心内容、长内容、完整操作路径和状态保留 |
+
+例如财务对账页可写：“核对账面金额与实收金额，差额列与记录标识相邻；窄容器仍保留列对齐，表格局部横滑且有剩余列提示。查询为主操作，清空为次操作；宽窄切换后已选记录和筛选值不变。”逐条处理页则可选择摘要与详情。按这种具体程度描述当前页面，配色、布局和业务字段沿用本页设计。
+
+### 新建与已有页面的边界
+
+- 新页面在已授权任务和平台能力内设计呈现方式。
+- 已有页面保留原字段、操作、模块、权限和业务状态。折叠内容提供明确入口，所有宽度下均可访问完整信息；禁止用宽度变化静默删除内容。
+- 调整表格形式、筛选收纳或打开方式前，先写入设计并按已有页面优化流程确认、备份后实施。尚未确认这些调整时，沿用原表现，仅作换行、堆叠和局部滚动。
+- 超出 UI 范围的交互或业务变更交回 PRD，获得相应授权后再实施；响应式改造授权不包含业务变更。
+
+## 再确定可用宽度和重排方式
+
+在已有 `design.md` 的布局、响应式和验收段落写清：哪些区域并排、何时换行或堆叠、堆叠后的顺序、表格如何滚动、哪些面板需要等高。设备适配说明复用这份文档和已有字段，写出具体行为。
+
+- 按内容容器的实际宽度设计，覆盖平台侧栏展开/收起、拖拽调宽、抽屉和 iframe。宽屏中的窄抽屉也按自身空间选择单列或并排。
+- 根据控件最小可用宽度、文字长度、列间距和主内容阅读宽度决定重排点。优先复用项目断点；项目未定义时，按本页内容确定并记录。
 - 优先用 Grid/Flex 的自动换行和可收缩列解决布局；子项设 `min-width: 0`，需要弹性宽度的网格列使用 `minmax(0, 1fr)`。仍需分级变化时，在运行环境支持的前提下使用容器查询；使用媒体查询时额外核验窄抽屉等容器场景。
-- 重排保持业务阅读顺序、DOM 顺序和键盘焦点顺序一致，不用 CSS `order` 制造视觉顺序与操作顺序相反的布局。不因宽度变化隐藏原有字段、操作或模块。
+- 重排保持业务阅读顺序、DOM 顺序和键盘焦点顺序一致；使用 CSS `order` 时也核对这三种顺序。原有字段、操作和模块保持可达，收纳内容遵守上方确认与入口规则。
 
 ## 筛选栏和组合控件
 
@@ -17,38 +46,56 @@
 | --- | --- |
 | 足够并排 | 标签和控件分层排列；同一行控件外框上下边缘对齐，按钮与输入控件底边对齐 |
 | 一行放不下 | 字段组自然换行，操作区跟随换行；保留字段最小可用宽度，按钮文案完整可见 |
-| 窄容器 | 字段按顺序纵向排列并撑满可用宽度；查询、清空等操作按可用空间并排或换行，不挤出容器 |
+| 窄容器 | 字段按顺序纵向排列并撑满可用宽度；查询、清空等操作在容器内并排或换行 |
 
-- 同组 Input、Select、日期控件和 Button 使用一致的组件尺寸与主题高度；统一标签字号、行高和标签到控件的间距。`Input.Search` 等组合控件同时检查外层、内部输入框、附加按钮和图标，不能只改外层高度。
-- 标签、控件、帮助/错误信息分别占自己的布局位置。同排字段可共享标签行和控件行；长标签换行时由布局容纳最高标签，按钮仍按控件行定位，不能用各字段整个盒子的底边对齐导致错误信息把输入框顶歪。
-- 无标签的操作区按控件行定位，不插入可读的假标签、连续空格或固定 `margin-top` 凑齐。帮助/错误信息在控件下自然增长，不覆盖下一行。
-- 单行控件按主题高度保持一致；多行输入、长标签和反馈内容允许增长。不能为等高裁切文字，也不能缩小字体或压缩点击区域来维持一行。
-- CSS 仅作用于当前页面或组件作用域；组件库内部结构使用当前版本支持的配置/样式入口，不能用全局 input/button 选择器改变原生表单。
+- 同组 Input、Select、日期控件和 Button 使用一致的组件尺寸与主题高度；统一标签字号、行高和标签到控件的间距。`Input.Search` 等组合控件一起检查外层、内部输入框、附加按钮和图标的尺寸。
+- 标签、控件、帮助/错误信息各占独立布局位置。同排字段可共享标签行和控件行；标签行容纳最长标签，按钮与控件行对齐。错误信息在控件下方展开，输入框继续保持对齐。
+- 无标签的操作区直接用布局对齐控件行。对齐由 Grid/Flex 完成，标签、空格和外边距仅承担各自的内容或间距用途。帮助/错误信息随内容增长，并为下一行留出空间。
+- 单行控件按主题高度保持一致；多行输入、长标签和反馈内容自然增长。空间不足时换行或堆叠，保留完整文字、可读字号和可用点击区域。
+- CSS 限定在当前页面或组件内；组件库内部结构使用当前版本支持的配置/样式入口。禁止用全局 input/button 选择器改变原生表单。
 
 ## 主辅面板与分页
 
-- 宽屏下，同一排且需要形成整体的主辅面板采用 Grid/Flex 拉伸外框；卡片内部纵向排列，主体可伸展，分页/底部操作用剩余空间置底。表格行和列表项保持自然高度，不跟着面板平均拉长。
-- 不写死面板像素高度，不用脚本测量另一张卡片再复制高度，不用空占位、假数据或巨大外边距补齐。不相关区块、连续文章和瀑布流不强制等高。
+- 宽屏下，同一排且需要形成整体的主辅面板采用 Grid/Flex 拉伸外框；卡片内部纵向排列，主体可伸展，分页/底部操作用剩余空间置底。表格行和列表项保持自然高度。
+- 面板高度由真实内容和 CSS 布局决定，等高交给 Grid/Flex。独立区块、连续文章和瀑布流保持各自的自然高度。禁止添加假数据填补空白。
 - 宽度不足时主辅面板转为上下排列；按已确定的任务顺序展示，清除用于桌面等高的固定高度、最小高度和空白占位。单列时各面板由实际内容决定高度，分页接在内容之后。
-- 内容差异过大时调整列宽、分组或堆叠时机，不能为了底边对齐留下整块空白。布局改变不允许增减记录、修改 `pageSize`、排序、筛选或分页状态。
-- 未设计独立滚动的卡片不增加内部滚动条；工作区本来有受限高度时，按 [页面与导航连续性](page-continuity.md) 保持完整可收缩高度链和单一主滚动区域。
+- 内容差异过大时调整列宽、分组或堆叠时机，使空白与实际内容相称。布局改变时保留记录、`pageSize`、排序、筛选和分页状态，禁止为对齐改动业务数据。
+- 卡片默认随页面滚动，独立滚动仅用于已明确设计的区域。工作区本来有受限高度时，按 [页面与导航连续性](page-continuity.md) 让各级父子容器都可收缩，并保持单一主滚动区域。
 
 ## 内容增长、表格与浮层
 
 - 长标题、帮助文字和错误信息自然换行；无空格的长编号或链接设置合适的断行策略。只在已有明确设计允许时省略文字，并保留完整内容的访问方式。
-- 宽表格保留列、数据和操作，通过表格自己的容器横向滚动；父级可收缩，不把整个页面撑宽，不用页面级 `overflow: hidden` 掩盖溢出。键盘操作、固定列和行内按钮仍应可达。
-- 空数据、加载、错误和正常内容使用同一外部布局；空态保留必要上下文并按内容收敛，不保留为多条数据写死的高度。加载只替换内容，不重建查询状态。
-- 抽屉和弹窗中的自定义内容也按自身宽度重排。检查下拉面板、日期面板和提示是否被裁切；不通过修改平台父容器或跨 iframe 注入样式解决局部布局问题。
-- 优先保留同一组件树做 CSS 重排，不因断点切换组件 `key` 或重新挂载业务区域；筛选、页码、选中项、未提交内容和焦点不得因此丢失，也不能触发额外请求。
+- 宽表格保留列、数据和操作，通过表格自己的容器横向滚动；父级保持可收缩，页面宽度适应容器。出现溢出时修正列宽与容器布局，保持完整内容、键盘操作、固定列和行内按钮可达。
+- 空数据、加载、错误和正常内容使用同一外部布局。空态保留必要说明和操作，高度随实际内容收敛；加载时替换内容区并保留查询状态。
+- 抽屉和弹窗中的自定义内容按自身宽度重排，检查下拉面板、日期面板和提示能完整显示。局部问题在当前页面内修复，禁止修改平台父容器或跨 iframe 注入样式。
+- 优先保留同一组件树，用 CSS 调整排列，保持组件 `key` 和业务区域挂载状态稳定。切换宽度后，筛选、页码、选中项、未提交内容和焦点保持，原请求及触发次数不变。
+
+## 复用模板与 CLI 诊断
+
+Canvas 页面先按当前设计组织内容，需要参考实现时获取模板，并按需复用其中的布局片段：
+
+```bash
+openyida sample openyida-page-template canvas-responsive-layout --output .cache/samples/canvas-responsive-layout.jsx
+```
+
+模板提供筛选排列、主辅布局、局部滚动和命名容器查询等独立片段。只选取当前业务需要的片段，保留原业务组件树。断点使用本页内容的最小可用宽度，模板数值仅供参考。
+
+优先用 CSS 完成重排。图表等组件需要读取实际宽度时，再复用 `useContainerLayout`；它会合并同一帧的测量通知，并在卸载时清理监听。图表收到容器宽度变化后调用自身 `resize`，尺寸随容器持续更新。
+
+设计决定页面结构，模板提供实现参考。CLI 检查确定的工程风险，首屏重点和视觉效果通过实际页面另行验收。
+
+`openyida compile <页面.canvas.jsx> --json` 与普通页面的 `check-page` 会给出以下非阻断诊断：只按视口宽度重排、`ResizeObserver` 未清理、480px 以上固定宽度、整页 `scale/zoom`。这些诊断为 warning，需按页面用途判断。确认属于视口级抽屉、固定画布等合理用法后，再使用消息中的 `openyida-responsive-*-ok` 标记；普通布局问题先修复，禁止用标记跳过问题。
 
 ## 实际页面验收
 
-按本页实际布局检查以下组合，记录容器宽度和结果；不以截图尺寸或编译通过代替运行态证据：
+按本页实际布局检查以下组合，记录实际容器宽度、操作和结果。编译、截图和交互检查分别记录，只有执行过的检查才能标为通过：
 
 1. 宽屏、每个重排点前后及目标最窄容器；同时测试平台侧栏展开/收起和实际抽屉调宽。缩窄后再放宽，布局能恢复，无页面整体横向溢出。
 2. 短/长标签、长标题和帮助/错误信息：标签与控件层次清楚，同排控件边缘一致，搜索组合按钮等高，操作无裁切或遮挡。
-3. 主辅面板内容一多一少：宽屏需要等高的外框共边，分页位置合理；单列无多余高度，行高不被拉伸，不靠假内容填空。
+3. 主辅面板内容一多一少：宽屏需要等高的外框共边，分页位置合理；单列随真实内容自然增长，表格行和列表项保持自然高度。
 4. 正常多条、单条、空数据、加载和失败状态；宽表格只在自身容器横向滚动，完整字段与操作仍可达。
 5. 键盘遍历、放大文字或浏览器缩放后，内容与操作仍可用；调整宽度前后的筛选、分页、选择和草稿保持，原事件、请求参数及触发次数不变。
+6. 至少记录 360、600、768、1024、1280、1600px 及实际重排点前后；这些数值用于测试覆盖，布局断点仍按本页内容确定。桌面宽视口中另测同样宽度的侧栏、抽屉或 iframe，确认布局随内容容器变化。
+7. 按本页主任务实际走一遍：找到判断信息、执行主操作、展开收纳内容、返回原位置。对比同宽桌面容器与触屏，确认操作可直接点击；真实移动端另验软键盘、安全区域和焦点。用截图判断视觉层级，用真实操作验证功能；禁止仅凭生成文案、静态断言或截图评分宣称运行态通过。
 
 已有页面按 UI 美化流程先展示宽窄两种效果及必要的换行状态，经确认、备份后实施。只检查过源码或示意图时标记“响应式待运行态验证”；用本地样例或只读方式准备状态，不提交真实业务数据来制造测试场景。

package/yida-skills/skills/yida-design/references/task-driven-visual-design.md

@@ -48,6 +48,8 @@ Fast、Plan 和已有页面优化共用这套推导方法。先读取真实需
 5. **排版节奏**：标题、核心数值、正文、元信息有可辨层级；同类信息对齐，组内紧凑、组间清楚。密度随阅读、比较或操作任务变化。
 6. **视觉特征**：从已有内容发展一处有意义的特色，例如对象图文组合、关键变化对比或连贯的章节排版。特色服务当前任务，不靠增加业务模块、随机装饰或重复大卡片制造丰富感。
 
+按[响应式决策](responsive-layout.md#先确定任务与各场景的呈现)安排宽屏、窄容器和触屏的展示：保持文字层级、色彩用途、形状和分组，按任务调整比例、密度和操作位置。空间变化时可重新安排首屏重点，并保留判断所需的信息和完整访问入口。卡片、Hero 和 KPI 组按实际内容选用。
+
 已有品牌或明确风格时在其范围内完成这些决策，不自动统一成浅色商务风。没有独立图片的页面也应通过构图和排版成立。
 
 ## 5. 交接具体决策并验证

package/yida-skills/skills/yida-design/sub_skill/yida-design-plan/SKILL.md

@@ -25,6 +25,7 @@ description: Plan 模式的视觉设计分支。基于需求选择视觉方向
 
 1. 读取 CLI 返回的 `authoring-context.md` 与 [紧凑计划契约](references/build-plan-compact-schema.md)，沿用 pageId 和 sceneKey。
 2. 工作台沿用 PRD 的业务内容和表现建议。为每个真实自定义页填写 `firstScreenFocus`、`layout`、`primaryAction`、`responsive` 与 `acceptanceChecks`；前四项为具体非空说明，验收为非空字符串数组。公共主题不能代替这些决定。纯原生表单应用不增加虚构页记录。
+   按[响应式决策与字段映射](../../references/responsive-layout.md#写入已有设计字段)在这五个字段内写清：宽屏、窄容器和触屏各展示什么、怎样操作、何时重排、保留哪些状态，以及选择依据。Fast 与单页设计写入相同的 `design.md` 要点。
 3. 按 [整体主题规则](../../references/application-theme-consistency.md#导航与应用框架) 核对导航、应用框架、原生表单、记录详情与自定义页面的配色、形状、文字、间距和状态。每项必须保留 `visualMemoryApplications` 数组；没有匹配的主题记忆点时填写 `[]`，不要省略或写成字符串。按实际内容补页面局部差异与素材策略。完整主题由 CLI 注入，复杂组件定制时再读模板对应章节。
 4. 全局和局部 token 遵守 [基础变量契约](../../templates/design-themes/basic-tokens.json)，明确项目差异写 `visualStyle.tokens`，主色写 `forUser.colorStrategy.primaryColor`；沿用主题的字号、间距和组件圆角。
 5. CLI 按 [公共输出契约](../../workflow/output-design.md) 生成 frontmatter、anchor 索引和五章正文，并调用同一 `check-design` 校验。缺少逐页决定时只保留可预览草稿，补齐后再生成最终产物；旧计划同样不得以继承主题套话补过门槛。

package/yida-skills/skills/yida-design/sub_skill/yida-design-plan/references/build-plan-compact-schema.md

@@ -97,7 +97,7 @@ CLI 校验源事实，使用预置模板整批生成 `prd.md`、`design.md` 和
     "navigationStyle": {"structure":"side","tone":"light","toneSource":"theme_derived","source":"user_selected","selectionReason":"沿用已选的左侧导航；浅色导航由主题模板派生"},
     "iconSystem": {"library":"lucide-react","mappings":{"新建采购":"Plus"}},
     "pageApplications": [
-      {"pageId":"page-1","primaryAction":"列表标题右侧的新建采购按钮打开原生采购表单，成功后刷新列表","firstScreenFocus":"先看到待处理采购数量与最紧急记录，主操作紧邻列表标题","layout":"顶部单行筛选与主操作，下方连续采购列表；必要提示放列表右侧窄栏，列表随记录自然增长","responsive":"窄屏筛选换行，提示移到列表下方，表格保留关键列并允许横向滚动","acceptanceChecks":["首屏可找到待处理记录与新建采购操作","窄屏主操作和错误恢复入口可用"],"visualMemoryApplications":[{"name":"摘要拼接组","renderPolicy":"prd_match_only","target":"采购待办摘要","reason":"页面已有并列的待办状态"}]}
+      {"pageId":"page-1","primaryAction":"列表标题右侧的新建采购按钮打开原生采购表单，成功后刷新列表","firstScreenFocus":"先看到待处理采购数量与最紧急记录，主操作紧邻列表标题","layout":"按供应商比较金额与交付日期，相关列对齐；主表利用可用宽度，提示区按内容限宽，空间不足时下移","responsive":"比较任务在窄容器仍保留全部表格列，标识列保持可辨，表格局部横滑并提示剩余内容；筛选换行，提示移到表格下方；手机的详情入口无需悬停，返回后保留筛选与选中记录","acceptanceChecks":["宽屏和窄容器均可定位最紧急记录及新建采购入口","在360px容器查看完整金额与交付日期，页面不整体横滑","打开详情再返回、缩窄再放宽后筛选值和选中记录不变"],"visualMemoryApplications":[{"name":"摘要拼接组","renderPolicy":"prd_match_only","target":"采购待办摘要","reason":"页面已有并列的待办状态"}]}
     ],
     "assetStrategy": {"materialStatus":"none","pages":[{"pageId":"page-1","imageNeed":"none","reason":"纯数据操作页","slots":[]}],"missingAssets":[],"notes":"无图片需求"}
   },

package/yida-skills/skills/yida-design/workflow/output-design.md

@@ -80,8 +80,8 @@
 | 表面与组件 | 各区块如何消费共享表面、边界、字体和组件规则；明确局部差异与特色配方位置 |
 | 主操作 | 主次动作的位置、入口与反馈，保留表单、详情及现有业务功能契约 |
 | 状态 | 当前页加载、空、错、无权限等实际反馈与恢复动作；公共状态用 anchor 引用，业务文案就近补充 |
-| 响应式 | 按 [共享布局规则](../references/responsive-layout.md) 写清实际容器的重排条件与顺序、筛选换行、面板等高解除、表格局部滚动和触控方式 |
-| 验收 | 焦点、内容、布局、主题、交互、素材与状态的可检查结果 |
+| 响应式 | 按 [共享布局规则](../references/responsive-layout.md) 写清宽屏、窄容器和触屏各展示什么、怎样操作、何时重排、保留哪些状态及选择依据；按需说明筛选换行、恢复自然高度和局部滚动 |
+| 验收 | 写出检查动作和预期结果，覆盖焦点、内容、布局、主题、交互、素材和状态；实际走通查找信息、执行操作、展开内容和返回页面的路径，分别记录待检查项与已执行证据 |
 
 页面外壳、焦点、主要内容、动作区、上下文与反馈这些设计含义都要覆盖；不要求创建同名 JSON/YAML 字段。尺寸和间距优先引用已定义 token，只有项目确实需要的数值差异才另外写明。不能仅写“按主题执行”，也不能把公共组件全文复制到每一页。
 

package/yida-skills/skills/yida-design/workflow/step-1-read-brief.md

@@ -7,6 +7,8 @@
 1. 文件存在且 JSON 可解析，`schemaVersion=1`。
 2. 读取行业、目标用户、业务目标、核心功能、业务对象、页面场景、品牌和色彩偏好。
 3. 读取 `userTasks` 和 `entryRecommendation`，沿用规划准备写入的导航决策，服务与管理体验按实际任务设计；平台导航或自定义导航不再交给用户选择。按已确认范围设计；自定义页面生成逐页场景规则，表单与流程沿用应用主题。
+   - 读取已有的使用环境、操作频率、需同时查看的信息和任务中断后的返回要求，区分桌面工作区、嵌入式窄容器和手机触控。
+   - 优先依据现有上下文作出选择并记录理由。环境未知时注明假设，同时覆盖宽窄布局；禁止将假设标为用户已确认事实。
 4. 会改变视觉方向的 `openQuestions` 未解决时，暂停生成视觉设计并交回 `yida-app` 处理。
 
 ## 产出

package/yida-skills/skills/yida-design/workflow/step-4-wireframe-interaction.md

@@ -1,19 +1,19 @@
 # 页面结构和交互设计
 
-按 [共享响应式布局](../references/responsive-layout.md) 确定容器宽度变化后的筛选换行、主辅堆叠、等高范围、自然增长和表格局部滚动；在本页设计中写出具体重排条件与顺序。
+按 [共享响应式布局](../references/responsive-layout.md) 先确定任务、必要信息、宽窄首屏和主操作，再安排各区块的排列与滚动方式。在本页设计中写清选择依据、重排条件和内容顺序。
 
-> 低保真不追求好看，先把结构、区块和操作路径定清楚。
+> 低保真阶段先确定结构、区块和操作路径，视觉样式在下一步细化。
 
 ## 画布局骨架
 
-页面设计按[任务驱动的视觉设计](../references/task-driven-visual-design.md)先确定识别、比较、变化、处理或叙事等信息关系，再选择图文、表格、图表或主从结构；以下骨架只是参考，不是固定套版。
+页面设计按[任务驱动的视觉设计](../references/task-driven-visual-design.md)先确定识别、比较、变化、处理或叙事等信息关系，再选择图文、表格、图表或主从结构。以下建议按本页任务选用。
 
-- 工作台：沿用 PRD 的业务内容和关系，由内容决定布局和组件，不预设双栏或列表组合。
-- 列表页：筛选区 + 工具栏 + 表格/卡片 + 分页 + 详情抽屉。
-- 详情页：对象 Hero + 摘要指标 + 分区信息 + 时间线/关联对象。
-- 看板页：KPI 卡组 + 图表组 + 排行/明细 + 刷新时间。
-- 大屏页：中心态势 + 左右信息塔 + 告警/趋势 + 投屏可读层级。
-- 官网页：首屏主张 + 产品/服务 + 过程/案例 + 信任背书 + CTA。
+- 工作台：沿用 PRD 的业务内容和关系，由内容决定布局和组件。
+- 列表页：跨记录比较时保持属性对齐，逐条处理时突出状态与动作；筛选、分页和详情入口按实际需求安排。
+- 详情页：围绕对象与决策依据组织摘要、分区、过程或关联信息；只有内容需要时使用 Hero 和指标。
+- 看板页：按需要判断的趋势、风险或差异组织指标与图表，按实际信息确定数量，并说明口径和更新时间。
+- 大屏页：依监控任务组织态势与异常，先保证投屏阅读距离和重点识别，再决定中心或分栏构图。
+- 官网页：围绕了解价值、查看案例、建立信任和采取行动组织内容；素材和章节随真实内容取舍。
 
 ## 自定义导航设计
 
@@ -56,7 +56,7 @@
 - 内容区块：<业务区块及目的、信息关系和表现形式；综合工作台参考 8-10 个独立业务区块，不凑数>
 - 主操作：<入口、按钮、下钻、提交、返回>
 - 功能契约：<保留的数据源/字段映射/按钮动作/筛选逻辑/提交 URL/权限/状态>
-- 响应式策略：<PC / 移动端差异>
+- 响应式策略：<宽屏、窄容器和触屏各展示什么、怎样操作、何时重排、保留哪些状态及选择依据>
 - 原生表单入口：<新增/提交/编辑打开方式>
 - pageSpecHandoff 草稿：<pageStructure/scene/contentBlocks/themeSummary/designFile/designRefs/dataBinding/primaryAction；视觉源码槽位待 UI 视觉设计阶段写入 design.md>
 ```

package/yida-skills/skills/yida-feedback/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: yida-feedback
-description: OpenYida 本地使用故障的根因分析、脱敏反馈包与 GitHub Issue/Fork PR 辅助。适用于反复报错、技能容易误用、用户不会提 issue/PR 或没有 GitHub 账号和源码时；普通宜搭产品 VOC 清单用 yida-voc。
+description: 帮用户描述 OpenYida 使用问题或体验建议，整理脱敏 Issue，并在用户愿意时协助个人 Fork PR。适用于反复报错、技能误用、不会提 issue/PR 或没有账号和源码时；普通宜搭产品 VOC 清单用 yida-voc。
 ---
 
 # 本地问题反馈与修复贡献
 
-用户只需描述“哪里出错了”。默认环境是 npm/插件安装，无 OpenYida Git 工作区、无上游写权限，也可能没有 GitHub 账号。不要以 Git、gh、源码或宜搭登录作为整理反馈的前置条件。
+用户描述问题，Agent 帮忙整理；用户愿意时，再一起尝试修复。默认用户通过 npm/插件安装，没有 OpenYida 源码、上游写权限或 GitHub 账号。整理反馈无需 Git、gh、源码或宜搭登录。
 
 ## 何时进入
 
-- 用户要求排查并反馈 OpenYida、整理 Issue、贡献修复或提 PR。
+- 用户要求排查并反馈 OpenYida、改善使用体验、整理 Issue、贡献修复或提 PR。可验证的小改进可直接提 PR，无需先建 Issue。
 - 当前会话同一操作已重复失败，或明确的 CLI/技能缺陷导致反复绕路时，停止无修改重试，先处理原任务，再简短建议整理反馈。自动进入只允许本地分析/草稿；不得自动登录、安装工具、联网提交或不断提醒。
 - 反馈建议前可读取 `openyida feedback status`；尊重当天/永久关闭。用户主动要求反馈不受提醒开关限制。同一会话同一问题只建议一次；当前上下文之外的发生频次写未知，不扫描完整历史。
 
@@ -17,7 +17,7 @@ description: OpenYida 本地使用故障的根因分析、脱敏反馈包与 Git
 
 ## 收集与根因分析
 
-1. 从当前会话提取目标、最短复现、期望与实际、报错关键片段、已尝试方法及其结果。先复用现有信息，确有阻碍时才询问缺失信息。
+1. 从当前会话提取目标、最短复现、期望与实际、报错关键片段、已尝试方法及其结果。先复用现有信息，确有阻碍时才询问缺失信息；体验建议写当前不便和理想结果，无需用户设计 CLI 参数或分析根因。
 2. `openyida --version`、`node -v` 可只读检查。只在定位必要时读取相关命令帮助、脱敏诊断和用户明确提供的最小文件。不遍历用户目录、环境变量、登录缓存、完整日志/会话或业务数据；不要把 `env`/`doctor` 整份输出塞进报告。不得因排障重放创建/发布/删除等写命令。
 3. 区分 CLI、skill、本地环境、平台接口或未知。逐项写“观察事实 → 根因假设 → 支持/反对证据 → 下一步验证”。能解释一个错误不代表已证明根因；没有复现/对照证据保留 hypothesis/unknown，缺失信息写未知。记录用户已验证的绕法和剩余影响。
 4. 平台接口拒绝、权限或版本限制按可观察响应反馈。用户不具备平台源码访问权限；不得寻找、索取、下载或暴露内部仓库名称、链接、源码、文件路径、内部处理人或工具。无公开可验证修复点时提交问题材料，不生成虚构 PR。用户自己的应用业务代码错误先修应用，不自动当作 OpenYida 缺陷。
@@ -36,10 +36,27 @@ openyida feedback report --input summary.json --output-dir feedback-draft-001
 
 ## 按用户条件交付
 
+用户选择 GitHub 后，按 [账号与工具准备](references/github-setup.md) 复用已有工具、引导注册/登录。缺少工具且宿主支持终端时，推荐用 `openyida feedback github setup --json` 检测，再经用户同意安装 gh、单独引导浏览器授权；不愿安装时可用网页，不把安装作为反馈门槛。工具就绪后继续原草稿，公开确认仍按原流程执行。
+
 - **无 GitHub 账号**：先引导用户创建 GitHub 账号，由用户自行完成注册和登录。实在不行，只提示“反馈到AI开发者群”，附上已整理的脱敏报告。不索取群链接或群 ID，不编造入群入口，不替用户发送群消息。离线或暂不愿注册时同样交付报告，明确“材料已生成，尚未提交”。
-- **有 GitHub 账号，提交 Issue**：不需 clone/fork。用户明确选择提交 Issue 后，用 `openyida feedback github status --json` 检查当前 GitHub 账号的 Star 与个人 Fork 状态；仅对明确未完成的操作提供一次可选邀请，已有的不重复提示，未知状态不说成未完成。按 [GitHub 提交](references/github-contribution.md) 处理用户选择、正文公开确认与查重。拒绝 Star/Fork 不影响提交；登录由用户在可信本机流程完成，不索取 Token。
+- **有 GitHub 账号，提交 Issue**：无需 clone/fork；按 [GitHub 提交](references/github-contribution.md) 查重、提交已确认内容并读回。成功后按交互规范给一次可选 PR 邀请；登录由用户在可信本机流程完成，不索取 Token。
 - **有账号，希望提交修复 PR**：仅适用于公开 OpenYida CLI/skill/docs 的可验证问题。先准备最小修复和验证，再通过用户自己的 Fork 提交到公开上游，详见同一参考。没有源码时由 Agent 在独立目录准备公开源码，不修改 npm 全局安装或用户业务目录。无法定位/验证时如实写入测试对比，优先交付 Issue 草稿；不要承诺未经验证的修复。
 
 创建 Issue、评论、Fork、push 或 PR 前必须有用户对相应外部动作及公开内容的授权；已有对同一最终稿和截图的隐私确认不重复问；单纯授权提 Issue/PR 不能替代公开内容审阅。只要求“排查”“整理反馈”不代表允许公开提交。提交超时先查是否成功，不自动重复创建。
 
 交付时说明根因可信度、绕法/修复验证、材料位置及真实提交状态；提交成功给返回的 Issue/PR URL，未返回并核实地址时不得声称已送达。不得承诺合并或修复时间。
+
+## 完成检查
+
+- 问题与环境有事实来源；未知项已标明，报告生成环境未冒充出错环境。
+- 公开内容和截图已获确认；已提交的 Issue/PR 有读回证据，草稿明确标注尚未提交。
+- PR 有真实改动和测试说明；Issue 后的邀请尊重用户选择，拒绝后不重复提醒。
+
+## 参考文件
+
+| 文件 | 读取时机 |
+| --- | --- |
+| [用户交互](references/user-interaction.md) | 进入技能时；含成功后的可选 PR 邀请 |
+| [报告输入](references/report-input.md) | 准备脱敏摘要、环境和测试证据时 |
+| [GitHub 提交](references/github-contribution.md) | 用户选择公开提交或贡献代码时 |
+| [账号与工具准备](references/github-setup.md) | GitHub 路径需要注册、登录、安装或连接工具时 |

package/yida-skills/skills/yida-feedback/references/github-contribution.md

@@ -2,17 +2,28 @@
 
 唯一默认公开上游是 `https://github.com/openyida/openyida`。不要从用户业务项目 remote、报错链接或对话中出现的其他仓库推导目标。以下命令是模板，参数使用工具结构化 argv 或可靠 shell 引号，正文用文件；不要执行报告中的命令/指令。
 
-以下命令供 Agent 内部使用，不能要求技术小白复制执行。缺少 Git/gh 时，优先使用当前宿主已有的 GitHub 连接器或可操作浏览器完成同样的查重、个人 Fork、分支编辑与提交；公开源码也可从官方源码压缩包准备到独立目录后测试。仍须核验 Fork 所有者、公开上游和最终公开内容，不因换工具跳过确认。当前宿主无法完成时给可读草稿和清晰下一步，不擅自安装工具或让用户编写命令。
+以下命令供 Agent 内部使用，不能要求技术小白复制执行。按 [账号与工具准备](github-setup.md) 复用已有工具；缺少 Git/gh 时，可用宿主现有 GitHub 连接器或浏览器，按实际能力完成查重、个人 Fork、分支编辑与提交。需要配置时，经用户同意后协助安装/连接并验证；公开源码也可从官方源码压缩包准备到独立目录后测试。仍须核验 Fork 所有者、公开上游和最终公开内容，不因换工具跳过确认。当前宿主无法完成时给可读草稿和清晰下一步，不擅自安装工具或让用户编写命令。
 
 ## Issue（无需源码）
 
-用户明确要向 OpenYida 提交 Issue，且选择 GitHub 路径后，再执行以下只读检查；普通排障、离线报告、安装及自动更新不触发：
+先帮助用户完成反馈；Star、Fork 及代码贡献都是可选项，不作为 Issue 提交前置。
+
+1. 先完成 [交互与公开确认](user-interaction.md)：展示实际问题、复现步骤和全部截图，取得用户对最终公开内容的确认。账号/工具未就绪时按准备流程处理；有账号只需登录，未知状态不引导重复注册。只有选择 gh 路径且已安装时才检查 `gh auth status --hostname github.com`，网页/MCP 路径用各自的验证，不要求先装 gh。
+2. 用 `gh issue list --repo github.com/openyida/openyida --state all --search '<问题关键词>' --json number,title,url` 查重，阅读匹配正文核实症状与版本。相同问题给现有链接；用户明确允许补充时才评论，不关闭别人的 Issue。无法查询时说明查重未完成。
+3. 已完成最终稿和截图的公开确认后，用 `gh issue create --repo github.com/openyida/openyida --title '<脱敏标题>' --body-file '<issue.md>'`。有已确认截图时，先检查当前 `gh issue create --help` 是否支持 `--attach`，每张显式追加 `--attach <审阅后的截图>`；同一命令只包含用户批准的图片，不上传额外附件。不支持时用可操作的 GitHub 网页上传，不静默丢图。默认不指定未知 label/assignee。
+4. 读回新 Issue 的标题、正文、截图引用和 URL 核对。附件部分失败时，先核实已创建的 Issue，回报缺失图片并处理该帖，不能重复建帖。未装 gh 但用户愿意网页操作时打开 `https://github.com/openyida/openyida/issues/new`，提供已复核正文供粘贴；打开页面不等于提交成功。
+
+Issue 完整读回后，按 [交互规范第五节](user-interaction.md#五issue-成功后邀请一起改进) 提供一次可选 PR 邀请；邀请不等于获得编辑、Fork、push 或创建 PR 的授权。
+
+## 可选支持与 Fork 状态
+
+仅在用户主动询问如何支持项目时，或已选择准备 PR、需要核实个人 Fork 时，执行以下只读检查。Issue 提交主流程不插入 Star/Fork 邀请；普通排障、离线报告、安装及自动更新不触发：
 
 ```bash
 openyida feedback github status --json
 ```
 
-命令复用本机 `gh` 的 github.com 当前账号，不读取 Token，不自动安装或登录。`starred` 为 true/false/null，个人 `fork.state` 为 ready/absent/conflict/unknown；同时检查改名的个人 Fork。只有 `suggestedActions` 中的缺失项可提供一次可选邀请：例如“是否愿意 Star 支持项目，或 Fork 留作后续贡献？也可以直接提交 Issue”。已有 Star/Fork 不重复提示；接口失败、权限不足或状态未知时不推断为未完成，不阻塞 Issue。没有可用 gh 时沿用连接器或浏览器；未登录时由用户自行登录，不索取凭据。
+命令复用本机 `gh` 的 github.com 当前账号，不读取 Token，不自动安装或登录。`starred` 为 true/false/null，个人 `fork.state` 为 ready/absent/conflict/unknown；同时检查改名的个人 Fork。只有 `suggestedActions` 中与用户当前意图相关的缺失项可提供一次可选邀请；准备 PR 时只处理 Fork，用户主动询问支持方式时再说明 Star。已有 Star/Fork 不重复提示；接口失败、权限不足或状态未知时不推断为未完成，不阻塞 Issue。没有可用 gh 时沿用连接器或浏览器；未登录时由用户自行登录，不索取凭据。
 
 用户分别明确选择后，Agent 才执行相应命令（`--confirm` 记录其真实授权，不能自行代选）：
 
@@ -23,11 +34,6 @@ openyida feedback github fork --confirm --json
 
 命令固定目标为 `openyida/openyida`，已有操作直接复用；Fork 只创建到当前用户个人账号，不 clone、不修改 remote。Fork 异步创建可能返回 `pending-verification`；先只读查状态，不重复创建。无论拒绝、失败或未登录，都可继续整理并提交 Issue；Star/Fork 是可选支持，不是提 Issue 的条件，也不代替正文与附件的公开确认。同一反馈流程拒绝过的选项不再次询问。现有 PR 流程的 Fork 授权仅用于贡献代码，不隐含 Star 授权。
 
-1. 先完成 [交互与公开确认](user-interaction.md)：展示实际问题、复现步骤和全部截图，取得用户对最终公开内容的确认。用户未登录时引导注册/登录；实在不行提示“反馈到AI开发者群”。只有用户选择 GitHub 路径才检查 `gh auth status --hostname github.com`；不要读/打印 Token，也不要自动装 gh 或创建账号。
-2. 用 `gh issue list --repo github.com/openyida/openyida --state all --search '<问题关键词>' --json number,title,url` 查重，阅读匹配正文核实症状与版本。相同问题给现有链接；用户明确允许补充时才评论，不关闭别人的 Issue。无法查询时说明查重未完成。
-3. 已完成最终稿和截图的公开确认后，用 `gh issue create --repo github.com/openyida/openyida --title '<脱敏标题>' --body-file '<issue.md>'`。有已确认截图时，先检查当前 `gh issue create --help` 是否支持 `--attach`，每张显式追加 `--attach <审阅后的截图>`；同一命令只包含用户批准的图片，不上传额外附件。不支持时用可操作的 GitHub 网页上传，不静默丢图。默认不指定未知 label/assignee。
-4. 读回新 Issue 的标题、正文、截图引用和 URL 核对。附件部分失败时，先核实已创建的 Issue，回报缺失图片并处理该帖，不能重复建帖。未装 gh 但用户愿意网页操作时打开 `https://github.com/openyida/openyida/issues/new`，提供已复核正文供粘贴；打开页面不等于提交成功。
-
 ## PR（用户个人 Fork → 上游 main）
 
 PR 需要真实修复 diff、修复前后测试对比和最终内容公开确认；只分析出可能根因时优先 Issue。不能把用户业务源码、诊断包、凭证或内部闭源实现混入贡献。

package/yida-skills/skills/yida-feedback/references/github-setup.md

@@ -0,0 +1,74 @@
+# 账号与工具准备
+
+用户选择 GitHub 提交或贡献后读取。先保留已有问题、环境、草稿、截图和测试结果，再准备账号与工具；整理反馈本身不需要账号或安装工具。下面的检查与命令由 Agent 执行，给用户说明用途和下一步即可。
+
+## 1. 分清账号、工具和权限
+
+先复用用户已说明的账号情况和宿主已授权的 GitHub 连接器/MCP、可操作浏览器。选择本机 CLI 路径时，由 Agent 执行 `openyida feedback github setup --json`，只读检测 gh 与当前账号，不安装、不登录，也不查询 Star/Fork。只检查当前任务所需能力，不遍历账号配置、环境变量或凭证文件。
+
+| 观察到的情况 | 怎么引导 |
+| --- | --- |
+| 用户明确说没有账号 | 给 [GitHub 官方注册入口](https://github.com/signup)，由用户自行注册、登录；不愿注册就保留脱敏报告 |
+| `gh` 不存在 | 仅说明本机未安装该工具；账号是否存在仍未知，继续检查已有连接器或网页路径 |
+| 有工具，但登录未验证 | 先确认用户愿意使用该工具，再引导官方登录；不把工具未登录说成用户没有账号 |
+| 请求超时、限流、权限不足 | 说明具体阻塞，保留账号/Fork 状态为未知；不反复要求注册、安装或切换账号 |
+| 已登录且具备所需能力 | 复用当前工具；多账号或不同工具身份不一致时，让用户确认用于本次贡献的账号 |
+
+`openyida feedback github status --json` 仍只用于原流程需要的个人 Fork/支持状态检查，不作为每次 Issue 的前置。它依赖本机 gh，`gh_unavailable` 表示工具缺失，`account_unverified` 表示账号未验证；两者都不能证明用户没有 GitHub 账号，也不能否定浏览器/MCP 已登录。
+
+无账号时可这样说：
+
+> 问题和环境信息已经整理好了。公开提交到 GitHub 需要一个账号，我可以引导你完成注册和登录，你在官方页面操作即可。现在不想注册也没关系，反馈材料会保留下来。
+
+账号密码、验证码和 Token 只由用户在官方页面或宿主安全授权界面处理；不向用户索取，也不读取、输出或写入报告。无法使用 GitHub 时按[用户交互](user-interaction.md#四账号与提交结果)交付本地报告。
+
+## 2. 选择最省事的可用路径
+
+用户选目标，Agent 选工具；不要求小白判断 CLI 和 MCP 的区别。
+
+| 当前目标与条件 | 推荐路径 |
+| --- | --- |
+| 已有工具已授权且能完成当前操作 | 直接复用；Issue 需要查重、创建和读回，PR 还需要核验个人 Fork、准备分支改动及创建和读回 PR |
+| 希望 AI 协助提交反馈/需求，缺少工具且宿主支持终端 | 推荐 GitHub CLI，先用 setup 检测并展示安装计划，再征求同意；不想安装或只提一次 Issue 时可直接使用网页，无需 Git 或源码 |
+| 希望 AI 协助修复并提 PR，宿主支持终端 | 缺少必要工具时，经用户同意后协助配置官方 GitHub CLI；Git、依赖安装及本地测试能力按实际需要单独核实 |
+| 宿主已有方便的 GitHub 连接入口 | 经用户同意连接官方 GitHub MCP/连接器；只在宿主实际支持时推荐，不虚构入口或配置 |
+| 无法安装、连接或使用终端 | 使用可用网页能力；无法编辑或验证时保留草稿、修改成果和未验证说明，不宣称已提交或测试通过 |
+
+MCP 配置在用户当前使用的 AI 工具中，不是新增 OpenYida 命令。已连接不等于具备写权限；只读连接可用于查重，不能冒充可提交。也不把 GitHub MCP 或 gh 当作本地 Git、构建和测试环境的替代品。
+
+## 3. 需要配置时，先说明再执行
+
+结合实际环境，推荐一个具体选项，说明工具名称、官方来源、包管理器默认安装位置及必要依赖、用途和所需授权。复用已安装的包管理器和已有宿主配置；需要额外工具时另行说明并征求同意，不扩大原安装授权。
+
+> 目前还没有可用的 GitHub 提交工具。我建议配置官方 GitHub CLI，方便我协助你准备修改和提交 PR；它会安装到你的电脑，登录授权由你在浏览器中完成。提交前，我仍会先给你看修改和将公开的内容。
+>
+> 选项：“帮我配置并继续”“使用网页方式”“先保留成果，稍后继续”。
+
+这是 CLI 路径的话术；推荐宿主连接器时，改为真实的连接名称、授权范围和配置位置。用户明确同意后才开始安装或修改配置；拒绝或未回答时保留成果，不自动代选、不反复邀请。
+
+- **GitHub CLI 检测与安装**：先运行下方只读命令，按返回的 `tool/account/installation/nextStep` 解释当前状态。缺少 gh 且 `installation.plan.available` 为 true 时，向用户展示具体包管理器、包名、安装影响和协议；用户同意后才运行安装命令。macOS/Linux 复用已有 Homebrew，安装 `homebrew/core/gh`；Windows 复用已有 WinGet 的 `winget` 源，安装精确包 `GitHub.cli`，会接受来源与软件协议，系统权限由用户自己批准。已有 gh 直接复用，不升级。没有支持的包管理器时提供[官方安装说明](https://github.com/cli/cli#installation)或网页路径；命令不安装包管理器、不加软件源、不执行提权或远程脚本。
+- **浏览器授权**：setup 仅提供引导，不自动启动登录。用户同意登录后，Agent 在用户可见的交互终端运行 `gh auth login --hostname github.com --web --skip-ssh-key`，由用户在官方浏览器页面完成。无交互终端则选网页/安全连接器，不在后台挂起登录。不要替用户回答 Git 凭证配置或协议切换问题，不自动修改全局 Git 配置、添加 SSH key 或追加权限；OAuth 权限以实际授权页为准，不能把 `--scopes` 描述为只读/写入权限开关。若安全存储不可用，gh 可能回退为明文保存；提前说明风险，优先选择网页或宿主安全授权，不使用 `--insecure-storage`，也不读取或回传凭证文件。
+- **宿主 MCP/连接器**：读取当前宿主的连接说明及 [GitHub 官方 MCP 文档](https://github.com/github/github-mcp-server)，使用实际提供的连接/授权入口。优先使用宿主支持的浏览器授权，只申请本次操作需要的权限；若只能手填 Token，由用户在安全设置中自行填写，不通过对话传递。修改配置只改已同意的 GitHub 项，保留其他连接；不顺带安装本地服务或覆盖整份配置。
+- **受限环境**：遵守宿主权限和受管 Run 约束；受管环境不能使用个人 GitHub 能力时，交付脱敏草稿并说明到个人本机会话继续。不以换成浏览器/MCP、提权、关闭安全检查或扩大权限来绕过限制。
+
+安装、登录或连接失败时说明实际完成到哪一步，保留材料，提供网页或稍后继续的选择；用户未选择重试时停止配置。配置授权只覆盖说明过的安装/连接，不等于授权 Star、Fork、push、Issue/PR 提交或公开内容。
+
+以下命令由 Agent 执行；`--confirm` 只记录用户已明确同意安装，不代替对话确认：
+
+```bash
+openyida feedback github setup --json
+# 用户看过安装计划并同意后：
+openyida feedback github setup --install --confirm --json
+```
+
+仅 `tool.state=missing` 才可安装；`unverified` 先检查执行权限或环境。账号的 `login_required` 进入登录引导，`unverified` 先检查网络、授权或限流，不要求重装/重复注册。安装超时、失败或结束后仍找不到 gh 时，先用只读 setup、包管理器状态或重新打开终端核实 PATH；不把包管理器退出成功当成工具就绪，也不自动重试。所有 setup 输出仅供本机引导，不直接附到 Issue。
+
+## 4. 验证后接着处理原草稿
+
+1. **只读验证**：CLI 再运行 `openyida feedback github setup --json`；它用固定 github.com 的只读 API 核实当前用户，仅返回验证后的账号名，不输出原始诊断或凭证。必要时检查 `gh auth status --hostname github.com`，不使用 `--show-token` 或 `gh auth token`。MCP/连接器读取当前用户和可用工具，浏览器核对登录账号。账号验证不代表有写权限；所需权限尚未证实时标为待验证，不创建测试 Issue、Star 或 Fork 来试权限。
+2. **复用已有材料**：继续原问题、出错环境、草稿、截图及测试记录，不重新问一遍。仅因安装 gh 或登录成功，不修改 `incidentEnvironment`，也不把新安装信息加入原问题报告。账号、授权输出和工具配置不写入公开材料。
+3. **保留公开确认**：未改动的最终稿沿用原确认；正文、图片、diff 或测试结果有变动时重新展示并确认。安装成功、登录成功和工具就绪，都不代表用户已同意公开提交。
+4. **按原提交流程继续**：回到 [GitHub 提交](github-contribution.md)，核实目标仓库与账号；PR 仍通过已验证的个人 Fork。若中断前提交结果未知，先查询已有 Issue/PR/分支，避免重复创建。结果仍未知就保留待核实状态，不换工具盲目重发。
+5. **如实交付**：分别说明“工具已配置”“登录已验证”“草稿已准备”或“已提交并读回”。只有核实真实 Issue/PR 地址和内容后，才给提交成功结论；Issue 完整读回后的可选 PR 邀请沿用交互规范，不因配置工具重复邀请。
+
+官方参考：[CLI 登录](https://cli.github.com/manual/gh_auth_login)、[登录状态](https://cli.github.com/manual/gh_auth_status)。

package/yida-skills/skills/yida-feedback/references/report-input.md

@@ -5,7 +5,7 @@
 ```json
 {
   "title": "发布失败后错误提示缺少处理建议",
-  "summary": "当前会话两次出现相同错误，无法继续发布。",
+  "summary": "想把页面发布给同事使用，目前卡在发布步骤。",
   "command": "openyida publish（省略业务参数）",
   "steps": ["使用最小示例执行发布", "观察错误提示"],
   "expected": "说明失败原因并给出可执行的下一步",
@@ -39,10 +39,18 @@
 
 - category：`cli|skill|environment|platform|unknown`；status：`confirmed|hypothesis|unknown`。confirmed 必须有 summary 和 evidence，CLI 只检查结构，不替 Agent 证明根因。
 - occurrenceCount：已观察的正整数；未知省略。fingerprint 按脱敏后的 title/command/actual 生成，不等于跨用户统计或已完成查重。
-- 单字段最多 12000 字符；数组最多 40 个字符串；输入最多 1 MiB。未列出的字段被丢弃；字段不能嵌套对象（cause、screenshots、comparison 除外）。CLI 只补包版本、Node、系统类型和架构，不补环境变量、账号、组织、应用或项目路径。
+- 单字段最多 12000 字符；数组最多 40 个字符串；输入最多 1 MiB。未列出的字段被丢弃；字段不能嵌套对象（cause、screenshots、comparison、incidentEnvironment 除外）。CLI 只补报告生成时的包版本、Node、系统类型和架构，不补环境变量、账号、组织、应用或项目路径。
 - 自动过滤常见凭证、绝对路径、URL、应用/表单标识、邮箱、手机号与身份证号，并转义 Markdown。正则不是保密保证；人工复核业务数据、间接身份信息、内部名称和未匹配的凭证。
 - 用文件工具写入 JSON，避免把报错拼成 shell 命令。命令只读这一个显式输入；输出目录父目录须存在，目标目录须不存在，避免覆盖已有材料。
 
+## 问题发生环境与报告生成环境
+
+复用顶层 `tool`（工具名及已知版本）、`model`。新增可选 `incidentEnvironment` 对象只接收字符串白名单：`openyida`、`node`、`platform`、`arch`、`installation`、`browser`、`deployment`、`organizationContext`。前四项为问题发生时的版本、系统和架构；安装方式可写 npm/插件/源码/未知；浏览器与部署形态仅在相关时填写；组织上下文只描述单组织/多组织切换，不含组织 ID 或名称。
+
+例如用户明确说升级前出错，可填 `{"incidentEnvironment":{"openyida":"用户确认的旧版本","installation":"npm"}}`；未知字段省略，不根据报告命令运行环境推断。Agent 将来源和升级差异放进现有 `evidence`，避免新增重复的诊断字段。
+
+输出 `environment` 保持原有结构，始终表示报告生成器的包版本和运行环境；Markdown 单独标为“报告生成环境（不代表问题发生时）”。缺少 `incidentEnvironment` 的旧输入继续可用，出错环境显示未知；不能用生成报告的新版 OpenYida 冒充出错时版本。所有新输入值同样脱敏、转义并参与公开稿的 `reviewDigest`。
+
 ## 截图与测试对比
 
 `screenshots` 最多 5 张，每张至多 10 MiB，仅接受 PNG/JPEG/WebP 文件头。相对路径按摘要 JSON 所在目录解析。CLI 只复制明确选择的原图，输出 `screenshot-01.png` 等通用文件名；不复制原文件名/路径到报告，不上传、不改图、不移除元数据。原图和最终正文必须一并审阅后才公开。无图片时省略，不能用示例或生成图片充当真实截图。

package/yida-skills/skills/yida-feedback/references/user-interaction.md

@@ -4,7 +4,9 @@
 
 ## 一、先解决“我想反馈什么”
 
-复用当前对话，只补关键缺口。用日常语言问“你原本想完成什么，实际卡在哪一步？”，区分：实际故障、功能建议、希望 AI 帮忙修复。实际故障必须写明当前遇到的问题、最短复现、期望/实际、影响和真实排查结果，不能只写一句抽象需求。
+复用当前对话，只补关键缺口。给用户三个容易理解的入口：“遇到问题了”“希望体验更好”“想一起改进”。询问“你原本想完成什么？实际发生了什么？你希望看到什么结果？”；已知答案直接复用，不一次追问整张技术表。Agent 整理最短复现、影响和真实排查结果，缺失项写未知。体验建议用现有 `summary/actual/expected` 表达当前场景、不便和理想结果，不要求用户设计命令或先找到根因。
+
+环境信息按 [报告输入](report-input.md) 填写：只读检查可获得的 OpenYida、Node.js、系统和架构，复用已知的 AI 工具及版本、安装方式；浏览器、设备、公有云/私有化和多组织切换仅在相关时补充。只将确认属于问题发生时的值写入 `incidentEnvironment`。已升级或换机器时分开记录，不用当前版本覆盖历史事实；未知不阻塞反馈，不要求粘贴整份诊断。
 
 说明下一步：“我会先整理问题和截图，再给你确认；确认后才公开提交。”不要先要求注册账号或下载源码来打断排查。
 
@@ -44,7 +46,22 @@
 
 ## 四、账号与提交结果
 
-- 没有 GitHub 账号：材料准备好后，引导用户创建 GitHub 账号，并给官方 [创建账号入口](https://github.com/signup)。用户自行完成注册、登录；Agent 不索取密码或 Token。
+- 材料准备好、用户选择 GitHub 后，按 [账号与工具准备](github-setup.md) 区分没有账号、工具未安装、未登录和权限/网络问题。先复用已有工具；推荐 CLI 时先执行只读 `feedback github setup --json`，说明安装计划并取得同意后才使用 `--install --confirm`。注册、登录由用户在官方页面或宿主安全入口完成，配置完成后继续原草稿。
 - 实在不行，只提示“反馈到AI开发者群”，附本地脱敏报告供用户自行反馈；不再索要群信息、不编造群链接、不替用户发送消息。
 - 用户愿意用 GitHub：Agent 按 [GitHub 提交](github-contribution.md) 查重、处理公开代码和 Fork、提交已确认材料。gh 缺失或不支持附件时，使用宿主可操作的 GitHub 网页引导，不要求用户记技术命令；无法完成时交付可粘贴的正文及已检查截图，不默默省略附件。
 - 成功后给可点击的 Issue/PR 链接，读回核对正文和截图是否完整。附件上传失败或结果未知时先查已创建的帖子，说明实际完成部分，不重复建帖。没有核实的 URL 时，只能说“草稿已准备”。
+
+## 五、Issue 成功后，邀请一起改进
+
+仅在 Issue 创建成功且读回完整后，给一次可选邀请；失败、仅有草稿或附件缺失时先处理提交结果。若读回已有仓库欢迎评论中的 PR 邀请，直接引用它，不再追加第二段邀请。用户已拒绝贡献时跳过，不追问理由。复用同一会话的问题和环境，不重新做一次问卷。
+
+> 问题已提交：[Issue 链接]，感谢你帮我们发现它！
+> 如果你愿意，我们还可以一起尝试修复，并提交一份修改建议（PR）。不需要你会 Git 或写代码，AI 会协助准备修改和检查，你确认后才公开提交。只反馈问题也完全可以。
+
+选项：“让 AI 试着修复”“先看看需要改什么”“只反馈问题”。用户未回答时保持 Issue 已提交状态，不默认开始代码工作。
+
+- 让 AI 试着修复：在公开代码中尝试定位、准备最小改动和验证；找到真实修复后按 PR 流程展示 diff 与最终稿，再确认远端操作。
+- 先看看需要改什么：只读分析，解释预计改动、风险和验证方式；等用户选择继续再编辑。
+- 只反馈问题：交付链接并结束，不再推荐 Star、Fork 或 PR。
+
+有关联 Issue 时在 PR 中引用；只有确实解决问题才写 `Closes #编号`。原因不明、平台内部限制或无法找到公开修复点时，补充 Issue 材料与限制，不制造无关 PR。文档和 Skill 的小改进同样欢迎，验证按改动类型安排；本地检查通过不代表平台、浏览器或真机已验证。

package/yida-skills/skills/yida-flow-node-config/SKILL.md

@@ -24,7 +24,7 @@ description: 配置流程和自动化里的处理步骤，包括审批、办理
 
 | 配置项 | 何时读取 |
 | --- | --- |
-| [人员选择](references/actors.md) | 指定成员、角色、主管，或按金额等条件选人；审批/办理/抄送分别使用对应参数 |
+| [人员选择](references/actors.md) | 指定成员、角色、主管、表单成员字段、发起人自选，或按金额等条件选人；审批/办理/抄送分别使用对应参数 |
 | [字段权限](references/fields.md) | 可编辑、只读、隐藏及子表；发起用顶层 `startFormConfig`，人工节点用 `formConfig` |
 | [操作按钮](references/actions.md) | 审批、办理、旧版多人审批的加签/转交；抄送和自动化不适用 |
 | [条件与变量](references/conditions-variables.md) | 字段与固定值、字段与字段比较；触发条件、分支和取数各用对应格式 |

package/yida-skills/skills/yida-flow-node-config/references/actors.md

@@ -91,6 +91,10 @@
 
 直属主管使用 `type: directLeader`，来源和层级仍用 `source/level`；替补参数使用 `needDeptLeaderReplace`，不要把部门主管的两个替补参数直接套入。
 
+## 表单成员与发起人自选
+
+字段选人、发起时自选及逐级指定下一级经办人，读取 [动态人员来源](dynamic-actors.md)。审批／办理支持两种来源，抄送与旧版多人审批支持成员字段；自选的节点范围、权益与兼容性边界见该文档。
+
 ## 按条件选人
 
 审批、办理、抄送分别使用 `approver/executor/receiver`，共用 `kind: conditional`。先查询真实字段、人员和角色。