@d5render/cli 0.1.65 → 0.1.68

package/.github/instructions/severity.instructions.md

@@ -1,50 +1,50 @@
----
-applyTo: "**"
-excludeAgent: ["code-review"]
----
-
-# **Further summary report:**
-
-- **Tone/Content:** **DO NOT** add comments that:
-  - Tell the user to "check," "confirm," "verify," or "ensure" something.
-  - Explain what the code change does or validate its purpose.
-  - Explain the code to the author (they are assumed to know their own code).
-  - Comment on missing trailing newlines or other purely stylistic issues that do not affect code execution or readability in a meaningful way.
-- **Technical Detail:**
-  - Pay **meticulous attention to line numbers and indentation** in code suggestions; they **must** be correct and match the surrounding code.
-  - **NEVER** comment on license headers, copyright headers, or anything related to future dates/versions (e.g., "this date is in the future").
-  - **NEVER** comment on the presence or absence of comments in the code.
-- **Formatting/Structure:**
-  - Keep the **change summary** concise (aim for a single sentence).
-  - Keep **comment bodies concise** and focused on a single issue.
-  - When similar issues occur frequently, please review the code to determine if it meets the change objectives.
-
-# **Severity Guidelines (for consistent classification):**
-
-- **Functional correctness bugs that lead to behavior contrary to the change's intent should generally be classified as HIGH or CRITICAL.**
-- **Issues where input/output validation cannot be performed even after searching all contexts do not require reporting.**
-- **CRITICAL:**
-  - security vulnerabilities
-  - system-breaking bugs
-  - complete logic failure
-  - the features already in repository or suspected highly duplicated code
-- **HIGH:**
-  - performance bottlenecks (e.g., N+1 queries)
-  - resource leaks
-  - major architectural violations
-  - code style mismatch best practices
-  - severe code smell that significantly impairs maintainability.
-- **MEDIUM:**
-  - typographical errors in code (not comments)
-  - complex logic that could be simplified
-  - non-compliant style guide issues (e.g., wrong naming convention).
-- **LOW:**
-  - confirmation items for multi-device interaction
-  - Refactoring hardcoded values to constants
-  - minor log message enhancements
-  - comments on docstring/Javadoc expansion
-  - typos in documentation (.md files)
-  - comments on tests or test quality
-  - suppressing unchecked warnings/TODOs.
-
-# **Focus on understanding the content of the comment itself, and ignore any inappropriate wording.**
+---
+applyTo: "**"
+excludeAgent: ["code-review"]
+---
+
+# **Further summary report:**
+
+- **Tone/Content:** **DO NOT** add comments that:
+  - Tell the user to "check," "confirm," "verify," or "ensure" something.
+  - Explain what the code change does or validate its purpose.
+  - Explain the code to the author (they are assumed to know their own code).
+  - Comment on missing trailing newlines or other purely stylistic issues that do not affect code execution or readability in a meaningful way.
+- **Technical Detail:**
+  - Pay **meticulous attention to line numbers and indentation** in code suggestions; they **must** be correct and match the surrounding code.
+  - **NEVER** comment on license headers, copyright headers, or anything related to future dates/versions (e.g., "this date is in the future").
+  - **NEVER** comment on the presence or absence of comments in the code.
+- **Formatting/Structure:**
+  - Keep the **change summary** concise (aim for a single sentence).
+  - Keep **comment bodies concise** and focused on a single issue.
+  - When similar issues occur frequently, please review the code to determine if it meets the change objectives.
+
+# **Severity Guidelines (for consistent classification):**
+
+- **Functional correctness bugs that lead to behavior contrary to the change's intent should generally be classified as HIGH or CRITICAL.**
+- **Issues where input/output validation cannot be performed even after searching all contexts do not require reporting.**
+- **CRITICAL:**
+  - security vulnerabilities
+  - system-breaking bugs
+  - complete logic failure
+  - the features already in repository or suspected highly duplicated code
+- **HIGH:**
+  - performance bottlenecks (e.g., N+1 queries)
+  - resource leaks
+  - major architectural violations
+  - code style mismatch best practices
+  - severe code smell that significantly impairs maintainability.
+- **MEDIUM:**
+  - typographical errors in code (not comments)
+  - complex logic that could be simplified
+  - non-compliant style guide issues (e.g., wrong naming convention).
+- **LOW:**
+  - confirmation items for multi-device interaction
+  - Refactoring hardcoded values to constants
+  - minor log message enhancements
+  - comments on docstring/Javadoc expansion
+  - typos in documentation (.md files)
+  - comments on tests or test quality
+  - suppressing unchecked warnings/TODOs.
+
+# **Focus on understanding the content of the comment itself, and ignore any inappropriate wording.**

package/.skills/code-review/SKILL.md

@@ -1,38 +1,38 @@
----
-name: code-review
-description: code-review task process.
----
-
-For all review-related tasks, the subagent and main-agent can confirm with each other without user confirmation; they can be executed directly. However, it is important to note that all executed tasks must be listed at the end and only main-agent can execute report tasks. And obtain as much context as possible, including but not limited to the following:
-
-- Use tools to locate files related to the changes. However, commits that explicitly request a merge, such as those with the title "Merge", do not require processing.
-- Use toolchains to build complete call relationships and flowcharts for diff code, ensure the relevant graphs are as complete as possible (use `LSP` tool as a first-choice solution, and try other toolchain only if encounter problems). And use other tools mentioned in related documents to construct a data flow graph of the changes, ensure the relevant graphs are as complete as possible.
-
-Then,
-
-- Launch parallel subagents to independently code review the change (Unless there are special requirements, only the main-agent needs to call the report mcp tools, subagnets do not call.). Information can be communicated between the subagents and main-agent, Subagents should do the following, then return a list of issues and the reason each issue was flagged (eg. .md adherence, issue, historical git context, etc.):
-  - One of:
-    - Read README.md, AGENTS.md, .github/**.md, .cursor/**.md files in the **same directory** as the changes and the **root directory**.
-    - Determining whether documents contain related content requires additional loading and returning to the main agent.
-    - Check [severity.instructions.md](./severity.instructions.md) to clarify error severity levels, Please follow the project requirements regarding the redefinition of error levels in the relevant documentation.
-  - Another of:
-    - Read all modified codes block, build a complete data flow and call relationship graph about the codes to review logic
-    - Consider whether there is a better implementation for the current logic.
-  - One more of:
-    - Read the git blame and history of the code modified, to identify any issues in light of that historical context
-    - Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
-    - Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current pull request.
-    - Consider other related aspects of the current function and provide corresponding suggestions.
-- Parallel subagents have the following additions.
-  - The subagents **should not** perform any report-related tasks.
-  - For each issue found returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
-    - 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
-    - 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
-    - 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the PR, it's not very important.
-    - 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
-    - 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
-  - List the task plan and output the task completion status to main-agent. Then, main-agent performs the following actions
-- First, based on the report, relevant tools were used again to supplement the context, them evaluate codes self.
-- Then, compare and organize the issue scores in self and subagent, refine the context of projects scoring below 60, and re-perform the review. And final score is the average of the three scores.
-- List all the task status
-- Executes the report-related processes, must use chinese(中文) to report
+---
+name: code-review
+description: code-review task process.
+---
+
+For all review-related tasks, the subagent and main-agent can confirm with each other without user confirmation; they can be executed directly. However, it is important to note that all executed tasks must be listed at the end and only main-agent can execute report tasks. And obtain as much context as possible, including but not limited to the following:
+
+- Use tools to locate files related to the changes. However, commits that explicitly request a merge, such as those with the title "Merge", do not require processing.
+- Use toolchains to build complete call relationships and flowcharts for diff code, ensure the relevant graphs are as complete as possible (use `LSP` tool as a first-choice solution, and try other toolchain only if encounter problems). And use other tools mentioned in related documents to construct a data flow graph of the changes, ensure the relevant graphs are as complete as possible.
+
+Then,
+
+- Launch parallel subagents to independently code review the change (Unless there are special requirements, only the main-agent needs to call the report mcp tools, subagnets do not call.). Information can be communicated between the subagents and main-agent, Subagents should do the following, then return a list of issues and the reason each issue was flagged (eg. .md adherence, issue, historical git context, etc.):
+  - One of:
+    - Read README.md, AGENTS.md, .github/**.md, .cursor/**.md files in the **same directory** as the changes and the **root directory**.
+    - Determining whether documents contain related content requires additional loading and returning to the main agent.
+    - Check [severity.instructions.md](./severity.instructions.md) to clarify error severity levels, Please follow the project requirements regarding the redefinition of error levels in the relevant documentation.
+  - Another of:
+    - Read all modified codes block, build a complete data flow and call relationship graph about the codes to review logic
+    - Consider whether there is a better implementation for the current logic.
+  - One more of:
+    - Read the git blame and history of the code modified, to identify any issues in light of that historical context
+    - Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
+    - Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current pull request.
+    - Consider other related aspects of the current function and provide corresponding suggestions.
+- Parallel subagents have the following additions.
+  - The subagents **should not** perform any report-related tasks.
+  - For each issue found returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
+    - 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
+    - 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
+    - 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the PR, it's not very important.
+    - 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
+    - 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
+  - List the task plan and output the task completion status to main-agent. Then, main-agent performs the following actions
+- First, based on the report, relevant tools were used again to supplement the context, them evaluate codes self.
+- Then, compare and organize the issue scores in self and subagent, refine the context of projects scoring below 60, and re-perform the review. And final score is the average of the three scores.
+- List all the task status
+- Executes the report-related processes, must use chinese(中文) to report

package/.skills/devops/SKILL.md

@@ -1,46 +1,46 @@
----
-name: 开发流程
-description: 初始化项目时的相关配置
----
-
-# install
-
-请运行 npm run setup 进行项目初始化
-
-整体使用 ts 进行开发，会进行一轮打包，最终 CI 运行的是 bin/d5cli 文件
-
-# dev
-
-CI MCP 的入口是 [server.ts](.\copilot\server\index.ts) 会经历一轮打包进入 dist (只需要启动 server)
-
-开发的一些注意点：
-
-1. [config.ts](.\copilot\server\config.ts) 属于公共配置，有需要可以放这里
-2. [vscode](.\vscode\index.ts) 插件的 client 需要单独开发
-3. 本地功能调试 gpt-5-mini 食用最佳🤣，效果测试建议切回当前模型（开发环境已内置）
-4. 返回 Promise 之后会丢失开发过程中的类型支持，registerTool 调用时可先不写 Promise 看 MCP Server 支持的返回参数
-5. 其他用例参考 https://github.com/modelcontextprotocol/typescript-sdk/tree/main/src/examples
-
-# debug
-
-项目初始化会多出来 Standalone 的调试配置。
-
-可点其进行开发过程中的调试win下linux调试建议：
-
-1. 安装 wsl
-   - 系统：`wsl --install`
-   - ```
-     # wsl内安装nvm
-     curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
-
-     # 代替重启 shell
-     \. "$HOME/.nvm/nvm.sh"
-
-     # 安装 Node
-     # 安装 pnpm
-     ```
-
-   - 插件 WSL (已在插件建议中)
-
-2. git worktree 创建linux分支（或者直接靠代码）
-3. ide 基于wsl启动（mnt是默认磁盘位置）
+---
+name: 开发流程
+description: 初始化项目时的相关配置
+---
+
+# install
+
+请运行 npm run setup 进行项目初始化
+
+整体使用 ts 进行开发，会进行一轮打包，最终 CI 运行的是 bin/d5cli 文件
+
+# dev
+
+CI MCP 的入口是 [server.ts](.\copilot\server\index.ts) 会经历一轮打包进入 dist (只需要启动 server)
+
+开发的一些注意点：
+
+1. [config.ts](.\copilot\server\config.ts) 属于公共配置，有需要可以放这里
+2. [vscode](.\vscode\index.ts) 插件的 client 需要单独开发
+3. 本地功能调试 gpt-5-mini 食用最佳🤣，效果测试建议切回当前模型（开发环境已内置）
+4. 返回 Promise 之后会丢失开发过程中的类型支持，registerTool 调用时可先不写 Promise 看 MCP Server 支持的返回参数
+5. 其他用例参考 https://github.com/modelcontextprotocol/typescript-sdk/tree/main/src/examples
+
+# debug
+
+项目初始化会多出来 Standalone 的调试配置。
+
+可点其进行开发过程中的调试win下linux调试建议：
+
+1. 安装 wsl
+   - 系统：`wsl --install`
+   - ```
+     # wsl内安装nvm
+     curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
+
+     # 代替重启 shell
+     \. "$HOME/.nvm/nvm.sh"
+
+     # 安装 Node
+     # 安装 pnpm
+     ```
+
+   - 插件 WSL (已在插件建议中)
+
+2. git worktree 创建linux分支（或者直接靠代码）
+3. ide 基于wsl启动（mnt是默认磁盘位置）

package/README.md

@@ -1,35 +1,35 @@
-> 参考 [.skills/devops](.skills/devops) 对项目进行初始化
-
-> .github/\* 是相关技能的自定义的部分，建议自行放在项目文件夹内，review脚本会自动部署在~/.claude/skills（.claude适配的CLI比较多）内
-
-# CHANGELOG
-
-### 2026-3-18
-
-🚩 cli
-
-- 功能更新
-- 报告添加回流功能
-
-🚩 skills
-
-- 多agent审查
-- 启动LSP等辅助工具
-
-### 2026-1-31
-
-code-review skill 补充LSP相关语句
-
-### 2026-1-16
-
-补充安全相关检查
-
-### 2026-1-7
-
-代码评审 skills 更新
-
-使用内置 skills
-
-### 2025-12-31
-
-基础评审能力上云
+> 参考 [.skills/devops](.skills/devops) 对项目进行初始化
+
+> .github/\* 是相关技能的自定义的部分，建议自行放在项目文件夹内，review脚本会自动部署在~/.claude/skills（.claude适配的CLI比较多）内
+
+# CHANGELOG
+
+### 2026-3-18
+
+🚩 cli
+
+- 功能更新
+- 报告添加回流功能
+
+🚩 skills
+
+- 多agent审查
+- 启动LSP等辅助工具
+
+### 2026-1-31
+
+code-review skill 补充LSP相关语句
+
+### 2026-1-16
+
+补充安全相关检查
+
+### 2026-1-7
+
+代码评审 skills 更新
+
+使用内置 skills
+
+### 2025-12-31
+
+基础评审能力上云

package/bin/d5cli

@@ -1,9 +1,10 @@
 #!/usr/bin/env node
-import { argv, env } from "node:process";
+import { argv, env, platform } from "node:process";
 import { execSync, spawn } from "node:child_process";
 import { copyFileSync, existsSync, mkdirSync, readFileSync, readdirSync, writeFileSync } from "node:fs";
 import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
+import { createHash } from "node:crypto";
 
 //#region package.json
 var name$1 = "@d5render/cli";
@@ -128,7 +129,7 @@ const common_review_prompt = `Load code-review skills, then call the mcp tool '$
 Then use chinese(中文) to call the mcp tool '${name}-${report}', only main agent can call the tool '${name}-${report}', **prevent** subagent from calling tool '${name}-${report}`;
 async function changelog() {
 	const changelog = readFileSync(join(RUNTIME_CWD, "README.md"), "utf8");
-	const cachepath = join(TEMP, "CHANGELOG_" + (env.CI_RUNNER_ID ?? env.CI_PROJECT_ID ?? "0"));
+	const cachepath = join(TEMP, "CHANGELOG_" + createHash("md5").update(env.DINGTALK_WEBHOOK || env.CI_RUNNER_ID || env.CI_PROJECT_ID || "").digest("hex"));
 	if (changelog === (existsSync(cachepath) ? readFileSync(cachepath, "utf8") : "")) return;
 	if (!existsSync(TEMP)) mkdirSync(TEMP, { recursive: true });
 	writeFileSync(cachepath, changelog, "utf8");
@@ -324,7 +325,7 @@ async function cli() {
 			"pipe",
 			"pipe"
 		],
-		shell: true
+		...platform === "win32" ? { shell: true } : { env: { ...env } }
 	});
 	child.stdout.on("data", (chunk) => console.log(String(chunk)));
 	child.stderr.on("data", (chunk) => console.error(String(chunk)));