danepps/legal-research-skills

法律研究

近似於深度研究執行，專為法律領域量身打造，並預設為高效率。 它執行一個檢索管線，僅使用免費/開放網路法律來源（無 Westlaw/Lexis）； 階段性的形狀、上限和模型映射位於步驟 4 的調用程式碼旁。此設計 旨在降低 token 使用量——在單純的扇出模式中，最主要的成本來自於前沿模型讀取每個 擷取的頁面——同時仍能防止幻覺引用。對於高風險工作，可添加 deep（例如：「做一次深度搜索」）， 此時詳盡性優先於速度。

來源（開放網路）

判例法：CourtListener、Justia、Google Scholar 判例法、Cornell LII、Caselaw Access Project、 官方法院網站。學術文獻：SSRN、Google Scholar、法學院數位共享庫、 HeinOnline 開放內容、期刊網站、教師個人頁面。學術模式也會透過 Zotero MCP 伺服器搜尋使用者自己的 Zotero 文獻庫（若不可用則會優雅地略過）。

如何執行

1. 解析請求

從使用者的提示中提取：

• question — 法律問題（必要）。
• mode — caselaw、scholarship 或 both。預設為 both。可從措辭推斷 （「法院的見解為何」→ caselaw；「文獻現狀 / 學術辯論」→ scholarship）。
• outputStyle — practitioner（問題呈現 / 簡短回答 / IRAC）或 academic （引言 / 概觀 / 分析 / 腳註）。預設值：判例法 mode 為 practitioner，scholarship 和 both mode 為 academic。 尊重明確的覆寫。
• jurisdiction、asOfDate（預設為今天）以及任何 notes（事實、訴訟現狀、範圍）。

2. 僅在真正造成阻礙時才釐清

如果問題過於模糊而難以進行良好研究，請在啟動前提出 2–3 個針對性問題。 對於判例法，管轄權 和 程序現狀 最為重要；對於學術文獻， 特定的論點或子問題 以及 時間範圍 最為重要。不要過度提問——選取合理的 預設值並加以說明。

3. 預飛行：確保允許使用網路工具（在啟動前執行此操作）

研究子代理器會大量調用 WebSearch 和 WebFetch。如果這些工具未被預先 允許，每次調用都會彈出互動式權限提示——而中斷的提示可能會 導致研究代理器在執行中途被終止（一個真實的失敗模式：先前的執行因此遺失了 4 個向量中的 2 個）。

在調用 Workflow 之前，使執行過程自包含：

1. 讀取 ~/.claude/settings.json 並檢查 permissions.allow 中是否包含 "WebFetch" 和 "WebSearch"。
2. 如果缺少任何一個，請添加它（合併到現有的 allow 陣列中——切勿取代它；如果路徑不存在，則創建 permissions.allow 路徑）。如果兩者都已存在，則不做任何事。
3. 不要詢問使用者——這是該技能常規設定的一部分。（如果該檔案是受管理的/ 唯讀且您無法編輯，請告知使用者他們將看到每次擷取的提示並應接受 它們，或透過 /permissions 添加規則。）
4. 可選但值得一看：確定性判例引用驗證需要 CourtListener API 令牌。測試它，不要去尋找檔案——執行 python3 ${CLAUDE_PLUGIN_ROOT}/skills/legal-research/check_cite.py "347 U.S. 483"； 若退出碼爲 0 且包含 "found": true，則表示令牌運作正常，無需回報。 check_cite.py 會依序解析來自 COURTLISTENER_API_TOKEN、 COURTLISTENER_TOKEN 以及檔案 ~/.config/courtlistener/token 的令牌——按此順序， 而環境變數路徑（通常設定在 ~/.claude/settings.json 的 env 區塊中）是 正常安裝方式，因此檔案不存在並不代表什麼。如果測試實際上失敗了， 不要阻止執行——驗證代理器會退回使用網路檢查——但請在交付步驟中提及一次 （令牌頁面：https://www.courtlistener.com/profile/api-token/）。

4. 啟動工作流程

使用捆綁的腳本和解析後的參數調用 Workflow 工具：

Workflow({
  scriptPath: "${CLAUDE_PLUGIN_ROOT}/skills/legal-research/legal-research.workflow.js",
  args: {
    skillsDir: "${CLAUDE_PLUGIN_ROOT}/skills",      // 捆綁的輔助腳本所在位置
    question: "<法律問題>",
    mode: "caselaw" | "scholarship" | "both",
    outputStyle: "practitioner" | "academic",
    jurisdiction: "<例如：聯邦 / 第九巡迴上訴法院 / 密蘇里州 / 美國最高法院>",
    asOfDate: "<YYYY-MM-DD 或 'today'>",
    notes: "<事實、訴訟現狀、範圍、使用者強調的任何事項>",
    deep: false,  // 僅在使用者要求進行深度/詳盡/高風險搜索時設為 true
    projectDir: "<當前工作目錄——啟用本地語料庫調查向量；
                 僅在 cwd 明顯與問題無關時省略>"
  }
})

預設為精簡模式：約 4 個純搜索調查向量（加上在學術模式中的 Zotero 文獻庫掃描 以及對 projectDir 的本地語料庫掃描——先前的備忘錄和下載的來源是地圖和線索， 而非可引用的權威來源）。Scope 也會對問題進行分類（教義性 vs. 學術性；歷史性 與否）——這會選擇一個分析方法簡報，注入到 Draft 中（綜合紀律、 持有/意見區分、針對教義史問題的時代跨度分類法），並且對於歷史性 問題，將搜索向量分散到不同的時間層，使覆蓋範圍不會僅集中在現代 經典上。直接答案覆蓋單元（scholarship/both 模式，於 2026-07-16 添加， 在一次 Codex 比較執行擊敗了針對實際問題的 64 代理器 Claude 執行後）： Scope 必須至少投入一個向量來處理將問題的命名現象作為其自身對象的學術文獻—— 由專家期望的專業術語建構而成，並包含對最相關文獻的引用追蹤—— 與該現象僅隸屬的相鄰文獻區分開來。Survey 會標記此類核心候選文獻； triage 會將其提升為完整閱讀，優先於廣泛的相鄰文獻調查。此修正所解決的失敗： 映射了五個相鄰文獻領域（庭外言論、迴避、名人）卻錯過了少數直接關於該現象的 著作（例如司法自傳研究、「大法官書籍交易」的倫理章節），然後將該語料庫缺口 誤認為「沒有直接學術文獻」的發現。不存在/缺口的主張現在受到核心來源遺漏審計 的管制（在學術方法簡報中）：除非針對現象的搜索 AND 雙向引用追蹤確實執行了， 否則不能聲稱「沒有學術文獻直接涉及 X」——否則該主張的範圍應限於 「在所審查的來源中」，並標記未執行的搜索。扇出是圍繞覆蓋單元組織的， 代理器上限是一個天花板，而非配額——不重疊的通道勝過許多重疊的通用搜索。 管線：調查向量 → 去重 → 總共最多 ≤8 個獨特完整閱讀（非每個向量； 讀取器在放棄前會退回使用開放獲取鏡像——數位共享庫、作者頁面、CourtListener/LII—— ；將 PDF 透過硬的大小限制擷取器 fetch_page.py 路由；並在命題和引文旁邊 提取訴訟現狀/限制/協同意見/重要性）→ 一次基於會話模型的草稿（由方法簡報引導） → 一次有限制的缺口填補（最多 3 次目標檢索加一次重試波次，僅在草稿標記 缺少權威來源時進行）→ 對僅引用的權威來源進行分塊引用檢查（每個代理器 8 個； 判例引用透過 CourtListener 的引用查詢 API check_cite.py 進行確定性確認， 加上透過 cl_case_tools.py citing 進行系統性的引用意見處理掃描—— 一個基於相關性的處理語言探查，針對該案件實際的引用意見，附有存活日期， 取代了舊的一次搜索瀏覽；本輪已開啟的來源會跳過存在性重新檢查）→ 輕量最終化。 未被選中的候選來源以及每個已讀來源本身所依賴的權威來源，會作為有保留的 未讀線索 帶入草稿中，使廣度保持廣泛，同時擷取次數保持較少。 每次執行都有花費保護：一個硬編碼的軟上限（精簡模式約 250k 輸出 token， 深度模式約 1M——於 2026-07-15 從 600k 提高，起因是一次深度歷史執行在 中途達到上限，導致 43 個引用中的 35 個未被檢查）啟用與明確的 +500k 預算 相同的優雅降級階梯——減少讀取 → 跳過缺口填補 → 僅驗證關鍵引用—— 因此失控的執行會降級而非惡性循環。讀取、缺口填補和驗證代理器都帶有一個 存取紀律區塊（同日添加）：硬性的嘗試上限，僅限 WebSearch/WebFetch， 並明確禁止瀏覽器自動化、圖書館代理和 SSO/登入流程——付費來源 應誠實回報 opened=false，而不是繼續嘗試。模型：僅 Haiku 用於搜索摘要調查； Sonnet 用於分類、完整閱讀和驗證；Scope、Draft 和 Finalize 繼承會話模型 （若 Fable 啟用則使用 Fable）。deep:true（或類似 +800k 的 token 預算）會 擴展至最多 7 個向量，將讀取上限提高至 16，並為每個關鍵引用（上限 8 個） 提供一次 3 票對抗性反駁（重新開啟來源以逐字確認引文）。 工作流程會在背景執行，並在完成時通知您。

5. 交付

工作流程會回傳 { memo, exitState, degradation, counts, ... }。

• 在呈現前先檢查 exitState。 complete → 交付。complete_with_limits → 交付， 並說明記錄的缺口（列在 degradation 和備忘錄的「研究限制」章節中）。 budget_exhausted → 預算守門員實際上限制了覆蓋範圍（減少了讀取、跳過了缺口填補、 未檢查引用——詳見 degradation）；此備忘錄尚非可交付成果。經過驗證的 補救模式（2026 年 7 月的前 1960 年執行）：啟動針對性的讀取和驗證代理器——每個未覆蓋的 領域一個，賦予需要從官方判例彙編文字中擷取和確認的特定案例/引文—— 然後自行以工作流程驗證過的核心加上補救過程的結果來撰寫最終備忘錄。 不要將一份備忘錄交給使用者，其中一半範圍的「信心程度：不足」， 卻未填補缺口或進行詢問。補救代理器需要與工作流程代理器相同的存取紀律 （2026 年 7 月一次學術執行的教訓，一個無上限的補救代理器花了 30 多分鐘和約 245k token 升級到瀏覽器自動化以對付一篇付費的 1962 年文章）：在每個補救提示中寫入 硬性的嘗試上限（每個來源約 3 次）、僅限 WebSearch/WebFetch、明確禁止瀏覽器自動化 / 圖書館代理 / SSO 流程，以及「付費——這是我能達到的最強依據」是完全可接受的答案。 如果補救代理器仍然卡住，使用 SendMessage 要求其總結並回報，而不是等待。
• 將備忘錄作為主要交付成果呈現給使用者。
• 超連結（必要，根據作者要求，2026-08-29）： 備忘錄中的每則新聞報導、部落格文章或 其他網路來源都必須附帶其可運作的 URL 作為可點擊連結——絕不能僅以 媒體名稱歸屬，例如「(Politico)」或「(Roll Call, July 14, 2026)」。工作流程的引用區塊 會在代理器提示中強制執行此點；手寫編輯、補救過程以及任何臨時性的 （非工作流程）研究備忘錄也應遵守相同規則，並指示任何補救/填補代理器 為其引用的每個來源回傳 URL（沒有 URL 的主張視為未驗證）。
• 研究備忘錄標頭和產出頁尾（必要，根據作者要求——~/.claude/CLAUDE.md 中的全域規則）： 備忘錄直接在標題下方以結構化標頭區塊開頭（Topic: / Date: / By:）； Production details: 區塊放在檔案最末尾（所有附錄之後，包括 「本研究的限制」，以 --- 分隔線標示）——永遠不在上方。Date 是備忘錄 交付/撰寫的當地日期/時間；By 是 Claude-<orchestrating session model>（確切 ID）； Production details 應命名技能、實際使用的工作流程代理器模型（從 執行中的逐代理器進度記錄讀取——不要假設）、實際經過時間以及來自 完成通知的 <usage> 區塊的 token 計數（標記為子代理器輸出 token； 不包含協調器開銷）。如果在工作流程後執行了補救/填補過程，請添加其代理器計數 並說明時間僅涵蓋工作流程執行。
• 呈現驗證計數（「N 個權威已驗證，M 個未驗證」），讓他們知道 應信任的程度，並指向備忘錄的**「本研究的限制」**附錄（該附錄現在 會揭露每個權威的驗證基礎：直接全文 / 權威再現 / 二次佐證 / 僅引用）。
• 結果也帶有 skeleton——草稿所根據的、附有引文標記的分析大綱（每個關鍵 主張都標記到其發現，缺口標記為 GAP）。預設不呈現；如果使用者想要審計 推理過程，可以提供它，並且在您手動編輯備忘錄時自行使用 （一個沒有對應大綱行的主張在發展之前需要一個權威或一個保留條件）。
• 提供儲存選項：工作目錄中的 Markdown；Word 格式，透過捆綁的轉換器—— python3 ${CLAUDE_PLUGIN_ROOT}/skills/legal-research/md2docx.py memo.md memo.docx "<Title>"；或 透過連接器的 Google Drive。如果使用者一開始就要求 .docx，只需直接產生即可。
• 提供針對任何薄弱/未驗證點的後續處理，或切換輸出格式。

主張校準（v7）

引用驗證和主張校準捕捉的是不相交的錯誤類別：驗證捕捉關於來源的虛假陳述； 校準捕捉的是將真實發現組裝成未經支持的概括。管線現在同時強制執行兩者—— Draft 提示帶有一個主張強度檢查器（頻率/優先/最終性詞彙，如「首先」、 「唯一」、「壓倒性地」、「抹去」需要專門為支持它們而設計的搜索，否則應使用 樣本限定語言），讀取器會標記每個來源的立場（包括假設性和非先例性處置） 和相關性（僅程序 / 假設前提 / 相鄰學說），歷史性執行會獲得選擇偏差、 邊界日期和損害/排除檢查，深度執行會在草稿上添加專門的對抗性校準過程。 第三類錯誤存在於它們之間：一個

…

[為翻譯而截斷]