--- name: egnyte-file-delivery-and-sharing description: Prepare Egnyte files for an outside party or a colleague by checking exactly what will be exposed, reviewing existing links and comments, and creating a link or uploading a deliverable only after explicit approval. Use when the user asks to share, send, hand over, deliver, publish or give access to a file or folder, or asks what is already shared or who can see a document. --- # Prepare a file for delivery or sharing A handover answers one question: **who will be able to see what, and is that exactly what was intended?** The failure this skill prevents is sending the wrong version, or a whole folder, to someone who should see one file. Establish the exposure first, then act. ## 1. Confirm the target, the recipient and the intent Before touching anything, pin down with the user: - **The exact file or folder**, by full path. A search hit is not a confirmed target. If the user's wording is loose ("the contract"), resolve it with `search` or `list_filesystem_by_path` and show the matching paths back for confirmation. - **The recipient**, internal colleague or external party, and whether they need view-only or can change the file. - **The purpose**: a one-off review, an ongoing shared workspace, or a final deliverable. A final deliverable usually means a fixed version, not a live working file. If the target is a folder, say so plainly. Sharing a folder exposes everything inside it, present and future. Recommend sharing a single file unless the whole folder is intended. ## 2. Check what is already exposed Do this before creating anything new: - `list_links` to see existing links on the target. Note which are public, which are restricted, which have expiry dates, and which point at a folder rather than the file. - `get_link_details` on any link that looks relevant, to confirm its scope and recipients. - `list_comments` on the file. Comments often carry the real story: a note that a version is superseded, a reviewer's concern, a request to hold the file back. Report anything found: an old public link to a superseded draft is a finding to raise with the user before you add a new link beside it. ## 3. Check what the file actually is Confirm you are sending the correct version: - `get_file_content` or `summarize_document` to read the document's status, date and version markers (draft, final, "for internal use only", a redaction or confidentiality header). - `list_metadata_namespaces` and file metadata, where present, for classification or client tags that might forbid external sharing. Stop and raise the issue if the content contains internal-only material the recipient should not receive (privileged legal advice, pricing drafts, personal data, another client's name), or if a classification tag conflicts with an external share. Do not decide this for the user; state the conflict and ask. ## 4. Choose the smallest exposure that works Rank the options from least to most exposure, and recommend the lowest that serves the purpose: 1. **Share the one file** rather than its folder. 2. **Use a restricted link** (named recipients) rather than an open one. 3. **Set an expiry** on any external link, sized to the task (a review usually needs days, not months). 4. **Upload a fixed copy** as the deliverable when the working file will keep changing, so the recipient cannot see drafts being edited. 5. **Use view-only** where the recipient does not need to edit. Tell the user what each option exposes in one line, then recommend one. ## 5. Get explicit approval, then act Present the plan as a draft: the file path, the link type, the recipients, the permission level, the expiry, and any existing links to revoke or leave. Then state it plainly and wait. Every action below changes what outsiders can access, so each one requires the user's explicit approval in this conversation: - `create_link`: creates access for someone outside the current working set. Wait for the user's explicit yes before creating it. - `upload_file`: places a new file in the library, visible to whoever can see that location. Wait for the user's explicit yes before uploading. - `create_folder`: creates a new location that may change who sees what. Wait for the user's explicit yes before creating it. - `set_file_metadata`: changes classification or tags that other people may rely on. Wait for the user's explicit yes before setting it. - `create_comment`: visible to everyone with access to the file. Wait for the user's explicit yes before posting it. Switching the active account or workspace also counts as a change of scope. Wait for the user's explicit yes before switching. After approval, create the link or upload the copy, then read it back (`get_link_details`, or `list_filesystem_by_path` for an upload) to confirm the result matches the approved plan. Report any mismatch immediately. ## Common patterns and traps - **Sharing the folder when the file was meant.** The most common exposure error. Recheck the path after the link is created, not before. - **The "final" file that is not final.** A file named FINAL with a comment saying a revision is coming. Read the comments in step 2. - **Forgotten public links.** An old open link still works after the document was superseded. Check `list_links` every time, not only when the user asks. - **Expiry left blank.** An external link with no end date outlives the engagement. Propose an expiry and ask. - **Editable when view-only was intended.** Confirm the permission level explicitly; a default is not a decision. - **Search returns the wrong version.** Duplicates and old copies rank alongside the current one. Compare dates and paths before sharing. - **Confidential content inside a benign file name.** Read the content, not only the title. - **Metadata saying "do not share externally".** Treat it as a stop signal and ask, even if the user is sure. ## Output ``` Target: () Recipient: , , Existing exposure: Concerns: Recommended option: