Claude Code & Cowork: The Complete Ecosystem for Working with AI

Claude Code is Anthropic’s CLI agent. It reads your code, modifies your files, runs commands, manages your Git commits. So far, nothing dramatically different from a Cursor or a Copilot. What changes the game is the extensibility ecosystem that has grown around it: skills, hooks, subagents, agent teams, plugins. Claude Code is not a passive assistant. It is a platform on which you build your own workflows.

Here is what each building block brings in practice.

Skills: custom capabilities on demand

A skill is a Markdown file (SKILL.md) containing reusable instructions. When Claude Code loads it, it gains a new capability: deploying, auditing, scaffolding a component according to your conventions, running a test suite with a specific protocol.

Skills live in three places:

• ~/.claude/skills/ for your personal skills (available across all your projects)
• .claude/skills/ in the repo for skills shared with the team
• Inside plugins (more on that below)

There are two types. User-invocable skills are slash commands you trigger manually — /deploy, /review, /scaffold-component. Claude-invocable skills are background knowledge that Claude loads automatically when the context calls for it.

What makes skills powerful is that they are dynamic. You can use $ARGUMENTS to inject parameters, and the shell preprocessor !command to inject the output of a command at load time.

A concrete example — a /deploy skill:

---
name: deploy
description: Run tests, build, and deploy to production
user_invocable: true
---

# Deploy workflow

1. Run the full test suite: `npm test`
2. If tests pass, build the project: `npm run build`
3. Deploy to Cloudflare Pages: `npx wrangler pages deploy dist/`
4. Verify the deployment is live by checking the production URL
5. If any step fails, stop and report the error — do NOT continue

The advantage over a bash script: Claude Code adapts its behaviour when something goes wrong. A failing test does not produce a cryptic error message in your terminal — it produces an explanation of what broke and a proposed fix.

Hooks: automated guardrails

Hooks are actions that execute automatically at specific points in Claude Code’s lifecycle. Before it uses a tool (PreToolUse), after (PostToolUse), when you submit a prompt (UserPromptSubmit), when it stops (Stop), or when it sends a notification.

Three handler types exist:

• command: runs a shell command and uses its output
• prompt: sends a prompt to a fast sub-model for a decision
• agent: launches a full agent with tool access

The most immediate use case: preventing mistakes before they happen. A PreToolUse hook on the Bash tool can block a git push --force to main. A PostToolUse hook on the Edit tool can run a linter after every file modification.

Configuration example in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "handler": {
          "type": "command",
          "command": "eslint --fix $CLAUDE_FILE_PATH"
        }
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "handler": {
          "type": "prompt",
          "prompt": "If this command contains 'push --force' or 'push -f' to main or master, respond BLOCK. Otherwise respond ALLOW."
        }
      }
    ]
  }
}

Hooks turn Claude Code from an autonomous agent into an autonomous agent with rails. It is the difference between handing someone the car keys and handing them the keys with a GPS and speed limits built in.

Subagents: delegate intelligently

When a task is too large or too specialised, Claude Code can spawn subagents via the Task tool. Each subagent gets its own conversation, its own context, and can run in the background while the main agent continues working.

Several subagent types are available out of the box:

• Explore: read-only, fast, ideal for code search and investigation
• Plan: designed for architecture and planning, no file writes
• General-purpose: full access to all tools
• Bash: command execution only

You can also create custom subagents in .claude/agents/ with a YAML frontmatter. This is where it gets interesting: you can restrict available tools, force a specific model, or limit permissions.

---
name: security-reviewer
description: Reviews code changes for security issues
model: claude-sonnet-4-20250514
tools:
  - Read
  - Grep
  - Glob
allowedCommands: []
---

You are a security reviewer. Analyze the code changes for:
- SQL injection vulnerabilities
- XSS vectors
- Hardcoded secrets
- Insecure dependencies

Report findings with severity (critical/high/medium/low) and file locations.
Do NOT modify any files.

One limitation to know: subagents cannot spawn other subagents. The tree stays flat, which prevents infinite loops but requires you to think carefully about how you decompose tasks.

Agent Teams: orchestrate a swarm

Agent Teams take the concept a step further: multiple Claude Code instances work in parallel, coordinated by a team lead. This is an experimental feature, but already usable in practice.

The principle: a lead agent creates a team, spawns specialised teammates, and distributes tasks via a shared task list. Each agent can message the others, flag a blocker, or mark a task as done.

A typical use case: you have a full-stack feature to implement. The lead breaks down the work, assigns the frontend to one agent, the backend to another, and the tests to a third. All three work in parallel. When the backend agent finishes its endpoint, it signals the team, and the frontend agent can start the integration.

The core tools: TeamCreate to set up the team, TaskCreate for the task list, SendMessage for inter-agent communication, TaskUpdate for progress tracking.

It is powerful, but it demands a well-structured CLAUDE.md so that each agent has the necessary context without manual intervention.

Shared context: CLAUDE.md and memory

The CLAUDE.md file is the brain of the configuration. Claude Code reads it automatically at startup and refers to it throughout the session. It exists at multiple levels:

• Project (.claude/CLAUDE.md or CLAUDE.md at the root): code conventions, architecture, tech stack
• User (~/.claude/CLAUDE.md): personal preferences, global guidelines
• Local (.claude/CLAUDE.local.md): machine-specific configuration, not committed to Git

The .claude/rules/ directory lets you modularise instructions with separate files: testing.md, security.md, style.md. Each file loads as an additional rule.

Claude Code also has automatic memory. Between sessions, it retains patterns it learns about your codebase: naming conventions, test structure, formatting preferences. This memory accumulates and makes the agent more effective over time.

Practical tip: put the conventions that everyone must follow in the project CLAUDE.md (architecture, naming, stack). Put your personal preferences in your user CLAUDE.md (message verbosity, language, how to handle ambiguity).

Claude Cowork: the agent for non-developers

Claude Cowork is the graphical counterpart to Claude Code, integrated into Claude Desktop. It targets business profiles rather than developers: project managers, analysts, managers, consultants.

Cowork can browse the web, manipulate files, create documents (Word, Excel, PowerPoint, PDF), analyse data, and execute multi-step tasks. It runs locally in a virtualised environment, meaning it has access to your file system without sending your data to a remote server.

The plugin ecosystem is shared between Claude Code and Cowork. A document creation plugin works on both sides. This is what allows mixed teams (developers and business users) to work with the same tools and the same conventions.

Plugins: bringing it all together

Plugins are the packaging mechanism. A plugin bundles skills, hooks, custom agents, and MCP servers into a single installable package. Every element is namespaced: /marketing:brand-voice, /legal:contract-review.

Anthropic maintains official plugins on GitHub for several domains: legal, sales, marketing, data. The community publishes others. You can also create your own for internal workflows.

MCP (Model Context Protocol) integration is the layer that connects plugins to the outside world: databases, APIs, SaaS tools. An MCP server turns any data source into a tool that Claude Code can use natively.

When to use a plugin versus a standalone .claude/ configuration? If your skills and hooks are specific to one project, keep them in the repo. If you reuse them across multiple projects or want to share them with other teams, package them as a plugin.

How we use it

We use Claude Code daily on client projects. Our custom skills handle deployment workflows, technical documentation generation, and component scaffolding tailored to each project’s conventions. Our hooks enforce code quality before every commit. Subagents parallelise code reviews and security audits.

This is also what we teach in our training sessions. Not the theory of agentic AI, but the hands-on setup: how to structure an effective CLAUDE.md, which hooks to put in place from day one, how to break a project into tasks for Agent Teams.

The Claude Code ecosystem is evolving fast. But the fundamentals are stable: skills for capabilities, hooks for guardrails, subagents for parallelisation, and plugins for sharing. If you work with code every day, the investment pays for itself within a few days.