Router skill for legal-toolkit — the entry point that recognises user intent across 6 clusters (📋 Playbook / 📝 Template / 🚨 Runbook / 🔍 IRAC / 📅 Tracker / 🏛️ Compliance) and dispatches to the right specialist sub-skill. 7 active sub-skills (legal-contract-review / legal-playbook-author / legal-document-draft / legal-incident-response / legal-issue-spot / legal-research / this router); 4 more sub-skills (legal-contract-tracker / legal-regulation-watch / legal-corporate-governance / legal-dd-quickscan) are listed as not-yet-available with their planned phase. Returns a 6-cluster menu when intent is ambiguous — never guesses.
台灣 in-house 法務工具組 router。法務工具のルーター。
TRIGGER (中英雙語):
- legal / contract / NDA / playbook / 合約 / 法律 / 法務
- "I have a contract to review" / "需要審合約" / "建紅線"
- "legal-toolkit" / "什麼 legal 的 skill 可以用"
- first install / 剛裝好
USE WHEN: user mentions anything legal-toolkit-related and the
specific sub-skill is not clear from the request.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Exibindo SKILL.md
SKILL.md
Instruções da origem · Visualização somente leitura
name
using-legal-toolkit
title
using-legal-toolkit
description
Router skill for legal-toolkit — the entry point that recognises user intent across 6 clusters (📋 Playbook / 📝 Template / 🚨 Runbook / 🔍 IRAC / 📅 Tracker / 🏛️ Compliance) and dispatches to the right specialist sub-skill. 7 active sub-skills (legal-contract-review / legal-playbook-author / legal-document-draft / legal-incident-response / legal-issue-spot / legal-research / this router); 4 more sub-skills (legal-contract-tracker / legal-regulation-watch / legal-corporate-governance / legal-dd-quickscan) are listed as not-yet-available with their planned phase. Returns a 6-cluster menu when intent is ambiguous — never guesses.
台灣 in-house 法務工具組 router。法務工具のルーター。
TRIGGER (中英雙語):
- legal / contract / NDA / playbook / 合約 / 法律 / 法務
- "I have a contract to review" / "需要審合約" / "建紅線"
- "legal-toolkit" / "什麼 legal 的 skill 可以用"
- first install / 剛裝好
USE WHEN: user mentions anything legal-toolkit-related and the
specific sub-skill is not clear from the request.
The entry point. Listens to the user's natural-language request,
identifies which of the 6 functional clusters the task belongs to,
and dispatches to the appropriate sub-skill — or lists a menu when
the intent is ambiguous.
The router itself does no domain work: it never reads contracts,
never writes playbook entries, never produces legal findings. It is
a pure dispatch primitive (Harvey "Model System" layer).
When invoked, the router reads the user's request and applies the
following sequence of checks. First match wins — the router
does not run multiple branches; it picks one.
Step 1 — Extract intent signals
From the user's request, extract:
Keywords (in both English and zh-TW): contract, review, redline, NDA, 合約, 審查, 紅線, 建 playbook, 起草, privacy, 個資外洩, 法規, 股東會, DD, etc.
File types (if user attached / pointed at files): .md / .docx / .pdf of a contract → strong signal for Q1
Verbs: "審" / "改" / "建" / "查" / "監看" / "起草" — each maps to a different cluster
Q1 / Q7 are MVP — actually dispatch. Q2 is active in v0.4.0+ — actually dispatch. Q3 is active in v0.4.2+ — actually dispatch. Q4 (fact pattern) is active in v0.5.0+ and Q4 (law lookup) is active in v0.5.2+ — actually dispatch. Q5-Q6 are not yet available — see Step 4.
主管機關函覆 (authority-letter) — pure-LLM 函覆 drafting with canonical-§-gated citations
合約違約 (contract-breach) — thin classifier + handoff JSON to legal-contract-review (soft delegation; user manually 接力)
User confirms the auto-classified path before sub-protocol dispatch. → hand off to legal-incident-response skill.
Prerequisite check before handoff: same as Q2 — confirm legal-playbook/profile.yml exists (schema v2 — adds optional external_counsel + regulatory_authorities; backward-compat v1).
Q4 (fact pattern) — Issue spotting (active in v0.5.0+)
Keyword triggers: 「能不能做」/「是否合法」/「我們想做」/「分析一下」/「這樣可以嗎」/「合不合法」/「is it legal」/「can we」/「fact pattern」/「issue spot」.
Disambiguation: if the user's request is a literal law-text lookup (查 §227 / 找 110 年判決 / 法條), route to Q4-law-lookup instead (active v0.5.2+).
→ hand off to legal-issue-spot skill with the fact pattern as input.
Prerequisite check: NONE. legal-issue-spot is profile.yml-independent (input is fact pattern, no company identity needed).
Output expectation: 2-file in legal-outputs/<timestamp>-issue-spot/ (issues.md for 法務 + business.md for 業務). When ⚠️ low-confidence subsumption is detected, business.md trailer includes a /legal-research --query="..." handoff query string.
Q4 (law lookup) — Research (active in v0.5.2+)
Keyword triggers: 「查 §」/「§227 是」/「判例」/「法條」/「找判決」/「research」/「lookup」/「條文」/「函釋」/「what does §X say」.
Disambiguation: if the user's request is a fact-pattern question (能不能做 / 是否合法 / 我們想做 / 分析一下), route to Q4-fact (legal-issue-spot, active v0.5.0+).
→ hand off to legal-research skill with the query string.
Prerequisite check: NONE. legal-research is profile.yml-independent.
Plan-first 半互動: research emits plan.md then asks "Plan OK 嗎? Y/n" (classify-path precedent). User confirms → autonomous WebFetch loop (cap ≤ 5 rounds OR ≤ 30 fetches; early-stop ≥ 8 sources + ≥ 2 法源類型).
Output expectation: 4 files in legal-outputs/<timestamp>-research-<topic>/ (plan.md + state.json + research-memo.md for 法務 + executive-summary.md for 業務). Forced_stop emits ⚠️ "覆蓋未達 triangulation" warning block above §問題 in memo + REQUIRES §Escalation in summary.
Step 3 — Multi-intent handling
When the request matches multiple Q's (common: "review this contract AND update the playbook for it"):
Priority order:
Run the main task first
Then offer to follow up with the secondary
Example: user says "review this MSA, and the LoL fallback was wrong last time, let's fix it":
First: dispatch to legal-contract-review for the actual review
After review completes: prompt "Would you like to now revise the limitation-of-liability entry? /legal-playbook-author revise limitation-of-liability"
Why: running both in parallel costs context and may produce inconsistent state. Sequential with clear hand-off is cleaner.
Step 4 — Phase 4-5 "not yet available" path
For Q5-Q6 matches, the router:
Acknowledge the intent — tell the user "I see you want to "
Inform that the relevant skill is on the roadmap but not built yet:
The skill for that task is planned for Phase <N> per the roadmap
at legal-toolkit/ROADMAP.md. It is not yet available in this version.
Offer alternatives when possible:
For Q5 (lifecycle / regulation) — "No substitute yet; manual tracking + periodic re-review is the current path"
For Q6 (governance / DD) — "BLOCKED on the upstream prerequisite research note for 上市櫃 in-house Compliance. Estimated availability per ROADMAP §Phase 5"
Do not dispatch — the not-yet-built skill doesn't exist as an installable resource; pretending to dispatch would fail loudly
Step 5 — Ambiguous intent (no Q matches)
If none of Q1-Q7 match clearly, do not guess. Present the 6-cluster menu:
Menu prompt: 6-cluster menu (when intent is ambiguous)
Not-yet-available notice: explanation + alternative routing where possible
The router does NOT execute the sub-skill; it produces the dispatch + brief and lets the host runtime invoke the chosen sub-skill.
Output contract
✅ using-legal-toolkit complete.
Dispatched to: <sub-skill name> / "no dispatch (Phase 4-5 not yet)" / "asked clarification"
Intent recognised: <Q1-Q7 or unmatched>
Brief: <1-sentence summary of what the sub-skill should do>
