@laitszkin/apollo-toolkit 3.12.0 → 3.12.1

package/review-spec-related-changes/SKILL.md

@@ -1,47 +1,39 @@
 ---
 name: review-spec-related-changes
-description: >-
-  面向spec合規性的只讀審查技能。先唯一確定本次變更受哪一套 `docs/plans/...` 規劃文件約束，再按業務目標逐條判定 `Met`、`Partially met`、`Not met` 或 `Deferred/N/A`；`tasks.md` 的勾選不算證據。若範圍涉及代碼實作，完成業務結論後還必須對同一範圍追加 `review-change-set`、`discover-edge-cases` 與 `discover-security-issues`，並保持固定報告順序。
+description: 當你需要審查規格文檔相關變更時，調用此技能
 ---
 
 ## 目標
-輸出一份只讀的spec合規審查報告，先回答「這次變更是否真的滿足規劃中的業務要求」，再補充邊界、安全與代碼審查發現。報告需要對每條關鍵需求給出可追溯的狀態判定、證據來源、缺口說明、通過證據與剩餘不確定性；本技能不負責修改代碼或更新規劃文件。
+
+輸出一份 spec 相關變更審查報告，先回答「這次變更是否真的滿足規劃中的業務要求」，再補充邊界、安全與代碼審查發現。每條關鍵需求需給出可追溯的狀態判定、證據來源、缺口說明與剩餘不確定性；不負責修改代碼或更新規劃文件。
 
 ## 驗收條件
-- 在給出任何合規結論前，已唯一確定 governing spec；若存在兩個同樣合理的規劃根目錄且無法由倉庫證據消歧，必須停止並報告歧義，不能猜測。
-- 每條業務目標或驗收項只能根據可驗證證據判定為 `Met`、`Partially met`、`Not met` 或 `Deferred/N/A`；證據可來自代碼、測試、命令、日誌或追蹤，`tasks.md` 勾選本身不算證據。
-- 未滿足或部分滿足的必選業務要求永遠是最高嚴重度，報告排序中不得被安全、邊界或可維護性意見壓過。
-- 若範圍涉及代碼實作，完成業務結論後必須在同一範圍追加 `review-change-set`、`discover-edge-cases` 與 `discover-security-issues`；任一依賴不可用時，不得輸出「完整通過」結論。
-- 全流程保持只讀：不得修改實作、測試、spec、archive、commit、push、tag 或 release。
-- 最終交付物固定按以下順序輸出：業務缺口 → 邊界情況 → 安全問題 → 代碼審查問題 → 已滿足要求的通過證據 → 剩餘不確定性。
+
+- 生成完整的 code review report，內容涵蓋6個維度的代碼審查結果及改進建議。
 
 ## 工作流程
-1. 確定 governing spec。
-   - 若使用者已指定具體路徑，直接以該規劃目錄為準，閱讀 `spec.md`、`tasks.md`、`checklist.md`、`contract.md`、`design.md`，以及存在時的 `coordination.md`。
-   - 若使用者未指定，需根據 `git status`、diff、相關路徑、近期提交與計劃目錄證據回推出唯一 spec；若仍有歧義，立即停止。
-2. 建立spec基線。
-   - 從 governing spec 中抽取業務目標、驗收條件、非目標、已明示的延期項與要求執行的驗證。
-   - 將「產品必須做到什麼」和「代碼寫得是否漂亮」明確分開。
-3. 蒐集實作證據並先做業務判定。
-   - 閱讀最小必要代碼路徑、相關 diff、提交與測試，必要時執行 spec 點名且安全可跑的驗證命令。
-   - 對每條需求給出 `Met`、`Partially met`、`Not met` 或 `Deferred/N/A`，並附上精確 spec 引用與代碼/測試證據。
-   - 若 spec 中存在完全獨立的需求群組，可用只讀 subagent 並行評分；但最終排序、嚴重度與跨需求衝突整理由主代理負責。
-4. 對代碼範圍追加次級審查。
-   - 若審查對象包含代碼實作，必須在同一範圍追加 `review-change-set`、`discover-edge-cases` 與 `discover-security-issues`。
-   - 優先以一個只讀 subagent 對應一個次級技能並行執行，主代理只負責聚合結果，不重跑已委派分析。
-   - 若次級審查結果反過來影響某條業務需求的判定，必須先回寫業務結論，再輸出最終報告。
-5. 生成固定順序的最終報告。
-   - 先列出 `Not met` 與 `Partially met` 的業務缺口，再依序列出邊界情況、安全問題、代碼審查問題。
-   - 接著補上所有已確認 `Met` 的通過證據。
-   - 最後列出未驗證命令、無法映射的 spec 段落、外部依賴不可驗證處與其他剩餘不確定性。
-
-## 使用範例
-- 「這個 PR 有沒有滿足 `coordination.md` 和 `spec.md`？」-> 先唯一確定 governing spec，再按業務要求逐條打分，最後補上同範圍的邊界、安全與變更集審查。
-- 「請檢查 `docs/plans/2026-05-01/foo/` 對應的實作是否完成」-> 直接以指定目錄為準做只讀合規審查，不依賴聊天上下文猜測。
-- 「`tasks.md` 都打勾了，應該算完成吧？」-> 不能直接採信，仍需用代碼、測試、命令或追蹤證據重新驗證每條要求。
-- 「先跟我講哪個 requirement 沒達成，再看程式碼好不好」-> 報告必須先輸出業務缺口，不能先用重構或風格意見掩蓋未滿足的spec要求。
-
-## 參考資料索引
-- `review-change-set`：在相同代碼範圍上補做架構與簡化審查，避免將spec合規與代碼品質混為一談。
-- `discover-edge-cases`：在相同範圍上補做可重現邊界情況審查，補齊失敗路徑、併發與可觀測性風險。
-- `discover-security-issues`：在相同範圍上補做可重現安全審查，補齊攻擊面、授權與資料外洩風險。
+
+### 1. 建立審查範圍
+
+閱讀用戶指定的 spec ，並按照 spec 之中定義的實作範圍，檢索並閱讀相關代碼。
+如果外部環境允許使用 subagents，建議通過調度 subagents 完成代碼的深度閱讀。
+
+### 2. 進行多維度審查
+
+對所有實作代碼多維度的審查，確保代碼：
+- 無幻覺代碼
+- 無冗余代碼
+- 代碼無與 spec 之間的實作偏移
+- 無 spec 實作遺漏
+- 無架構瑕疵
+- 無性能隱患
+
+如果有代碼違反了上述6個原則，將他們紀錄在案。
+如果外部環境允許使用 subagents，建議通過調度 subagents 完成對代碼的多維度審查。
+
+### 3. 生成 code review report
+
+將上一步發現的所有問題代碼總結，並按照問題嚴重程度排序，生成code review report。report需要包含以下元素：
+- 問題描述、嚴重度及影響
+- 涉及的代碼檔案、行數
+- 建議修正方案

package/ship-github-issue-fix/SKILL.md

@@ -7,7 +7,7 @@ description: Resolve a GitHub issue in an existing repository and submit the fix
 
 ## Dependencies
 
-- Required: `read-github-issue`, `enhance-existing-features`, `recover-missing-plan`, and `commit-and-push`.
+- Required: `read-github-issue`, `enhance-existing-features`, and `commit-and-push`.
 - Conditional: `systematic-debug` when the issue is primarily a bug investigation or failing behavior report.
 - Optional: none.
 - Fallback: If any required dependency is unavailable, stop and report which dependency blocked the workflow.
@@ -32,7 +32,7 @@ description: Resolve a GitHub issue in an existing repository and submit the fix
 ### 2) Explore the codebase and decide whether specs are required
 
 - After reading the issue, inspect the real entrypoints, affected modules, tests, and existing planning files.
-- If the user references an expected `docs/plans/...` path that is missing or archived unexpectedly, run `$recover-missing-plan` before treating the issue as unspecced work.
+
 - Run `$enhance-existing-features` to decide whether specs are required from the actual change surface.
 - Default to direct implementation for clearly localized bug fixes, regressions, narrow optimizations, or small workflow corrections, even when the issue wording sounds broad.
 - Require specs when the explored change touches critical money movement, permissions, high-risk concurrency, or multi-module behavior changes that need approval traceability.

package/solve-issues-found-during-review/SKILL.md

@@ -1,58 +1,23 @@
 ---
 name: solve-issues-found-during-review
-description: >-
-  用於根據已確認的 review finding 清單逐項修復問題。必須按嚴重度排序、最小化修改、
-  每項修完立即驗證，並在結束前證明 spec 合規與相關安全 / edge-case finding 已真正清乾淨。
+description: 當你需要修復 code review report 之中發現的問題時，調用這個技能。
 ---
 
-# 修復審查發現的問題
-
-## Dependencies
-
-- Required: 使用者必須提供既有 review 報告或可重建的 finding 清單
-- Conditional: `review-spec-related-changes`、`review-change-set`、`systematic-debug`、`discover-security-issues`、`discover-edge-cases`、`commit-and-push`
-- Optional: 無
-- Fallback: 若沒有可重建的 finding 清單就必須停止；若 `review-change-set` 不可用，至少要用針對性測試與 diff 證據補足；若使用者要求提交或推送但 `commit-and-push` 不可用，也必須停止
-
-## Standards
-
-- Evidence: 每個修改都要能對應到一條已確認 finding、受影響程式碼與驗證證據
-- Execution: 依嚴重度由高到低處理，每項 finding 修完就驗證，再進入下一項；最後再做全域重驗證
-- Quality: 僅修確認問題，不夾帶順手重構或推測性 hardening；不能重現時必須留下 `Could not reproduce` 證據
-- Output: 交付逐項狀態、驗證證據、spec 合規結果、 ancillary review 清理結果，以及是否真正完成本輪修復
-
 ## 技能目標
 
-把 review 報告中的 confirmed findings 轉成一條可追蹤、可驗證、可收斂的修復流程，避免只做表面修改，並在結束前證明相關spec、安全與 edge-case 要求沒有留下實質風險。
+遵照 code review report 之中的建議方案，逐一將所有發現的代碼問題修正。
 
 ## 驗收條件
 
-- 每個程式碼改動都能對應到明確的 finding，且沒有混入無關修補
-- 所有 finding 均按嚴重度順序處理，並在每項修復後留下通過的驗證證據
-- 若此範圍受 `docs/plans/...`、`spec.md`、`tasks.md`、`checklist.md` 或 contract 約束，最終已有 spec 合規證據
-- 安全、edge-case 與其他隨附 review finding 已被修復或以可重現證據標記 `Could not reproduce`；若仍有 `Deferred`，只有在使用者明確縮 scope 時才能宣稱本輪完成
+- 所有 code review report 之中明確列出的問題都已經被完全修復。
 
 ## 工作流程
 
-1. 先完整閱讀 report 與受影響程式碼；若使用者只說「修 review finding」但沒提供內容，先嘗試從近期輸出或 diff 重建清單，重建失敗就停止
-2. 擷取每條 finding 的嚴重度、標題、證據位置與重現方式，並排除沒有被 reviewer 明確確認的猜測性項目
-3. 按 Critical -> High -> Medium -> Low 排序；只有在工作空間完全隔離且檔案不重疊時，才允許平行處理不同群組，否則一律串行
-4. 逐條處理 finding：先讀程式碼與重現路徑，再用最小修改修復，立刻執行最窄且足夠的驗證；若驗證結果不清楚，交給 `systematic-debug`
-5. 全部 finding 處理完後，對修改範圍做整體重驗證；若是 code-affecting 變更，重新跑 `review-change-set`
-6. 若存在綁定 spec 或計劃檔，使用 `review-spec-related-changes` 證明已重新符合要求；若 inbound package 含安全或 edge-case finding，使用 `discover-security-issues` 或 `discover-edge-cases` 的 rerun / scoped proof 證明該維度已清空
-7. 向使用者輸出逐項狀態、驗證命令、殘留阻塞與本輪是否真的完成；若要求提交或推送，再交給 `commit-and-push`
-
-## 使用範例
+### 1. 完整閱讀 code review report
 
-- 「修這份 review 裡的 HIGH SSRF finding」-> 只修該 finding 對應路徑，跑針對性測試與重現命令，確認通過後才處理下一條
-- 「report 裡還有 edge-case 與 security finding」-> 修完主問題後，還要補 rerun / scoped proof，不能只靠口頭說明就宣稱完成
-- 「reviewer 指的路徑現在不存在」-> 記錄檢查過的 commit 與路徑，若無法重現則標成 `Could not reproduce`，而不是虛構一個修復
+完整閱讀 code review report，並深入閱讀相關受影響代碼，理解建議修復方案。
+如果外部環境允許使用 subagents，建議通過subagents完成對代碼的深度閱讀。
 
-## 參考資料索引
+### 2. 修復發現的問題
 
-- `review-spec-related-changes`：驗證修復後仍符合 spec / plan
-- `review-change-set`：修復後的 code-affecting 差異重審
-- `systematic-debug`：修復過程中遇到不明測試或 runtime 問題時使用
-- `discover-security-issues`：清理安全 finding 時的 scoped proof
-- `discover-edge-cases`：清理 edge-case / hardening finding 時的 scoped proof
-- `commit-and-push`：使用者要求提交或推送時的最終交付流程
+按照 code review report之中的嚴重度排序，從最高嚴重度的問題開始建議方案修復。

package/spec-to-project-html/SKILL.md

@@ -20,7 +20,7 @@ description: >-
 
 ## 工作流程
 
-1. 先定位本次規劃目錄；使用者明確給出路徑時優先使用，否則結合 `coordination.md` 或 `recover-missing-plan` 找到正確 plan 集，並整理相關需求編號用於追蹤。
+1. 先定位本次規劃目錄；使用者明確給出路徑時優先使用，否則結合 `coordination.md` 找到正確 plan 集，並整理相關需求編號用於追蹤。
 2. 執行 `apltk architecture --help` 取得最新命令形態，然後按 `spec.md`、`design.md`、`contract.md`、`coordination.md` 的順序讀取內容，確定哪些功能、子模組、邊、變數或錯誤語義會發生變化。
 3. 先只列出受影響功能，不要提前把所有原始碼塞進主 agent。除了直接變更的功能，也要納入跨功能邊另一端的功能，確保 overlay 中的跨邊界關係完整。
 4. 為每個受影響功能派發一個可寫子 agent。每個子 agent 只負責自己功能內的 overlay 寫入：子模組、函式、變數、資料流、錯誤，以及功能內邊；若規劃領先於程式碼，則在角色、用途或資料流文案中明確標註 `planned`、`gap` 或 `TBD`。
@@ -37,6 +37,6 @@ description: >-
 
 - `init-project-html/SKILL.md`：基礎語義規則、邊類型與子模組表達約束。
 - `references/TEMPLATE_SPEC.md`：overlay 模式下的欄位、列舉與 diff 配對規則速查表。
-- `recover-missing-plan`：當 plan 路徑缺失或不明確時用於恢復正確 spec 集。
+
 - `generate-spec`、`implement-specs*`：需求編號和規劃流程的上游來源。
 - `apltk architecture --help`：`--spec` 模式命令與參數的唯一真源。

package/submission-readiness-check/SKILL.md

@@ -5,23 +5,7 @@ description: >-
   專案文件、`AGENTS.md` / `CLAUDE.md` 與已完成的 planning artifacts 是否都已更新到可提交狀態。
 ---
 
-# 提交前就緒檢查
-
-## Dependencies
-
-- Required: `align-project-documents`、`maintain-project-constraints`
-- Conditional: `archive-specs`
-- Optional: 無
-- Fallback: 若必需技能不可用，或明確需要 spec 歸檔但 `archive-specs` 不可用，必須停止並回報，不得給出虛假的 ready verdict
-
-## Standards
-
-- Evidence: 以實際 git diff、staged set、planning artifacts、`CHANGELOG.md` 與現有專案文件作為就緒判斷依據
-- Execution: 先確認下游提交類型，再處理 spec 歸檔、文件同步與 changelog，最後才給出 ready 或 blocking verdict
-- Quality: 所有命中的條件 gate 都必須真正完成；不能把 stale changelog、未同步文件或仍活躍的 plan set 當成小問題略過
-- Output: 回傳清楚的可提交判定，列出已同步項目與仍阻塞下游提交流程的問題
-
-## 技能目標
+## 目標
 
 在任何提交、推送、開 PR 或發版前，先把 repository 的外部說明、內部約束與 planning artifacts 同步到一致狀態，避免把未整理完成的變更交給下一個提交流程。
 
@@ -42,13 +26,13 @@ description: >-
 5. 檢查 `CHANGELOG.md`：對 commit / PR 流程，要讓 `Unreleased` 精準反映這次待提交內容，同時保留其他未出貨工作；對 release 流程，`Unreleased` 必須非空且已整理成可直接切版的 release notes
 6. 彙整哪些項目已同步、哪些仍阻塞；若還有未完成的 gate，明確回報 blocking item，而不是把責任留給下一個技能
 
-## 使用範例
+## 範例
 
 - 「準備提交這批變更」-> 檢查是否有未同步 changelog、文件與已完成但尚未歸檔的 spec
 - 「準備開 PR」-> 確保 `Unreleased` 反映當前 PR 範圍，並把 `AGENTS.md` / `CLAUDE.md` 與 docs 同步好
 - 「準備發版」-> 確保 `Unreleased` 非空且可直接作為 release notes，並先完成任何必要的 spec 歸檔與文件標準化
 
-## 參考資料索引
+## 參考資料
 
 - `align-project-documents`：同步 `docs/features/`、`docs/architecture/`、`docs/principles/`
 - `maintain-project-constraints`：同步 `AGENTS.md` / `CLAUDE.md`

package/systematic-debug/SKILL.md

@@ -10,7 +10,7 @@ description: >-
 ## Dependencies
 
 - Required: 無
-- Conditional: 視情況可搭配 `test-case-strategy`、`analyse-app-logs`、`scheduled-runtime-health-check`
+- Conditional: 視情況可搭配 `test-case-strategy`、`analyse-app-logs`
 - Optional: 無
 - Fallback: 無
 
@@ -52,4 +52,4 @@ description: >-
 
 - `test-case-strategy`：需要補重現測試或 drift check 時使用
 - `analyse-app-logs`：問題主要來自應用日誌時使用
-- `scheduled-runtime-health-check`：需要有界執行與執行後分析時使用
+

package/version-release/SKILL.md

@@ -10,7 +10,7 @@ description: >-
 ## Dependencies
 
 - Required: `commit-and-push`、`submission-readiness-check`
-- Conditional: `review-change-set`、`archive-specs`
+- Conditional: `archive-specs`
 - Optional: 無
 - Fallback: 缺少必需技能時必須停止，不能憑印象手動補一個發版流程
 
@@ -29,14 +29,14 @@ description: >-
 
 - 已先確認這是明確的 release / semver 請求；若只是 commit 或 push，必須改走 `commit-and-push`
 - 在修改任何版本相關檔案前，已清楚說出 current -> next 版本與將建立的 tag 字串
-- `submission-readiness-check`、必要的 `review-change-set` 與 `archive-specs` 都已完成，且 `CHANGELOG.md` 的 `Unreleased` 內容足以支撐本次發版
+- `submission-readiness-check` 與必要的 `archive-specs` 都已完成，且 `CHANGELOG.md` 的 `Unreleased` 內容足以支撐本次發版
 - 最終已同步版本檔、發布說明、commit、tag、remote refs 與 GitHub Release；若使用者明確要求不發布 Release，需在結果中清楚註明
 
 ## 工作流程
 
 1. 先確認使用者是否真的要求 release、publish、tag、patch、minor、major 或其他明確 semver 動作；若沒有，改用 `commit-and-push`
 2. 檢查目前 git 狀態、版本檔、既有 tag、本地與remote是否已有同版本 tag，以及 GitHub 上是否已有同版本 Release，避免重複發版
-3. 對 code-affecting 範圍先完成 `review-change-set`，再執行 `submission-readiness-check`；若它要求 `archive-specs` 或 changelog/文件同步，必須先完成
+3. 對 code-affecting 範圍執行 `submission-readiness-check`；若它要求 `archive-specs` 或 changelog/文件同步，必須先完成
 4. 根據版本檔、repo 歷史與使用者指示決定 current -> next 版本與 tag 格式；若語意不明，優先選較小 bump 並請使用者確認
 5. 一致更新所有版本入口，並把 `CHANGELOG.md` 的 `Unreleased` 移到新的版本區塊；release notes 只能來自整理過的 changelog 內容
 6. 建立 release commit 與 tag；若是 prerelease retarget，保留版本號不變，只把 tag / Release 移到新的 commit

package/discover-edge-cases/CHANGELOG.md

@@ -1,19 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-## [v0.2.1] - 2026-02-17
-
-### Changed
-- Remove `submit-changes` skill dependency from no-diff release flow while keeping the PR workflow.
-- Update skill and README guidance to use direct git commit/push before opening a PR.
-
-## [v0.2.0] - 2026-02-17
-
-### Added
-- Add no-diff workflow guidance to scan the whole codebase for actionable edge cases.
-- Add release-flow guidance for no-diff fixes: create worktree, use `submit-changes`, and open a PR.
-
-### Changed
-- Clarify scope selection logic: `git diff` path uses changed files only; no-diff path uses full-codebase scan.
-- Expand README examples to include a no-diff prompt and expected execution path.

package/discover-edge-cases/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 LaiTszKin
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/discover-edge-cases/README.md

@@ -1,87 +0,0 @@
-# discover-edge-cases
-
-`discover-edge-cases` is a Codex skill for discovering reproducible edge-case risks and coverage gaps.
-
-## Brief introduction
-
-This skill is discovery-oriented. It scans the current diff by default, or the full codebase
-when there is no diff, then validates the highest-risk edge cases with concrete evidence.
-It does not write tests, patch code, or open PRs.
-
-It follows a strict workflow:
-1. Detect whether `git diff` exists.
-2. Inspect only changed files plus minimal dependencies, or perform a full-project scan when no diff exists.
-3. Run `discover-security-issues` as an adversarial dependency for code-affecting scope.
-4. Probe the highest-risk edge cases and gather concrete evidence.
-5. Reproduce confirmed issues at least twice and check nearby variants.
-6. Prioritize confirmed findings and report hardening guidance only.
-
-## When to use
-
-Use this skill when a task asks you to:
-- find edge-case risks in a diff or codebase,
-- validate unusual inputs and error paths,
-- assess hardening gaps around null/empty/boundary handling,
-- review retries, timeouts, degradation paths, or stateful failure modes.
-
-## Core principles
-
-- Scope is `git diff` plus the minimal dependency chain by default.
-- If `git diff` is empty, run a full-codebase scan focused on high-risk modules.
-- Treat prior authorship as irrelevant; even code written earlier in the same conversation must be challenged like third-party code.
-- Decisions must be evidence-based; speculative ideas stay marked as hypotheses.
-- Keep only reproducible findings with exact evidence.
-- Run `discover-security-issues` as a required adversarial cross-check for code-affecting scope.
-- Report recommended fixes and test ideas, but do not implement them in this skill.
-
-## External API requirements
-
-When the selected scope involves external API calls, this skill requires checks for:
-- health/availability handling,
-- graceful handling of `429` and `500` responses,
-- actionable error logging (status code, request id, retry count, latency).
-
-## Example
-
-Prompt example:
-
-```text
-Please review this PR diff and find the 3 highest-risk edge cases.
-Validate null input, boundary timestamp, and API 429 retry behavior.
-Only report confirmed findings with reproduction evidence and suggested test coverage.
-```
-
-Expected behavior:
-- only changed files and minimal dependency chain are investigated,
-- each finding includes reproducible evidence,
-- speculative ideas are separated from confirmed issues,
-- the output stays discovery-only with no code edits.
-
-No-diff prompt example:
-
-```text
-There is no git diff in this repo. Scan the whole codebase for high-risk edge cases.
-If you find any actionable issues, reproduce them with evidence and report the highest-priority findings only.
-```
-
-## References
-
-- [`SKILL.md`](./SKILL.md) - full workflow and execution rules.
-- [`references/architecture-edge-cases.md`](./references/architecture-edge-cases.md) - cross-module/system-level edge-case checklist.
-- [`references/code-edge-cases.md`](./references/code-edge-cases.md) - code-level input, boundary, and error-path checklist.
-
-## Repository structure
-
-```text
-.
-├── LICENSE
-├── SKILL.md
-├── README.md
-└── references
-    ├── architecture-edge-cases.md
-    └── code-edge-cases.md
-```
-
-## License
-
-MIT

package/discover-edge-cases/SKILL.md

@@ -1,32 +0,0 @@
----
-name: discover-edge-cases
-description: 審查代碼在邊界狀況時可能會出現的問題。當你需要進行代碼審查時，調用此技能
----
-
-## 目標
-
-審查代碼並輸出一份代碼邊界問題審查報告，僅保留可重現、可驗證的風險。報告需要按優先級列出問題標題、證據、重現方式、受影響不變式、風險評估、加固建議與剩餘不確定性。
-
-## 驗收條件
-
-- 完整的代碼審查報告與建議修正。包括但不限於對代碼進行：資料完整性、靜默失敗、重試風暴、資源耗盡、部分提交/回滾失敗與跨模組傳播等審查結果。
-
-## 工作流程
-
-### 1. 深入閱讀相關代碼
-
-通過用戶指引或目前git變更狀態，定義審查範圍。完整閱讀並閱讀相關代碼片段並理解代碼。重點關注常見邊界問題。
-
-### 2. 報告整理及輸出
-
-將發現的邊界問題按嚴重程度排序，並輸出一份完整的審查報告
-
-## 使用範例
-
-- "幫我檢查這次 parser 改動有沒有邊界風險" -> "閱讀本次改動的相關代碼，檢查常見邊界問題是否存在，並輸出完整的驗證報告"
-- "看看這個支付狀態機還有哪些不容易被測到的問題" -> "優先檢查重試、部分提交、回滾、併發重入、順序依賴與可觀測性缺口。"
-
-## 參考資料索引
-
-- `references/architecture-edge-cases.md`：常見系統級邊界情況清單，涵蓋併發、背壓、分散式一致性、超時取消、回滾與部署漂移。
-- `references/code-edge-cases.md`：常見代碼級邊界情況清單，涵蓋輸入、數值、排序、錯誤處理、狀態污染、安全驗證與性能上限。

package/discover-edge-cases/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Discover Edge Cases"
-  short_description: "Find reproducible edge-case risks with evidence-only reporting"
-  default_prompt: "Use $discover-edge-cases to scan the current diff first (or the full codebase when there is no diff), discard any bias toward code written earlier in the conversation, run $discover-security-issues as an adversarial cross-check for code-affecting scope, identify the highest-risk reproducible edge-case findings, validate them with concrete evidence, prioritize the confirmed risks, and report hardening and test recommendations without modifying code."

package/discover-edge-cases/references/architecture-edge-cases.md

@@ -1,41 +0,0 @@
-# Common Architecture-level Edge Cases (Reference List)
-
-## How to use
-- Pick only 2-5 items directly related to the current change; avoid exhaustive scans.
-- If changes involve external dependencies/concurrency/scheduling/messaging, prioritize matching sections.
-
-## Concurrency and synchronization
-- Race conditions: concurrent updates to the same resource cause overwrite/lost updates
-- Deadlock/livelock: inconsistent lock ordering, reentrant lock misuse, or busy-wait loops
-- Visibility/memory consistency: cross-thread state is not synchronized
-- Async task leaks: background tasks not cancelled or cleaned up
-
-## Backpressure and resources
-- Backpressure failure: slow downstream causes upstream queue growth, OOM, or queue saturation
-- Resource starvation: high-priority tasks monopolize resources
-- Connection pool exhaustion: unreleased or delayed-release connections
-- File/socket leaks: exception paths skip close/release
-
-## Distributed systems
-- Network partition/intermittent unreachable state: requires retry/degrade/isolation strategy
-- Retry storms: retry amplification under failure
-- Consistency gaps: stale reads or partial writes
-- Duplicate messages: at-least-once delivery causes duplicate processing
-- Message ordering: reordering/out-of-order events corrupt state
-- Clock skew: time-based ordering/expiration becomes incorrect
-
-## Timeout and cancellation
-- Timeout not propagated: child tasks continue and consume resources
-- Non-reentrant cancellation: retry causes inconsistent state
-- Timeout boundary flapping: unstable behavior near timeout thresholds
-
-## Error handling and rollback
-- Partial success: multi-step writes complete only partially
-- Rollback failure: compensation action fails and leaves inconsistent data
-- Swallowed exceptions: errors are neither surfaced nor logged
-- Missing idempotency: retries create duplicate side effects
-
-## Deployment and versioning
-- Rolling upgrade mismatch: old/new versions run together with inconsistent behavior
-- Config drift: node configurations diverge
-- Hot reload instability: temporary unavailability or state loss during reload

package/discover-edge-cases/references/code-edge-cases.md

@@ -1,46 +0,0 @@
-# Common Code-level Edge Cases (Reference List)
-
-## How to use
-- Pick only 2-5 items directly related to the current change.
-- Prioritize observable failures and high-risk inputs.
-
-## Input and typing
-- Null/missing fields: None/null, empty string, empty collection
-- Unexpected types: string-number mixing, boolean-integer confusion
-- Oversized input: long strings, large arrays, deeply nested objects
-- Encoding issues: UTF-8/non-ASCII, invisible characters
-
-## Boundaries and numerics
-- Off-by-one: index 0/1 and length boundaries
-- Overflow/underflow: integer/timestamp boundaries
-- NaN/Inf: floating-point special values
-- Precision loss: money/ratio calculations
-- Negative values where invalid
-
-## Structure and ordering
-- Duplicate elements: dedup/accumulation logic
-- Ordering assumptions: sorting stability, input-order dependence
-- Empty/singleton collections: reduce/min/max/avg behavior
-- Mutable/immutable mismatch: in-place mutation of input data
-
-## Exceptions and error handling
-- Parsing failures: date/timezone, JSON, CSV
-- External dependency failures: 429/500/timeout
-- Swallowed errors: `except pass` or missing logs
-- Recovery strategy: retry count, backoff, degradation
-
-## State and side effects
-- Reentrancy: same request invoked multiple times
-- Global state contamination: cache/singleton bleed-through
-- Mutable default parameters: Python list/dict defaults
-- Resource release: file/connection not closed
-
-## Security and validation
-- Insufficient authorization behavior
-- Validation bypass via null/0/False
-- Path/injection risks from string concatenation
-
-## Performance and limits
-- N+1 query patterns inside loops
-- Large-data stress: timeout/memory pressure
-- Hotspots: lock contention under high-frequency calls

package/discover-security-issues/CHANGELOG.md

@@ -1,32 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on Keep a Changelog and this project follows Semantic Versioning.
-
-## [v0.0.3] - 2026-05-06
-
-### Changed
-- Rename skill directory and identifier from `harden-app-security` to `discover-security-issues`; refresh `SKILL.md`, `README.md`, and agent display metadata to match discovery-only semantics.
-
-## [v0.0.2] - 2026-03-11
-
-### Changed
-- Reworked the skill into a single discovery-only workflow and removed interaction/auto mode selection.
-- Removed proactive remediation behavior from the core workflow (no direct patching or PR delivery).
-- Expanded module scope from agent/finance only to include a new `software-system` domain for common software and web vulnerabilities.
-- Updated skill metadata and README to reflect adversarial finding/reporting-only behavior.
-
-### Added
-- Added `references/common-software-attack-catalog.md` covering SQL injection, XSS, CSRF, SSRF, path traversal, IDOR/BOLA, command injection, session/token risks, unsafe upload, and misconfiguration checks.
-
-## [v0.0.1] - 2026-02-17
-
-### Added
-- Documented explicit interaction and auto execution modes in the security hardening workflow.
-- Clarified handoff behavior for interaction mode and delivery expectations for auto mode.
-
-### Changed
-- Removed mandatory `$submit-changes` dependency from auto-mode PR delivery.
-- Switched auto-mode delivery guidance to standard git push plus PR creation workflow (prefer `gh pr create`).
-- Updated agent interface metadata to reflect interaction-first execution behavior.

package/discover-security-issues/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 LaiTszKin
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/discover-security-issues/README.md

@@ -1,35 +0,0 @@
-# discover-security-issues
-
-Evidence-first, **discovery-only** adversarial security workflow across agent, financial, and general software surfaces.
-
-## What this skill provides
-
-- Reproduce exploitable behavior with payloads, requests, and `path:line` proof—**no patches or PRs**.
-- Modules: `agent-system`, `financial-program`, `software-system`, and `combined` (cross-boundary chains).
-- Catalog-driven scenarios (SQLi, XSS, CSRF, SSRF, IDOR, prompt injection, money-path races, …).
-- Prioritized reporting plus advisory hardening notes and residual risk.
-
-## Layout
-
-- `SKILL.md` — workflow, modules, output shape.
-- `agents/openai.yaml` — metadata and default prompt.
-- `references/*` — attack catalogs and optional test-pattern snippets.
-
-## Typical use
-
-1. Pick module(s) and trust boundaries.
-2. Walk selected reference catalogs; record only **double-reproduced** issues.
-3. Prioritize and report; stop before implementation—hand off confirmed findings if fixes are needed.
-
-## Example
-
-```text
-Use $discover-security-issues in discovery-only mode.
-Module: combined (agent-system + software-system).
-Focus: prompt injection to privileged tools, SQL injection, IDOR.
-Deliver severity-ordered findings with exploit steps and path:line evidence.
-```
-
-## License
-
-MIT. See [LICENSE](LICENSE).