@weotro/dx 0.3.2 → 0.3.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: project-agent-standards
|
|
3
|
-
description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审规范、DX
|
|
3
|
+
description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审规范、DX 工作流、回访 Issue 规则、.scratch 跟踪与跨端联动约束，将 AGENTS.md 整理为按需读取的渐进披露结构。
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# 项目 Agent 规范整备
|
|
@@ -13,11 +13,19 @@ description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审
|
|
|
13
13
|
|
|
14
14
|
检查工作区状态，读取目标及祖先的 `AGENTS.md`。按需检查已有规范、贡献指南、GitHub 模板、技术栈清单、任务配置和 CI。优先搜索标题与职责，不能仅凭文件名判定规范缺失。
|
|
15
15
|
|
|
16
|
-
|
|
16
|
+
记录以下十项的现状、路径和缺口：Issue / PR 模板、agent 引用、开发评审规范、DX / Nx 工作流、回访规则、AGENTS.md 渐进披露结构、根 AGENTS.md 的开工前三问、`.scratch/` 的 Git 跟踪状态、跨端联动规则、GitHub Issue / PR 的直接提交流程。检查根及模块 agent 入口的内容分工、读取条件和引用链；祖先指令用于确定约束，不修改目标仓库之外的文件。区分已配置的命令、实际运行结果与未来建议；不读取或输出秘密值。
|
|
17
17
|
|
|
18
18
|
完成条件：每项均有存在证据或明确的缺失结论，能够识别目标模块与实际工具链。
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
### 检查 `.scratch/` 的 Git 跟踪
|
|
21
|
+
|
|
22
|
+
根目录 `.scratch/` 应纳入版本控制，不得被 Git 忽略。分别检查实际跟踪与忽略状态：用 `git ls-files -- .scratch/` 确认已有受跟踪文件；用 `git check-ignore -v --no-index -- .scratch/ .scratch/.gitkeep` 并结合目录内现有文件检查生效规则。即使已有文件被跟踪，也要检查是否仍有忽略规则阻止新增文件进入版本控制；命中 `!` 反向规则表示取消忽略，不能仅凭命令退出码判断。
|
|
23
|
+
|
|
24
|
+
缺失或空目录补 `.scratch/.gitkeep`，因为 Git 不跟踪空目录。最小调整仓库内的 `.gitignore`，解除对 `.scratch/` 及其内容的忽略；若由父目录或通配规则造成，确保父目录与内容均可被重新包含。全局忽略或 `.git/info/exclude` 的影响优先通过仓库内精确反向规则解决，不修改仓库外配置。保留凭据等敏感文件的专用忽略规则，不批量暂存现有内容。只读审核仅报告缺口。
|
|
25
|
+
|
|
26
|
+
完成条件：报告目录是否存在、是否被忽略、是否已有受跟踪文件及修复结果。新增文件尚未进入 Git 索引时标明“待纳入跟踪”，不能将“未被忽略”报告为“已跟踪”；只有用户授权暂存时才将核实过的文件加入索引。
|
|
27
|
+
|
|
28
|
+
## 2. 补齐 GitHub 模板与提交流程
|
|
21
29
|
|
|
22
30
|
使用随技能携带的完整模板，无需访问原始项目：
|
|
23
31
|
|
|
@@ -30,7 +38,13 @@ description: 审核并补齐项目面向 agent 的 GitHub 模板、开发评审
|
|
|
30
38
|
|
|
31
39
|
检查根目录、`docs/` 与 `.github/` 是否有竞争的默认 PR 模板；将仍适用的独有约束合入标准模板，再清理被取代的默认副本并更新引用。保留用途不同的 Issue Forms、多模板及配置，不因其存在就删除。已有标准文件中的项目专属验收要求同样需要保留。
|
|
32
40
|
|
|
33
|
-
|
|
41
|
+
检查 `AGENTS.md` 引用的 Issue / PR 流程、贡献指南及相关命令说明，确保明确采用以下正常提交流程；已有等效规则则复用，缺失时在现有流程文档中补齐，没有载体时创建 `docs/agents/github-workflow.md`，并在根 `AGENTS.md` 添加创建或更新 GitHub Issue / PR 时必须读取的入口：
|
|
42
|
+
|
|
43
|
+
> 用户要求创建 GitHub Issue / PR 时，完成必要的信息整理与项目要求的验证后，直接提交到 GitHub。Issue 创建为正式 Issue；PR 创建为可评审的普通 PR，不使用 Draft 状态或 `--draft`。不设置“先生成本地草稿、等待草稿确认、再发布”的中间流程，也不以 GitHub Projects 的 draft issue 代替正式 Issue。提交后返回实际链接，继续正常的评审、CI 与合并流程。
|
|
44
|
+
|
|
45
|
+
将已有“默认草稿”“先草稿再转正式”或“先确认草稿才能发布”的相冲突说明改为此流程，保留正常的内容检查、评审与 CI 要求。用于 CLI 提交正文的临时文件不属于草稿流程；用户只要求撰写或审核正文时，仍按该任务范围处理。本技能整备流程文档本身不创建或发布 Issue / PR。
|
|
46
|
+
|
|
47
|
+
完成条件：Issue / PR 均有可用模板，已有正确且适用的路径保留，默认 PR 模板选择无冲突，提交流程明确使用正式 Issue 与普通 PR，入口可达且无冲突的草稿要求，独有约束和用户原文可追踪。
|
|
34
48
|
|
|
35
49
|
## 3. 补齐面向 agent 的参考文档
|
|
36
50
|
|
|
@@ -60,7 +74,12 @@ DX 文档必须检查实际 DX 配置、Nx 目标与 CLI 能力。已接入则
|
|
|
60
74
|
>
|
|
61
75
|
> 1. "Is this a real problem?" - Reject over-engineering.
|
|
62
76
|
> 2. "Is there a simpler way?" - Always seek the simplest solution (KISS).
|
|
63
|
-
|
|
77
|
+
|
|
78
|
+
根据源码目录与工作区配置识别实际存在的 `mobile`、`admin`、`front` 应用，包括 `apps/` 等嵌套位置。存在其中至少两端时，检查根 `AGENTS.md` 是否已有覆盖这些端的联动规则；仅在某一端的模块入口中有规则不足以覆盖其他端发起的修改。缺失时在根入口补齐以下约束，并按实际存在的端适配：
|
|
79
|
+
|
|
80
|
+
> 修改 mobile、admin、front 任一端时，必须同时评估其他现有端是否需要同步修改，重点核对共享业务规则、接口契约、数据字段及对应用户流程。mobile 与 front 经常承载相同功能，修改其中一端时必须检查另一端的对应实现。需要联动时一并修改并验证受影响端；无需联动时在交付说明中简述依据。
|
|
81
|
+
|
|
82
|
+
已有等效约束时复用，仅有单端时将跨端检查记为“不适用”，不添加不存在的端或要求无关端机械同步。
|
|
64
83
|
|
|
65
84
|
渐进披露按任务需要加载说明：根入口保留项目识别、全局必需约束与条件明确的文档入口；模块入口保留该目录适用的规则；详细流程、命令说明、模板字段和专题规范放在被引用文档中。判断依据是内容职责与加载方式，不以行数或是否已有链接判定。只有简短必需规则的入口无需为了拆分而创建文件。
|
|
66
85
|
|
|
@@ -87,6 +106,6 @@ DX 文档必须检查实际 DX 配置、Nx 目标与 CLI 能力。已接入则
|
|
|
87
106
|
|
|
88
107
|
## 5. 验证与交付
|
|
89
108
|
|
|
90
|
-
检查差异、Markdown 链接、模板 frontmatter、占位符和竞争模板。逐项复核第 1
|
|
109
|
+
检查差异、Markdown 链接、模板 frontmatter、占位符和竞争模板。逐项复核第 1 步的十项清单与所有新引用，确认根入口的开工前三问完整、`.scratch/` 的跟踪与忽略状态已分别核实、适用项目的跨端联动规则覆盖实际存在的各端，已有正确且适用的内容未被改写，每处修改均有具体缺口或纠错依据，再执行一次不会增加文件或重复条目。对照迁移记录检查规则完整性，并分别用代码修改、Issue / PR 编写和回访任务走查入口；模拟用户要求创建 GitHub Issue / PR 的任务，确认流程直接提交正式 Issue 或普通 PR，没有草稿确认或 Draft 状态的中间环节；多端项目额外从 mobile 或 front 修改任务走查另一端影响评估，确认能够找到对应规范，且不会要求加载无关专题。
|
|
91
110
|
|
|
92
111
|
纯文档修改按项目规则做差异与格式验证；验证命令存在可以检查配置或安全的帮助输出，不为文档审核运行发布、迁移或全仓测试。报告每项的保留 / 新建 / 更新状态、文件链接、实际验证和未确认事项，以及渐进披露检查结论与章节迁移去向；未接入 DX / Nx 要明确说明。不要将文档中列出的命令写成已经执行通过。
|