@d5render/cli 0.1.60 → 0.1.61

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.
@@ -3,32 +3,47 @@ applyTo: "**"
3
3
  excludeAgent: ["code-review"]
4
4
  ---
5
5
 
6
+ # **Further summary report:**
7
+ - **Tone/Content:** **DO NOT** add comments that:
8
+ - Tell the user to "check," "confirm," "verify," or "ensure" something.
9
+ - Explain what the code change does or validate its purpose.
10
+ - Explain the code to the author (they are assumed to know their own code).
11
+ - Comment on missing trailing newlines or other purely stylistic issues that do not affect code execution or readability in a meaningful way.
12
+ - **Technical Detail:**
13
+ - Pay **meticulous attention to line numbers and indentation** in code suggestions; they **must** be correct and match the surrounding code.
14
+ - **NEVER** comment on license headers, copyright headers, or anything related to future dates/versions (e.g., "this date is in the future").
15
+ - **NEVER** comment on the presence or absence of comments in the code.
16
+ - **Formatting/Structure:**
17
+ - Keep the **change summary** concise (aim for a single sentence).
18
+ - Keep **comment bodies concise** and focused on a single issue.
19
+ - When similar issues occur frequently, please review the code to determine if it meets the change objectives.
20
+
6
21
  # **Severity Guidelines (for consistent classification):**
7
22
 
8
23
  - **Functional correctness bugs that lead to behavior contrary to the change's intent should generally be classified as HIGH or CRITICAL.**
9
24
  - **Issues where input/output validation cannot be performed even after searching all contexts do not require reporting.**
10
25
  - **CRITICAL:**
11
- - security vulnerabilities
12
- - system-breaking bugs
13
- - complete logic failure
14
- - the features already in repository or suspected highly duplicated code
26
+ - security vulnerabilities
27
+ - system-breaking bugs
28
+ - complete logic failure
29
+ - the features already in repository or suspected highly duplicated code
15
30
  - **HIGH:**
16
- - performance bottlenecks (e.g., N+1 queries)
17
- - resource leaks
18
- - major architectural violations
19
- - code style mismatch best practices
20
- - severe code smell that significantly impairs maintainability.
31
+ - performance bottlenecks (e.g., N+1 queries)
32
+ - resource leaks
33
+ - major architectural violations
34
+ - code style mismatch best practices
35
+ - severe code smell that significantly impairs maintainability.
21
36
  - **MEDIUM:**
22
- - typographical errors in code (not comments)
23
- - complex logic that could be simplified
24
- - non-compliant style guide issues (e.g., wrong naming convention).
37
+ - typographical errors in code (not comments)
38
+ - complex logic that could be simplified
39
+ - non-compliant style guide issues (e.g., wrong naming convention).
25
40
  - **LOW:**
26
- - confirmation items for multi-device interaction
27
- - Refactoring hardcoded values to constants
28
- - minor log message enhancements
29
- - comments on docstring/Javadoc expansion
30
- - typos in documentation (.md files)
31
- - comments on tests or test quality
32
- - suppressing unchecked warnings/TODOs.
41
+ - confirmation items for multi-device interaction
42
+ - Refactoring hardcoded values to constants
43
+ - minor log message enhancements
44
+ - comments on docstring/Javadoc expansion
45
+ - typos in documentation (.md files)
46
+ - comments on tests or test quality
47
+ - suppressing unchecked warnings/TODOs.
33
48
 
34
49
  # **Focus on understanding the content of the comment itself, and ignore any inappropriate wording.**
@@ -1,38 +1,39 @@
1
1
  ---
2
2
  name: code-review
3
3
  description: code-review task process.
4
- disable-model-invocation: false
5
4
  ---
6
5
 
7
- 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-related tasks.
6
+ For all review-related tasks, the subagent and main-agent can confirm with each other without user confirmation; they can be executed directly.
7
+ However, it is important to note that all executed tasks must be listed at the end and only main-agent can execute report tasks.
8
+ And obtain as much context as possible, including but not limited to the following:
9
+ - 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.
10
+ - 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.
8
11
 
9
- - Obtain as much context as possible and return a summary, including but not limited to the following:
10
- - 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.
11
- - Use tools to construct a data flow graph of the changes, ensure the relevant graphs are as complete as possible.
12
- - **You MUST use LSP tools** to build a complete code relationship graph. Follow the steps in [LSP.md](./lsp.md) strictly.
13
- - Other tools mentioned in related documents
14
- - Then, launch parallel agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. .md adherence, bug, historical git context, etc.):
15
- 1. Agent #1: Audit the changes to make sure they compily with the .md.
16
- - Read README.md, AGENTS.md, .github/**.md, .cursor/**.md files in the **same directory** as the changes and the **root directory**.
17
- - Determining whether documents contain related content requires additional loading and returning to the main agent.
18
- - 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.
19
- 2. Agent #2: Read the file changes to obvious bugs
20
- 3. Agent #3:
21
- - Read the git blame and history of the code modified, to identify any bugs in light of that historical context
22
- - Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
23
- - 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.
24
- - Consider other related aspects of the current function and provide corresponding suggestions.
12
+ Then,
13
+ - 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.):
14
+ - One of:
15
+ - Read README.md, AGENTS.md, .github/**.md, .cursor/**.md files in the **same directory** as the changes and the **root directory**.
16
+ - Determining whether documents contain related content requires additional loading and returning to the main agent.
17
+ - 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.
18
+ - Another of:
19
+ - Read all modified codes block, build a complete data flow and call relationship graph about the codes to review logic
20
+ - Consider whether there is a better implementation for the current logic.
21
+ - One more of:
22
+ - Read the git blame and history of the code modified, to identify any issues in light of that historical context
23
+ - Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
24
+ - 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.
25
+ - Consider other related aspects of the current function and provide corresponding suggestions.
25
26
  - Parallel subagents have the following additions.
26
- - The subagents **should not** perform any report-related tasks.
27
- - 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):
28
- - 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
29
- - 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.
30
- - 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.
31
- - 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.
32
- - 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.
33
- - List the task plan and output the task completion status.
34
- - Then, main agent performs the following actions
35
- - First, please 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.
36
- - The final score is the average of the three scores.
37
- - List all the task status
38
- - Executes the report-related processes, must use chinese(中文) to report
27
+ - The subagents **should not** perform any report-related tasks.
28
+ - 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):
29
+ - 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
30
+ - 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.
31
+ - 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.
32
+ - 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.
33
+ - 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.
34
+ - List the task plan and output the task completion status to main-agent.
35
+ Then, main-agent performs the following actions
36
+ - First, based on the report, relevant tools were used again to supplement the context, them evaluate codes self.
37
+ - 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.
38
+ - List all the task status
39
+ - Executes the report-related processes, must use chinese(中文) to report
@@ -1,3 +1,8 @@
1
+ ---
2
+ name: 开发流程
3
+ description: 初始化项目时的相关配置
4
+ ---
5
+
1
6
  # install
2
7
 
3
8
  请运行 npm run setup 进行项目初始化
@@ -20,21 +25,22 @@ CI MCP 的入口是 [server.ts](.\copilot\server\index.ts) 会经历一轮打包
20
25
 
21
26
  项目初始化会多出来 Standalone 的调试配置。
22
27
 
23
- 可点其进行开发过程中的调试
24
- win下linux调试建议:
28
+ 可点其进行开发过程中的调试win下linux调试建议:
29
+
25
30
  1. 安装 wsl
26
- - 系统:`wsl --install`
27
- -
28
- ```
29
- # wsl内安装nvm
30
- curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
31
-
32
- # 代替重启 shell
33
- \. "$HOME/.nvm/nvm.sh"
34
-
35
- # 安装 Node
36
- # 安装 pnpm
37
- ```
38
- - 插件 WSL (已在插件建议中)
31
+ - 系统:`wsl --install`
32
+ - ```
33
+ # wsl内安装nvm
34
+ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
35
+
36
+ # 代替重启 shell
37
+ \. "$HOME/.nvm/nvm.sh"
38
+
39
+ # 安装 Node
40
+ # 安装 pnpm
41
+ ```
42
+
43
+ - 插件 WSL (已在插件建议中)
44
+
39
45
  2. git worktree 创建linux分支(或者直接靠代码)
40
46
  3. ide 基于wsl启动(mnt是默认磁盘位置)
package/README.md CHANGED
@@ -1,3 +1,33 @@
1
- for devops, please refer [.skills/devops](.skills/devops)
1
+ > 参考 [.skills/devops](.skills/devops) 对项目进行初始化
2
2
 
3
- for codereview, please refer[.skills/code-review/SKILL.md](.skills/code-review/SKILL.md)
3
+ > .github/* 是相关技能的自定义的部分,建议自行放在项目文件夹内,review脚本会自动部署在~/.claude/skills(.claude适配的CLI比较多)内
4
+
5
+ # CHANGELOG
6
+
7
+ ### 2026-3-18
8
+
9
+ 🚩 cli
10
+ - 功能更新
11
+ - 报告添加回流功能
12
+
13
+ 🚩 skills
14
+ - 多agent审查
15
+ - 启动LSP等辅助工具
16
+
17
+ ### 2026-1-31
18
+
19
+ code-review skill 补充LSP相关语句
20
+
21
+ ### 2026-1-16
22
+
23
+ 补充安全相关检查
24
+
25
+ ### 2026-1-7
26
+
27
+ 代码评审 skills 更新
28
+
29
+ 使用内置 skills
30
+
31
+ ### 2025-12-31
32
+
33
+ 基础评审能力上云