@d5render/cli 0.0.90 → 0.1.1

package/.github/instructions/review.instructions.md

@@ -0,0 +1,43 @@
+---
+applyTo: "**"
+excludeAgent: ["code-review"]
+---
+
+1. **MUST** Take the file as the review target:
+    - The focus of this review is on the content involved in the diff but the evaluation dimensions need to be based on the file content.
+    - When the diff in the discrepancy report differs from the document content, the diff is only used as a line number reference.
+    - The actual content that needs to be reviewed should be **based on the document content**.
+2. Establish context by **reading relevant files**, files that are **imported/used by** the diff files or are **structurally neighboring** them (e.g., related configuration or test files).
+3. **Ensure the relationship diagram of the diff is complete:**
+    - After establishing the context, analyze the complete context of the difference code to ensure a relatively complete code relationship diagram can be built.
+    - If the content is incomplete, supplement the context and rebuild the relationship diagram.
+4. Read the commit message as the basic understanding of the current change
+5. Determine technology the repository belongs, draw upon your understanding of that technology, provide recommendations on cutting-edge technologies and best practices:
+    - **Consult the workspace introduction** yourself.
+    - Consult cutting-edge industry documentation yourself.
+6. **Execute as many relevant commands as possible to enrich your context.**
+7. **Prioritize Analysis Focus**:
+    - For all collected code, meticulously trace the logic to uncover functional bugs and correctness issues.
+    - Pay attention to the **correctness** of the analytical logic, the **efficiency** of the code, and its **long-term maintainability**.
+    - Concentrate your deepest analysis on the application code (non-test files).
+    - Actively consider edge cases, off-by-one errors, race conditions, and improper null/error handling.
+    - **focusing on major errors**, identify potential bugs, architectural impact, security vulnerabilities, performance bottlenecks, and clarity issues.
+    - focusing on last commit when the same functionality rolling commits occur.
+8. **Maintain skepticism but verify carefully**:
+    - Gather as much context as possible for the code you suspect, raise questions only after **ensuring you have a sufficient understanding** of the business logic.
+    - If doubts persist even after establishing a complete context, lower the severity rating of the issue.
+9. **Strictly** classify the severity according to the content of **file: [severity.instructions.md](./severity.instructions.md)**.
+10. **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.

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

@@ -0,0 +1,34 @@
+---
+applyTo: "**"
+excludeAgent: ["code-review"]
+---
+
+# **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/review/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: code-review
+description: code review suggestions
+---
+
+1. read file [review.instructions.md](./review.instructions.md).
+2. find all Markdown resumes within the project and their basic understanding of the project.
+3. based on the understanding of review to supplemented.
+4. run...

package/.skills/review/version

@@ -0,0 +1 @@
+0.0.0

package/CHANGELOG.md

@@ -0,0 +1,9 @@
+## 0.1.1 (2026-01-08)
+skills:review 0.0.0
+
+评审流程转移至skills内
+增加去重功能
+
+
+## 0.1.0 (2026-01-07)
+基础评审能力

package/README.md

@@ -0,0 +1,44 @@
+# install
+
+请运行 npm run setup 进行项目初始化
+
+整体使用 ts 进行开发，会进行一轮打包，最终 CI 运行的是 bin/d5cli 文件
+
+# dev
+
+CI MCP 的入口是 [server.ts](.\copilot\server\index.ts) 会经历一轮打包进入 dist (只需要启动 server)
+
+开发的一些注意点：
+
+1. [copilot.config.js](.\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
+
+copilot\CHANGELOG.md：有功能变更的时候写这里，将会
+1. 跟随发包时写进 根CHANGELOG.md
+2. 包第一次安装后会进行通知
+
+# 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/bin/CHANGELOG.md

@@ -0,0 +1,4 @@
+skills:review 0.0.0
+
+评审流程转移至skills内
+增加去重功能