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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
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>
