openyida 2026.8.13 → 2026.8.14

package/yida-skills/skills/yida-flash-note-to-prd/SKILL.md

@@ -3,29 +3,29 @@ name: yida-flash-note-to-prd
 description: 从已有钉钉闪记、会议记录或需求文档内容中提取产品需求，生成结构化 PRD。若用户只给 taskUuid，先用 yida-tingji 读取内容，再进入本技能。
 ---
 
-# 钉钉闪记转高质量 Prompt 技能
+# 闪记和会议内容转 PRD
 
 ## 严格禁止 (NEVER DO)
 
 - 不要在没有闪记内容的情况下强行生成 PRD，必须等待用户提供闪记文本、图片或链接
-- 不要将生成的 prompt 写入项目根目录，必须写入 `prd/<项目名>/prd.md`
+- 不要将生成的 PRD 写入项目根目录，必须写入 `prd/<项目名>/prd.md`
 - 不要忽略闪记中的 A1 结构化摘要（会议摘要、待办事项、决策结论），这是最高优先级信息
-- 不要生成传统产品文档格式，输出必须是可直接驱动宜搭开发的结构化 prompt
+- 不要生成泛泛的会议纪要，输出必须是可直接驱动宜搭开发的结构化 PRD
 
 ## 严格要求 (MUST DO)
 
 - 必须自动识别输入类型：文本闪记 / 图片闪记 / 闪记链接，分别处理
 - 用户只提供 `taskUuid` 且要求转 PRD 时，必须先加载 `yida-tingji` 读取听记内容，再用读取结果生成 PRD
-- 必须提取会议元信息（标题、参会人、时间）并写入 prompt 上下文
-- 生成的 prompt 必须包含：MVP 边界、用户角色与权限、核心用户旅程、功能模块、字段设计表、流程/状态机、数据关联与约束、交互验收标准、报表需求、OpenYida 落地约束、待确认事项
-- 生成完成后必须提示用户确认 PRD 内容，再进入开发流程
+- 必须提取会议元信息（标题、参会人、时间）并写入 PRD 上下文
+- 生成的 PRD 必须包含：MVP 边界、用户角色与权限、核心用户旅程、功能模块、字段设计表、流程/状态机、数据关联与约束、交互验收标准、报表需求、OpenYida 落地约束、待确认事项
+- 生成完成后必须提示用户确认 PRD 内容；用户确认要继续搭应用时，交给 `yida-app`
 
 ## 适用场景
 
 | 用户意图 | 触发条件 |
 |---------|---------|
 | 闪记转需求文档 | 用户发送闪记文本/图片、提到"闪记"、"会议纪要"、"会议记录" |
-| 快速启动开发 | 从会议记录直接生成可执行的开发 prompt |
+| 快速启动开发 | 从会议记录直接生成可执行的 PRD |
 | taskUuid 转 PRD | 先由 `yida-tingji` 读取听记，再处理已有内容 |
 
 ## 触发条件
@@ -67,16 +67,16 @@ description: 从已有钉钉闪记、会议记录或需求文档内容中提取
 
 ## 概述
 
-本技能将钉钉闪记（会议录音转文字的会议纪要、AI 听记图文纪要）**自动识别并转化为高质量的结构化 prompt**。生成的 prompt 写入 `prd/<项目名>/prd.md`，可直接驱动后续宜搭应用开发流程（创建应用 → 创建表单 → 编写页面 → 发布上线）。
+本技能将钉钉闪记、会议记录、需求讨论文本或截图转成结构化 PRD。生成结果写入 `prd/<项目名>/prd.md`，用户确认后再交给 `yida-app` 执行应用搭建或补齐。
 
-> **核心理念**：`prd/<项目名>/prd.md` 不是传统的产品文档，而是一段**精心结构化的 prompt**——它包含了足够的业务语义信息（功能模块、字段设计、流程设计、报表需求等），使得后续技能可以直接读取并执行开发。
+> **核心理念**：PRD 只写业务语义和验收口径，便于后续技能读取并执行；不要在 PRD 中编造 `appType`、`formUuid`、`fieldId` 等真实 ID。
 
 **核心能力**：
 - **自动识别闪记输入**：用户直接发送闪记文本或图片，AI 智能体自动触发本技能
 - **智能识别钉钉 A1 / 闪记生成的结构化摘要**（会议摘要、待办事项、决策结论等），作为高优先级信息
-- **自动提取会议元信息**（标题、参会人、时间、时长等），丰富 prompt 上下文
+- **自动提取会议元信息**（标题、参会人、时间、时长等），丰富 PRD 上下文
 - **识别发言人角色标注**（如"张三(产品经理)"），帮助区分不同角色视角
-- **生成可直接驱动开发的结构化 prompt**，包含 MVP 边界、角色权限、核心旅程、功能模块、字段设计表、流程/状态机、数据约束、验收标准、报表需求和待确认事项
+- **生成可直接驱动开发的结构化 PRD**，包含 MVP 边界、角色权限、核心旅程、功能模块、字段设计表、流程/状态机、数据约束、验收标准、报表需求和待确认事项
 
 ---
 
@@ -94,7 +94,7 @@ description: 从已有钉钉闪记、会议记录或需求文档内容中提取
 
 ## ⚡ AI 智能体自动执行流程（核心）
 
-> **重要**：本技能的主要执行方式是 **AI 智能体直接处理**，而非调用 CLI 命令。AI 智能体自身就是大模型，可以直接完成闪记内容的理解和高质量 prompt 生成。
+> **重要**：本技能的主要执行方式是 **AI 智能体直接处理**，而非调用 CLI 命令。AI 智能体自身就是大模型，可以直接完成闪记内容理解和 PRD 生成。
 
 当识别到用户输入为闪记/会议纪要内容时，按以下流程自动执行：
 
@@ -110,19 +110,19 @@ description: 从已有钉钉闪记、会议记录或需求文档内容中提取
          - 识别 A1 生成的结构化摘要段落（📋 会议摘要、✅ 待办事项、📌 决策结论等）
          - 识别发言人及其角色标注
            ↓
-[Step 3] 生成高质量结构化 prompt
-         - 按照「Prompt 输出模板」和「内容提取规则」生成
+[Step 3] 生成结构化 PRD
+         - 按照「PRD 输出模板」和「内容提取规则」生成
          - AI 智能体直接生成，无需调用外部 AI 接口
          - 严格遵循字段设计规则（使用宜搭标准字段类型）
-         - 严格遵循质量标准（每个模块含功能描述、交互规则、业务规则、字段设计表和验收标准）
-         - 生成的 prompt 必须包含足够的业务语义信息，使后续技能可直接读取执行
+         - 每个模块写清功能描述、交互规则、业务规则、字段设计表和验收标准
+         - PRD 必须包含足够的业务语义信息，使后续技能可直接读取执行
            ↓
 [Step 4] 写入文件 prd/<项目名>/prd.md
            ↓
 [Step 5] 输出摘要，询问用户是否需要调整
          - 展示：项目名称、功能模块数、待确认事项数
          - 询问：是否需要修改或补充
-         - 提示：可继续执行宜搭应用开发流程（prompt 已就绪）
+         - 用户确认继续搭建时，交给 `yida-app`
 ```
 
 ### 图片输入处理规则
@@ -206,13 +206,13 @@ cat meeting.txt | openyida flash-to-prd --name <项目名>
 
 ---
 
-## Prompt 输出模板
+## PRD 输出模板
 
 > 📖 生成的 PRD 文件标准结构详见 [references/flash-note-prd-template.md](references/flash-note-prd-template.md)。
 
 ---
 
-## AI Prompt 设计
+## 生成规则参考
 
 > 📖 完整的三层 Prompt 架构、Prompt 原文、分段处理策略和调用方式详见 [references/flash-note-prompt.md](references/flash-note-prompt.md)。
 
@@ -262,7 +262,7 @@ cat meeting.txt | openyida flash-to-prd --name <项目名>
 | 讨论要点 | 📊 / 📈 | 【讨论要点】 | 关键讨论内容摘要 |
 | 后续跟进 | ⏭️ / 👉 | 【后续跟进】 | 下一步计划和跟进事项 |
 
-> **优先级说明**：A1 摘要段落被视为高优先级信息，会在 Prompt 中优先注入，帮助 AI 更准确地提取需求。
+> **优先级说明**：A1 摘要段落被视为高优先级信息，会优先注入生成上下文，帮助 AI 更准确地提取需求。
 
 ### 发言人角色识别（extractSpeakers）
 
@@ -275,24 +275,22 @@ cat meeting.txt | openyida flash-to-prd --name <项目名>
 赵六：...                → 识别为 赵六，角色：未标注
 ```
 
-识别到的发言人角色信息会注入 Prompt，帮助 AI 区分不同角色视角的发言。
+识别到的发言人角色信息会注入生成上下文，帮助 AI 区分不同角色视角的发言。
 
 ---
 
-## OpenYida PRD 质量门槛
+## PRD 输出要求
 
-生成或评审 `prd/<项目名>/prd.md` 时，必须检查以下内容；缺失时写入「待确认事项」，不要假装已经明确：
+生成 `prd/<项目名>/prd.md` 时，写清以下内容；缺失时写入「待确认事项」，不要假装已经明确：
 
-| 质量项 | 必须回答的问题 |
-|--------|----------------|
-| MVP 边界 | 第一版必须做什么，哪些放到二期 |
-| 用户与权限 | 谁使用工作台，谁维护后台表，谁审批/调度/查看报表 |
-| 核心旅程 | 用户从进入页面到完成关键任务的步骤，是否避免原生表单割裂体验 |
-| 数据模型 | 表单之间如何关联，哪些字段唯一，哪些字段只能后台维护 |
-| 状态机 | 状态有哪些，谁能改，允许从哪个状态流转到哪个状态 |
-| 冲突与异常 | 时间冲突、重复提交、并发提交、取消/退回/失败如何处理 |
-| 交互验收 | 什么叫“好用”，用可验证标准描述，如 30 秒内完成预约、冲突即时提示 |
-| OpenYida 约束 | PRD 只写业务语义，不写 `formUuid`/`fieldId`；Schema ID 写入 `.cache/<项目名>-schema.json` |
+- 第一版必须做什么，哪些放到二期。
+- 谁使用主入口，谁维护后台表，谁审批、调度或查看报表。
+- 用户从进入页面到完成关键任务的步骤。
+- 表单之间如何关联，哪些字段唯一，哪些字段只能后台维护。
+- 状态有哪些，谁能改，允许从哪个状态流转到哪个状态。
+- 时间冲突、重复提交、并发提交、取消、退回、失败如何处理。
+- 用可验证标准描述验收口径。
+- PRD 只写业务语义，不写 `appType`、`formUuid`、`fieldId`；真实 ID 写入 `.cache/<项目名>-schema.json`。
 
 ## 前置依赖
 

package/yida-skills/skills/yida-flash-note-to-prd/references/flash-note-prd-template.md

@@ -1,7 +1,7 @@
 # PRD 输出模板
 
 > 本文档是 `yida-flash-note-to-prd` 技能的参考文档，定义生成的 PRD 文件的标准结构。
-> 生成的高质量 prompt 遵循以下标准结构，写入 `prd/<项目名>/prd.md`。
+> 生成的 PRD 遵循以下标准结构，写入 `prd/<项目名>/prd.md`。
 
 ```markdown
 # <项目名称> — 产品需求文档

package/yida-skills/skills/yida-form-detail/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: yida-form-detail
 description: >
-  表单页视觉引导与表单详情页 formDetail 样式优化。表单页开发默认加载本技能做视觉引导，合并 Divider 分割线语义分组；拿到真实 formUuid 后默认使用 openyida form-detail-style 写入表单 Schema JS，在 componentDidMount 中注入全局主题和详情页条件样式。
+  表单页视觉引导与表单详情页 formDetail 样式优化。表单页开发默认加载本技能做视觉引导，合并 Divider 分割线语义分组；拿到真实 formUuid 后必须使用 openyida form-detail-style 写入表单 Schema JS，在 componentDidMount 中注入全局主题和详情页条件样式。
 license: MIT
 compatibility:
   - opencode
@@ -27,7 +27,7 @@ metadata:
 为宜搭表单页开发提供默认视觉引导，并默认优化 `formDetail` 的视觉效果。
 
 - 表单字段结构阶段：输出表单视觉引导，要求用 `Divider` 做语义分组，字段密度、分组标题、局部多列和说明字段都服务于真实业务填写路径。
-- 表单详情页样式阶段：拿到真实 `formUuid` 后默认把 formDetail CSS 写入表单 Schema JS。运行时 `openyidaThemeDidMount` 判断当前文档是否为 `formDetail`，是详情页才注入 `style#yida-form-detail-style`，否则不注入详情页结构样式。
+- 表单详情页样式阶段：拿到真实 `formUuid` 后必须把 formDetail CSS 写入表单 Schema JS。运行时 `openyidaThemeDidMount` 判断当前文档是否为 `formDetail`，是详情页才注入 `style#yida-form-detail-style`，否则不注入详情页结构样式。
 - 表单运行态主题阶段：提交页和详情页必须消费同一个 `style#yida-global-theme`；`openyida create-form create/update/...` 和 `openyida form-detail-style apply` 都必须执行公共注入脚本，把 `openyida:theme` 区块写入表单 Schema 的 `actions.module.source`，并让根节点 `componentDidMount` 指向 `openyidaThemeDidMount`。自定义页抽屉 iframe 再通过 `FormOpenContainer` 的 iframe `onLoad` 同步父页面 tokens。
 
 ## 何时使用
@@ -43,7 +43,7 @@ metadata:
 - 不要用 `RichTextField` 承载样式，设计器可能提示组件未找到。
 - 不要用 `openyida publish` 发布这个样式；它不是自定义页面源码。
 - 不要编造 `appType`、`formUuid` 或 `fieldId`。缺失时先从命令输出、缓存或 `openyida get-schema` 获取。
-- 未拿到真实目标 `formUuid` 前，不要执行 formDetail CSS Schema 注入；拿到 `formUuid` 后默认执行幂等注入。
+- 未拿到真实目标 `formUuid` 前，不要执行 formDetail CSS Schema 注入；拿到 `formUuid` 后必须执行幂等注入。
 - 不要用 `GroupContainer` / `PageSection` 代替普通业务分组；表单页视觉引导必须合并 `Divider` 分割线规则。
 
 ## 表单视觉引导（默认）
@@ -57,7 +57,7 @@ metadata:
 - 分组结构：<每个分组名称；每组开头必须用 Divider，包括第一组>
 - Divider 策略：<默认 bold-with-thin；同一张表单保持同一种 dividerType；标题跟随应用主题>
 - 字段密度：<单列为主；短字段成对时局部 ColumnContainer>
-- 详情页策略：<拿到 formUuid 后默认注入 formDetail CSS；如需自定义品牌色，说明 CSS 变量调整点>
+- 详情页策略：<拿到 formUuid 后必须注入 formDetail CSS；如需自定义品牌色，说明 CSS 变量调整点>
 ```
 
 视觉引导阶段的 `Divider` 规则必须和 `yida-create-form-page` 合并执行：字段较多时每个语义分组开头都放 `Divider`，第一个分组也要放；`Divider` 不放在字段列表末尾；普通业务分组不使用 `GroupContainer` / `PageSection`。
@@ -66,7 +66,7 @@ metadata:
 
 ### 表单结构视觉引导
 
-由 `yida-form-detail` 决定分组、密度、Divider 策略和详情页默认样式注入策略；由 `yida-create-form-page` 写入结构化字段 JSON 并执行 `openyida create-form create/update/...`。表单保存时默认补齐 `openyida:theme` 区块和 `openyidaThemeDidMount`。
+由 `yida-form-detail` 决定分组、密度、Divider 策略和详情页样式注入策略；由 `yida-create-form-page` 写入结构化字段 JSON 并执行 `openyida create-form create/update/...`。表单保存时必须补齐 `openyida:theme` 区块和 `openyidaThemeDidMount`。
 
 ### formDetail 样式注入
 
@@ -104,9 +104,9 @@ openyida form-detail-style remove <appType> <formUuid> --json
 
 ## 决策规则
 
-- 创建或更新表单结构：默认加载本技能做视觉引导，必须合并 Divider 分割线分组；拿到真实 `formUuid` 后默认注入或补齐 formDetail CSS。
+- 创建或更新表单结构：默认加载本技能做视觉引导，必须合并 Divider 分割线分组；拿到真实 `formUuid` 后必须注入或补齐 formDetail CSS。
 - 完整应用表单：先读取 `prd.md` 的表单业务目标和字段语义，再读取 `design.md` 的主题、密度、Divider、详情页策略；不要从 PRD 复制视觉规则。
 - 用户要求完整美化或未指定特殊样式：使用默认 CSS 全量注入。
 - 用户只要求某一区域：从默认 CSS 中截取对应分区，仍写入同一个 `openyida:theme` 区块。
 - 用户有品牌色：优先改 CSS 顶部变量，不要大面积改选择器。
-- 新建应用完成后如包含表单：表单结构阶段默认使用视觉引导，并默认完成表单详情页优化样式注入；跳过注入只能来自明确技术阻塞并在 final 说明。
+- 新建应用完成后如包含表单：表单结构阶段默认使用视觉引导，并必须完成表单全局主题和详情页优化样式注入；跳过注入只能来自明确技术阻塞并在 final 说明。

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

@@ -5,40 +5,41 @@ description: 宜搭登录态管理。以 OpenYida auth snapshot 为准；默认
 
 # yida-login
 
-## Mode
+## 模式
 
-- Do not infer auth mode from agent name, runtime product, workspace path, or a guessed environment variable.
-- First read `openyida agent-capabilities --summary-json`; fallback to `openyida login --check-only --json` only when needed.
-- If the snapshot reports `login.auth_source=env` or `failure_reason=env_token_missing`, treat it as runtime-environment injected token mode. The only credential sources are runtime-environment injected token env such as `OPENYIDA_ACCESS_TOKEN` and `OPENYIDA_REFRESH_TOKEN`.
-- Otherwise, `auth_mode=token` uses the default OAuth token session flow.
-- NEVER infer auth from `.cache/cookies*.json`.
+- Codex、yida-agent 等宿主都使用同一套 OpenYida auth snapshot 规则。
+- 不要根据 agent 名称、宿主产品、workspace 路径或猜测的环境变量推断认证模式。
+- 先读 `openyida agent-capabilities --summary-json`；只有需要更多信息时，才降级执行 `openyida login --check-only --json`。
+- snapshot 返回 `login.auth_source=env` 或 `failure_reason=env_token_missing` 时，进入运行环境注入 token 模式。凭证只来自运行环境注入的 `OPENYIDA_ACCESS_TOKEN`、`OPENYIDA_REFRESH_TOKEN` 等环境变量。
+- 其他 `auth_mode=token` 场景使用默认 OAuth token session。
+- 不要从 `.cache/cookies*.json` 推断登录态。
 
-## Preflight
+## 前置检查
 
-Run first:
+先执行：
 
 ```bash
 openyida agent-capabilities --summary-json
 ```
 
-Fallback only when needed:
+必要时降级：
 
 ```bash
 openyida env --json
 openyida login --check-only --json
 ```
 
-## Decision Table
+## 判断表
 
-| Observed status | Action |
+| 状态 | 动作 |
 |---|---|
-| `auth_mode=token`, `status=ok` or `can_auto_use=true` | Continue business command |
-| `auth_source=env` / `failure_reason=env_token_missing` | Treat as runtime-environment injected token mode; if token is missing, STOP and ask the runtime environment to inject `OPENYIDA_ACCESS_TOKEN` or `OPENYIDA_REFRESH_TOKEN`; do not OAuth |
-| `auth_mode=token`, not logged in, and snapshot does not report env injection | Run `openyida login`, then verify with `openyida login --check-only --json` |
+| `auth_mode=token` 且 `status=ok` 或 `can_auto_use=true` | 继续执行业务命令 |
+| `auth_source=env` / `failure_reason=env_token_missing` | 进入运行环境注入 token 模式；缺 token 时停止，让 Codex、yida-agent 等宿主注入 `OPENYIDA_ACCESS_TOKEN` 或 `OPENYIDA_REFRESH_TOKEN`；不要执行 OAuth |
+| `auth_mode=token`，未登录，且 snapshot 未返回 env 注入 | 执行 `openyida login`，再用 `openyida login --check-only --json` 验证 |
 
-## Token Mode Commands
+## Token 模式命令
 
-Use OAuth login only when the auth snapshot does not report env injection.
+只有 auth snapshot 未返回 env 注入模式时，才使用 OAuth 登录。
 
 ```bash
 openyida login
@@ -48,7 +49,7 @@ openyida auth refresh
 openyida auth logout
 ```
 
-If user gives a Yida entry URL, pass it through:
+用户给出宜搭入口 URL 时，原样传入：
 
 ```bash
 openyida login https://yida-group.alibaba-inc.com/
@@ -56,11 +57,11 @@ openyida login --alibaba
 openyida login --intl
 ```
 
-Overseas / international / global / Japan / Global YiDA => add `--intl` or equivalent.
+海外 / international / global / Japan / Global YiDA 使用 `--intl` 或等价入口。
 
-## Runtime-Environment Injected Token Mode Commands
+## 运行环境注入 Token 模式命令
 
-Use only after the auth snapshot reports `auth_source=env` or `failure_reason=env_token_missing`.
+只有 auth snapshot 返回 `auth_source=env` 或 `failure_reason=env_token_missing` 后，才进入本模式。
 
 ```bash
 openyida agent-capabilities --summary-json
@@ -70,7 +71,7 @@ openyida auth status
 openyida auth refresh
 ```
 
-Expected usable compact shape:
+可继续执行的结果：
 
 ```json
 {
@@ -81,17 +82,17 @@ Expected usable compact shape:
 }
 ```
 
-If the runtime environment did not inject token env, the auth snapshot reports `failure_reason=env_token_missing`; stop and go back to that runtime environment instead of launching OAuth.
+如果运行环境没有注入 token，auth snapshot 会返回 `failure_reason=env_token_missing`；停止任务，让 Codex、yida-agent 等宿主补齐 token 注入，不要触发 OAuth。
 
-## NEVER
+## 禁止
 
-- Never hardcode or print `access_token`, `refresh_token`, Cookie, or CSRF.
-- Never read/write `.env`, token files, or Cookie files manually.
-- In runtime-environment injected token mode: 不要再执行 `openyida login` 触发 OAuth.
-- In runtime-environment injected token mode: 缺 token 时回到运行环境修复注入，不要查找本地 `.cache/cookies*.json`.
-- Do not pass Cookie, `_csrf_token`, or Bearer token manually in business commands.
+- 不要硬编码或打印 `access_token`、`refresh_token`、Cookie 或 CSRF。
+- 不要手动读写 `.env`、token 文件或 Cookie 文件。
+- 运行环境注入 token 模式下，不要再执行 `openyida login` 触发 OAuth。
+- 运行环境注入 token 模式下，缺 token 时让 Codex、yida-agent 等宿主修复注入，不要查找本地 `.cache/cookies*.json`。
+- 不要在业务命令里手动传 Cookie、`_csrf_token` 或 Bearer token。
 
-## Done
+## 完成条件
 
-- Login/auth snapshot reports usable auth, or
-- Runtime-environment injected token mode reports a clear stop reason for the runtime environment to fix.
+- Login/auth snapshot 返回可用登录态；或
+- 运行环境注入 token 模式返回明确停止原因，交由宿主修复。

package/yida-skills/skills/yida-publish-page/SKILL.md

@@ -7,13 +7,17 @@ description: 自定义页面 JSX 编译发布技能。
 
 > 资源边界：本技能只处理普通 OpenYida 页面发布；目标不明时先只读确认或询问用户。
 
-## Resource-First 发布目标
+## 执行边界
+
+本技能负责三件事：确认发布目标、执行编译发布、给出 final 证据。页面源码由 `yida-custom-page` 或 `yida-canvas-custom-page` 产出；缺少自定义页面容器时，先交给 `yida-create-page` 创建后再回来发布。
+
+## 发布目标确认
 
 发布前必须先解析目标页面 context；本技能优先服务已有页面：
 
-- 用户说“优化这个页面 URL / 修改这个页面 / 重新发布 / 覆盖现有页面”并提供页面 URL、`formUuid`、bound page 或 workspace 中可确认的 display page 时，直接把该页面作为发布目标，不创建 app/page。
-- bound page 是默认发布候选，不是强制目标；如果当前会话绑定页面 A，而用户本轮明确指定页面 B，必须先解析 B。B 有唯一 URL / display `formUuid` 时发布到 B；B 只有名称或描述且无法唯一匹配时先问用户；不要静默发布到 A。
-- 只有无法解析目标页面，且用户明确要新增一个页面容器时，才回到 `yida-create-page` 创建缺失 display page；已有 appType 不代表需要新建 app。
+- 用户说“优化这个页面 URL / 修改这个页面 / 重新发布 / 覆盖现有页面”并提供页面 URL、`formUuid`、bound page 或 workspace 中可确认的 display page 时，直接把该页面作为发布目标。
+- bound page 是默认发布候选，不是强制目标；如果当前会话绑定页面 A，而用户本轮明确指定页面 B，必须先解析 B。B 有唯一 URL / display `formUuid` 时发布到 B；B 只有名称或描述且无法唯一匹配时先问用户。
+- 只有无法解析目标页面，且用户明确要新增页面容器时，才回到 `yida-create-page`。
 - 发布目标必须是 `formType=display` 的自定义页面；普通表单、流程表单、数据底表的 `formUuid` 不能作为 `openyida publish` 第三个参数。
 - 多个页面候选按根技能来源优先级选择；同级冲突或无法判断页面类型时才问用户或执行只读 `list-forms` 确认。
 
@@ -23,7 +27,6 @@ description: 自定义页面 JSX 编译发布技能。
 - 不要把 AI 生成的普通 React 项目代码直接发布；源码应使用 OpenYida 页面源码格式：普通自定义页面 JSX/Jsx 组件链路用 `.oyd.jsx` / `.jsx` 并通过 `check-page` / `compile` 预检，Code Canvas 用 `.canvas.jsx` 并通过 `publish` 的 Canvas 编译阶段校验
 - 不要在宜搭原生 `export function renderJsx()` 页面里手写 Hooks；如确需 `useState/useEffect`，必须使用 `.oyd.jsx` 的 `export default function Page()` authoring 模式，让 OpenYida 兼容编译器降级
 - 不要编造 appType 和 formUuid，必须从已有记录或命令返回中获取
-- 用户已给页面 URL / `formUuid` / bound page 时，不要先创建新 app 或新 page；直接确认目标并发布到已有页面。
 
 ## 严格要求 (MUST DO)
 
@@ -78,7 +81,7 @@ openyida publish <源文件路径> <appType> <formUuid> [--compat] [--canvas] [-
 | `--auto-nav-order` | 否 | 发布成功后立刻执行轻量导航排序；PRD 已写明导航顺序时优先用 `openyida nav-group order <appType> <页面/表单...>`，PRD 缺少明确页面清单时才用本参数兜底；排序失败只警告，不回滚已发布页面 |
 | `--force` | 否 | 显式绕过发布目标类型保护；只有确认目标是自定义页面但导航接口暂时无法识别时才使用 |
 
-## 发布目标确认
+## 确认命令
 
 发布前先确认目标页面，避免把 JSX 覆盖到数据底表：
 

package/yida-skills/references/development-rules.md

@@ -1,85 +0,0 @@
-# 核心规则详解
-
-> 逐条展开主 SKILL.md「核心规则」的操作细节，编号与主文件一一对应（FATAL 1–4 / IMPORTANT 1–11）。需要更多篇幅的规则指向文末专节。
-
-## 致命规则（FATAL）
-
-**F1 技能加载唯一入口**：执行任何子技能前，支持 `use_skill` 的宿主必须调用 `use_skill("<技能名>", "<本阶段目的>")` 加载对应技能；不要用 `Read` / `read_file` / `cat` 读取 `SKILL.md` 路径。`skills-index.json` 是给能读取索引的工具快速找到技能用的；不能读取它的工具直接忽略。完全没有 `use_skill` / `search_skills` 的本地工具，才允许按根技能路由表和技能包相对路径逐个读取当前阶段唯一必要的技能文档；禁止并发批量读取多个 `SKILL.md`，禁止预读未来阶段技能。
-
-**F2 corpId 一致性检查**：创建页面前对比 prd 文档与 token 登录态中的 corpId——
-- 一致 → 继续；
-- 不一致 → 询问用户：重新登录到正确组织，还是在当前组织新建应用。
-
-**F3 发布前本地校验**：
-- 普通自定义页面 `.oyd.jsx` / `.jsx` 发布前先跑 `openyida check-page <源文件>` + `openyida compile <源文件>`；Code Canvas `.canvas.jsx` 不跑这两个普通自定义页面检查，改由 `openyida publish` 的 Canvas 编译阶段或 `compileCanvasLocal` 快检校验；
-- 发布时留意"同名双副本内容不一致"警告，必要时加 `--health-check` 做首屏 HTTP 健康检查；
-- 任何 JSON 配置写盘后先做 JSON 解析校验，再调用平台命令。
-
-**F4 命令输入文件禁止 shell 写入**：当 OpenYida 命令需要 JSON/YAML/CSV/config/script 文件参数时，必须先使用当前 agent 运行时提供的结构化文件写入工具（如 create_file / Write / file edit tool）创建文件，再把文件路径传给命令。禁止用 shell heredoc、`cat`/`echo`/`printf`/`tee` 加输出重定向，或把 `openyida` 命令 stdout 重定向成业务配置、Schema、导入数据或一次性脚本。
-
-## 重要规则（IMPORTANT）
-
-| # | 规则 | 操作细节 |
-|---|------|---------|
-| 1 | 按阶段加载必要技能 | 按意图选定 1 个主技能；完整应用按阶段加载当下唯一需要的子技能，仅在已加载技能明确要求时才读对应 `references/`。 |
-| 2 | 优先复用缓存 | `appType`/`formUuid`/`fieldId`/`reportId` 先从 `.cache/<项目名>-schema.json` 读，缺失或不确定再 `openyida get-schema`。 |
-| 3 | 页面规格优先 | 自定义页面先由 `yida-design` 产出 `prd.md` 与 `design.md`，两者是唯一设计事实源；`page-spec.json` 只在生成器/交接需要时从两者派生。复杂实现先生成或编写可编译骨架，页面目标、区块、数据和交互以 PRD 为准，布局、主题、材质和状态视觉以 design.md 为准。 |
-| 4 | 配置优先于页面代码 | 字段结构、公式、联动、报表聚合、审批、集成和连接器动作交给对应技能；自定义页面代码负责展示数据、响应点击、打开表单/详情页，并串联表单、流程、报表和导航入口。 |
-| 5 | 数据性能优先 | 统计聚合用 `yida-report` 服务端聚合；不在自定义页面前端分页拉全量后自行聚合。 |
-| 6 | 避免无效重试 | 失败先按错误信息查登录态/组织/参数/字段 ID；无修改不连续重试超 1 次。 |
-| 7 | 配置分两处存 | 详见 [配置信息分两处存储](#配置信息分两处存储) 与 [PRD 质量门槛](#prd-质量门槛)。 |
-| 8 | 临时文件入 project `.cache/` | 详见 [临时文件规范](#临时文件规范)。 |
-| 9 | 报表美化先问方案 | 详见 [报表优化 / 美化提示规则](#报表优化--美化提示规则)。 |
-| 10 | 按 schema 证据选技能 | 先看 `formType`、组件树、`dataSource.online`；`receipt/process/report` 分别落到表单/流程/报表技能。默认页是自定义展示页、或确需列表/看板/工具页交互时，默认落到 `yida-canvas-custom-page`；只有强依赖 `this.$(fieldId)`、`this.utils.yida.*`、`this.dataSourceMap`、表单提交或字段双向绑定深度耦合时，才落到 `yida-custom-page`。 |
-| 11 | 官方示例范式优先 | 蒸馏宜搭示例中心时，先按 [官方示例 Schema 范式](official-example-schema-patterns.md) 理解脱敏 schema 的承载方式，不凭截图/卡片标题/页面视觉判断。 |
-
-## 配置信息分两处存储
-
-| 信息类型 | 存储位置 | 内容示例 |
-|---------|---------|---------|
-| 业务语义信息 | `prd/<项目名>/prd.md` | 字段名称、字段类型、字段说明 |
-| 视觉契约信息 | `prd/<项目名>/design.md` | 主题 token、布局密度、圆角规则、组件规则、状态规则 |
-| Schema ID | `.cache/<项目名>-schema.json` | `appType`、`formUuid`、`fieldId` |
-
-> prd 文档**不记录** `formUuid`/`fieldId` 等 ID，这些只写入 `.cache/`。
-
-## PRD 质量门槛
-
-`prd/<项目名>/prd.md` 不是需求摘要，必须能直接驱动后续技能执行；`prd/<项目名>/design.md` 不是参考链接摘要，必须能直接驱动所有页面视觉实现。PRD 至少包含：
-
-- **MVP 范围**：V1 必做 / V1 不做 / V2 候选
-- **目标用户与权限**：角色、入口、可执行操作
-- **核心用户旅程**：完成关键任务的步骤与成功标准
-- **页面与表单配置**：业务语义字段（不写 `formUuid`/`fieldId`）
-- **流程与状态机**：状态、允许操作、下一状态、操作角色
-- **数据关联与约束**：唯一性、关联关系、冲突校验、并发/重复提交风险
-- **交互与验收标准**：用可验证标准描述"好用"
-- **落地约束**：Schema 写 `.cache/<项目名>-schema.json`；发布前按页面链路校验，普通自定义页面跑 `check-page` + `compile`，Canvas 跑 Canvas 编译快检或由 `publish` 编译阶段校验
-
-## 临时文件规范
-
-所有 OpenYida 业务中间文件（token session、schema 缓存、字段/报表/流程配置、导入数据、一次性脚本等）**必须写在 OpenYida project 工作目录的 `.cache/` 下**，不写业务仓库根目录、系统 `/tmp` 或其他位置。源码中的 `<projectRoot>` 指 OpenYida project 工作目录；从 workspace 根执行命令时路径通常是 `project/.cache/...`，从 project 工作目录内执行时路径是 `.cache/...`。
-
-文件必须由 agent 的结构化文件写入工具创建，再传给 OpenYida 命令。不要通过 `execute_shell` 加 heredoc、`cat`/`echo`/`printf`/`tee`、管道或重定向来生成 JSON/YAML/CSV/config/script 文件。`/tmp` 只允许用于外部工具强制要求的系统临时路径，OpenYida 业务配置、schema、导入数据和一次性脚本不写 `/tmp`。
-
-| 工件类型 | 推荐位置 |
-|---------|---------|
-| Schema / ID 映射 | `<projectRoot>/.cache/<项目名>-schema.json` |
-| 字段 / 报表 / 流程 / 连接器配置 | `<projectRoot>/.cache/openyida/<项目名或任务名>/` |
-| 批量导入数据（JSON/JSONL/CSV） | `<projectRoot>/.cache/openyida/<项目名或任务名>/data-import/` |
-| 一次性 Python / JS 脚本 | `<projectRoot>/.cache/openyida/<项目名或任务名>/scripts/` |
-
-> 只有需长期维护的 PRD、页面源码、示例资源才写入 `prd/`、`pages/src/`、`project/` 等正式目录。
-
-## 报表优化 / 美化提示规则
-
-用户提到"优化 / 美化 / 更好看 / 不够漂亮"等报表视觉相关诉求时，**先问用户选哪种方案**，再动手：
-
-| 方案 | 做法 | 适用 | 落到 |
-|------|------|------|------|
-| A 优化原生报表 | 调整图表类型、布局、筛选器，仍用宜搭原生组件 | 快速优化、无需写代码 | `yida-report`（`openyida create-report`） |
-| B ECharts 高级报表 | ECharts + 自定义页面 JSX，高度定制 | 精美视觉、复杂交互、数据大屏 | 读 `yida-chart` 子技能文档 |
-
-话术示例：
-
-> 我可以两种方式帮你优化报表：**①优化原生报表**——调整图表类型组合、布局、筛选器，快速提升；**②ECharts 高级报表**——自定义页面实现渐变、动画、自定义主题等精美效果。你选哪种？

package/yida-skills/skills/yida-app/references/app-build-contract.md

@@ -1,141 +0,0 @@
-# yida-app 执行编排参考
-
-本文件只记录完整应用落地过程中的执行细节。需求分析、产品设计、数据结构、页面布局、应用主题色/风格摘要和验收标准由 `yida-design` 输出到 `prd/<项目名>/prd.md`；完整 UI 设计规范、主题 token、布局密度、圆角规则、组件和状态规则输出到 `prd/<项目名>/design.md`。
-
-## PRD 输入
-
-`yida-app` 开始创建或补齐应用资源前，必须已经拿到 `yida-design` 输出的 `prd/<项目名>/prd.md` 和 `prd/<项目名>/design.md`。已有 app/page/form/process 只作为上下文复用；缺失资源按 PRD 的资源创建顺序落地，页面视觉按 design.md 落地。
-
-| 产物 | 用途 |
-| --- | --- |
-| PRD | 描述应用基本信息、应用配置、数据结构、页面与功能、业务逻辑、交互状态、资源蓝图、资源创建顺序、页面实现交付顺序、导航顺序和验收标准 |
-| design.md | 描述主题 token、视觉 DNA、布局密度、圆角规则、场景配方、组件规则、状态规则和页面视觉验收 |
-
-PRD 记录应用级运行上下文 `appType/corpId/baseUrl`；`formUuid`、`fieldId`、`pageId` 等细节 ID 写入 `.cache/<项目名>-schema.json`。页面实现阶段读取 PRD 的业务输入，并直接读取 design.md 的主题、布局、材质、圆角、密度、组件和状态规则；走生成器时再派生 `page-spec.json`，手写时直接按 PRD + design.md 实现。
-
-## 字段文件示例
-
-字段配置文件写到 `.cache/openyida/<项目名>/xxx-fields.json`，从 workspace 根执行时传 `project/.cache/openyida/<项目名>/xxx-fields.json`。
-
-```json
-[
-  { "type": "TextField", "label": "访客姓名", "required": true },
-  { "type": "PhoneField", "label": "联系电话" },
-  { "type": "DateField", "label": "到访时间" },
-  { "type": "SelectField", "label": "访问状态", "options": ["预约中", "已到访", "已离开"] }
-]
-```
-
-创建后把返回 ID 汇总到：
-
-```json
-{
-  "appType": "APP_XXXXXX",
-  "pages": {
-    "访客登记表": {
-      "formUuid": "FORM-XXXXXX",
-      "fields": {
-        "访客姓名": "textField_xxxxxxxx"
-      }
-    },
-    "访客工作台": {
-      "formUuid": "FORM-YYYYYY"
-    }
-  }
-}
-```
-
-## 页面链路选择
-
-- 默认使用 `yida-canvas-custom-page`：现代 React 交互、hooks、图表、工作台、看板、列表、详情、官网、门户壳等面向用户页面。
-- 仅当强依赖原生实例数据桥时使用 `yida-custom-page`：`this.$(fieldId)`、`this.utils.yida.*`、`dataSourceMap`、提交流程或设计器数据源深度耦合。
-- PRD 中的资源蓝图、页面与功能设计、交互状态、页面实现交付顺序、各页面布局和主题风格摘要，必须进入 `page-spec.json` 或页面实现备注。design.md 中的主题 token、完整 UI 设计、圆角、密度、组件和状态规则由页面实现阶段重新读取，不复制进 `page-spec.json`。`page-spec.json` 必须标记 `sourceOfTruth`；与 PRD/design.md 冲突时重生成 spec。生成源码后发现业务事实缺失时回写 `prd.md`，发现视觉事实缺失时回写 `design.md`；只有实现偏差才小范围 patch 源码。
-- 截图验收、公开访问、数据源深接和精细导航分组只在用户明确要求或 PRD 验收标准命中时追加。完整应用默认在表单创建后注入 formDetail CSS，并写入 1-3 条核心普通表单 seed records，不再作为可选后置。
-
-## 常用 URL
-
-| 页面类型 | URL 格式 |
-|---------|---------|
-| 应用首页 | `{base_url}/{appType}/workbench` |
-| 表单提交页（默认隐藏导航） | `{base_url}/{appType}/submission/{formUuid}?isRenderNav=false` |
-| 自定义页面 | `{base_url}/{appType}/custom/{formUuid}` |
-| 自定义页面隐藏导航 | `{base_url}/{appType}/custom/{formUuid}?isRenderNav=false` |
-| 表单详情页（抽屉/隐藏导航） | `{base_url}/{appType}/formDetail/{formUuid}?formInstId={formInstId}&navConfig.layout=1180&isRenderNav=false` |
-
-建议在链接末尾拼接 `corpid={corpId}`，便于切换到正确组织。
-
-## 典型执行顺序
-
-### 访客系统
-
-1. 解析资源上下文，读取 `yida-design` 的 `prd.md` 与 `design.md`，明确访客登记表、访问记录表、访客工作台布局和页面视觉契约。
-2. 创建或复用应用，拿到 `appType`。
-3. 创建访客登记表、访问记录表。
-4. 使用 `yida-data-management` 为核心普通表单写入 1-3 条业务化访客记录，并 query 抽查。
-5. 创建访客工作台页面。
-6. 生成主页面，展示今日预约、待确认、最近访问记录、登记入口和空态。
-7. 发布页面并按 PRD 导航顺序做轻量排序。
-8. 先输出 2-3 句业务交付总结，再给一个主入口链接，例如“已完成访客登记表和访问记录表，并发布访客工作台入口。当前应用已支持访客登记、访问状态跟踪和最近访问查看，示例记录与导航排序也已就绪。主入口：{base_url}/{appType}/workbench”。
-
-### CRM 系统
-
-1. 解析资源上下文，读取 `yida-design` 的 `prd.md` 与 `design.md`，明确客户信息表、跟进记录表、首页布局、详情下钻和页面视觉契约。
-2. 创建或复用应用。
-3. 创建客户信息表、跟进记录表。
-4. 若产品设计包含审批节点，再创建流程表单。
-5. 使用 `yida-data-management` 为客户信息表、跟进记录表等核心普通表单写入 1-3 条业务化记录，并 query 抽查。
-6. 创建 CRM 首页并发布，按 PRD 导航顺序做轻量排序。
-7. 用户要求报表时，再追加对应资源。
-
-### 数据大屏
-
-1. 解析资源上下文，读取 `yida-design` 的 `prd.md` 与 `design.md`，明确大屏指标、数据对象、页面布局和主题强度。
-2. 创建或复用应用。
-3. 创建数据录入表单或报表数据源。
-4. 若大屏依赖本轮普通表单数据，使用 `yida-data-management` 写入 1-3 条指标源记录并 query 抽查。
-5. 创建 Canvas 大屏页面或 ECharts 页面。
-6. 发布页面，按 PRD 导航顺序做轻量排序，并输出 URL。
-
-## 最终输出口径
-
-完整应用 final 先写 2-3 句业务语言总结交付内容，再给一个主入口链接。不要默认列资源 ID 表格、资源清单或长列表。
-
-推荐写法：
-
-已完成订单、客户和商品等核心业务表单，并发布首页、订单管理和库存看板等入口页面。当前应用已支持订单录入、库存预警、销售统计、表单提交入口和详情查看，示例记录、轻量导航排序与表单详情样式也已就绪。
-
-主入口：`{base_url}/{appType}/workbench`
-
-不推荐写法：
-
-- 默认输出 `资源类型 | 名称/用途 | ID | 状态` 表格。
-- 默认输出资源清单、长列表或多段技术明细。
-- 默认暴露 appType、formUuid、pageId、reportId。
-- 把 `/admin` 管理页、Schema 页、CDN 构建产物或中间文件链接当成交付结果。
-
-只有用户明确要求排障、复盘资源 ID、迁移或复制配置时，才补充技术 ID。
-
-## 默认 seed records 规则
-
-完整应用默认写入；用户明确不要造数、目标是配置字典/权限表、敏感个人数据表、纯附件表或字段缺少可安全构造值时跳过并说明原因。
-
-- 每个核心普通表单 1-3 条即可，列表/工作台通常 2 条，看板/排行/状态分布通常 3 条。
-- 示例记录必须是当前业务语义，不写“测试1 / demo / mock”。
-- 先用 `openyida get-schema <appType> <formUuid> --field-map-json` 获取真实字段 ID。
-- `DateField` / `CascadeDateField` 使用 13 位毫秒时间戳。
-- 每条记录单独执行 `openyida data create form`，不要把多条实例作为顶层数组传入。
-- 写入后执行 query 抽查至少 1 条，确认 `formData` 非空。
-
-## 删除应用确认
-
-删除应用不可逆。执行前必须展示应用名称、应用 ID、影响范围，并等待用户回复“确认删除”或同等明确确认；模糊回复不能执行。
-
-## 故障处理
-
-| 场景 | 处理 |
-|------|------|
-| 发布提示登录失效 | 重新登录后再发布，不无修改重试 |
-| corpId 不一致 | 询问重新登录或当前组织继续 |
-| 不知道字段 ID | 使用 `yida-get-schema` 或 `.cache/<项目名>-schema.json` |
-| Babel/页面校验失败 | 依据报错修 JSX，再重新校验 |
-| 创建应用/表单失败 | 检查登录态、组织、参数、输入文件 |