import-skill

name	import-skill
description	Import a skill from anywhere (local path, URL, GitHub repo, or a registry hit from skill_search) into durin through the security floor — scanned, gated, and audited before install.
metadata	{"durin":{"emoji":"📥"}}

Import Skill

Bring a skill from anywhere — a local path, a direct SKILL.md URL, a GitHub repo, or a registry hit — into durin through the security floor. Every import is scanned and gated before install; nothing third-party lands in skills/ unvetted.

When to use

• "import the skill at <path / url / repo>"
• "install <github repo> as a skill"
• "add this skill from <link>"
• "find me a skill that does X" — search the registries first, then import the pick

Flow

Drive everything through the skill_import tool. Never write to skills/ yourself.

0. No concrete source? Search first. When the user wants a capability but has no path, URL, or repo in hand, skill_search(query=...) returns ranked hits from the configured registries, each with a ref (e.g. clawhub:<slug>, github:owner/repo/<subdir>). Pick with the user, then feed that ref through this same flow — search never installs.

1. Resolve the source. skill_import(action="resolve", source="<what the user gave you>"). A source is rarely a direct SKILL.md: a repo may hold many skills, and a link may need a look. If the result carries an unresolved_reason, the source is fuzzy — investigate it: use web_fetch to read the page or browse the repo, work out the concrete source (a github:owner/repo/<subdir> or a direct SKILL.md URL), and resolve again.

2. Disambiguate. If resolve returns several candidates, show the user the list (name + ref) and ask which one(s) they meant via ask_user_question. Never import them all silently — the user usually means one.

3. Fetch into quarantine. skill_import(action="fetch", source="<the chosen candidate's ref>"). This downloads the skill and runs the scan. Read back verdict, findings, and needs.

4. Show the user, then gate. Surface the verdict and findings plainly with ask_user_question. The needs field says what the gate requires:

   • needs == "allow" → safe and trusted; you may install without extra ceremony.
   • needs == "confirm" → it carries code, is caution, or comes from a source not on the allowlist. Ask the user to confirm before installing.
   • needs == "block" → the scan found a serious risk (a prompt-injection, a fetch-and-execute, a destructive command). Install is blocked unless the user explicitly tells you to force it. Decide nothing about this on their behalf — pass override=true only when the user has said, in their own words, to install it anyway.

5. Install (or discard). skill_import(action="install", name="<the quarantined name>", confirm=<true if confirmed>, override=<true only on explicit user force>).

   • A refusal with refused == "exists" means a skill of that name is already installed. Show the user; re-run with replace=true only if they want to overwrite it.
   • Dependencies: with skills.install_policy: auto the skill's declared install specs run right after install; otherwise use skill_install_deps(name=...), which dry-runs the exact commands for the user to approve. To discard instead: skill_import(action="reject", name="<name>").

6. It is usable immediately. No restart or new session: the skill is indexed for memory_search at install time and skill_view loads it on demand. Offer to exercise it right away.

7. Check composition. The security gate says the skill is safe; it does not say it is well built. Compare the installed body against list_workflows: if it narrates by hand a procedure a local workflow automates (multi-source fan-out, gather, synthesize, verify), or walks a deterministic transformation that plainly wants a script, propose adapting it — keep its domain knowledge, delegate the orchestration to the workflow (or bundle the steps as a script) — and apply only if the user agrees. Never rewrite an import silently; the user chose this skill as-is.

Rules

• The gate is enforced in code: a dangerous skill will not install without override, a code / caution / un-allowlisted skill will not install without confirm, and an existing name will not be overwritten without replace. The tool refuses and tells you what it needs — relay that to the user; do not try to work around it.
• You surface the verdict and the reasons. The user approves. Trust is theirs to grant, never yours to assume.