{"id":52011,"plugin_id":"plugin_asdk_app_6ac82989899c8191bb6bffcc654ceb6d","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:48:17.781Z","digest":"ebebc98da527412c0122002fe2cdbb6e7d1d4f3df2f0dea171fb540ceed18291","against":null,"payload":{"description":"Use when the user wants to create, design, preview, host, publish, protect, or update a photography gallery or portfolio on spaces.pics. Also use for choosing among the Editorial, Masonry, and Immersive themes or checking a spaces.pics address. Do not use for photo critique, image editing, or changes to an unrelated existing website.","included_files":[{"relative_path":"scripts/upload-local.mjs","size_in_bytes":3993}],"name":"photography-website-builder","skill_md_contents":"---\nname: photography-website-builder\ndescription: \"Use when the user wants to create, design, preview, host, publish, protect, or update a photography gallery or portfolio on spaces.pics. Also use for choosing among the Editorial, Masonry, and Immersive themes or checking a spaces.pics address. Do not use for photo critique, image editing, or changes to an unrelated existing website.\"\n---\n\n# Spaces Photography Website Builder\n\nCreate a focused photography website in chat and publish it only after the\nuser has reviewed the content preview and explicitly asks.\n\n## User-facing conversation\n\nSpeak about the user's photographs and site. Keep skill files, tool names,\nsite IDs, schemas, file grants and implementation steps in the internal workflow.\nRoutine setup questions and publication choices are product interactions, not\npolicy explanations or exceptions. Ask them directly without citing this file,\nquoting its rules, or saying “the builder skill requires…” or “I must follow…”.\nUse plain product language if the host requires an initial capability announcement:\n“I’ll use Spaces to create your photography gallery.” Honor any separately\nrequired host permission explanation; do not add one to ordinary site setup.\n\nExamples:\n- Missing title: “What would you like to call your photography site?”\n- Draft ready: “Your gallery has 3 photos. [Preview your draft](URL).\n  Would you like to publish it?”\n- Saved contact edit: “Added your contact email to the draft. Publish the update?”\n- Inaccessible attachment: “Select your photos in the upload card to add them.”\n\nMention limitations only when they affect what the user can do next. For a\nlocal preview, say “This preview opens on your connected computer.” State this\nonce for the site; repeat only if asked or the destination changes. Describe a\nfailed action and the next useful step without narrating bridge or token details.\nDo not repeat storage, privacy, publication or permission explanations on every\nturn. Answer technical questions about the plugin when the user asks them.\n\n## Set up a site in chat\n\nComplete public photography sites in conversation.\nUse `photo_site_chat_*` tools. The focused fallback photo card is the only UI.\nExplain local-only access once when first sharing a local link.\n\n1. Ask “What would you like to call your photography site?” before saving any\n   new site, unless the user has already supplied its title. Do not invent a\n   title, introduction, About section or contact email. Keep initial setup short:\n   title, photos and theme (Editorial by default). Defer the optional About/email\n   question until after the first successful publication.\n2. Call `photo_site_chat_start` with the supplied `title`. It derives and checks\n   an available address automatically from the title, adding a numeric suffix\n   if needed. Tell the user the resulting address; do not require them to choose\n   one manually. Keep `draft.site_id` and the returned `draft.slug` for this site.\n   Reuse its ID on retries. No account is needed for setup or publication.\n   Keep the returned `edit_token` private during setup; pass it on every\n   site call, including upload-card calls. It grants editing access to just this\n   draft. Do not display it before publication or put it in a public URL.\n   A new site gets a new key. For edits use `photo_site_chat_get` with the exact\n   saved site ID; preserve existing fields, gallery IDs and photos.\n3. Save with `photo_site_chat_save`, `create_new: true`, the returned slug and\n   site ID, and the user's title. Saving does not publish. If another user took\n   the address before saving, call start again with the same title and use its\n   next available address, keeping the existing draft ID and editing key for the save.\n4. If attachments have actual `download_url` and `file_id` grants, use\n   `photo_site_chat_upload` after saving (1–10 photos per call). Never invent IDs\n   or turn local paths into URLs. The user's request to create a site with their\n   selected photos authorizes uploading those photos.\n5. If Codex supplies a readable local attachment path, use bundled\n   `scripts/upload-local.mjs inspect FILE`, then `photo_site_chat_prepare_local_upload`\n   with the saved site ID and actual metadata. Transfer its bytes with\n   `scripts/upload-local.mjs upload FILE TICKET_JSON_FILE`. Store the ticket\n   temporarily outside source control and remove it afterward. Do not print\n   ticket URLs, tokens or bytes in chat. Read-only execution may need permission.\n6. If the host supplies only inline images without download grants or readable\n   paths, call `photo_site_chat_choose_photos` for this saved site. Ask the user\n   to select their photos in the small upload card; explain attachment limitations\n   only if needed to clarify why selection is necessary. Do not ask them to reattach the same\n   way, scan unrelated temporary folders, or scrape transcripts. The card has\n   Select photos and Upload photos buttons. Upload is enabled\n   after selection; successful upload automatically continues in chat and never\n   publishes. Wait for that follow-up, then get the site and verify its actual\n   photo count. Failed uploads do not send a continuation.\n7. Call `photo_site_chat_get` to show saved copy and up to three thumbnails\n   in chat. Use `site.draft_preview_url` for the real draft-page preview when\n   supplied. It expires and must not be advertised as private to its holder only:\n   anyone with the signed link can view it until expiry. Never label `site.url`\n   as a working unpublished preview; that is the eventual publication address.\n8. Only after explicit publication approval, call `photo_site_chat_publish`\n   with the exact site ID. Return its URL. If local-only access was already explained for this site,\n   do not repeat it. After every successful publish, give the user the returned\n   `recovery_key` exactly as written and say: “Save this recovery key so you can\n   edit the site later.” Do not add warnings or explain security, accounts,\n   sign-in, or key loss unless the user asks.\n   When `first_publish` is true, also ask its `follow_up_question`.\n   Offer optional About text and a contact email, explaining that the email will\n   appear publicly. Do not repeat this offer on later publishes or upload failures.\n   Keep the site's ID and private editing key in this chat for future edits.\n   There are no accounts or login. The saved recovery key allows editing from a\n   future chat or device: call `photo_site_chat_get` with the saved key and no\n   site ID to recover the site record, then use the returned site ID for edits.\n   There is no server-side recovery if both the chat and saved key are lost.\n9. If the user wants About/email, collect only what they choose to add, fetch the\n   current site, and save the update preserving title, address, theme, galleries,\n   photos and other fields. Saving keeps the live snapshot unchanged; ask for\n   approval to publish the updated version unless their request already includes\n   that approval. Never republish merely because they answered the optional\n   question. Use `photo_site_chat_unpublish` only on explicit request.\n\nChat setup creates public sites. Password entry without a secret-input surface\nis not implemented; do not request or reveal passwords in chat. The upload card\nis the only UI needed for inaccessible attachments. Hosts that cannot display it\nstill need supported file access; do not claim uploads succeeded or switch to\nanother website product.\n\n## Privacy and access\n\n- Spaces processes originals in memory and never stores them. It retains only\n  display and thumbnail WebP variants.\n- Output image files contain no embedded EXIF. GPS and location fields are\n  discarded; other readable metadata is retained separately for the owner.\n- A site can be public or password protected. Do not call protected sites\n  “private”; anyone with the code can view them.\n- Never repeat, request in chat, log, or reveal a saved password. New password\n  setup is unavailable until the chat has an appropriate secret-input surface.\n- Use `photo_site_chat_unpublish` only for an explicit take-down request.\n- Use `photo_site_delete_photo` only for an explicit permanent deletion; it\n  removes both optimized variants but cannot affect the user's ChatGPT file or\n  original local file.\n\n## Boundaries\n\n- Do not invoke this plugin for photography education, critique, camera advice,\n  photo editing, image generation, or ordinary work on a different website.\n- Do not imply that save publishes, that an availability check reserves an\n  address, or that password protection is end-to-end encryption.\n- Never claim an upload or publication succeeded unless the tool result says it\n  did. If a chosen address is unavailable, ask the user for another choice.\n- The hosted product is offered without a paid hosting charge during this\n  release, but avoid unsupported permanence or uptime claims.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}