The operator's layer
skills · plugins · persistent memory · hooks — the four surfaces that make Cowork yours
Out of the box Cowork is a generic agent. The interesting version — the one that knows your project conventions, invokes your team's playbooks by name, remembers your past corrections, and gates risky tools through a hook — is the version you build on top of it. Four surfaces do the building.
Skills are reusable playbooks — a markdown file with a trigger and a body. Plugins are packaged extensions, from the marketplace or your private folder. Persistent memory is a file-based store the agent reads at the start of every session. Hooks are pre/post-tool shell commands wired into settings.json that fire deterministically around agent actions.
None of these are documented as "advanced." All four are foundational the moment you have two people running the same workflow. This module is how to think about each, with the file shapes that actually work.
// Anthropic's launch keynote — the skills + plugins demo. Watch on YouTube →
Anatomy of a skill
// audience: anyone who's written the same prompt twiceA skill is a markdown file with YAML frontmatter that tells Cowork when to load it and what it does. Once a skill exists, an operator invokes it by name (slash command) or it loads automatically based on a trigger phrase. Skills live in two places: ~/.claude/skills/ (personal) and .claude/skills/ in your repo (project / team).
The four pieces that matter:
name— the slash-command handle. Used as/cyberhawk-audit.description— the trigger heuristic. Cowork loads the skill when the user's phrasing matches. Write it as "Use when the user X / Y / Z"; vague descriptions auto-load when you don't want them.- Body — the playbook. Numbered steps that the agent treats as authoritative.
- "When NOT to" section — the negative space. Stops the skill from firing in scenarios you've already learned about. Saves more incidents than the playbook prevents.
Our team's skill library, as a real example. Fifteen skills in the repo, each one a playbook we used to write from scratch every time:
pickbits-daily-trends— daily AI-news digest generation, sourcing rules, dedup logicpickbits-daily-signal-reels— vertical reel composition with the avatar-over-screenshot gotchaspickbits-daily-stories-ig— IG Stories carousel rendercyberhawk-audit— the example abovefield-guide-commercial— long-form video pipeline with Veo/Whisperuniversity-genz-reel— Gen Z TikTok compositionindie-game-shipping-pipeline— manifest → sprites → Tauri → Steamworksroguelite-design— design framework + ROI rankingbrowser-game-perf— Canvas2D perf gotchas- …and six more.
Each one started as a chat I had three times before I noticed the pattern. The trigger language ("Use when the user…") is the part you tune over time — if a skill auto-loads when you don't want it, narrow the description.
Custom GPTs (ChatGPT): closest analogue. UI-driven creation, conversational; doesn't compose with filesystem or scheduled steps the way skills do.
Copilot Extensions: packaged as a publishable extension. More like a plugin (next workflow) than a per-team skill.
The trust boundary
// audience: team leads picking what to installPlugins are packaged extensions that ship more than a markdown file — bundled tool definitions, optional UI, sometimes code that runs locally. Two sources:
- Marketplace plugins — Anthropic-vetted, community-published, or first-party. Discoverable from Settings → Plugins.
- Private plugins — your team's internal tools. Loaded from a folder you control.
The pre-approval workflow we use for teams:
Audit before install
For any new marketplace plugin: who publishes it, what permissions does it ask, does it call out to a third-party endpoint? Five-minute read.
Pilot one operator
Have one person on the team install and use it for a week. Note where it fires, what it touches, whether the value matches the auth surface it asks for.
Approve / archive
Add to the team's approved-plugin list with a one-line note on what it's for. If it didn't earn its keep in the pilot, archive and document why.
Quarterly re-audit
Plugins update; permissions can grow. Re-read the manifest of every approved plugin once a quarter and remove anything that drifted.
Private plugins are the second source — the ones you build because no public plugin fits. Same trust model with one inversion: you are the publisher, so the audit is internal code review, not external read. Versioning, signing, and roll-out follow your team's normal release process.
Custom GPTs / GPT Store is the comparable surface for ChatGPT — one user installs per chat. Copilot Extensions ship through the GitHub Marketplace and follow GitHub's review process. The Cowork-specific piece is the side-by-side of marketplace and private folder — both load at startup with no toggle.
What to save (and what not to)
// audience: anyone past their tenth sessionCowork ships with a file-based memory system at ~/.claude/projects/{project}/memory/. The agent reads it at session start; entries persist across conversations. The good news: this is a real persistence layer. The trap: most people put the wrong things in it.
Memory has four useful types:
- User — who you are and how you work. Role, expertise, preferences. "Senior IT architect; new to React but ten years of Go; prefer terse responses."
- Feedback — things the agent should and shouldn't do. From corrections AND confirmations. "Don't mock the database in tests — last quarter's mock/prod divergence."
- Project — ephemeral facts with absolute dates. Deadlines, who-is-doing-what, in-flight initiatives. "Merge freeze begins 2026-03-05 for mobile release cut."
- Reference — pointers to systems outside the project. "Pipeline bugs tracked in Linear project INGEST."
What NOT to save:
- Anything derivable from the code — file paths, function signatures, project structure. Reading the repo is faster than recalling a stale memory.
- Git history —
git logis authoritative. - Debug solutions — the fix is in the code; commit message has the why.
- Current-conversation state — use task lists or plans, not memory.
The discipline: memory is for the surprising and the durable. If the next conversation could derive a fact by reading the codebase or running git blame, don't save it. If a fact would be invisible without the memory entry — a past incident, a stakeholder preference, a corrected pattern — save it with why so you can judge edge cases later.
The biggest gotcha: memories age. A fact that was true in March may be false by November. Before recommending a recalled item, verify it against current state — the file still exists, the function is still named that, the flag is still on. Trust what you observe now; update stale entries.
# A real entry from our memory file --- name: pd_human_impact_lens description: PD human-impact lens = HARD GATE type: feedback --- Every story must answer "how does this affect ordinary people day-to-day?" in one sentence. Failures dropped, not demoted. H2 leads with second-person hook. Industry-insider / shareholder / procurement framing fails. Why: established 2026-05-10 after a week of finance-led stories testing flat on engagement. How to apply: every PD draft, every regen, every social variant.ChatGPT memory is conversational-fact-shaped — "user lives in Austin," "user prefers Python." Cowork's memory is operational — rules, gotchas, system pointers. Different intent. Copilot Workspace has no comparable persistent layer per-user; context resets per task.
Pre-tool, post-tool, user-prompt-submit
// audience: anyone wiring automation around the agentHooks are shell commands the Cowork harness fires deterministically at specific events — before a tool call, after a tool call, when the user submits a prompt, when the agent stops. They live in settings.json and they run outside the agent's judgment. The agent can't skip them, override them, or fail to fire them.
Three hooks worth wiring on day one:
- Pre-Bash — intercept dangerous commands before they run. Block
rm -rfagainst parent dirs, refusegit push --forceto main, lognpm installcalls to an audit file. The agent's safety rails are belt; this is braces. - Post-Edit — run a linter or formatter every time the agent writes a file. Stops "your tests pass, your linter explodes" sessions.
- Stop — fire a notification when the agent finishes a long-running task. We pipe ours to a desktop notify so we don't have to glance at the panel.
Why hooks beat instructions. You can tell the agent "always run the formatter after editing" — and 95% of the time it will. The hook is the 5% backstop. For anything where the cost of forgetting is high (audit logs, safety checks, destructive command gates), don't rely on the agent's discipline; wire the hook and move on.
The harness layer matters because it's the part that doesn't depend on the LLM. When Cowork upgrades to a new model, your hooks still run unchanged. When you switch projects, the per-project settings.json reconfigures. Hooks are how an IT-Pro team imposes their operating discipline on top of whatever model is loaded today.
rm -rf ~ into a Cowork prompt. The hook intercepts. Big red banner: "Blocked by pre-Bash hook." Caption: "You don't have to trust the agent. You can verify."ChatGPT / Codex / Copilot Workspace don't expose a hook surface to end users. Anthropic's hook system is the differentiator here — if you need deterministic gates around agent behaviour, this is the only one of the four products that ships them as a first-class configuration surface.
Curating across people and time
// audience: teams of two or moreThree rules to keep the operator's layer from rotting:
- Skills live in the repo, not in someone's home folder. A skill that only Mark has is a single point of failure. Commit them to
.claude/skills/in the project tree and they ship with the codebase. - Hooks are per-project unless they're security-flavoured. Project hooks live in
.claude/settings.json; personal-or-global ones live in~/.claude/settings.json. The Bash-safety hook goes global; the post-edit formatter is per-project. - Memory is per-operator. Don't try to share it — people work differently and a shared memory file becomes the lowest common denominator. Share memories worth saving as docs or skills instead.
The trust boundary, restated: skills, plugins, memory, hooks are the four surfaces where you (the operator) tell Cowork what is true and what is required. Each is reversible — delete the file, rebuild from scratch. The discipline is treating them like the source code you ship; the failure mode is treating them like prompts you'll re-type next week.
The honest read
// audience: everyoneSkills, plugins, memory, hooks have a compounding cost: each one becomes something you maintain. Don't add one until a clear failure mode demands it:
- If you've only used the prompt once, write it as a chat. Skills earn their place after the third repetition.
- If the plugin's permissions exceed the value, archive it. Plugins are not free.
- If a memory entry would just restate something the codebase already says, skip it.
- If the hook is "the agent should X" — that's a system prompt, not a hook. Hooks are for things the agent cannot be trusted to do.
The right test: is this layer making the agent more deterministic, or am I just hoarding configuration? Determinism wins.
You curated the layer. We help you ship it across the team.
Module C04 of five in the Cowork for IT Pros track. If you want this built on your team's actual practice — with your skill library, your plugin curation, your hooks and memory hygiene — our advisory engagements are scoped for exactly that.
← Back to Cowork track ← C03 · Connect C05 · Govern →