Use this whenever the user asks to mount anything — local folders, S3
buckets, S3-compatible services (Cloudflare R2, MinIO), or Adobe da.live
/ AEM Document Authoring repos. Read this skill BEFORE deciding which
backend to use; do NOT default to a local file picker when the user
names a remote service. Covers credential setup with profile-namespaced
`secret set` keys (e.g. `s3.aws.access_key_id`) or the extension Options
page, the right `mount --source` invocation per intent, and common errors
(EACCES on missing credentials, EBUSY on concurrent edits, EFBIG on
oversized files).
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
npx skills add https://github.com/ai-ecoverse/slicc --skill mount
Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
Use this whenever the user asks to mount anything — local folders, S3
buckets, S3-compatible services (Cloudflare R2, MinIO), or Adobe da.live
/ AEM Document Authoring repos. Read this skill BEFORE deciding which
backend to use; do NOT default to a local file picker when the user
names a remote service. Covers credential setup with profile-namespaced
`secret set` keys (e.g. `s3.aws.access_key_id`) or the extension Options
page, the right `mount --source` invocation per intent, and common errors
(EACCES on missing credentials, EBUSY on concurrent edits, EFBIG on
oversized files).
allowed-tools
bash, read_file, write_file, edit_file
Mount
The mount shell command bridges remote storage into the VFS. After mounting, read_file, write_file, edit_file, and bash (with cat, ls, etc.) all work against the remote source as if it were a local directory. Three backends:
Backend
Source URI
Auth
Local
(no --source)
OS file picker — cone-only, fails in scoops
S3
s3://<bucket>[/<prefix>]
Profile-namespaced secrets (s3.<profile>.*)
DA
da://<org>/<repo>[/<path>]
Adobe IMS bearer (reuses the Adobe LLM provider login)
Choosing a backend from user intent
When the user asks to "mount X", read the request literally before defaulting to local:
User says
Use this backend
"mount my Documents folder" / "mount /tmp"
Local — mount /mnt/documents
"mount this S3 bucket: s3://my-bucket/foo"
S3 — mount --source s3://my-bucket/foo /mnt/s3
"mount this R2 bucket"
S3 with a custom-endpoint profile (R2 is S3-compatible)
"mount the AEM DA repo for org/site"
DA — mount --source da://<org>/<site> /mnt/da
"mount this Adobe DA project" / "mount da.live"
DA
"mount this S3-compatible storage" (MinIO, etc.)
S3 with a custom-endpoint profile
If the URL scheme is s3:// or da://, the choice is unambiguous — don't ask. If the user gives a hostname or describes a service without a URL, ask one specific clarifying question (e.g. "Is this the AEM Document Authoring service at da.live, or a different system?") rather than offering a menu of generic options.
Don't default to local when the user mentions a remote service name.
Setting up credentials before the first mount
S3 / R2 / MinIO
S3 mounts read credentials from profile-namespaced secrets. Set them via the secret command before mounting. The agent never sees real secret values; only the server-side sign-and-forward handler does.
# AWS S3 (default profile)
secret set s3.default.access_key_id AKIA... --domain "*.amazonaws.com"
secret set s3.default.secret_access_key ... --domain "*.amazonaws.com"
secret set s3.default.region us-east-1 --domain "*.amazonaws.com"# Cloudflare R2 (uses a custom endpoint, requires path-style addressing for some setups)
secret set s3.r2.access_key_id ... --domain "*.r2.cloudflarestorage.com"
secret set s3.r2.secret_access_key ... --domain "*.r2.cloudflarestorage.com"
secret set s3.r2.endpoint https://<account>.r2.cloudflarestorage.com --domain "*.r2.cloudflarestorage.com"# Optional — only set this if R2 returns "Bucket name was not in expected format" at first read:
secret set s3.r2.path_style true --domain "*.r2.cloudflarestorage.com"
Per-profile keys: access_key_id and secret_access_key are required; region (default us-east-1), endpoint (custom host for R2/MinIO), session_token (for STS), and path_style ("true" for path-style addressing) are optional.
In CLI / Electron mode secrets live in ~/.slicc/secrets.env (or macOS Keychain via swift-server). In extension mode they live in chrome.storage.local and the secret command writes to it directly.
Adobe da.live
DA mounts use the Adobe IMS bearer token from the existing Adobe LLM provider — there are no DA-specific secrets to set. If the user has not logged into the Adobe LLM provider yet, the first mount will fail with EACCES. Tell them to log in via Settings → Providers → Adobe (or run oauth-token adobe) first.
Mounting
# Local (interactive picker, cone only)
mount /mnt/local
# S3 — bucket + optional prefix
mount --source s3://my-bucket /mnt/s3
mount --source s3://my-bucket/site --profile aws /mnt/aws
# Cloudflare R2 — same s3:// scheme, different profile (custom endpoint)
mount --source s3://my-r2-bucket/path --profile r2 /mnt/r2
# Adobe da.live — org + repo
mount --source da://my-org/my-repo /mnt/da
Useful flags:
--profile <name> — selects which s3.<profile>.* keys to use (S3 only). Defaults to default.
--no-probe — skip the mount-time HEAD bucket / GET /list probe. Use when you want the mount to land even if the source is temporarily unreachable; first read/write will surface any auth errors instead.
--max-body-mb <n> — override the per-mount body-size limit. Defaults: S3 25 MB, DA 5 MB. Files exceeding this throw EFBIG before bytes flow.
Lifecycle
mount list # show all active mounts
mount unmount /mnt/r2 # tear down (cache stays for next mount within TTL)
mount unmount --clear-cache /mnt/r2 # tear down + drop cached listings/bodies
mount refresh /mnt/r2 # re-walk the source and diff against cache
mount refresh --bodies /mnt/r2 # also conditionally re-fetch changed bodies
mount refresh prints a structured summary: Refreshed /mnt/r2: +2 -1 ~3 (47 unchanged, 0 errors). Use it after you know the remote changed externally and you want the local view to catch up before the 30 s TTL expires.
Index state and bounds (mount list)
Each mount is indexed in the background for fast file discovery and listings; mount list shows each mount's index state. The walk is bounded — defaults (raised 10×): max directory depth 400, max total entries 2,000,000. Two env vars override them: SLICC_MOUNT_INDEX_MAX_DEPTH and SLICC_MOUNT_INDEX_MAX_ENTRIES (an invalid value falls back to the default with a warning).
When a bound is hit the index is skipped (reads still work via the slow fallback) and mount list shows a distinct cause, so advise the right remedy:
directory nesting exceeded the depth limit → raise SLICC_MOUNT_INDEX_MAX_DEPTH or unmount.
mounted tree is too large → raise SLICC_MOUNT_INDEX_MAX_ENTRIES or unmount (this is not a cycle).
self-referential mount cycle detected → a real, confirmed cycle; unmount it.
index error: <message> → any other indexing failure.
Don't call a large or deep mount "cyclic" — only self-referential mount cycle detected means a true self-reference.
Reading and writing once mounted
Treat the mount path like any other VFS directory:
ls /mnt/da
read_file /mnt/da/index.html
write_file /mnt/da/new-page.html "<html>..."
edit_file /mnt/da/index.html # via the standard edit_file toolrm /mnt/da/old.html
Reads and writes use TTL + ETag caching (30 s default). Reads are zero-RTT within TTL. Writes use If-Match / If-None-Match: * for conflict detection.
Common error patterns
Error
What it means
mount: probe failed for s3://… — profile 'aws' missing required field 'access_key_id'.
The user hasn't set credentials yet. Walk them through secret set s3.<profile>.*.
EACCES: s3 access denied
Wrong credentials, wrong region, or the bucket policy denies the user.
EACCES: da access denied
IMS token expired or user not authed against the Adobe provider.
EBUSY: remote modified since last read — re-read and retry
Concurrent writer changed the file. Re-read with read_file and retry the edit.
EFBIG: body exceeds maxBodyBytes
File is over the per-mount size limit (S3 25 MB, DA 5 MB). Use shell tools (aws s3 cp) for very large files instead, or pass --max-body-mb <n> at mount time.
mount: cannot mount local directories from a scoop (no UI).
Local mounts need a user gesture. Either ask the cone to mount, or use S3/DA which work in scoops.
When asked to "explore" a mounted DA or S3 source
After mounting, prefer bash: ls over read_file for navigation — it's instant within the TTL window because the listing is cached. Only read_file files you actually intend to read; every read is a network round-trip on the first call.
For DA specifically: the /list endpoint doesn't include file sizes, so ls -l triggers one HEAD per file the first time, then caches. Subsequent ls -l within 30 s is free.
Don't
Don't suggest the user install a separate AWS CLI / da.live SDK — mount is the integration point.
Don't try to cd into a remote mount before mounting; bash's working directory is independent of mount setup.
Don't ask "do you have credentials" if the user has already named a service — try the mount first, surface the actionable error from the probe, and walk them through the specific secret set commands.
Don't fall back to a local mount if the user mentioned a remote service. Default to clarifying which remote backend, not which directory to pick.
