{"id":18171,"plugin_id":"plugins_6a86c89122448191877aded354e4f25f","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:41.357Z","digest":"05fa8d16b4c389a7387b4a8886ccc418d9f2a595a06407dd16a10d93f7f993dd","against":null,"payload":{"name":"ai-hooter","description":"Use AI Hooter when the user explicitly asks to be hooted, called, summoned, or alerted, including persistent project-wide grants such as “use Hooter whenever you need me” and explicit revocations of that grant. Never use it for routine updates or without an explicit task or project authorization.","included_files":[{"relative_path":"scripts/hooter-cli.mjs","size_in_bytes":10242}],"skill_md_contents":"---\nname: ai-hooter\ndescription: Use AI Hooter when the user explicitly asks to be hooted, called, summoned, or alerted, including persistent project-wide grants such as “use Hooter whenever you need me” and explicit revocations of that grant. Never use it for routine updates or without an explicit task or project authorization.\n---\n\n# AI Hooter\n\nAI Hooter is an opt-in human-attention workflow for Codex on macOS. It plays a\nfunny local voice alert through the separately installed AI Hooter Mac app.\nThe pairing credential and all alerts stay on localhost.\n\n## Use the bundled helper\n\nResolve `scripts/hooter-cli.mjs` relative to this `SKILL.md` and execute it with\nthe Mac's installed `node` runtime. Never download or substitute another\nscript. Run commands from the user's current project so project-scoped\nauthorization is associated with the correct project.\n\nThe helper prints one JSON object. Treat `ok: true` as success. Every command\nthat can contact the local Mac app (`pair`, `status`, `forget`, `call`, and\n`acknowledge`) must be run with Mac-local or localhost access on the first\nattempt. Do not try those commands inside the restricted task sandbox first:\nit can block `127.0.0.1` even when the app is running and correctly paired.\nThe local-only `arm` and `disarm` commands do not need localhost access.\n\nIf a command was accidentally attempted without that access and the helper\nreports that it could not reach the local macOS app, retry the exact same\nbundled-helper command once using Mac-local or localhost access approval. Do\nnot download another helper, change the command, re-pair, or tell the user the\napp is offline before that retry. If an access-approved attempt fails, show the\nreturned message once and continue safely.\n\nFor every other failure, show the returned message once and continue safely.\n\n## Pair the Mac app\n\nPairing and authorization are separate. Pairing connects Codex to the local\nMac app; it does not grant permission to hoot.\n\nWhen the user explicitly asks to pair, connect, or set up AI Hooter, run:\n\n`node <helper-path> pair`\n\nTell the user to click **Allow** on the approval card opened by AI Hooter and\nwait for the command to finish. Confirm success only when the helper returns\n`ok: true`. A fresh successful pairing makes the Mac app speak its own pairing\nconfirmation. Do not send a separate `call`; pairing still grants no permission\nfor later Codex alerts.\n\nUse `node <helper-path> status` only when the user asks whether Hooter is\nconnected. Use `node <helper-path> forget` only when the user explicitly asks\nto forget, disconnect, revoke, or reset local pairing.\n\n## Authorization scopes\n\nAI Hooter is off by default. Do not infer permission from installation,\npairing, or ordinary status language.\n\nA request such as “Hoot me when this task finishes” authorizes only the named\ntask or condition. A request such as “Use Hooter whenever you need me for this\nproject” grants persistent project scope. For persistent scope, run:\n\n`node <helper-path> arm`\n\nThe bundled SessionStart hook restores that saved project authorization in\nfuture Codex tasks for the same project. Never carry it to another project.\n\nWhen the user explicitly revokes persistent project permission, run:\n\n`node <helper-path> disarm`\n\n## Deliver an authorized hoot\n\nWhen the authorized condition occurs, run exactly one command:\n\n`node <helper-path> call --event <event> --project <project> --summary <summary> --urgency <urgency>`\n\nAllowed events are `attention`, `decision`, `question`, `access`,\n`browser_handoff`, `approval`, `blocked`, `security_critical`, `review`,\n`complete`, and `summary`. Allowed urgencies are `normal`, `important`, and\n`critical`.\n\nKeep `project` between 1 and 80 characters. For ordinary events, `summary` is\nvisual dashboard context; the Mac app speaks its built-in or user-selected\nphrase, and metadata length must never block delivery. Use event `summary` only\nwhen the user explicitly asked to hear a completed-work summary; its supplied\ntext is spoken aloud, must be at most 700 user-visible characters, and must stay\nwithin four concise sentences.\n\nNever put source code, credentials, tokens, private customer data, or long\nerror output in a summary. Quote every command-line value safely. If a value\ncannot be represented safely, shorten or paraphrase it instead of exposing\nthe original data.\n\nPreserve the returned `hoot_id` until the user's next message. When the user\nreturns, acknowledging that matching summon is the first action of the new\nturn. Run this as the first tool action, before commentary, analysis, planning,\nother tools, edits, tests, or a user-facing response—even when the new message\nalso contains another request:\n\nMultiple Codex tasks and projects may have outstanding Hoots at the same time.\nEach task must retain only the `hoot_id` returned to that task. Never replace it\nwith a global “latest” ID or acknowledge an ID learned from another task.\n\n`node <helper-path> acknowledge --hoot-id <hoot-id>`\n\nRun that first tool action with Mac-local or localhost access on its first\nattempt. Wait for the helper result, then clear the remembered ID and continue\nwith the user's message. Never acknowledge an ID from another task. A\nreachability failure from an attempt that lacked Mac-local access is the one\nexception to the no-retry rule: make the required access-approved retry before\nclearing the ID. After an access-approved failure, show the returned message\nonce, clear the remembered ID, and continue safely without another retry.\n\n## Attention rules\n\nFor an authorized task or project, hoot before waiting for the user when\nmeaningful progress depends on the user doing, seeing, testing, choosing,\napproving, unlocking, signing in, handing over a browser, or supplying\ninformation. Completing the user's requested work is also an attention event\nwhen the user asked to be hooted on completion.\n\nTime the hoot at the attention boundary, never while autonomous work remains.\nFor completion or review, finish every edit, command, test, and verification\nfirst. Make the helper call the final tool action, then immediately send the\nfinished user-facing response. Do not continue thinking through the task,\nrunning tools, or making changes after a successful hoot.\n\nFor a question, approval, access request, or handoff, prepare the complete\nuser-facing request first. Make the helper call the final tool action, then\nimmediately send that request. Never hoot merely because work has started or\nwhile the user would return to an agent that is still working.\n\nDo not hoot for routine commentary or progress. Call at most once for the same\ncondition. A standing project authorization may be reused for later distinct\nattention conditions until the user revokes it.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}