@d5render/cli 0.1.56 → 0.1.58

package/package.json

@@ -1,37 +1,40 @@
 {
   "name": "@d5render/cli",
-  "type": "module",
+  "version": "0.1.58",
   "license": "MIT",
   "author": "jasirou",
-  "main": "./bin/d5cli",
-  "version": "0.1.56",
-  "devDependencies": {
-    "@modelcontextprotocol/sdk": "^1.25.1",
-    "@types/node": "^25.0.3",
-    "@types/vscode": "^1.107.0",
-    "@vscode/vsce": "^3.7.1",
-    "json5": "^2.2.3",
-    "oxfmt": "^0.21.0",
-    "oxlint": "^1.37.0",
-    "rolldown": "1.0.0-beta.58",
-    "vitest": "^4.0.17",
-    "zod": "^4.3.5"
+  "bin": {
+    "d5cli": "bin/d5cli"
   },
   "files": [
-    ".github/instructions/code-review.instructions.md",
-    ".github/instructions/severity.instructions.md",
-    ".skills/devops",
+    "CHANGELOG.md",
     ".skills/code-review",
-    "bin/copilot.js",
+    ".skills/devops",
+    "bin/mcpServer.js",
     "bin/d5cli",
-    "CHANGELOG.md"
+    ".github/instructions/severity.instructions.md"
   ],
-  "bin": {
-    "d5cli": "bin/d5cli"
+  "type": "module",
+  "main": "./bin/d5cli",
+  "dependencies": {
+    "vscode-languageserver-protocol": "^3.17.5"
+  },
+  "devDependencies": {
+    "@modelcontextprotocol/sdk": "^1.25.3",
+    "@types/node": "^25.1.0",
+    "@types/vscode": "^1.108.1",
+    "@vscode/vsce": "^3.7.1",
+    "json5": "^2.2.3",
+    "oxfmt": "^0.21.0",
+    "oxlint": "^1.42.0",
+    "rolldown": "1.0.0-rc.2",
+    "vitest": "^4.0.18",
+    "zod": "^4.3.6"
   },
   "scripts": {
-    "build:copilot": "node ./setup.js build",
+    "build": "node ./setup.js build",
     "release": "node ./setup.js publish",
-    "setup": "node ./setup.js"
+    "setup": "node ./setup.js",
+    "test": "node ./setup.js build:development"
   }
 }

package/.github/instructions/code-review.instructions.md

@@ -1,43 +0,0 @@
----
-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/CHANGELOG.md

@@ -1,10 +0,0 @@
-### 2026-1-16
-补充安全相关检查
-
-### 2026-1-7
-代码评审 skills 更新
-
-使用内置 skills
-
-### 2025-12-31
-基础评审能力上云