@weotro/dx 0.3.2 → 0.3.4

package/lib/codex-initial.js

@@ -33,6 +33,7 @@ const DELETED_SKILLS = [
   'pr-ship',
   'pr-train-ship',
   'create-issue',
+  'stagewise-ui-debugging',
   'third-party-review',
 ]
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@weotro/dx",
-  "version": "0.3.2",
+  "version": "0.3.4",
   "type": "module",
   "license": "MIT",
   "repository": {

package/skills/project-agent-standards/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: project-agent-standards
-description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审规范、DX 工作流与回访 Issue 规则，将 AGENTS.md 整理为按需读取的渐进披露结构。
+description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审规范、DX 工作流、回访 Issue 规则、.scratch 跟踪与跨端联动约束，将 AGENTS.md 整理为按需读取的渐进披露结构。
 ---
 
 # 项目 Agent 规范整备
@@ -13,11 +13,21 @@ description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审
 
 检查工作区状态，读取目标及祖先的 `AGENTS.md`。按需检查已有规范、贡献指南、GitHub 模板、技术栈清单、任务配置和 CI。优先搜索标题与职责，不能仅凭文件名判定规范缺失。
 
-记录以下七项的现状、路径和缺口：Issue / PR 模板、agent 引用、开发评审规范、DX / Nx 工作流、回访规则、AGENTS.md 渐进披露结构、根 AGENTS.md 的开工前三问。检查根及模块 agent 入口的内容分工、读取条件和引用链；祖先指令用于确定约束，不修改目标仓库之外的文件。区分已配置的命令、实际运行结果与未来建议；不读取或输出秘密值。
+记录以下十一项的现状、路径和缺口：Issue / PR 模板、agent 引用、开发评审规范、DX / Nx 工作流、回访规则、AGENTS.md 渐进披露结构、根 AGENTS.md 的开工前三问、`.scratch/` 的 Git 跟踪状态、跨端联动规则、GitHub Issue / PR 的直接提交流程、中文协作与英文诊断的语言规范。检查根及模块 agent 入口的内容分工、读取条件和引用链；祖先指令用于确定约束，不修改目标仓库之外的文件。区分已配置的命令、实际运行结果与未来建议；不读取或输出秘密值。
+
+另检查根 `AGENTS.md` 的视觉核对规则：是否明确默认无需视觉核对，以及用户或适用技能明确要求时的例外。
 
 完成条件：每项均有存在证据或明确的缺失结论，能够识别目标模块与实际工具链。
 
-## 2. 补齐 GitHub 模板
+### 检查 `.scratch/` 的 Git 跟踪
+
+根目录 `.scratch/` 应纳入版本控制，不得被 Git 忽略。分别检查实际跟踪与忽略状态：用 `git ls-files -- .scratch/` 确认已有受跟踪文件；用 `git check-ignore -v --no-index -- .scratch/ .scratch/.gitkeep` 并结合目录内现有文件检查生效规则。即使已有文件被跟踪，也要检查是否仍有忽略规则阻止新增文件进入版本控制；命中 `!` 反向规则表示取消忽略，不能仅凭命令退出码判断。
+
+缺失或空目录补 `.scratch/.gitkeep`，因为 Git 不跟踪空目录。最小调整仓库内的 `.gitignore`，解除对 `.scratch/` 及其内容的忽略；若由父目录或通配规则造成，确保父目录与内容均可被重新包含。全局忽略或 `.git/info/exclude` 的影响优先通过仓库内精确反向规则解决，不修改仓库外配置。保留凭据等敏感文件的专用忽略规则，不批量暂存现有内容。只读审核仅报告缺口。
+
+完成条件：报告目录是否存在、是否被忽略、是否已有受跟踪文件及修复结果。新增文件尚未进入 Git 索引时标明“待纳入跟踪”，不能将“未被忽略”报告为“已跟踪”；只有用户授权暂存时才将核实过的文件加入索引。
+
+## 2. 补齐 GitHub 模板与提交流程
 
 使用随技能携带的完整模板，无需访问原始项目：
 
@@ -30,7 +40,13 @@ description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审
 
 检查根目录、`docs/` 与 `.github/` 是否有竞争的默认 PR 模板；将仍适用的独有约束合入标准模板，再清理被取代的默认副本并更新引用。保留用途不同的 Issue Forms、多模板及配置，不因其存在就删除。已有标准文件中的项目专属验收要求同样需要保留。
 
-完成条件：Issue / PR 均有可用模板，已有正确且适用的路径保留，默认 PR 模板选择无冲突，独有约束和用户原文可追踪。
+检查 `AGENTS.md` 引用的 Issue / PR 流程、贡献指南及相关命令说明，确保明确采用以下正常提交流程；已有等效规则则复用，缺失时在现有流程文档中补齐，没有载体时创建 `docs/agents/github-workflow.md`，并在根 `AGENTS.md` 添加创建或更新 GitHub Issue / PR 时必须读取的入口：
+
+> 用户要求创建 GitHub Issue / PR 时，完成必要的信息整理与项目要求的验证后，直接提交到 GitHub。Issue 创建为正式 Issue；PR 创建为可评审的普通 PR，不使用 Draft 状态或 `--draft`。不设置“先生成本地草稿、等待草稿确认、再发布”的中间流程，也不以 GitHub Projects 的 draft issue 代替正式 Issue。提交后返回实际链接，继续正常的评审、CI 与合并流程。
+
+将已有“默认草稿”“先草稿再转正式”或“先确认草稿才能发布”的相冲突说明改为此流程，保留正常的内容检查、评审与 CI 要求。用于 CLI 提交正文的临时文件不属于草稿流程；用户只要求撰写或审核正文时，仍按该任务范围处理。本技能整备流程文档本身不创建或发布 Issue / PR。
+
+完成条件：Issue / PR 均有可用模板，已有正确且适用的路径保留，默认 PR 模板选择无冲突，提交流程明确使用正式 Issue 与普通 PR，入口可达且无冲突的草稿要求，独有约束和用户原文可追踪。
 
 ## 3. 补齐面向 agent 的参考文档
 
@@ -42,7 +58,7 @@ description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审
 | DX / Nx 工作流 | [工作流骨架](assets/dx-development-workflow.md) | `docs/guides/dx-development-workflow.md` |
 | 回访规则 | [回访规则](assets/follow-up-issues.md) | `docs/agents/follow-up-issues.md` |
 
-文档写给执行任务的 agent：说明触发条件、具体决策、命令前置条件、失败处理与完成证据。删除骨架中的编写提示及不适用分支，替换所有 `{{...}}`。保留目标项目语言约定，无约定时使用简体中文。
+文档写给执行任务的 agent：说明触发条件、具体决策、命令前置条件、失败处理与完成证据。删除骨架中的编写提示及不适用分支，替换所有 `{{...}}`。新建或修改的内容遵循第 4 步的语言规范。
 
 开发规范应覆盖实际模块与风险；不会因使用此技能就迁移成三层架构或引入新的测试框架。将已有约束、此次建立的规则和未来建议分清；尚未接入的检查不能写成已经运行的门禁。
 
@@ -54,13 +70,30 @@ DX 文档必须检查实际 DX 配置、Nx 目标与 CLI 能力。已接入则
 
 ## 4. 检查并改造 AGENTS.md 的渐进披露结构
 
+检查根 `AGENTS.md`（沿用仓库已有的文件名大小写）是否明确包含以下语言规范。已有完整等效规则则保留，部分缺失时只补缺项，缺失时在根入口的全局约束中添加；仅写“默认中文回复”不足以覆盖全部要求：
+
+> 所有输出文档、讨论与回复、Issue / PR 的标题和正文、评审评论以及代码注释均使用简体中文；程序日志、错误信息及其他运行时诊断文本使用英文。代码标识符、命令、协议字段及引用的原始日志或错误文本保持原样。
+
+检查模块入口与被引用规范中的语言要求，修正与上述规则冲突的说明，确保中文协作与英文诊断两类要求同时生效。只读审核仅报告缺口；本次整备补齐规则，不批量翻译历史文档或改写应用日志。
+
 检查根 `AGENTS.md`（沿用仓库已有的文件名大小写）是否包含以下开工前三问。已有完整等效约束且正确、符合项目状况时保持原样；部分缺失时只补缺项，整段缺失时在根入口的工作原则或全局约束处加入以下内容，沿用项目语言。此约束属于全局必需规则，保留在根入口正文中：
 
 > Ask yourself before starting:
 >
 > 1. "Is this a real problem?" - Reject over-engineering.
 > 2. "Is there a simpler way?" - Always seek the simplest solution (KISS).
-> 3. "Will it break anything?" - Backward compatibility is an iron law.
+
+根据源码目录与工作区配置识别实际存在的 `mobile`、`admin`、`front` 应用，包括 `apps/` 等嵌套位置。存在其中至少两端时，检查根 `AGENTS.md` 是否已有覆盖这些端的联动规则；仅在某一端的模块入口中有规则不足以覆盖其他端发起的修改。缺失时在根入口补齐以下约束，并按实际存在的端适配：
+
+> 修改 mobile、admin、front 任一端时，必须同时评估其他现有端是否需要同步修改，重点核对共享业务规则、接口契约、数据字段及对应用户流程。mobile 与 front 经常承载相同功能，修改其中一端时必须检查另一端的对应实现。需要联动时一并修改并验证受影响端；无需联动时在交付说明中简述依据。
+
+已有等效约束时复用，仅有单端时将跨端检查记为“不适用”，不添加不存在的端或要求无关端机械同步。
+
+检查根 `AGENTS.md` 是否包含以下视觉核对规则。已有完整等效规则则保留，部分缺失时只补缺项，缺失时在根入口的验收约束中添加：
+
+> 在验收或检查前端、移动端 App 或页面时，默认无需进行视觉核对；只有用户或当前任务适用的技能明确要求视觉核对时才执行。功能、交互、测试及构建等其他必要验证仍按任务要求进行。
+
+核对模块入口与被引用的验收规范，修正默认强制视觉核对的冲突说明，保留用户或适用技能明确要求的例外。只读审核仅报告缺口。
 
 渐进披露按任务需要加载说明：根入口保留项目识别、全局必需约束与条件明确的文档入口；模块入口保留该目录适用的规则；详细流程、命令说明、模板字段和专题规范放在被引用文档中。判断依据是内容职责与加载方式，不以行数或是否已有链接判定。只有简短必需规则的入口无需为了拆分而创建文件。
 
@@ -87,6 +120,8 @@ DX 文档必须检查实际 DX 配置、Nx 目标与 CLI 能力。已接入则
 
 ## 5. 验证与交付
 
-检查差异、Markdown 链接、模板 frontmatter、占位符和竞争模板。逐项复核第 1 步的七项清单与所有新引用，确认根入口的开工前三问完整，已有正确且适用的内容未被改写，每处修改均有具体缺口或纠错依据，再执行一次不会增加文件或重复条目。对照迁移记录检查规则完整性，并分别用代码修改、Issue / PR 编写和回访任务走查入口，确认能够找到对应规范，且不会要求加载无关专题。
+复核视觉核对规则的默认行为与例外：普通前端、移动端 App 或页面验收不增加视觉核对要求；用户或适用技能明确要求时执行，且不影响其他必要验证。
+
+检查差异、Markdown 链接、模板 frontmatter、占位符和竞争模板。逐项复核第 1 步的十一项清单与所有新引用，确认根入口的开工前三问完整、语言规范覆盖中文文档与讨论、Issue / PR、评论和代码注释以及英文日志与错误信息、`.scratch/` 的跟踪与忽略状态已分别核实、适用项目的跨端联动规则覆盖实际存在的各端，已有正确且适用的内容未被改写，每处修改均有具体缺口或纠错依据，再执行一次不会增加文件或重复条目。对照迁移记录检查规则完整性，并分别用代码修改、Issue / PR 编写和回访任务走查入口；模拟用户要求创建 GitHub Issue / PR 的任务，确认流程直接提交正式 Issue 或普通 PR，没有草稿确认或 Draft 状态的中间环节；多端项目额外从 mobile 或 front 修改任务走查另一端影响评估，确认能够找到对应规范，且不会要求加载无关专题。
 
 纯文档修改按项目规则做差异与格式验证；验证命令存在可以检查配置或安全的帮助输出，不为文档审核运行发布、迁移或全仓测试。报告每项的保留 / 新建 / 更新状态、文件链接、实际验证和未确认事项，以及渐进披露检查结论与章节迁移去向；未接入 DX / Nx 要明确说明。不要将文档中列出的命令写成已经执行通过。

package/skills/stagewise-ui-debugging/SKILL.md

@@ -1,54 +0,0 @@
----
-name: stagewise-ui-debugging
-description: 仅在显式调用 stagewise-ui-debugging 时使用：对比 Stagewise 设计稿与前端 UI。
----
-
-# Stagewise UI 调试
-
-## 执行边界与优先级
-
-在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
-只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
-仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
-
-## 概览
-
-用于对齐 `design/ui_kits/app/` 设计稿和 `apps/front` 前端页面。核心原则：改 UI 前先在相同视口下，对比 Stagewise 包装后的设计站和前端站。
-
-## 速查
-
-| 目标 | 未启动时的候选命令 | 默认访问地址 |
-| --- | --- | --- |
-| 设计稿 | `dx start stagewise-design-system` | `http://localhost:8766/ui_kits/app/` |
-| 前端页面 | `dx start stack-front` | `http://localhost:3002` |
-
-`stagewise-design-system` 会用 Stagewise 包装设计静态站，桥接 `8765 -> 8766`。`stack-front` 会启动 PM2 交互式服务栈和 `stagewise-front`，桥接 `3001 -> 3002`。
-
-## 流程
-
-1. 从项目配置核实地址并检查服务状态，复用已启动的实例。缺少服务时，根据项目实际命令自主启动所需的本地开发服务；默认命令示例：
-   ```bash
-   dx start stagewise-design-system
-   dx start stack-front
-   ```
-2. 用浏览器工具访问所需页面。打不开、空白或渲染异常时，自行检查端口、启动日志和依赖，修复可回滚的本地问题后重试；需要用户凭据或交互时说明具体阻塞。
-3. 在相同浏览器视口下对比本次涉及的组件或页面。响应式改动检查桌面和移动端；单一断点修改先验证该断点，影响布局时再扩展。
-4. 检查 DOM 时记住：两个页面都经过 Stagewise 包装。包装节点、桥接覆盖层、注入属性可能和裸应用 DOM 不同。优先做视觉对比和稳定的应用层选择器检查；编辑前先确认样式来自产品 UI，而不是 Stagewise 外壳。
-5. 修改后端或前端页面后，页面会自动刷新到最新状态。需要确认时重新查看或刷新浏览器对比，不要先急着重启服务。
-6. 如果任务涉及真实 UI 实现，按项目指令读取涉及组件的设计规则；`design/readme.md`、`design/SKILL.md`、`ruler/design-system.md` 仅在实际存在且与本次修改相关时读取。
-
-## 触发示例
-
-用户说：“调一下前端和设计稿的卡片间距。”
-
-用户显式调用本技能后，检查服务、定位该卡片并在同一视口对比，修改间距并验证受影响的布局。普通间距调整不自动加载本技能。
-
-## 常见误区
-
-| 常见问题 | 处理方式 |
-| --- | --- |
-| 用 `localhost:3001` 和设计稿对比，而不是 Stagewise 的 `3002` | 使用包装后的地址，让前端和设计稿处在同一种调试表面。 |
-| 把空白页直接当成 UI bug | 先确认对应 `dx start ...` 服务正在运行且健康。 |
-| 用不同视口宽度对比 | 设计稿和前端设置相同视口，并补充移动端检查。 |
-| 根据 Stagewise 包装 DOM 直接改样式 | 确认选中的节点或样式属于产品 UI，不是 Stagewise 外壳。 |
-| 每次页面改动后立刻手动重启 | 先看自动刷新或热更新后的浏览器结果，再决定是否需要重启。 |

package/skills/stagewise-ui-debugging/agents/openai.yaml

@@ -1,2 +0,0 @@
-policy:
-  allow_implicit_invocation: false