Skill library default ./library + direct execution without explicit opt-in

Start with argument parsing in src/webwright/skill_factory/route.py and direct execution in src/webwright/skill_factory/execute.py; compare the default-library behavior with the warning in src/webwright/tools/skill_use.py. Trace how a resolved skill.py is launched, then define the confirmation and library-location behavior against the suggested fix. Done means cwd is no longer the implicit default and first use of an unconfirmed library requires an explicit opt-in.

The skill-library commands resolve their library to ./library relative to the current working directory when SKILL_LIBRARY_ROOT is unset, and route executes what it finds there directly — no model in the loop, no confirmation step. Library entries are executable programs by design (skill.py files the project's own docs describe as shareable, committable artifacts), so the cwd default means "run the programs sitting next to wherever I happen to be standing".

Current code (main)

• src/webwright/skill_factory/route.py:166-167:

  p.add_argument("--library", default=os.environ.get("SKILL_LIBRARY_ROOT", "library"),
                 help="Path to the skill library (default: $SKILL_LIBRARY_ROOT or ./library).")
  

  library here is a bare relative path, so it resolves against the process cwd.

• src/webwright/skill_factory/execute.py:1,23-56 — the module's own docstring: "Direct execution: run an executable skill on filled params, no agent, no model." run_skill runs the resolved skill.py via subprocess.run([sys.executable, str(skill.resolve()), "taskspec.json"], ...) with no approval or trust prompt anywhere.

• src/webwright/tools/skill_use.py:60-67 warns when a relative library path resolves to nothing — the missing-library case is handled loudly, but a ./library that does exist in the cwd loads silently.

The footgun

Running python -m webwright.skill_factory.route "<task>" from a directory that merely contains a library/ folder — a cloned repo, an unpacked archive, a shared drive mount — loads and executes whatever skill.py files are in it, at the user's privilege, with no signal beyond the decision line the command prints. The intent is surely "my library, learned in earlier runs" (the examples ship --library "$WORKSPACE_DIR/../library" for exactly that). But an absolute or user-level default plus an explicit --library for "run a library from this directory" would keep the convenience while making "execute third-party programs" an affirmative act rather than a side effect of cwd.

This is a hardening request, not a bug report: sharing libraries is a designed feature, and a user who passes --library <someone else's dir> has asked for it. The gap is only the default — discovery by cwd plus zero-confirmation execution of whatever is discovered.

Suggested fix

• Default the library root to a user-level location ($SKILL_LIBRARY_ROOT, else something like ~/.webwright/library), never cwd; the shipped example invocations that pass --library explicitly are unaffected.
• On first execution against a library not seen before, print the resolved absolute path and require an explicit flag (--yes or an interactive confirm) — a one-time opt-in per library.
• Optionally record known libraries (path + a hash of their contents) so re-running a previously confirmed library stays frictionless while a changed or new one re-prompts.