Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Pushary/pushary-skill --skill pushary-coworkgit clone --depth 1 https://github.com/Pushary/pushary-skillWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pushary/pushary-skill/pushary-cowork)<a href="https://agentmods.dev/skills/pushary/pushary-skill/pushary-cowork"><img src="https://agentmods.dev/badge/skills/pushary/pushary-skill/pushary-cowork.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00207 | $0.01285 |
| Opus 5 | $0.00103 | $0.00642 |
| Sonnet 5 | $0.00041 | $0.00257 |
| Haiku 4.5 | $0.00021 | $0.00128 |
Grade A, and why
pushary-cowork scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pushary for Claude Cowork
Pushary is connected as a custom connector. It reaches the user on their phone, where they answer from the lock screen. Use it proactively. Do not wait for the user to ask.
Ask in as few interruptions as possible
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 confirms 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_userinstead of guessing or stalling. Use typeconfirmfor yes or no,selectfor a fixed set of options, andinputfor free text. - You are about to do something risky or irreversible. Deleting or overwriting files, spending money, sending anything external, bulk changes: call
ask_userwith typeconfirmfirst and wait for approval. - A task finishes. Call
send_notificationwith a short summary of what changed, and passcontext.typeastask_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. If the user is likely to reply to what you hand back, keep a reply channel open as well, see below. - You are blocked or hit an error you cannot resolve. Call
send_notificationwithcontext.typeaserrorso the user knows, andask_userif 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_userso 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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 52 lines · 207 tokens per session scan A 3d461263a568
pushary-cowork is a skill published in the GitHub repository Pushary/pushary-skill (1 stars, last pushed 2d ago), licensed MIT. It adds 207 tokens to every session and 1,285 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
markifact-overview
Reference — what Markifact is, what the MCP server exposes, and the discover→inspect→run pattern. Always loaded into the performance-marketer agent.
safe-write-operations
Reference — rules for safely executing write/destructive operations against ad accounts. Always loaded into the performance-marketer agent.
mindstorming
Use before drafting any non-code knowledge-work deliverable, including strategic memos, business reviews, OKR defences, PRDs, decision docs, briefing docs, exec talking points, Slack messages to leadership, frameworks, post-mortems, one-pagers, BRDs. Triggers on asks like "help me write up X", "draft this memo", "what…
reviewing-docs
Use when the user has a finished or near-finished document (memo, business review, PRD, decision doc, briefing, comms, framework, talking points, post-mortem) and wants it pressure-tested before it ships, such as "review this doc", "poke holes in this", "is this ready to send". Works on any doc, not just…
deep-interview
Conducts a structured technical deep-dive to gather detailed requirements, constraints, and decisions from the user. Use when starting a complex feature or when the user wants to be asked structured clarifying questions before implementation.
diagnose
Diagnostic pipeline for complex/intermittent bugs. Uses diagnostics roles for Investigation, Verification, and Solution before Lead Programmer handoff. Use ONLY for non-obvious failures (root cause unclear, reproduction unstable, fixes reverted). NOT for trivial bugs with known cause — fix them directly.