Update to Heyzine Flipbooks

{
  "name": "flipbook-access-control",
  "description": "Configure access to Heyzine flipbooks and bookshelves. Use when users ask to enable or disable protection, set a shared password, grant individual access, revoke credentials, or audit available access data.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 401
    }
  ],
  "skill_md_contents": "---\nname: flipbook-access-control\ndescription: Configure access to Heyzine flipbooks and bookshelves. Use when users ask to enable or disable protection, set a shared password, grant individual access, revoke credentials, or audit available access data.\n---\n\n# Access control for flipbooks and bookshelves\n\nProtection has a publication mode and, for individual access, credential\nentries.\n\n## Inputs and boundaries\n\n- Resolve the target from an id, public URL, short id, or an unambiguous title\n  returned by `heyzine_list_flipbooks` or `heyzine_list_bookshelves`.\n- Set `type` to `bookshelf` for a bookshelf and `flipbook` for a flipbook.\n- If a title is ambiguous, show the candidates and ask which one. Never guess\n  the target, protection mode, password, email address, or current access list.\n- No MCP tool lists current access entries. If asked who has access, explain\n  that the current list must be checked in the Heyzine access settings.\n\n## Set the protection mode\n\nCall `heyzine_access_setup` with `id`, `type`, and one of:\n\n| Mode | Behavior |\n| --- | --- |\n| `everyone` | One shared password; requires `password` |\n| `users` | Only entries added to the access list can open it |\n| `disabled` | Removes the access gate and makes the publication public |\n\nOptional `text_user` and `text_password` relabel the fields on the login\nscreen. Send them only when the user supplies the labels.\n\nUse `everyone` for one password shared by all visitors. Use `users` when access\nmust be managed per person or credential. Before switching to `disabled`,\nstate the exact title and explain that the publication will become public,\nthen obtain confirmation unless the user already confirmed that exact change.\n\nNever invent a password. If one is required, ask for it or offer to generate\none; generate it only after the user accepts.\n\n## Grant individual access\n\nCall `heyzine_access_add` with `id`, `type`, `access_type`, and the required\ncredential:\n\n| `access_type` | Required input | Visitor flow |\n| --- | --- | --- |\n| `user_pass` | `user` and `password` | Username and password |\n| `google` | `user` email | Google sign-in |\n| `pass_only` | `password` | Password without a username |\n| `otp` | `password` | Predefined one-time password |\n| `email_link` | `user` email | Sign-in link by email |\n| `send_code` | `user` email | Generated code sent by email |\n| `email_code` | `user` email | Code delivered by email |\n\n`email_link`, `send_code`, and `email_code` require a plan with password email\nsupport. If the server rejects the plan, report its message and stop. Do not\nsilently switch to another access type.\n\nFor `users` mode, configure the mode before adding entries. For a batch, add\none entry per call and report each failure without changing the requested\ncredential type.\n\n## Revoke individual access\n\nCall `heyzine_access_remove` with `id`, `type`, and either `user` or `password`\nto identify the entry. Confirm the exact publication and entry when either is\nambiguous. Do not disable the entire protection mode as a substitute for a\nfailed removal.\n\n## Handle credentials\n\nDo not write passwords into files or artifacts unless the user explicitly asks\nfor a credential document. Repeat a supplied or generated shared password only\nwhen the user needs it for distribution. Never claim that an earlier\nconversation entry reflects the current server-side access list.\n\n## Report the result\n\nState the publication, resulting mode, and the entry added or removed. For a\nshared password, explain what visitors must enter without exposing unrelated\ncredentials.\n"
}