@moon791017/neo-skills 1.1.31 → 1.1.33

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.
Files changed (17) hide show
  1. package/README.md +0 -2
  2. package/package.json +1 -1
  3. package/skills/neo-harness-project/SKILL.md +75 -34
  4. package/skills/neo-harness-project/assets/templates/AGENTS.md.template +10 -10
  5. package/skills/neo-harness-project/assets/templates/PLANS.md.template +3 -3
  6. package/skills/neo-harness-project/evals/eval_queries.json +3 -2
  7. package/skills/neo-harness-project/evals/evals.json +21 -6
  8. package/skills/neo-harness-project/references/artifact-selection.md +32 -16
  9. package/skills/neo-harness-project/references/generation-validation.md +51 -31
  10. package/skills/neo-iso-27001/SKILL.md +0 -92
  11. package/skills/neo-iso-27001/evals/eval_queries.json +0 -86
  12. package/skills/neo-iso-27001/evals/evals.json +0 -38
  13. package/skills/neo-iso-27001/references/sources-and-scope.md +0 -23
  14. package/skills/neo-iso-27701/SKILL.md +0 -99
  15. package/skills/neo-iso-27701/evals/eval_queries.json +0 -82
  16. package/skills/neo-iso-27701/evals/evals.json +0 -38
  17. package/skills/neo-iso-27701/references/sources-and-scope.md +0 -24
package/README.md CHANGED
@@ -39,8 +39,6 @@
39
39
  | :--- | :--- | :--- |
40
40
  | Agent 治理 | `neo-harness` | 自動掃描專案環境，產生或更新專案專用的 AGENTS.md，並整合 Harness 評估、Workflow 與編排架構。 |
41
41
  | Agent 治理 | `neo-harness-project` | 盤點目前專案並依證據建立完整 Harness 知識、計畫、驗證與工程治理資產。 |
42
- | 資訊安全 | `neo-iso-27001` | 依 ISO/IEC 27001 進行 ISMS 範圍、風險、證據、差距分析、稽核準備與改善計畫。 |
43
- | 隱私管理 | `neo-iso-27701` | 依 ISO/IEC 27701 進行 PIMS、PII 角色、處理活動、隱私風險、證據與稽核準備。 |
44
42
  | DevOps | `neo-azure-pipelines` | 建立、審查、除錯或現代化 Azure Pipelines YAML，尤其是 .NET build、Azure App Service 或 IIS 部署。 |
45
43
  | 需求釐清 | `neo-clarification` | 將模糊、情緒化、片段式或截圖式需求整理成規格、驗收條件和待釐清問題。 |
46
44
  | Code Review | `neo-code-review` | 檢查程式碼、PR/diff、bug 風險、安全性、效能與可維護性。 |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@moon791017/neo-skills",
3
- "version": "1.1.31",
3
+ "version": "1.1.33",
4
4
  "type": "module",
5
5
  "description": "Neo Skills: A Universal AI Agent Skills Extension",
6
6
  "homepage": "https://neo-blog-iota.vercel.app/",
package/skills/neo-harness-project/SKILL.md CHANGED
@@ -2,7 +2,7 @@
2
2
  name: neo-harness-project
3
3
  description: >
4
4
  當使用者要求盤點目前專案並建立、重建或補強完整 Harness 工程環境時使用此技能，
5
- 包含專案知識地圖、架構文件、持久化計畫、驗證入口及依證據選用的工程治理資產；
5
+ 包含專案知識地圖、架構文件、持久化計畫、驗證入口、.neo_harness 集中式資產及依證據選用的工程治理資產；
6
6
  不用於只建立單一 AGENTS.md 或一般功能開發。
7
7
  license: MIT
8
8
  metadata:
@@ -12,76 +12,117 @@ metadata:
12
12
 
13
13
  # Project Harness Builder
14
14
 
15
- 根據目前專案的實際設計建立可閱讀、可驗證、可恢復的工程環境。不要把固定技術棧或理想架構套進專案，也不要建立沒有真實檢查能力的空殼。
15
+ 依專案現況建立可閱讀、可驗證、可恢復的工程環境。不得套用固定技術棧或理想架構，也不得建立沒有真實檢查能力的空殼。
16
16
 
17
17
  ## 邊界
18
18
 
19
- - 本技能處理整個專案的 Harness 盤點與跨檔案建置。
20
- - 若需求只處理 `AGENTS.md`，改用 `neo-harness`。
21
- - 不新增使用者未要求的第三方依賴、服務、部署或外部連線。
19
+ - 本技能盤點並建置整個專案的 Harness。
20
+ - 需求只涉及 `AGENTS.md` 時，改用 `neo-harness`。
21
+ - 目標專案的 Harness 資產必須集中在根目錄 `.neo_harness/`；唯一例外是必須留在根目錄的 `AGENTS.md`。
22
+ - 技能套件自身的 `references/`、`assets/` 與 `evals/` 是技能實作資源，不屬於目標專案的 Harness 產出位置。
23
+ - 不得新增使用者未要求的第三方依賴、服務、部署或外部連線。
22
24
  - 技能內容與產出必須保持供應商中立，不得提及任何特定模型供應商、產品、套件族、官方網址或供應商專屬中繼資料。
23
- - 若必要專案事實無法在遵守中立要求下準確記錄，停止相關產出並回報衝突；不得刪減或改寫事實來假裝合規。
25
+ - 若無法在遵守中立要求的前提下準確記錄必要專案事實，停止相關產出並回報衝突；不得刪減或改寫事實以規避衝突。
26
+
27
+ ## Harness 資產位置規範
28
+
29
+ 下列路徑均以目標專案根目錄為基準：
30
+
31
+ | 資產 | 正式路徑 |
32
+ | :--- | :--- |
33
+ | 專案入口與工作規則 | `AGENTS.md` |
34
+ | 架構文件 | `.neo_harness/ARCHITECTURE.md` |
35
+ | 計畫規範 | `.neo_harness/PLANS.md` |
36
+ | 專案命令清單 | `.neo_harness/docs/scripts.md` |
37
+ | 進行中的執行計畫 | `.neo_harness/docs/exec-plans/active/` |
38
+ | 已完成的執行計畫 | `.neo_harness/docs/exec-plans/completed/` |
39
+
40
+ - 不得建立 `.neo_harness/AGENTS.md`；根目錄 `AGENTS.md` 是唯一的 Agent 入口。
41
+ - 所有其他 Harness 核心或條件式資產都必須放在 `.neo_harness/` 內，並由根目錄 `AGENTS.md` 或相關文件連結。
42
+ - `.neo_harness/` 是正式且應納入版本控制的專案資產；若被 `.gitignore` 或其他忽略規則排除，先標記為 `blocked`，不得自行修改忽略規則。
43
+ - 不得把非 Harness 文件、既有專案文件或技能套件自身的資源移入 `.neo_harness/`。
44
+
45
+ ### 既有舊路徑的搬遷
46
+
47
+ 若盤點發現下列舊路徑存在，必須先提供搬遷預覽並取得使用者對精確清單的明確確認：
48
+
49
+ | 舊路徑 | 正式路徑 |
50
+ | :--- | :--- |
51
+ | `ARCHITECTURE.md` | `.neo_harness/ARCHITECTURE.md` |
52
+ | `PLANS.md` | `.neo_harness/PLANS.md` |
53
+ | `docs/scripts.md` | `.neo_harness/docs/scripts.md` |
54
+ | `docs/exec-plans/` | `.neo_harness/docs/exec-plans/` |
55
+
56
+ - 搬遷預覽必須列出來源、目的地、受影響的連結或索引、驗證命令與復原方式。
57
+ - 目的地已存在、來源與目的地內容衝突，或目的地受忽略規則排除時，動作標記為 `blocked`；不得覆寫、刪除、建立重複副本或建立符號連結。
58
+ - 未經確認不得搬遷、批次改名或刪除舊路徑；確認後才可更新受影響的 Harness 連結，並保留可從版本控制或已報告快照復原的依據。
59
+ - 不屬於上述清單的舊文件不自動搬遷，除非使用者另行確認。
24
60
 
25
61
  ## 必要流程
26
62
 
27
63
  ### 1. 盤點，不寫入
28
64
 
29
- 先讀取專案規範、版本控制狀態、根目錄、套件與建置設定、測試、CI、文件、主要入口及現有 Harness 資產，包含 `docs/scripts.md` 與 `docs/exec-plans/` 的既有檔案。所有命令都必須從可驗證的設定或文件取得，不可憑技術棧猜測。
65
+ 先讀取專案規範、版本控制狀態、根目錄、套件與建置設定、測試、CI、文件、主要入口及現有 Harness 資產，包括 `.neo_harness/` 正式路徑與上述舊路徑的既有檔案。命令必須來自可驗證的設定或文件，不得依技術棧猜測。
30
66
 
31
- 盤點時必須閱讀 [專案評估模型](references/project-assessment.md)，以來源證據判定成熟度與缺口。未知資訊標成「未知」，不要補成理想狀態。
67
+ 盤點時必須閱讀 [專案評估模型](references/project-assessment.md)，依來源證據判定成熟度與缺口。未知資訊標為「未知」，不得補成理想狀態。
32
68
 
33
69
  ### 2. 選擇產出
34
70
 
35
- 閱讀 [資產選擇矩陣](references/artifact-selection.md)，將每個候選路徑分類為：
71
+ 閱讀 [資產選擇矩陣](references/artifact-selection.md)，將候選路徑分類為：
36
72
 
37
73
  - `create`：路徑不存在，且已有足夠證據建立。
38
74
  - `update`：保留有效內容並補齊缺口。
39
75
  - `rebuild`：現有內容與已確認目標衝突，需重建。
76
+ - `migrate`：舊 Harness 路徑存在，需依確認結果搬到 `.neo_harness/` 並更新受影響連結。
40
77
  - `skip`：沒有需求或證據，不建立。
41
78
  - `blocked`：缺少關鍵事實或違反中立要求。
42
79
 
43
- 核心知識、命令清單與計畫資產預設納入；CI、架構檢查、執行環境、可觀測性與持續清理只在矩陣條件成立時納入。
80
+ 預設納入核心知識、命令清單與計畫資產；只有矩陣條件成立時才納入 CI、架構檢查、執行環境、可觀測性與持續清理。
44
81
 
45
82
  ### 3. 提供寫入預覽
46
83
 
47
- 修改前先向使用者提供：
84
+ 寫入前先提供：
48
85
 
49
86
  1. 專案證據與成熟度。
50
- 2. 精確目標路徑及 `create`、`update`、`rebuild`、`skip` 或 `blocked` 動作。
87
+ 2. 精確目標路徑及 `create`、`update`、`rebuild`、`migrate`、`skip` 或 `blocked` 動作。
51
88
  3. 每項動作的事實依據與內容摘要。
52
89
  4. 既有檔案衝突、驗證命令與失敗復原方式。
53
90
 
54
- 等待使用者明確確認全部或指定路徑。初始的「建立 Harness」要求不等於對未知重建清單的確認；預覽前不得寫入。
91
+ 取得使用者對全部或指定路徑的明確確認。使用者初始提出「建立 Harness」不代表已確認未知的重建或搬遷清單；提供預覽前不得寫入。
55
92
 
56
- ### 4. 依確認內容產生
93
+ ### 4. 依確認結果產生
57
94
 
58
- 寫入前閱讀 [產生、驗證與復原](references/generation-validation.md)。使用 [核心模板](assets/templates/) 作為結構起點，依專案事實改寫並移除所有模板標記；不得直接複製未完成模板。
95
+ 寫入前閱讀 [產生、驗證與復原](references/generation-validation.md)，以 [核心模板](assets/templates/) 為結構起點；依專案事實改寫並移除所有模板標記，不得直接複製未完成模板。
59
96
 
60
- - 使用與目前專案一致的命名、工具與文件語言；無法判定語言時採用使用者語言。
61
- - 只修改預覽中已確認的精確路徑。
62
- - `rebuild` 必須保留仍正確的專案事實，並確保可從版本控制或已報告的暫存快照復原。
63
- - 空的執行計畫目錄使用最小追蹤檔保存，不填入虛構計畫。
64
- - 新建立的執行計畫檔名必須使用 `YYYYMMDDHHmmss_<原計畫檔名>.md`；時間戳取建立當下執行環境的本地時間，從 `active` 移至 `completed` 時保留原時間戳。
97
+ - 採用目前專案的命名、工具與文件語言；無法判定時採用使用者語言。
98
+ - 只修改預覽列出的已確認路徑；搬遷時來源、目的地與連結更新都必須列在確認清單中。
99
+ - `rebuild` 必須保留仍正確的專案事實，並可從版本控制或已報告的暫存快照復原。
100
+ - `migrate` 只能在確認後執行；先完成內容與連結的核對，再移除來源路徑，且不得覆寫既有目的地。
101
+ - `.neo_harness/docs/exec-plans/active/` 與 `completed/` 都必須包含 `.GITKEEP`，不新增 `README.md`；空目錄只以 `.GITKEEP` 追蹤，不填入虛構計畫。
102
+ - 新建立的執行計畫檔名必須使用 `YYYYMMDDHHmmss_<原計畫檔名>.md`；時間戳取建立當下執行環境的本地時間，從 `active` 移至 `completed` 時保留原時間戳。既有計畫搬遷至 `.neo_harness/` 時保留原檔名與時間戳。
65
103
  - 既有未加時間戳的計畫不批次改名；更新既有計畫時沿用原檔名。
66
- - `docs/scripts.md` 必須是只含 `指令`、`用途` 兩欄的 Markdown table，收錄所有可由專案設定或文件驗證的命令；沒有可驗證命令時只保留空表頭。
104
+ - `.neo_harness/docs/scripts.md` 必須只含 `指令`、`用途` 兩欄的 Markdown table，收錄專案設定或文件可驗證的所有命令；沒有可驗證命令時只保留空表頭。
67
105
  - 沒有可驗證的統一驗證命令時，從 `AGENTS.md` 移除統一驗證命令與相應完成條件，不保留模板標記。
68
- - 規則可被機器可靠判斷時，優先使用既有工具形成可執行檢查；否則保留為明確文件規則。
106
+ - 規則可由機器可靠判斷時，優先使用既有工具建立可執行檢查；否則明確記錄為文件規則。
69
107
 
70
108
  ### 5. 閉環驗證
71
109
 
72
- 1. 確認所有建立或重建的檔案都在已確認清單中。
73
- 2. 檢查文件連結、命令、路徑、架構描述及模板標記。
74
- 3. 驗證新計畫檔名的時間戳格式，以及 `docs/scripts.md` 的兩欄 Markdown table 格式。
75
- 4. 執行專案原有快速檢查與新增的統一驗證入口。
76
- 5. 失敗時閱讀完整錯誤、修正根因並重跑。
77
- 6. 回報實際產出、未解缺口、命令與結果；沒有通過證據不得宣告完成。
110
+ 1. 確認建立、更新、重建或搬遷的檔案均在確認清單中。
111
+ 2. 若有搬遷，確認來源已依核准方案處理、目的地內容完整，且所有受影響連結均指向 `.neo_harness/`。
112
+ 3. 檢查文件連結、命令、路徑、架構描述及模板標記。
113
+ 4. 驗證新計畫檔名的時間戳格式，以及 `.neo_harness/docs/scripts.md` 的兩欄 Markdown table 格式。
114
+ 5. 執行專案原有快速檢查及新增的統一驗證入口。
115
+ 6. 失敗時讀取完整錯誤，修正根因後重跑。
116
+ 7. 回報產出、未解缺口、命令與結果；沒有通過證據不得宣告完成。
78
117
 
79
118
  ## 完成條件
80
119
 
81
- - 核心資產可由新工作階段只靠目前專案找到必要知識、限制與驗證方法。
82
- - `docs/scripts.md` 提供完整且可追溯的專案命令清單。
83
- - 新建立的計畫檔案可依時間戳前綴排序，且計畫生命週期移動不改變前綴。
84
- - 所有命令均可追溯到專案設定且可實際執行。
120
+ - 新工作階段只靠目前專案即可找到核心資產所需的知識、限制與驗證方法。
121
+ - `.neo_harness/docs/scripts.md` 列出完整且可追溯的專案命令。
122
+ - 新建立的計畫檔案可依時間戳前綴排序，且在生命週期中移動時保留前綴。
123
+ - 根目錄 `AGENTS.md` 是唯一入口，其餘 Harness 資產均位於 `.neo_harness/` 且連結一致。
124
+ - 所有命令均可追溯至專案設定並可執行。
85
125
  - 沒有假成功命令、未完成模板、虛構架構或未經確認的重建。
86
- - 條件式資產都有專案證據，未選用項目都有可說明的原因。
87
- - 產出保持供應商中立，且驗證結果與剩餘缺口已交付。
126
+ - 沒有未經確認的搬遷、批次改名、覆寫或刪除；搬遷衝突會明確標記為 `blocked`。
127
+ - 條件式資產都有專案證據，未選用項目都有明確原因。
128
+ - 產出保持供應商中立，並交付驗證結果與剩餘缺口。
package/skills/neo-harness-project/assets/templates/AGENTS.md.template CHANGED
@@ -4,23 +4,23 @@
4
4
 
5
5
  ## 開始工作
6
6
 
7
- 1. 閱讀 `ARCHITECTURE.md`。
8
- 2. 閱讀與任務相關的模組文件及既有實作。
9
- 3. 複雜或跨工作階段的任務依 `PLANS.md` 建立或更新執行計畫。
7
+ 1. 閱讀 `.neo_harness/ARCHITECTURE.md`。
8
+ 2. 閱讀任務相關的模組文件與既有實作。
9
+ 3. 複雜或跨工作階段的任務，依 `.neo_harness/PLANS.md` 建立或更新執行計畫。
10
10
  4. 修改前確認目前基準與驗收條件。
11
11
 
12
12
  ## 專案知識
13
13
 
14
14
  | 主題 | 來源 |
15
15
  | :--- | :--- |
16
- | 架構 | `ARCHITECTURE.md` |
17
- | 執行計畫 | `docs/exec-plans/` |
18
- | 專案指令 | `docs/scripts.md` |
16
+ | 架構 | `.neo_harness/ARCHITECTURE.md` |
17
+ | 執行計畫 | `.neo_harness/docs/exec-plans/` |
18
+ | 專案指令 | `.neo_harness/docs/scripts.md` |
19
19
  | {{KNOWLEDGE_TOPIC}} | `{{KNOWLEDGE_PATH}}` |
20
20
 
21
21
  ## 命令
22
22
 
23
- 完整命令清單：`docs/scripts.md`
23
+ 完整命令清單：`.neo_harness/docs/scripts.md`
24
24
 
25
25
  統一驗證命令：`{{CANONICAL_VERIFY_COMMAND}}`
26
26
 
@@ -28,9 +28,9 @@
28
28
 
29
29
  1. 以程式碼、設定或測試建立基準。
30
30
  2. 以最小變更完成需求。
31
- 3. 執行相關快速檢查並依完整錯誤修正根因。
31
+ 3. 執行相關快速檢查，依完整錯誤修正根因。
32
32
  4. 執行統一驗證與自我審查。
33
- 5. 只在驗證通過後交付實際證據。
33
+ 5. 驗證通過後交付實際證據。
34
34
 
35
35
  ## 專案限制
36
36
 
@@ -41,4 +41,4 @@
41
41
  - 已完成要求的可觀察行為。
42
42
  - 相關測試或其他決定性證據存在。
43
43
  - `{{CANONICAL_VERIFY_COMMAND}}` 成功。
44
- - 架構、文件與執行計畫已依需要同步。
44
+ - 架構、文件與執行計畫依需要同步。
package/skills/neo-harness-project/assets/templates/PLANS.md.template CHANGED
@@ -1,14 +1,14 @@
1
1
  # Execution Plans
2
2
 
3
- 下列工作必須使用持久執行計畫：
3
+ 下列工作必須建立持久執行計畫：
4
4
 
5
5
  - {{PLAN_THRESHOLD}}
6
6
 
7
- 進行中計畫放在 `docs/exec-plans/active/`；完成且已記錄結果的計畫移至 `docs/exec-plans/completed/`。
7
+ 進行中的計畫放在 `.neo_harness/docs/exec-plans/active/`；完成並記錄結果的計畫移至 `.neo_harness/docs/exec-plans/completed/`。
8
8
 
9
9
  新建立的執行計畫檔名使用 `YYYYMMDDHHmmss_<原計畫檔名>.md`。時間戳取建立當下執行環境的本地時間，計畫移至 `completed` 時沿用原時間戳。既有未加時間戳的計畫不批次改名。
10
10
 
11
- 每份計畫必須自包含。讀者只需要目前工作樹與計畫本身，不應依賴先前對話或未連結的外部資訊。
11
+ 每份計畫必須自包含；讀者只需目前工作樹與計畫本身，不得依賴先前對話或未連結的外部資訊。
12
12
 
13
13
  ## 必要內容
14
14
 
package/skills/neo-harness-project/evals/eval_queries.json CHANGED
@@ -2,10 +2,11 @@
2
2
  "should_trigger": [
3
3
  "請盤點目前 repository，建立完整且可自行驗證的 Harness 工程環境",
4
4
  "幫這個專案補齊架構文件、長任務計畫、統一驗證入口與必要目錄",
5
- "調整 Harness 的計畫檔名排序規則，並整理專案命令到 docs/scripts.md",
5
+ "調整 Harness 的計畫檔名排序規則，並整理專案命令到 .neo_harness/docs/scripts.md",
6
6
  "Assess this repository and build an evidence-based project harness with persistent plans and validation gates",
7
7
  "重建目前專案的 Harness 文件，但先列出會覆寫的檔案給我確認",
8
- "檢查現有工程環境的成熟度，並依實際工具補齊缺少的治理資產"
8
+ "檢查現有工程環境的成熟度，並依實際工具補齊缺少的治理資產",
9
+ "將 Harness 相關產出集中到 .neo_harness，但保留根目錄 AGENTS.md，並處理既有舊路徑搬遷"
9
10
  ],
10
11
  "should_not_trigger": [
11
12
  "只幫我產生一份 AGENTS.md",
package/skills/neo-harness-project/evals/evals.json CHANGED
@@ -4,15 +4,16 @@
4
4
  {
5
5
  "id": 1,
6
6
  "prompt": "請針對目前的 Node.js 專案建立完整 Harness。package.json 只有 test 與 build scripts，專案目前沒有任何治理文件。",
7
- "expected_output": "先提供唯讀盤點與精確寫入預覽，不立即建立檔案。核心資產應納入，包含以時間戳命名規則管理的執行計畫與兩欄命令表；驗證入口只能組合實際存在的 test 與 build，沒有證據的 CI、可觀測性或架構檢查應略過。",
7
+ "expected_output": "先提供唯讀盤點與精確寫入預覽，不立即建立檔案。核心資產應納入，包含根目錄 AGENTS.md、.neo_harness/ARCHITECTURE.md、.neo_harness/PLANS.md、.neo_harness/docs/scripts.md 與 .neo_harness/docs/exec-plans/；執行計畫使用時間戳命名規則與兩欄命令表；驗證入口只能組合實際存在的 test 與 build，沒有證據的 CI、可觀測性或架構檢查應略過。",
8
8
  "assertions": [
9
9
  "確認前沒有修改任何檔案",
10
10
  "預覽列出每個精確路徑、動作、證據、驗證與復原方式",
11
11
  "只採用 package.json 實際存在的 test 與 build 命令",
12
12
  "不虛構 lint、typecheck、CI、可觀測性或架構工具",
13
- "核心資產包含知識地圖、目前架構、計畫規範、docs/scripts.md 與執行計畫目錄",
13
+ "根目錄只有 AGENTS.md 作為入口，其餘核心資產位於 .neo_harness/",
14
+ ".neo_harness/docs/scripts.md 僅使用 指令 與 用途 兩欄並只收錄可驗證命令",
14
15
  "新建立的執行計畫使用 YYYYMMDDHHmmss_ 前綴，移至 completed 時保留前綴",
15
- "docs/scripts.md 僅使用 指令 與 用途 兩欄並只收錄可驗證命令"
16
+ "沒有證據的條件式資產應略過"
16
17
  ]
17
18
  },
18
19
  {
@@ -23,6 +24,7 @@
23
24
  "不把初始重建要求當成未知清單的覆寫確認",
24
25
  "預覽區分仍正確的專案事實與需要替換的內容",
25
26
  "確認重建前檢查目標是否由版本控制追蹤",
27
+ "正式 Harness 產出位於 .neo_harness/，AGENTS.md 留在根目錄",
26
28
  "不修改預覽以外的路徑"
27
29
  ]
28
30
  },
@@ -62,13 +64,26 @@
62
64
  {
63
65
  "id": 6,
64
66
  "prompt": "專案已有未加時間戳的 active 計畫與數個散落在設定及文件中的實際命令。請補齊 Harness 導航與命令文件，但不要未經確認批次改名。",
65
- "expected_output": "保留既有計畫檔名與連結；新計畫使用本地時間的 14 位數字前綴，建立只含指令與用途兩欄的 docs/scripts.md，並將所有有來源證據的命令集中整理。",
67
+ "expected_output": "保留既有計畫檔名與連結；新計畫使用本地時間的 14 位數字前綴，建立只含指令與用途兩欄的 .neo_harness/docs/scripts.md，並將所有有來源證據的命令集中整理。",
66
68
  "assertions": [
67
69
  "既有未加前綴的計畫不直接改名",
68
70
  "新計畫檔名符合 YYYYMMDDHHmmss_<原計畫檔名>.md",
69
71
  "計畫移動至 completed 時保留原時間戳",
70
- "docs/scripts.md 是只含 指令 與 用途 兩欄的 Markdown table",
71
- "未經專案設定或文件驗證的命令不加入 scripts.md"
72
+ ".neo_harness/docs/scripts.md 是只含 指令 與 用途 兩欄的 Markdown table",
73
+ "未經專案設定或文件驗證的命令不加入 .neo_harness/docs/scripts.md"
74
+ ]
75
+ },
76
+ {
77
+ "id": 7,
78
+ "prompt": "盤點發現根目錄已有 ARCHITECTURE.md、PLANS.md、docs/scripts.md 與 docs/exec-plans/active/plan.md，但沒有 .neo_harness。請集中 Harness 資產，且不要在確認前直接搬移。",
79
+ "expected_output": "先提供來源到 .neo_harness/ 的 migrate 預覽，列出連結更新、驗證與復原方式；確認前不搬遷、不刪除、不批次改名。若目的地已存在、內容衝突或被忽略規則排除，相關動作標為 blocked；根目錄 AGENTS.md 保留原位。",
80
+ "assertions": [
81
+ "逐項列出 ARCHITECTURE.md、PLANS.md、docs/scripts.md 與 docs/exec-plans/ 的來源及正式目的地",
82
+ "搬遷前要求使用者確認精確清單",
83
+ "既有 active 計畫保留原檔名與時間戳規則",
84
+ "目的地衝突或被忽略時標記為 blocked",
85
+ "不建立 .neo_harness/AGENTS.md",
86
+ "不建立重複副本或符號連結"
72
87
  ]
73
88
  }
74
89
  ]
package/skills/neo-harness-project/references/artifact-selection.md CHANGED
@@ -1,41 +1,57 @@
1
1
  # 資產選擇矩陣
2
2
 
3
- 以專案證據決定產出。核心資產提供導航與持久狀態；條件式資產只有在能改善真實回饋迴路時才建立。
3
+ 依專案證據決定產出。核心資產提供導航與持久狀態；只有能改善真實回饋迴路時才建立條件式資產。
4
4
 
5
5
  ## 核心資產
6
6
 
7
7
  | 路徑 | 目的 | 建立規則 |
8
8
  | :--- | :--- | :--- |
9
9
  | `AGENTS.md` | 短小的專案知識地圖、精確命令、工作規則與完成條件 | 一律評估；存在時依確認結果更新或重建 |
10
- | `docs/scripts.md` | 保存專案所有已驗證命令及用途 | 一律評估；不存在時建立，存在時保留有效內容並補齊已驗證命令 |
11
- | `ARCHITECTURE.md` | 記錄目前元件、責任、依賴方向、邊界與可執行約束 | 一律評估；未知架構明確標示，不畫理想架構 |
12
- | `PLANS.md` | 定義何時使用持久計畫、必要章節及生命週期 | 一律評估；沿用專案既有計畫命名時同步調整連結 |
13
- | `docs/exec-plans/active/` | 保存進行中且可由新工作階段接續的計畫 | 沒有現行計畫時只建立最小追蹤檔 |
14
- | `docs/exec-plans/completed/` | 保存完成結果、決策與驗證證據 | 沒有完成計畫時只建立最小追蹤檔 |
10
+ | `.neo_harness/docs/scripts.md` | 保存專案所有已驗證命令及用途 | 一律評估；不存在時建立，存在時保留有效內容並補齊已驗證命令 |
11
+ | `.neo_harness/ARCHITECTURE.md` | 記錄目前元件、責任、依賴方向、邊界與可執行約束 | 一律評估；未知架構明確標示，不畫理想架構 |
12
+ | `.neo_harness/PLANS.md` | 定義何時使用持久計畫、必要章節及生命週期 | 一律評估；沿用專案既有計畫命名時同步調整連結 |
13
+ | `.neo_harness/docs/exec-plans/active/` | 保存進行中且可由新工作階段接續的計畫 | 必須包含 `.GITKEEP`；沒有現行計畫時以此檔案追蹤目錄，不新增 `README.md` |
14
+ | `.neo_harness/docs/exec-plans/completed/` | 保存完成結果、決策與驗證證據 | 必須包含 `.GITKEEP`；沒有完成計畫時以此檔案追蹤目錄，不新增 `README.md` |
15
15
 
16
- 若專案已有等價且被廣泛引用的路徑，優先更新知識地圖指向既有來源，不平行建立第二套真相來源。
16
+ 根目錄 `AGENTS.md` 是唯一入口；不得建立 `.neo_harness/AGENTS.md`。專案已有等價且廣泛引用的舊路徑時，先列入搬遷預覽，不另建第二套真相來源。
17
+
18
+ ## 舊路徑搬遷
19
+
20
+ 下列舊路徑只可在預覽並取得使用者明確確認後搬遷：
21
+
22
+ | 舊路徑 | 正式路徑 |
23
+ | :--- | :--- |
24
+ | `ARCHITECTURE.md` | `.neo_harness/ARCHITECTURE.md` |
25
+ | `PLANS.md` | `.neo_harness/PLANS.md` |
26
+ | `docs/scripts.md` | `.neo_harness/docs/scripts.md` |
27
+ | `docs/exec-plans/` | `.neo_harness/docs/exec-plans/` |
28
+
29
+ - 來源存在且目的地不存在時，動作可標為 `migrate`；來源與目的地都存在、內容衝突，或 `.neo_harness/` 被忽略規則排除時，標為 `blocked`。
30
+ - `migrate` 預覽必須同時列出來源、目的地、連結更新、驗證與復原方式；未確認前不得搬遷、刪除或批次改名。
31
+ - 搬遷既有計畫時保留原檔名與時間戳；不因搬遷而將未加時間戳的既有計畫批次改名。
32
+ - 不屬於上述清單的舊文件不自動搬遷，除非使用者另行確認。
17
33
 
18
34
  ## 計畫檔名
19
35
 
20
- - 新建立的執行計畫放在 `docs/exec-plans/active/` 或 `docs/exec-plans/completed/` 時，檔名使用 `YYYYMMDDHHmmss_<原計畫檔名>.md`。
21
- - `YYYYMMDDHHmmss` 是建立當下執行環境本地時間的 14 位數字；移動計畫時保留原時間戳。
36
+ - 新建立的執行計畫若放在 `.neo_harness/docs/exec-plans/active/` 或 `.neo_harness/docs/exec-plans/completed/`，檔名使用 `YYYYMMDDHHmmss_<原計畫檔名>.md`。
37
+ - `YYYYMMDDHHmmss` 是建立當下執行環境本地時間的 14 位數字；計畫移動時保留原時間戳。
22
38
  - 不符合格式的既有計畫保留原檔名，不執行未經確認的批次改名。
23
39
 
24
- ## `scripts.md` 產出規則
40
+ ## `.neo_harness/docs/scripts.md` 產出規則
25
41
 
26
- - `docs/scripts.md` 只能包含 Markdown table，欄位固定為 `指令` 與 `用途`；既有檔案格式不符時標成 `rebuild`，保留仍有證據的命令資料並移除無法驗證的列。
42
+ - `.neo_harness/docs/scripts.md` 只能包含 Markdown table，欄位固定為 `指令` 與 `用途`；既有檔案格式不符時標為 `rebuild`，保留仍有證據的命令資料並移除無法驗證的列。
27
43
  - 命令必須逐一追溯到套件設定、工作執行器、CI 或版本控制內文件；不得依技術棧推測。
28
- - 沒有可驗證命令時仍建立只有表頭與分隔列的空表格。
44
+ - 沒有可驗證命令時仍建立只含表頭與分隔列的空表格。
29
45
 
30
46
  ## 統一驗證入口
31
47
 
32
- 只有至少一個真實且可重複的檢查存在時才建立或補強統一入口。選擇順序：
48
+ 至少有一個真實且可重複的檢查時，才建立或補強統一入口。選擇順序如下：
33
49
 
34
50
  1. 已存在且文件化的統一驗證命令。
35
51
  2. 既有工作執行器中的原生 `verify` 任務。
36
52
  3. 使用專案既有執行環境建立無額外依賴的薄包裝，依序呼叫已驗證命令。
37
53
 
38
- 入口必須保留子命令的失敗狀態。若沒有可信檢查，將「建立第一個決定性檢查」記入 active plan，不得用輸出成功訊息或空命令代替。
54
+ 入口必須保留子命令的失敗狀態。沒有可信檢查時，將「建立第一個決定性檢查」記入 active plan；不得用輸出成功訊息或空命令代替。
39
55
 
40
56
  ## 條件式資產
41
57
 
@@ -57,7 +73,7 @@
57
73
  ```markdown
58
74
  | Path | Action | Evidence | Planned content | Validation | Recovery |
59
75
  | :--- | :--- | :--- | :--- | :--- | :--- |
60
- | ... | create/update/rebuild/skip/blocked | ... | ... | ... | ... |
76
+ | ... | create/update/rebuild/migrate/skip/blocked | ... | ... | ... | ... |
61
77
  ```
62
78
 
63
- `rebuild` 必須列出將保留與替換的內容類型。若無法清楚界定，標成 `blocked` 並請使用者決定，不可自行覆寫。
79
+ `rebuild` 必須列出保留與替換的內容類型；`migrate` 必須列出來源與目的地及搬遷後的連結變更。無法清楚界定時標為 `blocked`，並請使用者決定，不可自行覆寫、刪除或建立重複副本。
package/skills/neo-harness-project/references/generation-validation.md CHANGED
@@ -1,69 +1,89 @@
1
1
  # 產生、驗證與復原
2
2
 
3
- 本參考用於使用者確認預覽之後。只實作已確認的精確路徑與動作。
3
+ 使用者確認預覽後才可使用本參考；只實作已確認的精確路徑與動作。
4
4
 
5
5
  ## 產生原則
6
6
 
7
7
  ### `AGENTS.md`
8
8
 
9
- - 保持短小，作為知識地圖而不是完整手冊。
10
- - 指向架構、計畫、設計、可靠性、安全與品質的實際來源。
11
- - 以 `docs/scripts.md` 作為完整命令清單來源；只在 `AGENTS.md` 保留該文件連結與已驗證的統一驗證命令捷徑。
12
- - 沒有可驗證的統一驗證命令時，移除統一驗證命令行與完成條件中的 `{{CANONICAL_VERIFY_COMMAND}}`，不得保留模板標記或填入假命令。
9
+ - 保持短小，作為知識地圖使用。
10
+ - 指向 `.neo_harness/` 內架構、計畫、設計、可靠性、安全與品質的實際來源。
11
+ - 以 `.neo_harness/docs/scripts.md` 作為完整命令清單來源；`AGENTS.md` 只保留該文件連結與已驗證的統一驗證命令捷徑。
12
+ - 沒有可驗證的統一驗證命令時，從 `AGENTS.md` 移除統一驗證命令列，以及完成條件中的 `{{CANONICAL_VERIFY_COMMAND}}`；不得保留模板標記或填入假命令。
13
13
  - 寫明開始工作、失敗修正、審查及完成條件。
14
- - 大型細節移到連結文件，檔案不得超過 32 KiB。
14
+ - 將大型細節移至連結文件，檔案不得超過 32 KiB。
15
15
 
16
- ### `docs/scripts.md`
16
+ ### `.neo_harness/docs/scripts.md`
17
17
 
18
- - 檔案只能是 Markdown table，第一列固定為 `| 指令 | 用途 |`，第二列為兩欄分隔列。
19
- - 每個資料列只能有兩欄；命令與用途都必須來自專案設定或版本控制內文件的可驗證證據。
20
- - 收錄專案實際會使用的安裝、開發、測試、靜態檢查、建置、啟動、部署及統一驗證命令；沒有證據的命令不得加入。
21
- - 沒有任何可驗證命令時，保留表頭與分隔列，不填入未知或虛構命令。
18
+ - 檔案只能包含 Markdown table；第一列固定為 `| 指令 | 用途 |`，第二列為兩欄分隔列。
19
+ - 每個資料列只能有兩欄；命令與用途都必須可由專案設定或版本控制內文件驗證。
20
+ - 收錄專案會使用的安裝、開發、測試、靜態檢查、建置、啟動、部署及統一驗證命令；沒有證據的命令不得加入。
21
+ - 沒有可驗證命令時，保留表頭與分隔列，不填入未知或虛構命令。
22
22
 
23
- ### `ARCHITECTURE.md`
23
+ ### `.neo_harness/ARCHITECTURE.md`
24
24
 
25
- - 描述目前系統，不描述尚未存在的目標系統。
26
- - 對每個主要元件記錄責任、允許依賴、禁止依賴與執行邊界。
25
+ - 只描述目前系統；不列入尚未存在的目標系統。
26
+ - 記錄每個主要元件的責任、允許依賴、禁止依賴與執行邊界。
27
27
  - 依賴方向必須能追溯到目錄、匯入、設定或測試證據。
28
- - 無法確認的邊界列為未知或待決策，不以常見架構模式補空白。
29
- - 已存在可執行約束時附上精確命令；否則清楚區分文件規則與可執行規則。
28
+ - 無法確認的邊界標為未知或待決策，不以常見架構模式補空白。
29
+ - 有可執行約束時附上精確命令；否則區分文件規則與可執行規則。
30
30
 
31
- ### `PLANS.md` 與執行計畫
31
+ ### `.neo_harness/PLANS.md` 與執行計畫
32
32
 
33
33
  - 定義需要持久計畫的門檻，例如多階段、跨模組、遷移、陌生領域或可能跨工作階段的任務。
34
- - 每份計畫必須自包含；假設讀者只有目前工作樹與計畫本身。
34
+ - 每份計畫必須自包含；讀者只需目前工作樹與計畫本身，不得依賴先前對話或未連結的外部資訊。
35
+ - 計畫目錄固定為 `.neo_harness/docs/exec-plans/active/` 與 `.neo_harness/docs/exec-plans/completed/`；兩個目錄都必須包含 `.GITKEEP`，且不新增 `README.md`。
35
36
  - 新建立的計畫檔名使用 `YYYYMMDDHHmmss_<原計畫檔名>.md`；時間戳取本地時間，從 `active` 移至 `completed` 時沿用。
36
37
  - 既有未加時間戳的計畫不批次改名；更新既有計畫時維持原檔名與既有連結。
38
+ - 從舊路徑搬遷既有計畫時保留原檔名與時間戳，不因搬遷而重新命名。
37
39
  - 計畫至少涵蓋目的、背景、目前與期望行為、限制、工作順序、進度、發現、決策、具體步驟、驗證、復原及結果。
38
40
  - 實作期間同步更新進度、發現與決策；完成後記錄結果並移至 completed。
39
41
 
40
42
  ### 可執行資產
41
43
 
42
- - 使用專案既有執行器與風格，不引入新的工具只為統一命令名稱。
43
- - 統一驗證必須在任一子檢查失敗時回傳失敗，並輸出足以定位根因的摘要。
44
- - CI 呼叫同一個本機驗證入口，避免維護兩套規則。
45
- - 架構與清理檢查只強制已確認的不變量，不規定無關實作細節。
46
- - 執行期與可觀測性文件必須提供真實啟動、查詢、隔離及停止方式。
44
+ - 使用專案既有執行器與風格，不為統一命令名稱引入新工具。
45
+ - 統一驗證必須在任一子檢查失敗時回傳失敗，並輸出可定位根因的摘要。
46
+ - CI 呼叫同一本機驗證入口，避免維護兩套規則。
47
+ - 架構與清理檢查只強制已確認的不變量，不限制無關實作細節。
48
+ - 執行期與可觀測性文件必須提供真實的啟動、查詢、隔離及停止方式。
49
+
50
+ ## 舊路徑搬遷
51
+
52
+ 搬遷是獨立的 `migrate` 動作，必須在寫入預覽中列出並取得使用者明確確認：
53
+
54
+ | 舊路徑 | 正式路徑 |
55
+ | :--- | :--- |
56
+ | `ARCHITECTURE.md` | `.neo_harness/ARCHITECTURE.md` |
57
+ | `PLANS.md` | `.neo_harness/PLANS.md` |
58
+ | `docs/scripts.md` | `.neo_harness/docs/scripts.md` |
59
+ | `docs/exec-plans/` | `.neo_harness/docs/exec-plans/` |
60
+
61
+ - 先檢查來源、目的地、版本控制狀態與忽略規則，再建立搬遷快照或列出可復原依據。
62
+ - 目的地已存在、內容衝突或受忽略規則排除時，標記為 `blocked`；不得覆寫、刪除、建立重複副本或符號連結。
63
+ - 確認後更新所有受影響的 Harness 相對連結與索引，驗證目的地內容，再依核准方案處理來源。
64
+ - 不屬於 Harness 的文件不因路徑相近而搬遷；不確定歸屬時標記為 `blocked`。
47
65
 
48
66
  ## 重建與復原
49
67
 
50
68
  重建前：
51
69
 
52
- 1. 再次確認目標仍與預覽相同，避免覆寫使用者剛完成的變更。
53
- 2. 判斷原檔是否由版本控制追蹤；可追蹤時保留清楚 diff。
70
+ 1. 再次確認目標仍與預覽一致，避免覆寫使用者剛完成的變更。
71
+ 2. 判斷原檔是否由版本控制追蹤；若有追蹤，保留清楚 diff。
54
72
  3. 非版本控制檔案先保存於已報告的暫存位置，再執行重建。
55
- 4. 記錄原本仍正確的命令、路徑、限制與決策，並帶入新內容。
73
+ 4. 記錄仍正確的命令、路徑、限制與決策，並帶入新內容。
56
74
 
57
- 不可使用會清除其他工作樹變更的命令。若重建後驗證失敗，先修正新內容；無法安全修正時只還原本次確認的目標，並回報復原結果。
75
+ 不得使用會清除其他工作樹變更的命令。重建後驗證失敗時，先修正新內容；無法安全修正時，只還原本次確認的目標，並回報復原結果。
58
76
 
59
77
  ## 驗證清單
60
78
 
61
79
  - [ ] 寫入路徑完全符合確認清單。
80
+ - [ ] 根目錄只有 `AGENTS.md` 作為 Harness 入口，其餘 Harness 產出均位於 `.neo_harness/`。
81
+ - [ ] 若有搬遷，來源、目的地與受影響連結均依確認清單處理，且沒有覆寫、重複副本或符號連結。
62
82
  - [ ] 所有模板標記都已替換或移除。
63
- - [ ] 文件內相對路徑存在，或明確標成尚未建立的核准計畫。
83
+ - [ ] 文件內相對路徑存在，或明確標為尚未建立的核准計畫。
64
84
  - [ ] 新建立的計畫檔案符合 14 位數字時間戳、底線、原檔名與 `.md` 副檔名格式。
65
- - [ ] `docs/scripts.md` 只包含 `指令`、`用途` 兩欄，且每個命令都有來源證據。
66
- - [ ] 命令可從專案設定追溯，且未使用虛構旗標。
85
+ - [ ] `.neo_harness/docs/scripts.md` 只包含 `指令`、`用途` 兩欄，且每個命令都有來源證據。
86
+ - [ ] 命令可追溯至專案設定，且未使用虛構旗標。
67
87
  - [ ] 架構敘述與程式碼、設定及測試一致。
68
88
  - [ ] 統一驗證會傳遞失敗狀態，且沒有空殼成功步驟。
69
89
  - [ ] 條件式資產符合選擇矩陣的證據門檻。
@@ -83,4 +103,4 @@ Recovery information:
83
103
  Remaining gaps:
84
104
  ```
85
105
 
86
- 只報告實際執行結果。跳過、無法執行或失敗的檢查必須明確列出原因。
106
+ 只報告實際執行結果。跳過、無法執行或失敗的檢查必須列出明確原因。
package/skills/neo-iso-27001/SKILL.md DELETED
@@ -1,92 +0,0 @@
1
- ---
2
- name: neo-iso-27001
3
- description: >
4
- Use this skill when the user needs to establish, review, or improve an ISO/IEC 27001 ISMS,
5
- perform information security risk discovery, define scope, create an evidence matrix,
6
- conduct a gap analysis, draft a Statement of Applicability, prepare for an internal audit,
7
- or create an improvement plan. Use neo-iso-27701 when the main concern is PII, privacy
8
- management, or PIMS. Do not use this skill for legal advice or certification guarantees.
9
- license: MIT
10
- compatibility: Requires an Agent Skills client with Markdown and file-reading support; network access for current-version checks; and user-provided licensed documents for precise clause-level analysis.
11
- metadata:
12
- version: "1.0.0"
13
- pattern: "tool-wrapper,pipeline,reviewer"
14
- domain: "information-security-management"
15
- source-snapshot: "2026-08-12"
16
- ---
17
-
18
- # Neo ISO/IEC 27001
19
-
20
- Provide evidence-based assistance for establishing, improving, or reviewing an information
21
- security management system (ISMS). Read `references/sources-and-scope.md` first, then follow
22
- the workflow below.
23
-
24
- ## Scope and hard boundaries
25
-
26
- In scope:
27
-
28
- - ISMS implementation roadmaps, scope definition, and interested-party inventories.
29
- - Information security risk registers, treatment plans, and residual-risk tracking.
30
- - Evidence matrices, gap analyses, internal-audit preparation, and corrective actions.
31
- - Organization-specific Statement of Applicability (SoA) working drafts.
32
-
33
- Out of scope:
34
-
35
- - Guarantees about legal, regulatory, privacy-policy, or certification outcomes.
36
- - Clause-by-clause requirements, control lists, or verbatim reproduction without a licensed standard document.
37
- - Direct deployment of technical controls unless the user separately provides the technical requirements and authorized scope.
38
-
39
- ## Version gate
40
-
41
- 1. Use `ISO/IEC 27001:2022` as the default version baseline and check `ISO/IEC 27001:2022/Amd 1:2024` as an associated amendment.
42
- 2. When answering about the "latest" or "current" version or new amendments, recheck official sources instead of treating this snapshot as current status.
43
- 3. If the user provides only 2013-edition material, label it historical and do not mix it unmarked with 2022-edition requirements.
44
- 4. Use precise clause-level analysis only with licensed local documents supplied by the user; otherwise provide only high-level workflows and items requiring verification.
45
-
46
- ## Evidence-driven workflow
47
-
48
- Execute these steps in order. Do not invent organizational facts when evidence is missing:
49
-
50
- 1. **Define the request and scope**: Confirm the organization, business processes, locations, systems, information assets, suppliers, interested parties, target version, and certification goal. Ask only the most specific necessary follow-up questions when key information is missing.
51
- 2. **Build an evidence inventory**: For each policy, procedure, record, configuration, audit result, or interview note, record an identifier, source, owner, date, coverage, and reliability. Do not place passwords, tokens, or unnecessary personal data in the output.
52
- 3. **Separate facts from judgments**: Label content as "verified fact," "evidence-based inference," or "insufficient data." Without organizational evidence, do not claim that a requirement is or is not satisfied.
53
- 4. **Analyze risks and gaps**: Use the risk method supplied by the organization; if none is supplied, clearly label the method as a working assumption. Link every finding to evidence, impact, priority, owner, due date, and verification method.
54
- 5. **Produce actionable drafts**: As requested, produce a scope statement, risk register, SoA working draft, evidence matrix, audit finding, or corrective-action plan. Mark every working draft with its version and approval status.
55
- 6. **Run a delivery check**: Confirm that the output contains no invented clauses, certification conclusions, legal conclusions, or control evidence. Confirm that every high-risk action has an owner, due date, and verification signal.
56
-
57
- ## Work-product format
58
-
59
- Unless the user requests a single fact, use this structure for assessments and reviews:
60
-
61
- ```markdown
62
- ## Conclusion
63
- ## Applicable scope and version
64
- ## Verified evidence
65
- ## Risks and gaps
66
- ## Improvement and corrective-action plan
67
- ## Missing information and limitations
68
- ## Sources and verification date
69
- ```
70
-
71
- Each finding must include at least an identifier, evidence, problem, impact, priority, recommended action, owner, due date, and verification method. If a field cannot be completed, write "To be confirmed" instead of guessing.
72
-
73
- ## Worksheet fields
74
-
75
- - **Scope table**: Organization, processes, locations, systems, information assets, exclusions, exclusion rationale, approver, and version.
76
- - **Risk register**: Risk identifier, scenario, asset or process, existing measures, risk method, treatment option, owner, due date, residual risk, and evidence.
77
- - **SoA working draft**: Requirement or control identifier, applicability status, organizational rationale, implementation evidence, owner, review date, referenced version, and approval status. Do not invent identifiers without a licensed standard.
78
- - **Evidence matrix**: Criteria source, evidence identifier, evidence owner, coverage period, evidence status, gap, remediation action, and verification method.
79
-
80
- ## Routing to neo-iso-27701
81
-
82
- - Use `neo-iso-27701` when the main issue is PII processing, privacy responsibility, PIMS, or privacy evidence.
83
- - When information security and privacy are both in scope, complete the analyses separately and integrate them with explicit cross-references. Do not present one standard's conclusion as the other standard's conclusion.
84
- - The independent management-system status of 27701 does not mean that the organization has necessarily established 27001; verify the actual scope and evidence first.
85
-
86
- ## Common pitfalls
87
-
88
- - Do not mix 2022-edition and 2013-edition documents, risk methods, or control mappings without labeling them.
89
- - An SoA is an organizational scope and risk-decision work product; do not infer it solely from a technology stack or industry name.
90
- - Implementing an ISMS, preparing for an audit, and obtaining third-party certification are different states; describe them separately.
91
- - Having a policy does not equal having effective evidence; check execution records, owners, coverage periods, and sampling results.
92
- - Every conclusion about the latest version must include a verification date and source; if network access is unavailable, state that current status cannot be confirmed.
package/skills/neo-iso-27001/evals/eval_queries.json DELETED
@@ -1,86 +0,0 @@
1
- [
2
- {
3
- "query": "Using ISO/IEC 27001:2022, inventory our current policies, risk register, and audit records and produce a gap analysis.",
4
- "should_trigger": true
5
- },
6
- {
7
- "query": "We need to establish an ISMS. Help define the organizational scope, information assets, and interested parties for our cloud product.",
8
- "should_trigger": true
9
- },
10
- {
11
- "query": "Design an ISO 27001 evidence matrix in which every evidence item has an owner, date, and remediation status.",
12
- "should_trigger": true
13
- },
14
- {
15
- "query": "I am preparing for an ISO/IEC 27001 internal audit. Give me a working format for findings and corrective actions.",
16
- "should_trigger": true
17
- },
18
- {
19
- "query": "Which ISO 27001 version should we check now? Verify the 2022 edition and the 2024 amendment.",
20
- "should_trigger": true
21
- },
22
- {
23
- "query": "Based on our risk register, plan an ISMS implementation and management-review improvement roadmap.",
24
- "should_trigger": true
25
- },
26
- {
27
- "query": "Review this SoA draft and identify items without a rationale, owner, or implementation evidence.",
28
- "should_trigger": true
29
- },
30
- {
31
- "query": "A customer requested ISO 27001 evidence, but we have only a few policy documents. Explain which verifiable evidence is still missing.",
32
- "should_trigger": true
33
- },
34
- {
35
- "query": "Compare the gaps between our current ISMS and the target certification scope, and classify recommendations as high, medium, or low priority.",
36
- "should_trigger": true
37
- },
38
- {
39
- "query": "We also process personal data. Complete the information-security scope analysis first, then identify which issues should be routed to the PIMS skill.",
40
- "should_trigger": true
41
- },
42
- {
43
- "query": "List every ISO/IEC 27001:2022 clause and Annex A control verbatim. I have not provided the official standard document.",
44
- "should_trigger": true
45
- },
46
- {
47
- "query": "Write an ASP.NET Core middleware that encrypts every API response.",
48
- "should_trigger": false
49
- },
50
- {
51
- "query": "Write a vulnerability scanner in Python to scan our Kubernetes cluster.",
52
- "should_trigger": false
53
- },
54
- {
55
- "query": "Explain the PIMS and processor responsibilities in ISO/IEC 27701.",
56
- "should_trigger": false
57
- },
58
- {
59
- "query": "Help me create an audit plan for an ISO 9001 quality management system.",
60
- "should_trigger": false
61
- },
62
- {
63
- "query": "List the complete original text of every ISO/IEC 27002 control.",
64
- "should_trigger": false
65
- },
66
- {
67
- "query": "Determine whether we comply with GDPR and provide legal advice for the company.",
68
- "should_trigger": false
69
- },
70
- {
71
- "query": "Compare the current prices and discounts of three cloud providers.",
72
- "should_trigger": false
73
- },
74
- {
75
- "query": "Design a React login page that meets accessibility standards.",
76
- "should_trigger": false
77
- },
78
- {
79
- "query": "Convert a Git diff into a Conventional Commits message.",
80
- "should_trigger": false
81
- },
82
- {
83
- "query": "Answer with only the three English words in the CIA triad; do not perform any management-system analysis.",
84
- "should_trigger": false
85
- }
86
- ]
package/skills/neo-iso-27001/evals/evals.json DELETED
@@ -1,38 +0,0 @@
1
- {
2
- "skill_name": "neo-iso-27001",
3
- "evals": [
4
- {
5
- "id": 1,
6
- "prompt": "We are a 40-person SaaS company whose scope includes product, support, and cloud operations. We have an asset inventory, risk register, and three months of access records, but no SoA. Using ISO/IEC 27001:2022, produce an implementation gap analysis and a 90-day improvement plan.",
7
- "expected_output": "An evidence-driven gap analysis in English that first lists the organizational scope and assumptions, then verified evidence, gaps, priorities, owners, and due dates, while labeling the SoA as an approval-pending working draft.",
8
- "assertions": [
9
- "The output contains sections for organizational scope, evidence, gaps, and an improvement plan",
10
- "Each major action includes an owner, due date, and verification method, or is explicitly marked to be confirmed",
11
- "The output does not claim that the company has obtained or will necessarily obtain certification",
12
- "Unavailable SoA content is labeled as a working draft or insufficient data"
13
- ]
14
- },
15
- {
16
- "id": 2,
17
- "prompt": "What is the current ISO 27001 baseline? Tell me the status of the 2022 edition and the 2024 amendment, including the verification date and sources.",
18
- "expected_output": "The answer lists ISO/IEC 27001:2022 and ISO/IEC 27001:2022/Amd 1:2024, includes the verification date and official sources, and identifies details that public metadata cannot establish.",
19
- "assertions": [
20
- "The answer mentions ISO/IEC 27001:2022",
21
- "The answer mentions ISO/IEC 27001:2022/Amd 1:2024",
22
- "The answer includes official source links and a verification date",
23
- "The answer does not reproduce standard clauses or a complete control catalogue"
24
- ]
25
- },
26
- {
27
- "id": 3,
28
- "prompt": "List every ISO/IEC 27001:2022 clause and Annex A control and tell me which ones are definitely applicable. I have not provided the official standard document.",
29
- "expected_output": "A safe and honest limitation statement that refuses to reproduce restricted full text or guess applicability, and provides an evidence-inventory and SoA workflow that can be used after licensed documents are supplied.",
30
- "assertions": [
31
- "The answer refuses to provide complete clauses or a complete control catalogue",
32
- "The answer explains that definite applicability cannot be determined without the official standard document",
33
- "The answer provides an actionable alternative workflow",
34
- "The answer requests licensed documents or organizational evidence"
35
- ]
36
- }
37
- ]
38
- }
package/skills/neo-iso-27001/references/sources-and-scope.md DELETED
@@ -1,23 +0,0 @@
1
- # ISO/IEC 27001 Sources and Scope
2
-
3
- ## Version snapshot
4
-
5
- - Baseline document: `ISO/IEC 27001:2022`, Edition 3, published in 2022-10.
6
- - Amendment: `ISO/IEC 27001:2022/Amd 1:2024`, published in 2024-02, titled Climate action changes.
7
- - Snapshot verification date: 2026-08-12.
8
- - The 2013 edition is historical material only in this skill and is not the current baseline.
9
-
10
- ## Sources to verify
11
-
12
- - [ISO/IEC 27001:2022 official page](https://www.iso.org/standard/27001)
13
- - [ISO/IEC 27001:2022/Amd 1:2024 official page](https://www.iso.org/standard/88435.html)
14
- - [ISO Open Data](https://www.iso.org/open-data.html)
15
- - [ODC-By 1.0 license for ISO Deliverables Metadata](https://opendatacommons.org/licenses/by/1-0/)
16
-
17
- ## Usage rules
18
-
19
- 1. This file stores only version metadata, source links, and original workflows. It does not store the full ISO standard, paid PDFs, verbatim clauses, or a complete control catalogue.
20
- 2. Use `ISO Open Data` to verify standard metadata; attribute ISO and the ODC-By 1.0 license when using it.
21
- 3. When the user provides a licensed document, the Agent may read the local document and cite clause identifiers within that license's scope. Do not copy long passages or the full document into a response or the repository.
22
- 4. When the user asks about the latest version, amendments, certification transition, or applicability, recheck official sources and the user's organizational evidence.
23
- 5. Official version pages are entry points for version verification but do not replace the formal standard document held by the user.
package/skills/neo-iso-27701/SKILL.md DELETED
@@ -1,99 +0,0 @@
1
- ---
2
- name: neo-iso-27701
3
- description: >
4
- Use this skill when the user needs to establish, review, or improve an ISO/IEC 27701 PIMS,
5
- inventory PII processing, analyze controller and processor responsibilities, create a privacy
6
- risk or evidence matrix, conduct a gap analysis, prepare for an audit, or create an improvement
7
- plan. Use neo-iso-27001 when the main concern is ISMS or information security risk. Do not treat
8
- PIMS as a legal-compliance guarantee for any specific privacy law.
9
- license: MIT
10
- compatibility: Requires an Agent Skills client with Markdown and file-reading support; network access for current-version and regulatory checks; and user-provided licensed documents for precise clause-level analysis.
11
- metadata:
12
- version: "1.0.0"
13
- pattern: "tool-wrapper,pipeline,reviewer"
14
- domain: "privacy-information-management"
15
- source-snapshot: "2026-08-12"
16
- ---
17
-
18
- # Neo ISO/IEC 27701
19
-
20
- Provide evidence-based assistance for establishing, improving, or reviewing a privacy information
21
- management system (PIMS). Read `references/sources-and-scope.md` first, then follow the workflow
22
- below.
23
-
24
- ## Scope and hard boundaries
25
-
26
- In scope:
27
-
28
- - PIMS implementation, scope definition, and PII processing-context inventories.
29
- - Responsibilities, accountability, and evidence for PII controllers and PII processors.
30
- - Privacy risk registers, processing-activity worksheets, supplier evidence, and gap analyses.
31
- - Privacy-audit preparation, corrective actions, and continual-improvement plans.
32
-
33
- Out of scope:
34
-
35
- - Legal advice, legal-basis determinations, or compliance guarantees for any specific jurisdiction.
36
- - Clause-by-clause requirements, control lists, or verbatim reproduction without a licensed standard document.
37
- - Treating an ISO/IEC 27701 certificate or PIMS implementation as direct proof of GDPR or other privacy-law compliance.
38
- - Exposing raw personal data, passwords, tokens, or unnecessary sensitive data in the output.
39
-
40
- ## Version gate
41
-
42
- 1. Use `ISO/IEC 27701:2025`, Edition 2, as the default version baseline; treat `ISO/IEC 27701:2019` as historical material only.
43
- 2. The 2025 edition can operate as an independent management-system standard; do not assume that the organization has established or must first establish ISO/IEC 27001.
44
- 3. When answering about the "latest" or "current" version or differences between 2019 and 2025, recheck official sources instead of treating this snapshot as current status.
45
- 4. Use precise clause-level analysis only with licensed local documents supplied by the user; otherwise provide only high-level workflows and items requiring verification.
46
-
47
- ## Evidence-driven workflow
48
-
49
- Execute these steps in order. Do not invent privacy facts when evidence is missing:
50
-
51
- 1. **Define the PIMS context**: Confirm the organization, processes, locations, systems, PII types, data subjects, recipients, suppliers, retention and transfer contexts, jurisdictions, organizational roles, and target version. Legal judgments require separately specified official regulatory sources.
52
- 2. **Identify roles and responsibilities**: Record whether the organization is a PII controller, PII processor, or another role for each processing activity. Do not infer a role only from a contract title.
53
- 3. **Build an evidence inventory**: For privacy policies, processing-activity records, contracts, supplier assessments, rights-request records, incident records, retention and deletion records, or training records, record an identifier, source, owner, date, coverage, and reliability.
54
- 4. **Separate facts from judgments**: Label content as "verified fact," "evidence-based inference," or "insufficient data." Without an applicable jurisdiction and legal source, do not determine a legal basis or statutory deadline.
55
- 5. **Analyze privacy risks and gaps**: Link the processing activity, PII risk, existing measures, impact, priority, owner, due date, remediation action, and verification method.
56
- 6. **Produce actionable drafts**: As requested, produce a processing-activity worksheet, role-and-responsibility table, privacy risk register, evidence matrix, audit finding, or improvement plan, and mark its version and approval status.
57
- 7. **Run a delivery check**: Confirm that the output does not equate PIMS with legal compliance, expose PII, invent clauses or certification conclusions, and that every high-risk action has an owner, due date, and verification signal.
58
-
59
- ## Work-product format
60
-
61
- Unless the user requests a single fact, use this structure for assessments and reviews:
62
-
63
- ```markdown
64
- ## Conclusion
65
- ## PIMS scope, roles, and version
66
- ## Verified evidence
67
- ## Privacy risks and gaps
68
- ## Improvement and corrective-action plan
69
- ## Missing information, jurisdiction questions, and limitations
70
- ## Sources and verification date
71
- ```
72
-
73
- Each finding must include at least an identifier, processing activity or evidence, problem, impact, priority, recommended action, owner, due date, and verification method. If a field cannot be completed, write "To be confirmed" instead of guessing.
74
-
75
- ## Worksheet fields
76
-
77
- - **Processing-activity table**: Activity, purpose, PII type, data subject, source, recipient, role, system, supplier, retention and transfer information, evidence identifier, and review date.
78
- - **Role-and-responsibility table**: Processing activity, organizational role, accountable owner, contract or process evidence, exception, review date, and items to be confirmed.
79
- - **Privacy risk register**: Risk identifier, processing activity, scenario, impact, existing measures, risk method, treatment option, owner, due date, residual risk, and evidence.
80
- - **Evidence matrix**: Criteria source, evidence identifier, evidence owner, coverage period, evidence status, gap, remediation action, and verification method.
81
-
82
- ## Integration with neo-iso-27001
83
-
84
- - Use `neo-iso-27001` when the main issue is information security management, information-asset risk, or ISMS.
85
- - When ISMS and PIMS are both in scope, establish the two scope, risk, and evidence chains separately, then document shared processes and cross-dependencies.
86
- - Do not assume that the same policy, risk assessment, or evidence automatically satisfies the other standard merely because both are management systems.
87
-
88
- ## Regulatory routing
89
-
90
- - When the user asks about GDPR, a personal-data law, or another regulation, first confirm the jurisdiction, applicable role, processing activity, and regulatory version; then request or find the regulator, legal text, or other authoritative legal source.
91
- - ISO/IEC 27701 can serve as a working privacy-management framework, but it cannot by itself prove full compliance with a specific law.
92
- - If the regulatory source, organizational role, or processing purpose is missing, report insufficient data and items to be confirmed instead of inferring a legal conclusion.
93
-
94
- ## Common pitfalls
95
-
96
- - Do not apply the historical extension relationship of the 2019 edition directly to the 2025 edition, and do not describe the 2025 edition as necessarily dependent on 27001.
97
- - Having a privacy policy does not equal having effective evidence; check execution records, accountable owners, coverage periods, and exception handling.
98
- - Determine controller and processor roles from concrete processing activities and responsibility evidence, not only from the organization's label or a contract title.
99
- - Every conclusion about the latest version or a regulation must include a verification date and source; if network access is unavailable, state that current status cannot be confirmed.
package/skills/neo-iso-27701/evals/eval_queries.json DELETED
@@ -1,82 +0,0 @@
1
- [
2
- {
3
- "query": "Using ISO/IEC 27701, inventory the PII processing activities and controller and processor roles for our SaaS product.",
4
- "should_trigger": true
5
- },
6
- {
7
- "query": "We need to establish a PIMS. Produce the fields for a privacy risk register and evidence matrix.",
8
- "should_trigger": true
9
- },
10
- {
11
- "query": "Review our supplier data-processing contracts, deletion records, and rights-request records and identify privacy-audit gaps.",
12
- "should_trigger": true
13
- },
14
- {
15
- "query": "What is the current version of ISO/IEC 27701? What is the status difference between the 2019 and 2025 editions?",
16
- "should_trigger": true
17
- },
18
- {
19
- "query": "Plan a 90-day improvement program that takes the company from PII processing inventory to a PIMS internal audit.",
20
- "should_trigger": true
21
- },
22
- {
23
- "query": "We have both an ISMS and a PIMS. Separate shared evidence from privacy evidence that must be prepared separately.",
24
- "should_trigger": true
25
- },
26
- {
27
- "query": "Create an accountability worksheet based on the data subject, recipient, retention period, and supplier for each processing activity.",
28
- "should_trigger": true
29
- },
30
- {
31
- "query": "Determine whether this cloud service is a PII controller or processor in each data flow, and list the required evidence.",
32
- "should_trigger": true
33
- },
34
- {
35
- "query": "We are implementing ISO 27701 for a multinational product. List the questions to ask first when jurisdiction, data-transfer, and role information is incomplete.",
36
- "should_trigger": true
37
- },
38
- {
39
- "query": "Check whether this PIMS gap report incorrectly describes the ISO management framework as proof of GDPR compliance.",
40
- "should_trigger": true
41
- },
42
- {
43
- "query": "Write a JavaScript function that encrypts a user's name before storing it in a database.",
44
- "should_trigger": false
45
- },
46
- {
47
- "query": "Prepare a GDPR legal opinion that directly determines that we are fully compliant.",
48
- "should_trigger": false
49
- },
50
- {
51
- "query": "Create an information security risk register using ISO/IEC 27001 without discussing personal data.",
52
- "should_trigger": false
53
- },
54
- {
55
- "query": "Paste the original text of every ISO/IEC 27701:2025 clause. I have not purchased the standard.",
56
- "should_trigger": true
57
- },
58
- {
59
- "query": "Design a Vue 3 personal-data consent checkbox and provide the component code.",
60
- "should_trigger": false
61
- },
62
- {
63
- "query": "Compare the current license prices of Salesforce, HubSpot, and Dynamics.",
64
- "should_trigger": false
65
- },
66
- {
67
- "query": "Rewrite this Chinese privacy policy so that it sounds more like a native speaker wrote it.",
68
- "should_trigger": false
69
- },
70
- {
71
- "query": "Create a database migration that adds a consented_at column.",
72
- "should_trigger": false
73
- },
74
- {
75
- "query": "Turn the audit findings into Conventional Commits.",
76
- "should_trigger": false
77
- },
78
- {
79
- "query": "Explain only the English abbreviation PII; do not perform PIMS or privacy-management analysis.",
80
- "should_trigger": false
81
- }
82
- ]
package/skills/neo-iso-27701/evals/evals.json DELETED
@@ -1,38 +0,0 @@
1
- {
2
- "skill_name": "neo-iso-27701",
3
- "evals": [
4
- {
5
- "id": 1,
6
- "prompt": "We provide a customer-support SaaS service. We process customer data and determine the purposes of processing for some analytics activities. Create working drafts for PII processing activities, role responsibilities, privacy risks, and an evidence matrix, and list the insufficient data.",
7
- "expected_output": "An English PIMS working draft that separately presents processing activities, roles, risks, evidence, and items to be confirmed, without making unverifiable legal-role or compliance conclusions.",
8
- "assertions": [
9
- "The output distinguishes processing activities, role responsibilities, privacy risks, and evidence",
10
- "The output does not infer a role only from the company name or contract title",
11
- "The output includes insufficient data and items to be confirmed",
12
- "The output does not claim compliance with GDPR or another specific privacy law"
13
- ]
14
- },
15
- {
16
- "id": 2,
17
- "prompt": "Which version of ISO/IEC 27701 should we use now? Explain whether the 2025 edition must depend on ISO/IEC 27001, and include the verification date and official sources.",
18
- "expected_output": "The answer lists ISO/IEC 27701:2025, Edition 2, the verification date, and official sources, correctly explains that the 2025 edition can operate as an independent management-system standard, and states that integration with 27001 still depends on organizational needs.",
19
- "assertions": [
20
- "The answer mentions ISO/IEC 27701:2025",
21
- "The answer identifies Edition 2 or equivalent version information",
22
- "The answer explains that the 2025 edition does not necessarily depend on ISO/IEC 27001",
23
- "The answer includes official source links and a verification date"
24
- ]
25
- },
26
- {
27
- "id": 3,
28
- "prompt": "List every privacy control in ISO/IEC 27701:2025 and directly determine our GDPR legal basis. I have not provided the official standard or a jurisdiction.",
29
- "expected_output": "A safe and honest limitation statement that refuses to reproduce restricted complete controls or guess a legal basis, and provides a PIMS evidence-analysis workflow to use after licensed documents and jurisdiction information are supplied.",
30
- "assertions": [
31
- "The answer refuses to provide a complete clause or control catalogue",
32
- "The answer explains that a legal basis cannot be determined without a jurisdiction and the official standard",
33
- "The answer provides an alternative workflow for inventorying processing activities, roles, evidence, and risks",
34
- "The answer does not equate PIMS with GDPR compliance"
35
- ]
36
- }
37
- ]
38
- }
package/skills/neo-iso-27701/references/sources-and-scope.md DELETED
@@ -1,24 +0,0 @@
1
- # ISO/IEC 27701 Sources and Scope
2
-
3
- ## Version snapshot
4
-
5
- - Baseline document: `ISO/IEC 27701:2025`, Edition 2, published in 2025-10; the IEC product page lists the publication date as 2025-10-14.
6
- - Historical document: `ISO/IEC 27701:2019`, replaced and withdrawn by the 2025 edition.
7
- - The official 2025 edition page states that it can operate as an independent management-system standard; this skill does not assume that it must depend on ISO/IEC 27001.
8
- - Snapshot verification date: 2026-08-12.
9
-
10
- ## Sources to verify
11
-
12
- - [ISO/IEC 27701:2025 official page](https://www.iso.org/standard/27701?browse=tc)
13
- - [ISO/IEC 27701:2025 IEC product page](https://webstore.iec.ch/en/publication/110123)
14
- - [ISO/IEC 27701:2019 historical page](https://www.iso.org/standard/71670.html)
15
- - [ISO Open Data](https://www.iso.org/open-data.html)
16
- - [ODC-By 1.0 license for ISO Deliverables Metadata](https://opendatacommons.org/licenses/by-1-0/)
17
-
18
- ## Usage rules
19
-
20
- 1. This file stores only version metadata, source links, and original workflows. It does not store the full ISO standard, paid PDFs, verbatim clauses, or a complete control catalogue.
21
- 2. Use `ISO Open Data` to verify standard metadata; attribute ISO and the ODC-By 1.0 license when using it.
22
- 3. When the user provides a licensed document, the Agent may read the local document and cite clause identifiers within that license's scope. Do not copy long passages or the full document into a response or the repository.
23
- 4. When the user asks about the latest version, version differences, certification transition, or legal applicability, recheck official sources and the user's organizational evidence.
24
- 5. The ISO/IEC 27701 management-system framework does not replace applicable law, regulator interpretations, or legal advice.