pushary 1.8.0

package/data/cowork/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: pushary-cowork
+version: 0.4.2
+description: Phone notifications and human-in-the-loop for Claude Cowork through the Pushary connector. Use inside a Cowork session whenever you need a human and nobody is watching the session, such as before an irreversible or destructive action, before spending money, deploying, force-pushing or deleting, when blocked on a decision outside your authority, when running unattended and you hit a genuine ambiguity, when another skill's workflow says to confirm with the user, and when a task finishes or fails with nobody watching. Also use it when the user says things like ping me on my phone when this is done, ask me before doing anything risky, keep me in the loop while I am away, or notify me if you get stuck. Sends completion alerts, asks questions (yes/no, multiple choice, or free text) via push, and gets answers from connected devices. This Pushary connector is cooperative; it does not install native Cowork permission hooks. Pushary is a hosted service, $9.99/mo after a 3-day card-first trial.
+metadata:
+  tags: notifications, push, mcp, human-in-the-loop, cowork, claude, alerts, approvals
+---
+
+# Pushary for Claude Cowork
+
+Pushary is connected as a custom connector. It reaches the user on their phone, where confirm notifications can offer lock-screen actions; choices and text open the app. Use it proactively. Do not wait for the user to ask.
+
+## Ask in as few interruptions as possible
+
+Honor authorization already granted in this session. Ask only for a missing decision or an action outside that authorization, or when an enforced host policy requires it. A multi-step task alone does not require plan approval. Never ask again merely because the next authorized step deletes, deploys or publishes something. These skills guide the agent; supported hooks and runtime approval gates enforce policy. Do not bypass an enforced gate.
+
+Every question costs the user their attention wherever they are. Before a run of more than a step or two, work out where you will need a human and fold those points together: one `select` carrying the real options beats three `confirm`s in a row, ask once at a boundary rather than once per instance, and never ask what you can determine yourself from the task or from a tool call you can make.
+
+## When to reach out
+
+- **You need a decision or a clarifying answer.** Call `ask_user` instead of guessing or stalling. Use type `confirm` for yes or no, `select` for a fixed set of options, and `input` for free text.
+- **An action outside your existing authorization is risky or irreversible.** Deleting or overwriting files, spending money, sending anything external, bulk changes: call `ask_user` with type `confirm` first and wait for approval.
+- **Meaningful work finishes while the user is away, or they requested an alert.** Call `send_notification` with a short summary of what changed, and pass `context.type` as `task_complete`. That is what marks it a task update, and the user's setting for where task updates land can only route one that says so. Keep a reply channel open only for a specific unresolved decision needed to finish, as described below.
+- **You are blocked or hit an error you cannot resolve.** Call `send_notification` with `context.type` as `error` so the user knows, and `ask_user` if you need a decision to continue.
+- **Another skill's workflow says to confirm with the user.** That instruction assumes someone is watching the session. Often nobody is. Route the confirmation through `ask_user` so the run continues when they answer, instead of stalling on a prompt they never see.
+
+## Hand back with a way to reply
+
+The connector is the only channel between this session and the user's phone, and it carries only what you ask it to. A plain completion notice is one way traffic: once your turn ends nothing here is listening, so anything the user types back on their phone has nowhere to land. Pushary also cannot start a new Cowork task on its own, so a reply that says "now do X" reaches nobody unless you asked for it before you stopped.
+
+When a specific unresolved decision is needed before you can finish, keep the channel open:
+
+1. Call `send_notification` with `context.type` set to `task_complete` and `context.askQuestion` set to an `input` question, such as "Which of these two drafts should I publish?".
+2. Poll the returned `linkedCorrelationId` once with `wait_for_answer`, then follow its handoff.
+3. Act on the answer in this same session, then hand back the same way again if more work follows.
+
+Do not create a question just to keep the turn alive or ask for optional feedback after every result. Once this turn ends, tell the user to reopen Cowork for follow-up work.
+
+## How to wait for answers
+
+Read `answered`, `status` and `handoffAction` (falling back to `nextAction`) on every response. Only `pending` is live; expired, cancelled, missing and unavailable are not new timeouts. Follow the returned handoff rather than inventing a retry loop. Before moving a live question to the current chat, cancel it. If cancellation says `stop`, stop; if it loses a race, poll once for one second and honor the winning answer. Silence is never consent. A select or input value containing “yes” is answer data, not approval of a separate action.
+
+Delivery is controlled by the user's policy: `push_first` uses presence, `push_only` requests push every time, `notify_only` leaves the decision in the current client, and `terminal_only` avoids push. Do not override the mode or duplicate a question on every surface. The runtime owns delivery, expiry and settlement; do not claim that a reply can restart an ended agent turn.
+
+- If `ask_user` times out, call `wait_for_answer` once with the same question id. If it is still pending, cancel it before asking in the current client. If cancellation returns `handoffAction: "stop"`, stop. Otherwise, if cancellation returns false, poll once for 1 second and honor the answer that won the race.
+- On long tasks where the user might be away, prefer `send_notification` with `context.askQuestion` over a blocking `ask_user`. The user can answer from the notification page while the question remains live. Poll the returned `linkedCorrelationId` once when you need the result, then follow the returned handoff; do not promise an overnight wait or a reply after the turn ends.
+- Use `cancel_question` to retract a question that is no longer needed.
+
+## Answer surfaces and account boundaries
+
+| Surface | What the user can do |
+| --- | --- |
+| Mobile app | Answer confirm, select and input questions. Supported confirm notifications offer approve/deny actions on the lock screen; arbitrary choices and text open the app. |
+| Mac notch | Answer personal account questions with confirm, select, input and question-set controls, including keyboard controls. Presence and delivery policy determine when the phone is also reached. |
+| Slack | Answer through buttons, menus or text modals when the integration and intended recipient are configured. |
+| Browser | Open the decision page as a fallback; browser notification delivery requires permission. |
+
+Personal setup connects the operator's devices. For a Mac, install from https://pushary.com/download, sign in to the same personal account and connect your agents in the app. Run `npx @pushary/agent-hooks@latest cowork` for connector setup, then ask one harmless test question inside Cowork, answer it from Pushary, and verify Cowork receives the answer. CLI doctor checks do not verify a hosted connector. Test phone fallback while away from the Mac; do not infer delivery from a successful API call alone.
+
+Partner customers use scoped enrollment links issued by their application. Do not enroll them into the operator's account or send their decisions through personal tools. The Mac notch currently uses the personal account/session API; do not promise a Partner customer inbox on Mac. See https://pushary.com/docs/agents/embed for Partner setup.
+
+## Conventions
+
+- Reuse one opaque `sessionId` per Cowork task. Do not reuse it across parallel tasks or put credentials in it.
+- Pass `agentName` as `Claude Cowork - <task name>` on every call, so the user knows which session is asking and their dashboard groups the session correctly.
+- Keep questions short and decision-shaped. One sentence of context, then the ask. The user is reading a lock screen, not a report.
+- Do not ask through Pushary for things you can safely decide yourself. Reserve it for real decisions, risky steps, completions, and errors, so a ping always means something.
+
+## Setup and capability boundary
+
+Install the Pushary Cowork plugin to supply this skill and its remote MCP connector, or add `https://pushary.com/api/mcp/mcp` under Customize > Connectors. Sign in with the same Pushary account used by your phone and Mac. Enable the connector in the task and approve its tool access when Claude asks. For proactive behavior, use this skill or standing instructions under Settings > Cowork; do not rely on a repository memory file.
+
+Anthropic documents plugin hooks in supported Cowork versions. This plugin currently uses the cooperative connector and does not install or verify native permission hooks. Local and cloud Cowork tasks may have different capabilities; do not infer them from the product name. Native Claude permission prompts still need Claude’s own approval surface.
+
+## If the connector is missing
+
+If no Pushary tools are available in this session, the connector is not enabled. Tell the user once: Pushary is not connected in this session. Enable it under Customize, Connectors, or set it up at https://pushary.com/docs/agents/guides/claude-desktop. Then continue the task without it.

package/data/cursor-plugin/.cursor-plugin/plugin.json

@@ -0,0 +1,25 @@
+{
+  "name": "pushary",
+  "displayName": "Pushary — Control Panel for AI Agents",
+  "description": "Push notifications, human-in-the-loop questions, and permission gating for your AI coding agent. Get a push when a task finishes, answer the agent from your phone, and approve risky commands before they run.",
+  "version": "0.2.3",
+  "author": { "name": "Pushary", "email": "business@pushary.com" },
+  "homepage": "https://pushary.com",
+  "repository": "https://github.com/Pushary/cursor-plugin",
+  "license": "MIT",
+  "keywords": [
+    "notifications",
+    "push",
+    "human-in-the-loop",
+    "permissions",
+    "approvals",
+    "mcp",
+    "agent",
+    "control-panel",
+    "ask",
+    "alerts"
+  ],
+  "category": "developer-tools",
+  "tags": ["notifications", "approvals", "human-in-the-loop", "mcp", "workflow"],
+  "logo": "assets/logo.png"
+}

package/data/cursor-plugin/CHANGELOG.md

@@ -0,0 +1,70 @@
+# Changelog
+
+## 0.2.3
+
+- Approval text never hides part of a command. The value after a credential name is hidden only up to the first space, quote or piece of shell syntax, so `echo "password=" && rm -rf ~` and `eval TOKEN="x; rm -rf ~"` both show the `rm`. A private key block is hidden only when it holds nothing but the key.
+- Updates and Terminal hand an approval back to Cursor promptly. The gate no longer waits for a phone answer that Updates never asks for, and it withdraws the phone question before Cursor decides. An answer that arrives in that moment still counts.
+- A file change that goes back to the agent's own permissions is refused with the reason, because Cursor file hooks cannot show a local approval. Choose Every time for file changes you want to approve from your phone.
+- With no phone or other notification channel connected, a file change is refused with a message that says so. Shell commands and MCP calls still open Cursor's own prompt with "No device connected, approve here."
+- Approval questions carry the repository and the tool name the gate judged, so routing and repository rules apply to the question as they did to the gate. A file change is asked about with its full path, so path rules and routing match it. A path longer than 80 characters falls back to the file type instead of making the question fail.
+
+## 0.2.2
+
+- Allow file edits when the server explicitly says the action is not gated.
+- Keep unresolved file checks denied with an accurate retry message, while shell/MCP hooks retain the native prompt.
+
+## 0.2.0
+
+The gate stopped carrying its own copy of the policy engine.
+
+Pattern matching, glob compilation, the destructive-command list and policy
+resolution all lived in this file, roughly two hundred and fifty lines of it,
+kept in step with the real engine by hand. That is how 0.1.1 happened: the copy
+matched on tool name alone, so every argument rule was invisible here. It also
+never gained the safe read-only allowlist, so `git status` reached your phone
+from Cursor and from nowhere else.
+
+The gate now asks the server, which runs the same engine as every other client
+over the same policy and mode state. There is nothing left to keep in step.
+
+- The safe read-only allowlist applies here now: ordinary read-only commands
+  stop reaching your phone.
+- A policy change takes effect immediately. The five-minute on-disk policy cache
+  is gone, along with the stale-cache fallback.
+- An unreachable Pushary hands the command to Cursor's own prompt, as before.
+  Nothing is ever denied because we could not reach the server.
+
+## 0.1.1
+
+Policy parity with the other agents. The gate matched rules on tool NAME alone, so
+every argument rule was invisible here: a `Bash(rm:*)` deny you had written did
+nothing, and `rm -rf` was auto-approved by a broad `Bash` allow. Cursor was
+strictly less safe than Claude Code for the same dashboard policy.
+
+- Argument rules now match: `Bash(git status)` exact, `Bash(npm test:*)` prefix,
+  and path-style globs, with the same precedence the hook uses.
+- The destructive ceiling applies: a command the classifier flags can no longer
+  auto-approve through a general bare-tool or wildcard rule. An explicit rule you
+  wrote still wins.
+- Repo-scoped rules are honoured. Identity is the normalized git remote, read from
+  `.git/config` as a file; credentials are stripped. `PUSHARY_REPO_KEY` pins it,
+  `PUSHARY_REPO_KEY=off` disables scoping.
+- Approvals now carry the command target and body, so the server can drop the
+  one-tap Approve on a dangerous call and the audit trail records Cursor
+  decisions at the same grain as every other agent.
+- `scripts/pushary-gate.test.mjs` mirrors the monorepo's policy tests, since the
+  matcher is vendored and cannot be imported.
+
+Verified against the canonical matcher over 1512 resolutions: zero cases where
+the gate is less safe. The remaining differences are all the safe-read-only
+allowlist, which is deliberately not vendored because it only ever loosens a
+decision.
+
+## 0.1.0
+
+Initial release.
+
+- MCP server (`send_notification`, `ask_user`, `wait_for_answer`, `cancel_question`, `list_sessions`) wired via `mcp.json`, key supplied at runtime through `PUSHARY_API_KEY`.
+- Always-on rule and full tool-reference skill so the agent uses Pushary proactively.
+- `beforeShellExecution` gate (`scripts/pushary-gate.mjs`, zero-dependency) that evaluates risky commands against your Pushary dashboard policy — auto-approve, the four approval modes, timeout actions, live mode override, and kill switch, scoped to the Cursor conversation. Falls back to Cursor's own prompt when Pushary is unreachable, and is fail-closed: a broken gate blocks rather than allows.
+- Commands: `/pushary-test`, `/notify-when-done`.

package/data/cursor-plugin/CONTRIBUTING.md

@@ -0,0 +1,40 @@
+# Contributing
+
+Bug reports, documentation fixes, runnable examples, and patches are welcome.
+Open an issue in this public repository, or fork it and open a pull request here.
+You do not need access to Pushary's private repository to contribute.
+
+## Start small
+
+Pick an unassigned `good first issue`, explain the change you plan, and include
+steps that another developer can use to verify it. For a bug, include the package
+and framework versions, your OS, expected behavior, and a minimal reproduction.
+Never include API keys, enrollment links, customer data, or private transcripts.
+
+For a JavaScript adapter, run `npm install`, `npm run typecheck`, `npm test`, and
+`npm run build` in your clone. Follow the README for Python or plugin-specific
+setup. Documentation changes should have working links and commands you tried.
+
+## How your patch ships
+
+This repository is a public mirror of a directory in Pushary's private monorepo.
+We review your PR here, then apply accepted changes upstream before publishing
+this mirror. A direct merge into the mirror could be overwritten by the next sync.
+
+The maintainer handling your PR will:
+
+1. Review the patch and discuss requested changes in the public PR.
+2. Apply accepted changes upstream, retaining author attribution in that commit.
+3. Run the relevant checks, release a package if needed, and sync this repository.
+4. Link the public sync commit and released version (when applicable) back to your
+   PR, credit your contribution publicly, then close it as shipped.
+
+Public sync commits squash private history, so upstream author attribution does
+not automatically appear in this mirror's GitHub contributor graph. The public
+PR and shipping comment preserve visible credit. An upstream-only patch is not
+considered shipped. If we cannot accept a change, we explain why on the PR.
+
+## Security
+
+Report vulnerabilities privately to aadil@pushary.com instead of opening a public
+issue. If this repository has a SECURITY.md, follow its disclosure guidance.

package/data/cursor-plugin/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Pushary
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/data/cursor-plugin/README.md

@@ -0,0 +1,113 @@
+<p align="center">
+  <img src="assets/logo.png" alt="Pushary" width="72" height="72" />
+</p>
+
+<h1 align="center">Pushary for Cursor</h1>
+
+<p align="center">A control panel for your AI coding agent. Get a push when work finishes, answer the agent from your phone, and approve risky commands before they run.</p>
+
+---
+
+## What it is
+
+Pushary connects Cursor to your phone. When the agent finishes a task, needs a decision, or is about to run something risky, it reaches you with a push notification. You answer from the lock screen and the agent keeps going. It works even when you have stepped away from your computer.
+
+## What it does
+
+There are three things.
+
+1. Notify. The agent sends a push when a long task finishes, or when a build, test, or deploy fails. The push can include what changed, the error, and suggested next steps.
+
+2. Ask. The agent asks you questions through push: yes or no, multiple choice, or free text. It waits for your answer. The bundled instructions guide the agent to use Pushary for questions. Native editor question dialogs are not automatically intercepted.
+
+3. Gate. Shell commands, file writes/edits/deletes, and third-party MCP calls reach your Pushary policy before execution. The policy can approve, deny, or wait for your answer. Cancelled or unverifiable decisions stop the action. Cursor’s generic file-tool hook does not enforce `ask`, so an unresolved file action is denied. File actions explicitly marked `not_gated` by the server proceed; shell/MCP hooks can hand off to Cursor’s prompt.
+
+## Install
+
+You need two things: the plugin, and an API key.
+
+### Option 1: Cursor Marketplace (recommended)
+
+Open the Marketplace panel in Cursor, search for Pushary, and click install. Then set your API key (see below).
+
+### Option 2: CLI
+
+This also sets up Claude Code, Codex, and Hermes if you use them.
+
+```bash
+npx @pushary/agent-hooks@latest setup
+```
+
+### Option 3: Manual MCP
+
+Add this to `.cursor/mcp.json` in your project, or `~/.cursor/mcp.json` for every project:
+
+```json
+{
+  "mcpServers": {
+    "pushary": {
+      "type": "http",
+      "url": "https://pushary.com/api/mcp/mcp",
+      "headers": { "Authorization": "Bearer ${env:PUSHARY_API_KEY}" }
+    }
+  }
+}
+```
+
+The plugin and CLI installer use the same decision service. Manual MCP-only configuration provides questions and notifications, but does not install approval or activity hooks.
+
+## Set your API key
+
+The plugin reads your key from the `PUSHARY_API_KEY` environment variable. Get a key at https://pushary.com, then add it to your shell profile:
+
+```bash
+echo 'export PUSHARY_API_KEY="pk_xxx.sk_xxx"' >> ~/.zshrc
+source ~/.zshrc
+```
+
+Install the Pushary app on your phone (or turn on web push) so the agent can reach you.
+
+## Troubleshooting
+
+macOS GUI apps do not read `.zshrc`. If Settings > MCP shows pushary in red after you set the env var, launch Cursor from a terminal where `PUSHARY_API_KEY` is exported, or set the variable system-wide so GUI apps see it.
+
+## What is in the plugin
+
+| Part | File | What it does |
+|------|------|--------------|
+| MCP server | `mcp.json` | Connects Cursor to the Pushary tools: `send_notification`, `ask_user`, `wait_for_answer`, `cancel_question`, `list_sessions` |
+| Rule | `rules/pushary.mdc` | Always on guidance so the agent uses Pushary on its own |
+| Skill | `skills/pushary/SKILL.md` | Full tool reference: parameters, examples, return values |
+| Hook | `hooks/hooks.json` and `scripts/pushary-gate.mjs` | Evaluates tool approvals and reports session/tool activity |
+| Commands | `commands/` | `/pushary-test` and `/notify-when-done` |
+
+## How the gate decides
+
+The hooks register the supported execution boundaries; your dashboard policy decides which actions need approval. No shell-command regex hides a tool from policy evaluation. Lifecycle hooks report session starts, turn completion, tool results, compaction, and subagent activity.
+
+Timeout approvals apply only after the configured wait actually elapsed. Short editor hook budgets can end a wait earlier; cancellation is attempted before handoff. An uncertain cancellation denies the action. Local plugin installation does not install hooks into remote or cloud agent environments.
+
+## Commands
+
+- `/pushary-test` sends a test push so you can confirm delivery.
+- `/notify-when-done` tells the agent to push a summary when the current task finishes.
+
+## Development
+
+`skills/pushary/SKILL.md` mirrors the Pushary skill that ships with `@pushary/agent-hooks`. Keep the two the same.
+
+Test the plugin locally before publishing:
+
+```bash
+ln -s "$(pwd)" ~/.cursor/plugins/local/pushary
+```
+
+Then reload Cursor with Developer: Reload Window.
+
+## Security
+
+This repository has no secrets. Your key is read at runtime from `PUSHARY_API_KEY`. The gate script has no dependencies and only talks to pushary.com. Read `scripts/pushary-gate.mjs` to see exactly what it sends. See `SECURITY.md` for details.
+
+## License
+
+MIT. See `LICENSE`.

package/data/cursor-plugin/SECURITY.md

@@ -0,0 +1,33 @@
+# Security
+
+## Reporting a vulnerability
+
+Email **security@pushary.com** with details and reproduction steps. Please do not open a public
+issue for security reports. We aim to acknowledge within 72 hours.
+
+## What this plugin sends
+
+The plugin connects Cursor to the Pushary MCP server at `https://pushary.com/api/mcp/mcp` using
+the API key you provide via the `PUSHARY_API_KEY` environment variable. No key is committed to
+this repository.
+
+The permission gate (`scripts/pushary-gate.mjs`) runs only on shell commands matching the regex
+in `hooks/hooks.json`. For a matched command it sends, over HTTPS to Pushary:
+
+- the command text,
+- the basename of the working directory (e.g. `my-repo`, not the full path),
+- an agent label (`Cursor - <project>`),
+- the Cursor conversation id, so the dashboard kill switch and per-session mode can target this session,
+- a machine id — the first 8 hex characters of a SHA-256 of your hostname (never the hostname itself).
+
+It also fetches your permission policy and mode from `pushary.com` (the policy is cached in the
+system temp directory for 5 minutes). It contacts no host other than `pushary.com`, has no
+third-party dependencies, and writes only that policy cache to disk. The full source is in this
+repository — read it before installing.
+
+## Fail-closed by design
+
+The gate is configured `failClosed: true`. If the gate cannot produce a decision (crash,
+timeout, invalid output), Cursor **blocks** the matched command rather than letting it run
+unapproved. When Pushary is reachable but you don't answer in time, it falls back to Cursor's
+own in-editor approval prompt.

package/data/cursor-plugin/commands/notify-when-done.md

@@ -0,0 +1,14 @@
+---
+name: notify-when-done
+description: Send a Pushary push summarizing what changed when the current task finishes.
+---
+
+When you finish the current task, send a Pushary push notification so the user knows it's done — even if they have stepped away from the editor.
+
+Call `send_notification` with:
+- `title`: a short summary (under 60 chars) of what was completed
+- `body`: one line on the outcome (under 200 chars)
+- `agentName`: `"Cursor - {project}"`
+- `context`: `{ type: "task_complete", summary, filesChanged, nextSteps }`
+
+Send a single notification for the task. If the task fails instead, send `context.type: "error"` with `errorMessage` and the file where it failed.

package/data/cursor-plugin/commands/pushary-test.md

@@ -0,0 +1,13 @@
+---
+name: pushary-test
+description: Send a test Pushary push notification to confirm notifications are working.
+---
+
+Send a test push notification with the Pushary `send_notification` tool so the user can confirm delivery on their phone.
+
+Call `send_notification` with:
+- `title`: "Pushary test"
+- `body`: "If you can read this on your phone, Pushary is working."
+- `agentName`: `"Cursor - {project}"` (use the current project folder name)
+
+Then tell the user it was sent and to check their device. If the call fails, report the error and remind them to set the `PUSHARY_API_KEY` environment variable and sign in at https://pushary.com.

package/data/cursor-plugin/hooks/hooks.json

@@ -0,0 +1,75 @@
+{
+  "version": 1,
+  "hooks": {
+    "beforeShellExecution": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 60,
+        "failClosed": true
+      }
+    ],
+    "beforeMCPExecution": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 60,
+        "failClosed": true
+      }
+    ],
+    "preToolUse": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "matcher": "Write|Delete|Edit",
+        "timeout": 60,
+        "failClosed": true
+      }
+    ],
+    "postToolUse": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "stop": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "sessionStart": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "sessionEnd": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "beforeSubmitPrompt": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "preCompact": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "subagentStart": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ],
+    "subagentStop": [
+      {
+        "command": "node ./scripts/pushary-gate.mjs",
+        "timeout": 10
+      }
+    ]
+  }
+}

package/data/cursor-plugin/mcp.json

@@ -0,0 +1,11 @@
+{
+  "mcpServers": {
+    "pushary": {
+      "type": "http",
+      "url": "https://pushary.com/api/mcp/mcp",
+      "headers": {
+        "Authorization": "Bearer ${env:PUSHARY_API_KEY}"
+      }
+    }
+  }
+}

package/data/cursor-plugin/rules/pushary.mdc

@@ -0,0 +1,40 @@
+---
+description: Pushary is connected. Use it to ask the user questions, notify them, and gate risky commands through push.
+alwaysApply: true
+---
+
+# Pushary
+
+Pushary is connected as an MCP server. It reaches the user on their phone, so use it on your own without being asked. Assume the user may be away from the editor.
+
+## Ask the user through Pushary
+
+When Pushary is connected, it is your channel for reaching the user. Any time you would stop and ask the user something, ask it through the `ask_user` tool and wait for the answer, instead of only asking in the chat. This covers all of your questions:
+
+- Yes or no. Use type "confirm".
+- Multiple choice. Use type "select" with 2 to 6 options.
+- A name, a path, a value, or other free text. Use type "input".
+- Approval of a plan or an approach before you start. Use type "select" with the options the user is choosing between, or "confirm" to approve a single plan.
+
+`ask_user` blocks and returns `{ answered, value, nextAction, handoffAction }`. Always set `context` to one line on what you are doing, and set `agentName` to "Cursor - {project}". If `answered` is false, follow `handoffAction` when present, otherwise `nextAction`: poll once when instructed, then cancel a live phone question before asking in the current chat. Never assume approval.
+
+If the user answers in the chat before the push comes back, call `cancel_question` with the correlationId before acting. If cancellation returns `handoffAction: "stop"`, stop. Otherwise, if cancellation returns false, poll once for 1 second and honor any phone answer that won the race.
+
+## Notify the user
+
+Use `send_notification` when something is worth the user's attention:
+
+- A task of 3 or more steps finishes. Use `context.type` "task_complete" with a short summary and the files changed.
+- A build, test, or deploy fails. Use `context.type` "error" with the error message.
+- A long job finishes, such as a migration, refactor, or generation.
+
+## Risky commands are gated for you
+
+Risky shell commands (rm, force push, history rewrites, database drops, deploys, systemctl, and similar) are sent to the user for phone approval automatically by the plugin's hook, following the user's Pushary policy. You do not need to ask separately for those. For anything else destructive that the hook might not catch, ask first with `ask_user`.
+
+## Keep it tidy
+
+- Keep titles under 60 characters and bodies under 200. Put detail in the `context` object, not the title.
+- Send at most 3 notifications per task unless the user asks for more.
+
+For the full tool reference, with every parameter, examples, and return values, see the pushary skill.