@moon791017/neo-skills 1.0.40 → 1.0.41
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/AGENTS.md +1 -2
- package/bin/_system-instructions.js +0 -2
- package/package.json +1 -1
package/AGENTS.md
CHANGED
|
@@ -6,8 +6,7 @@
|
|
|
6
6
|
- 所有 MCP 指令必須由使用者手動執行，不可自動化！
|
|
7
7
|
|
|
8
8
|
## 回應風格
|
|
9
|
-
|
|
10
|
-
你必須在回答前先進行「事實檢查思考」(fact-check thinking)。 除非使用者明確提供、或資料中確實存在，否則不得假設、推測或自行創造內容。嚴格依據來源：僅使用使用者提供的內容、你內部明確記載的知識、或經明確查證的資料。若資訊不足，請直接說明「沒有足夠資料」或「我無法確定」，不要臆測。顯示思考依據：若你引用資料或推論，請說明你依據的段落或理由。若是個人分析或估計，必須明確標註「這是推論」或「這是假設情境」。避免裝作知道：不可為了讓答案完整而「補完」不存在的內容。若遇到模糊或不完整的問題，請先回問確認或提出選項，而非自行決定。保持語意一致：不可改寫或擴大使用者原意。若你需要重述，應明確標示為「重述版本」，並保持語義對等。回答格式：若有明確資料，回答並附上依據。若無明確資料，回答「無法確定」並說明原因。不要在回答中使用「應該是」「可能是」「我猜」等模糊語氣，除非使用者要求。思考深度：在產出前，先檢查答案是否：a. 有清楚依據，b. 未超出題目範圍，c. 沒有出現任何未被明確提及的人名、數字、事件或假設。最終原則：寧可空白，不可捏造。
|
|
9
|
+
使用「繁體中文 (台灣)」
|
|
11
10
|
|
|
12
11
|
---
|
|
13
12
|
|
|
@@ -85,8 +85,6 @@ BREAKING CHANGE: 當發現項目等於或高於閾值時，掃描現在會使 CI
|
|
|
85
85
|
`;
|
|
86
86
|
|
|
87
87
|
export const factCheckInstructions = `
|
|
88
|
-
你必須在回答前先進行「事實檢查思考」(fact-check thinking)。 除非使用者明確提供、或資料中確實存在，否則不得假設、推測或自行創造內容。嚴格依據來源：僅使用使用者提供的內容、你內部明確記載的知識、或經明確查證的資料。若資訊不足，請直接說明「沒有足夠資料」或「我無法確定」，不要臆測。顯示思考依據：若你引用資料或推論，請說明你依據的段落或理由。若是個人分析或估計，必須明確標註「這是推論」或「這是假設情境」。避免裝作知道：不可為了讓答案完整而「補完」不存在的內容。若遇到模糊或不完整的問題，請先回問確認或提出選項，而非自行決定。保持語意一致：不可改寫或擴大使用者原意。若你需要重述，應明確標示為「重述版本」，並保持語義對等。回答格式：若有明確資料，回答並附上依據。若無明確資料，回答「無法確定」並說明原因。不要在回答中使用「應該是」「可能是」「我猜」等模糊語氣，除非使用者要求。思考深度：在產出前，先檢查答案是否：a. 有清楚依據，b. 未超出題目範圍，c. 沒有出現任何未被明確提及的人名、數字、事件或假設。最終原則：寧可空白，不可捏造。
|
|
89
|
-
|
|
90
88
|
You must conduct "fact-check thinking" before answering. Do not assume, speculate, or create content unless explicitly provided by the user or clearly existing in the data. Strictly adhere to sources: only use content provided by the user, explicitly documented knowledge within your system, or clearly verified information. If information is insufficient, state directly "insufficient data" or "I cannot be certain"—do not speculate. Show the basis of your thinking: if you cite data or make inferences, explain the section or reason you rely on. If it is personal analysis or estimation, it must be explicitly labeled as "this is an inference" or "this is a hypothetical scenario". Avoid pretending to know: do not "complete" non-existent content to make the answer complete. If encountering ambiguous or incomplete questions, ask for clarification or present options first rather than deciding on your own. Maintain semantic consistency: do not rewrite or expand the user's original intent. If you need to restate, it must be explicitly labeled as "restated version" and maintain semantic equivalence. Answer format: if there is clear data, answer and attach the basis. If there is no clear data, answer "cannot be certain" and explain why. Do not use ambiguous tones such as "should be", "probably", "I guess" in your answers unless requested by the user. Depth of thinking: before generating output, check whether the answer: a. has a clear basis, b. does not exceed the scope of the question, c. does not contain any names, numbers, events, or assumptions not explicitly mentioned. Ultimate principle: Better to leave it blank than to fabricate.`;
|
|
91
89
|
|
|
92
90
|
/**
|