A Cowork plugin is just a folder with a manifest, a handful of skills, and a list of connectors your team already trusts. The gap between 'we do this workflow manually every week' and 'we have a plugin for that' is smaller than most Sydney operators expect, and the payoff compounds every time a new starter installs it instead of being talked through the process by a colleague.
What actually goes inside a plugin
A plugin bundles three things together: skills (the step-by-step instructions Claude follows for a specific job, written in plain markdown with a clear trigger description), a manifest file naming the plugin and listing its components, and a suggested connector list so a new user knows what to authorise on day one. None of this requires writing code in the traditional sense. A skill is closer to a well-structured SOP than a script, which is exactly why a non-technical operations lead can own and update one.
Skills: markdown files with a trigger description and numbered steps, one skill per distinct job
Manifest: the plugin.json naming the bundle and listing its skills and suggested connectors
Connector list: which tools (Gmail, Notion, Xero, HubSpot) the plugin expects to be authorised
Optional slash commands: shortcuts that skip the trigger-phrase step for frequent jobs
Start from a real workflow, not a wishlist
The plugins that get used are built from a workflow someone already does badly by hand, not a wishlist of things AI could theoretically do. Pick the task that happens weekly, has a clear start and end point, and currently lives in one person's head. Write the skill as if you were training a competent new hire: what triggers this, what tools do you touch, what does 'done' look like, and what should never happen without a human checking first.
The build sequence that avoids a rewrite
Draft the skill first as a plain checklist, run it manually in a live Cowork session against a real example, and only then fold the corrected steps back into the skill file. Skipping straight to a polished plugin before testing the raw steps against a real task is the single biggest cause of a plugin that looks right and behaves wrong. Once one skill works reliably, add the next, and only bundle skills that genuinely belong together, three unrelated skills crammed into one plugin is harder to maintain than three small plugins.
What a Sydney consultancy actually shipped
A twelve-person Sydney bookkeeping practice built a three-skill plugin covering client onboarding checklists, monthly BAS reminder drafting, and a weekly aged-receivables chase list, bundled with Xero and Gmail connectors. Building it took a partner roughly six hours across two sessions, mostly spent testing the BAS reminder skill against three real clients before trusting it. The practice now installs the same plugin for every new hire in under ten minutes, replacing what used to be a half-day shadowing exercise worth roughly $400 in senior staff time per new starter.
Distribution without a marketplace listing
You don't need to publish anywhere to get value. A plugin folder can be shared directly, dropped into a shared drive, or version-controlled in a private repository your team pulls from. Publishing to a broader marketplace is a separate decision, worth making only once the plugin has proven itself internally across a few real users and a few real weeks, not before.
Internal-only: share the folder directly, fastest path to value
Team repository: version-controlled, good once more than one person edits skills
Public marketplace: only after internal proof, adds discoverability but also maintenance obligations
Keeping a plugin healthy after launch
A plugin isn't a one-off build, it needs an owner who reviews it when the underlying workflow changes, a new field appears in Xero, a connector gets deprecated, a step in the process shifts. Treat plugin maintenance the same way you'd treat updating a written SOP: whoever owns the process owns the skill file, and a quarterly ten-minute check against how the team is actually using it catches drift before it becomes a support headache. Practices that skip this step tend to find their plugin quietly stops matching reality within two or three months, and nobody notices until a new hire follows outdated steps.
Version control matters more than it sounds like it should. Even a simple dated backup of the skill files before a significant edit gives you a way back if a change breaks something a colleague was relying on. For a team of any size beyond a single operator, a shared folder with clear file naming beats emailing updated skill files around, and a proper git repository is worth the small extra setup once more than two people are editing skills regularly.
The honest starting point for most Australian small businesses is one plugin, three skills, tested against real work before anyone else touches it. Everything else, distribution, a manifest with extra metadata, a slash command shortcut, is worth adding once that first plugin has already saved someone real time.
