How to Customise Claude Cowork: Global Instructions, Folder Rules, Skills, and Plugins

Most Claude Cowork users we have audited are leaving the majority of the product’s value on the table — not because they are using it wrong, but because they have never touched the customisation settings. Default Cowork is useful. Customised Cowork is what the eight-to-fifteen-hours-per-week productivity numbers come from.

Customisation in Cowork happens in four layers. Each one solves a different problem, and each one has a specific place in the settings UI. This post walks through all four, in the order we configure them for clients, with copy-paste templates you can adapt to your business in an afternoon.

For the broader context: our first 30 days rollout playbook covers when to do each piece, and our Plugins vs. Skills explainer covers what each layer actually contains.

The four layers at a glance

Order of configuration matters. We always do them in the order above.

Layer 1 — Global instructions

Global instructions are the one-time setup that pays off every session afterwards. They tell Cowork who you are, what you do, how you want it to behave, and what it must never do. Once set, you stop having to type the same context into every prompt.

Where: Settings → Cowork → Global instructions → Edit.

Best practice: keep it under 500 words. Anything longer dilutes the effect. Cover four things: your role, how you want output, file conventions, approval rules.

Template — adapt to your business:

I'm Sagar Jani, founder of Sandlabs (AI consulting and software for
B2B SaaS and Australian professional services).

How to work with me:
1. Read the relevant files before every task. Do not invent.
2. If anything is ambiguous, ask one specific clarifying question
   before executing. I prefer one good question to ten guesses.
3. Show a plan for any multi-step task. Run the plan only after I
   approve it. For single-step tasks, you can just do them.
4. Never delete files or send external communications (email, Slack,
   LinkedIn) without explicit approval in the same session.

Output style:
- Australian English (organisation, optimise, recognise).
- Plain prose. No marketing buzzwords (synergy, leverage, ecosystem,
  paradigm, holistic, robust, supercharge).
- Concrete numbers and named tools — never "significant time savings",
  always "6 to 8 hours per week".
- Tables where comparisons help. Avoid ASCII bullets when a table is
  clearer.

File conventions:
- Working folders are under ~/Documents/sandlabs/. Each client has
  their own subfolder. Each project has a README.md at its root —
  read it first.
- Reports go into the same folder as the source data, named
  YYYY-MM-DD-report-{topic}.md.
- Drafts go into a 'drafts/' subfolder. Final versions move to the
  project root only after review.

Safety:
- Treat anything under ~/Documents/sandlabs/clients/ as confidential.
  Do not paste client data into external tools.
- For anything financial, double-check sums and flag anomalies before
  writing to a spreadsheet.

Two principles inside this template are worth highlighting:

• "Ask one specific clarifying question." Without this instruction, Cowork tends to either make assumptions or ask three vague questions. The wording matters.
• "Show a plan." Multi-step actions in Cowork are where rollouts get bitten by the "deleted 11GB of files" type of incident. Forcing a plan-then-approve flow is the single biggest safety control you have.

Quick edits in-session: you can type Update my global instructions to add: [new rule] and Cowork will update them and confirm. Useful for capturing rules as you discover them.

Layer 2 — Folder instructions

Folder instructions are project- or client-specific context that auto-activates whenever Cowork is working in a particular directory. This is where the customisation gets genuinely powerful — Cowork inherits the right context for the right job without you having to specify it.

Where: right-click a folder in Cowork → Edit instructions. (Or set the active folder and edit from the settings panel.)

Best practice: use folder instructions for rules, not tasks. Standing constraints, not workflows. "Always include the X disclaimer" — not "do Y today."

Template — a client folder:

Client: AcmeCorp (mortgage broker, Melbourne, 8 staff).

Engagement context:
- AI Cowork setup sprint, signed off March 2026.
- Primary contact: Jane Smith, Operations Manager.
- Their CRM is Connective. Their accounting is Xero.

Voice and conventions for AcmeCorp:
- Their preferred salutation in client comms is "G'day [first name]".
- They send reports as PDF, not Excel. Cover page with their logo
  (in this folder under brand/logo.png).
- Compliance: ASIC credit licence holder. Any external comms
  referencing financial advice must include the disclaimer in
  brand/disclaimer.md.

Project boundaries:
- Anything in raw-data/ is read-only. Outputs go to deliverables/.
- The proposal-archive/ folder is reference material — read it for
  context, never modify.

Cadence:
- Weekly status report every Friday, format defined in templates/
  status-report.md.
- Monthly P&L summary first Monday of the month.

Template — a project folder:

Project: 30-day Cowork rollout — internal (Sandlabs).

What this project is:
- We are rolling out Cowork to our own team to dogfood the playbook
  we sell to clients.

Conventions:
- All Skills live in skills/. SKILL.md files only. Reference docs
  alongside, never inside SKILL.md.
- Override notebook is at override-notebook.md. Append, do not edit.
- Weekly review notes go into weekly/, named YYYY-MM-DD.md.

Boundary:
- Do not run any workflow against external systems from this folder.
  This is the planning and writing layer. Execution happens in
  separate per-tool folders.

The pattern: folder instructions answer the question "if I dropped a smart new hire into this folder cold, what would they need to know to act correctly?"

Layer 3 — Skills

Skills are reusable expertise — SKILL.md files Cowork loads on demand based on the request. Our Claude Skills guide covers the full structure, and our 15 Claude Skills for small business covers which to build first.

For the customisation pass: upload the Skills you have built (or installed) in Settings → Skills.

Two things to verify after upload:

1. Description matching. Read each Skill’s description field aloud. If you cannot imagine a request from your team that would trigger it, the description is too narrow or too vague. Rewrite.
2. Cross-references. If one Skill defers to another ("follow the brand-voice Skill for tone"), confirm the referenced Skill is also uploaded. Skills do not call each other automatically — Claude has to independently match both.

Team / Enterprise admins: Skills uploaded via Settings → Skills are per-user by default. To push a Skill to the whole organisation, deploy it via the plugin marketplace (Layer 4). There is no in-between option for "give this Skill to half the team."

Layer 4 — Plugins and the private marketplace

This is the admin layer. It only matters for Team or Enterprise plans, but it is the layer that turns Cowork from "a tool individuals use" into "infrastructure the company runs on."

Where: Admin settings → Customize → Plugin marketplace.

What you can do here:

• Curate the marketplace. Add Anthropic’s public plugins (HR, finance, design, engineering, operations, investment banking, equity research, private equity, wealth management) plus any partner or custom plugins you build.
• Per-user provisioning. Restrict visibility so each team only sees the plugins relevant to their role. The marketing team should not see the IB plugin, and vice versa.
• Auto-install. Push plugins to specific teams automatically on day one — no "install this thing" message in Slack required.
• Private GitHub sources (beta). Treat your plugins like any other code — version-controlled, reviewed, deployed from a repo.
• Company branding. Rebrand the Cowork home screen with your logo and accent colour. Small touch, but signals that this is your tool, not a generic SaaS.

Configuration order we recommend:

1. Install Anthropic’s public plugins relevant to your departments.
2. Build one custom plugin per department that bundles your Skills + the connectors they need.
3. Set per-user provisioning so each team sees only the relevant bundle.
4. Auto-install the bundle for any new hire as part of IT onboarding.

For the conceptual difference between plugins and Skills, see Claude plugins vs. Skills.

Slash commands and connectors (the supporting cast)

Two layers we have not covered yet, both of which fold into the plugin layer.

Slash commands are quick triggers for common workflows — /schedule for scheduled tasks, custom commands like /pipeline-review that a plugin can register. Cowork’s February 2026 update added structured form-based slash commands, so a /draft-offer command can pop a form (candidate name, role, salary band) and produce a polished offer letter. Build slash commands for any workflow your team triggers more than once a week.

Connectors are MCP integrations — Slack, Gmail, Microsoft Teams, Google Drive, HubSpot, Salesforce, Snowflake, and 30+ more. Configuration is per-user OAuth. The admin layer here is which connectors to approve org-wide. Don't allow every connector — restrict to the ones the business actually uses, and add new ones as workflows demand.

Admin-only features worth knowing about

For Team and Enterprise admins, three more settings are worth a look:

• OpenTelemetry support. Track Cowork usage, costs per user, and which connectors are being hit most. Useful for cost management and for spotting which Skills are actually getting used.
• Code execution and file creation toggle. Required for Skills with scripts. Off by default in some Enterprise configurations — turn it on or Skills cannot do their work.
• Capabilities toggle. Organisation-wide on/off for Cowork itself. Used during phased rollouts (enable for one department, then expand).

Order of operations — what to do first

If you are configuring Cowork from scratch for a team:

1. Global instructions — half a day. The 500-word template above, adapted.
2. Two folder instruction examples — half a day. One for a client folder, one for an internal project folder. The team can copy the pattern for everything else.
3. Brand voice Skill plus meeting notes Skill — one day. The two Skills every other Skill ends up referencing.
4. Department Skills (3–5 per department) — one to two weeks. Built from the override notebook your team is keeping during the rollout.
5. Private plugin marketplace — one day, once the Skills library is stable. Bundle Skills into department plugins and set provisioning.
6. Slash commands — ongoing. Build them as the team identifies workflows triggered weekly.

This is roughly the same shape as our 30-day rollout playbook, with the customisation steps mapped to specific weeks.

Common mistakes

Skipping global instructions. Most users never set them. The result: every prompt has to re-establish context, output drifts in tone, and the safety rules ("never delete without approval") are not there when they are needed.

Putting workflows in folder instructions. Folder instructions are for standing rules, not current tasks. "Always include the disclaimer" is correct. "Do the Friday report this week" is not — that belongs in a Skill or a chat prompt.

Building Skills before global instructions exist. Skills assume a base of behaviour. If global instructions do not establish that base (output style, file conventions, approval rules), every Skill has to re-specify it, and Skills become 200 lines of repeated boilerplate.

Provisioning every plugin to every user. Default-off, not default-on. Give each team only the plugins they need. Otherwise the marketplace becomes noise.

Forgetting to update. Customisation rots. We recommend a quarterly review of global instructions and active Skills — usually a 90-minute session to add new rules from the past quarter’s overrides, retire Skills that nobody used, and refresh descriptions on Skills that have drifted.

When to bring in help

DIY works for a 5–10 person team with standard tools. The templates above plus our Skills guide plus a week of iteration will get you to a working setup.

We get involved when:

• You want a department-grade configuration deployed in one to two weeks instead of one to two months.
• You need custom MCP connectors built for tools not in the marketplace.
• You need governance — version control over Skills, approval workflows, audit logs.
• You are deploying for 20+ users across multiple departments and want consistency without slowing each team down.

At Sandlabs, our AI consulting engagements cover global instructions design, custom Skill library, MCP build where needed, and plugin marketplace setup.

Tell us about your workflow →

Getting started this week

Three steps to move from default Cowork to customised Cowork by Friday:

1. Today (60 minutes): open Settings → Cowork → Global instructions. Paste the template above, adapt the role and conventions to your business, save.
2. Tomorrow (60 minutes): pick your most-used client folder. Right-click → Edit instructions. Paste the client-folder template, adapt, save. Watch how the next Cowork session in that folder behaves differently.
3. This week: if you have Team or Enterprise, open Admin → Customize → Plugin marketplace. Install the public plugin for your largest department. Set per-user provisioning so only that team sees it.

Customisation is the only part of the Cowork stack that compounds. Skills you build today still work next year. Global instructions written carefully today still work for the next person who joins your team. Spend the afternoon.

Explore our AI & Claude consulting services →