Searches the domestic courts of 122 jurisdictions — 153 databases, 49 automated — for extradition and arrest-warrant surrender decisions, each in its own language and vocabulary. Answers the question no commercial database does: how are OTHER executing states treating this requesting state, or this ground? Searching by requesting state localises its name per jurisdiction (AE becomes 'Emiratele Arabe Unite' in Romania, 'Emirati Arabi Uniti' in Italy), so the sweep finds what those courts actually wrote. Every hit passes a relevance gate; every search leaves a dated report, so the research is reconstructable months later. Use when asked what foreign courts have said about surrender to a given state, whether any European court has refused extradition on prison conditions, assurances or Article 3, for comparative extradition research, or to build a foreign-authority section of an extradition argument. Not for domestic case law of the user's own jurisdiction, and never a substitute for reading the judgment.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
scripts/xsearch.py), or work the coverage map by hand where no shell is available.A recurring problem in extradition defence and prosecution is showing how other executing states treat a given requesting state or a given ground: Rechtbank Amsterdam on prison conditions, German OLG and Bundesverfassungsgericht decisions on assurances, Irish High Court surrender judgments, Italian Cassazione, Polish SAOS. That material sits in a hundred-plus national databases, each with its own interface, language and vocabulary, and no commercial service searches them together.
This skill drives an open-source engine — 153 adapters, MIT licensed — that does.
It is not for the domestic case law of the user's own jurisdiction (use a national database or a commercial service), and it does not read, translate, or interpret the judgments it finds.
Every result is a lead, never an authority. The engine reports that a judgment exists and that its metadata matched extradition vocabulary. It does not know what the judgment holds. Before anything from here reaches advice, a pleading or a court:
on_topic means
extradition vocabulary appeared in the title or snippet. It is not a finding
that the case is about the user's point.One-off install, then search:
python3 scripts/xsearch.py install
# How are executing states treating Romania?
python3 scripts/xsearch.py search --issuing-state RO --countries NL,DE,IE
# A ground, in a state's own language, in its own courts
python3 scripts/xsearch.py search "detentie omstandigheden" --countries NL
# Non-arrest-warrant vocabulary — third-state extradition
python3 scripts/xsearch.py search --issuing-state TR --mode extradition
# Narrowed by date
python3 scripts/xsearch.py search --issuing-state PL --countries NL,DE --since 2023-01-01
Supporting commands: preview AE --countries RO,IT,PL (what a requesting state
is actually searched as), sources --countries NL,DE (which databases exist and
their status), runs (past searches), show <run-id> (a past report in full).
Options: --mode both|eaw|extradition, --since / --until, --limit N per
database, --top N printed, --include-manual, --no-expand.
Without a shell — in an assistant that cannot run Python — do not pretend to
sweep. Load reference/jurisdictions.md, identify the databases that cover the
executing states in question, and work them one at a time with whatever browsing
is available, using the localised vocabulary from preview's logic: the
requesting state's name in that jurisdiction's language, plus that
jurisdiction's extradition terms. Say plainly that this is a partial search.
Scope it. An unconstrained sweep hits every database, and one source
(pl-saos, Poland) takes about 98 seconds on its own while every other adapter
answers in under five. Name the executing states whose practice is actually
needed. If Poland is wanted, warn the user about the wait rather than letting a
90-second silence read as a hang.
Search by requesting state, not by keyword, when the question is about a
state. --issuing-state RO localises "Romania" into each jurisdiction's
language and combines it with that jurisdiction's extradition vocabulary in the
source's own query syntax. A free-text search for "Romania" finds far less. Run
preview first to show the user what will be asked — and if it warns that
babel is missing, stop and install it: without it, localisation silently
degrades and every requesting-state search narrows without saying so.
Read the arithmetic, not just the hits. "19 results — 8 on point, 10 off
topic" means the sweep worked and that source is noisy. "20 results, 0 on point"
usually means the database sorted by date and stemmed loosely, and the run
established nothing: widen --limit, or go at it by free text in the local
language.
Watch for deep-link sources. 104 of the 153 databases cannot be automated.
Normally they are skipped. But if every database selected is deep-link only —
several jurisdictions have nothing else — they are returned anyway, and a "hit"
is a link to a court's search page, not a decision. Check the ACCESS column
in sources before treating a thin result as a nil return.
Then do the real work. Open the judgment. Get it translated if it will be relied on. Test whether the foreign court's reasoning survives on facts like the user's — a refusal resting on 2019 prison-monitoring data does not carry itself into a later year without the intervening material.
xsearch.py writes a dated markdown report and a JSONL file per run, indexed in
runs.jsonl: what was asked, which databases answered, which failed, and every
hit with its relevance verdict. This exists so that months later the user can say
where a citation came from without re-running the sweep. Quote the run reference
in the case file.
The engine queries public court databases on a deliberately low-volume footing: one request per second per host, an honest User-Agent, and no automation at all of sources whose terms bar it. An advisory lock prevents two sweeps at once.
Do not parallelise it, loop it unattended across a list of states, or raise
--limit into the hundreds to bulk-collect. Several of these databases will
block on far less, and they are a shared resource for every practitioner who
does this work. If a user asks for bulk harvesting, decline and explain why.
| Path | What it holds |
|---|---|
scripts/xsearch.py | Installs and drives the engine; applies the relevance gate; writes the report |
scripts/quality.py | The relevance gate, carried here so the skill works against any version of the engine |
reference/jurisdictions.md | Coverage map — every jurisdiction, its databases, automated or deep-link |
Engine: https://github.com/mateiclej-wq/eu-extradition-search (MIT).
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Creates an Agent Authority Charter for enterprise or regulated AI agents before deployment. Use this Skill when a user needs to define what an AI agent is allowed to do, who delegated authority to it, what actions are permitted or prohibited, when human approval is required, what evidence must be preserved, and how the agent can be suspended, revoked, or escalated.
日本語の概要は準備中です。原文の説明を表示しています。
EU AI Act Knowledge Engine — authoritative regulatory Q&A grounded in 70 official EU source documents (including the 2026 Commission draft guidelines on Art. 6 high-risk classification — general principles, Annex I, Annex III). Answers any question about the AI Act with article-level citations from the full regulation text, Commission guidelines, EDPB/EDPS opinions, codes of practice, harmonised standards, FRIA guides, incident templates, and sector-specific guidance. This skill should be used when the user asks about the "EU AI Act", "AI Act regulation", "Regulation 2024/1689", "KI-Verordnung", asks to "explain an AI Act article", "what does Article X say", "AI Act requirements", "AI Act penalties", "AI Act timeline", "GPAI obligations", "high-risk AI", "prohibited AI practices", "AI Act and GDPR", "fundamental rights impact assessment", "AI Act standards", "AI Act national implementation", "AI literacy", "serious incident reporting", "Digital Omnibus", "AI regulatory sandbox", or any question about EU artificial intelligence regulation. Also triggers on German terms: "KI-Gesetz", "KI-Verordnung", "Hochrisiko-KI", "KI-Kompetenz", "Grundrechte-Folgenabschaetzung", "GPAI-Verhaltenskodex". For assessment workflows that produce a classification decision rather than a knowledge answer, offer to run a structured risk-tier classification in-session.
日本語の概要は準備中です。原文の説明を表示しています。
This skill builds a structured audit trail of an AI-assisted task: what the tool was asked to do, what materials it was given, what it produced, how the output was verified, and what was ultimately relied upon. It documents the workflow for supervision and later review without ruling on privilege or disclosure, so the record stays accurate rather than self-serving.
日本語の概要は準備中です。原文の説明を表示しています。
Use this skill when the user wants an AI governance, legal-risk, privacy, compliance, procurement, or vendor-risk review of an internal AI use case, an AI product feature, an LLM workflow, or a third-party AI vendor. The skill asks intake and clarifying questions first when facts or evidence are missing, identifies required documentation and missing evidence, maps the use case to AI governance frameworks and applicable legal domains, and produces a preliminary or final governance review with scorecards, findings, owners, remediation actions, and follow-up questions.
日本語の概要は準備中です。原文の説明を表示しています。
Turn an interpretive-ambiguity audit of a legal text — contract, statute, regulation, or judicial opinion — into a polished deliverable. Produces a multi-page website (default), a single-page interactive site, a Microsoft Word document, a PowerPoint deck, or a LaTeX/PDF. Use whenever a user has a stress-test result, ambiguity audit, or "where will this be litigated" scenarios and wants to publish, present, or share them. Triggers on "publish the audit," "make a report from this," "turn this into a website / deck / brief / Word doc," "make a Netlify site," "build slides of these ambiguities," "render the scenarios," "package this stress test," "produce a LaTeX version," and similar. Pairs with the ambiguity-stress-test skill (the underlying analysis) but works on any structured or semi-structured ambiguity analysis. Visual design is opinionated but the user can override colors, fonts, and brand label. Most formats need Python and a writable filesystem; single-file HTML works where the host has neither.
日本語の概要は準備中です。原文の説明を表示しています。
Adversarially stress-tests a legal text — a contract, statute, regulation, or judicial opinion — for interpretive ambiguity: it finds the seams where the people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix. Use it whenever someone wants to pressure-test, red-team, audit, or find weak spots, loopholes, gaps, ambiguities, or drafting problems in a legal document; whenever a drafter wants to tighten a contract, statute, regulation, or opinion before it issues; whenever a litigator wants to mine an opinion or contract for arguments; or whenever someone hands over a legal text and asks where it will be fought over or for issue-spotting. Trigger it for contract review, statutory-ambiguity analysis, judicial-opinion scope analysis, and drafting QA — even if the user never says "stress-test" or "ambiguity."
日本語の概要は準備中です。原文の説明を表示しています。