Harness content has no sync-from-source

[aug2uag]

What exists today

A harness's Skills are stored as literal file content: _skills_prepare (gateway) validates an uploaded {name, files:[{path, content}]} bundle and stores it verbatim (inline, or blob-offloaded past 48KB); _write_skills (runner) materializes exactly those bytes into the workspace each turn. There is no path anywhere in the gateway for a harness to instead point at an external source and have its content kept current automatically. Once uploaded, a skill is frozen until someone re-uploads it by hand.

The one place the gateway fetches content from a URL at all is _media_fetch (gateway/app.py:8585) — but that's per-turn, caller-supplied input (an image/video attached to a single message), not a standing, harness-owner-configured source the gateway would remember and re-pull on its own initiative. There's no precedent in this codebase for that second thing.

Why this is worth raising now

For a Skill — usually a handful of files, often edited directly in the console — re-uploading by hand is a reasonable default. It becomes a real limitation for anything larger and independently maintained: a real current" is a meaningful, ongoing need rather than a one-time paste. If harness-attached capabilities grow to include things shaped like that (a whole plugin directory, for instance, rather than a short Markdown skill), they'd inherit this same all-or-nothing-manual-upload limitation unless addressed at the Skills layer first, or explicitly designed around when that capability is added.

What this issue is asking for

A way for a harness's attached content to optionally carry a source reference instead of only literal content — e.g. a git URL + ref — with some sync point (on harness save, on a schedule, or an explicit "check for updates" action) that re-fetches and re-stores it. Not proposing a specific mechanism here; raising it to get direction on whether this is wanted at all before anyone builds it, since it's a materially different trust surface than upload — the gateway process would be making outbound fetches to an owner-supplied URL on its own, rather than only ever relaying content a request already contained.

[richard-epsilla]

Thanks for writing this up properly rather than just filing a feature request. The trust framing at the end is the part that matters most.

Context you may not have: the built-in skills already come from git. They live in their own repository, https://github.com/HarnessRouter/skills, and the image builds them in. HR_SKILLS_REPO and HR_SKILLS_REF are build args, install-skills.sh clones the ref and prints the commit it resolved to, and release CI passes an exact sha so two builds of the same tag ship the same catalogue. So "skill content comes from a git source" is already how most of the skills on any instance got there. What doesn't exist is the same thing for a source the harness owner picks.

We want it, and integrating with skills maintained on GitHub is the right direction. Skills that have their own repository, their own history and their own reviewers shouldn't have to be pasted into a form to be usable here. Your plugins PR sharpened this: a plugin directory is exactly the large, independently maintained, expects-to-track-a-source case, and it landed with the same copy-it-in-by-hand story.

One thing to pin down before anyone builds it, because it changes everything downstream: this should happen at harness configuration time, not at run time. A skill carries a source; you save the harness or press check for updates; we fetch, resolve the ref to a commit, and store the files in the harness exactly as an upload would. From then on nothing else changes. The runner still materializes bytes out of the harness record, a turn still touches no network for this, and running the same harness twice still gives you the same thing twice. The source becomes provenance and a refresh button, not a live pointer.

What we don't want is dynamic installation, where a turn resolves and pulls a skill while it runs. That trades reproducibility, offline behaviour and turn latency for convenience, and it makes the question "what code ran in that session" unanswerable after the fact. If that's what you had in mind, say so and we can argue about it, but I'd want a lot of convincing.

The other opinion I hold firmly: the gateway process shouldn't be the thing making the outbound request. It holds provider credentials and the secret store and sits inside whatever network the operator runs it in, and pointing it at a URL someone typed is the wrong privilege in the wrong place. That's an implementation detail of the sync job rather than a design constraint on the feature, and there are a few reasonable answers.

Two things worth deciding early: whether private repositories are in scope for the first version, since that means a stored credential and a real design conversation (my instinct is to leave them out at first, and support public repositories only), and whether check for updates is per skill or per harness.