Claude Code in depth: from the terminal to an agent operating system

Claude Code is not simply a tool that writes code faster. It is a different way of organising work: an agent with access to the repository, terminal, tests and the tools you choose to connect. When configured with context, method, permissions and review, it can become a shared capability for an entire team.

At Impulsa3 we take this idea into broader territory with I3OS, our practical agentisation case study. I3OS was not created to accumulate bots or replace professional judgement. It was created to connect each client’s context with reusable methods, authorised data, tools and human review.

Claude Code is one of the pieces that makes this change easiest to understand. This article brings together the fundamentals, configuration, Skills, Hooks, MCP, subagents, automation, plugins and execution on your own computer. The thesis is simple: productivity does not appear when you give the model more autonomy, but when you design the system it works in more effectively.

1. What changes when you move from assistant to agent

A conversational assistant responds to what you give it. An agent can work with the environment you authorise. In Claude Code, that environment is usually a repository: files, commands, Git, tests, documentation and, if configured, external services.

• Chatbot: receives text and returns text. The user manually moves the information and executes the decisions.
• Copilot: suggests lines, functions or answers within a development interface.
• Agent: receives a desired outcome, inspects the context, uses tools, modifies artefacts and verifies what it has done.
• Agentic system: turns that capability into a repeatable, measurable, governed and reusable method for a team.

That is why Claude Code can explain a codebase, implement a feature that affects several files, run tests, analyse a CI failure, prepare a review or propose an architecture change. But it can also make mistakes at high speed. Access to more tools does not eliminate the need for judgement: it makes it more important.

This is the connection with what we mean by AI agents in business: useful autonomy is not a magical property of the model. It is the result of combining a goal, context, tools, permissions, verification and accountability.

2. The right mental model: explore, plan, execute and verify

The most common mistake is to open Claude Code and ask it to start programming before it understands the problem. In a real project, the professional workflow looks more like a mini engineering pipeline:

1. Explore

First, Claude should read the repository structure, locate the relevant files, understand how the project runs and identify existing conventions. At this stage we are not looking for code. We want it to build a mental model and ask questions.

2. Plan

Next, define the outcome, separate the tasks, identify dependencies and make the risks explicit. A good plan is not a list of generic phrases: it says what changes, what does not, how it will be checked and which decisions need approval.

3. Execute

Implementation happens in small steps. Claude can edit, run commands, read errors and correct them. The person should keep the goal visible, review the diffs and prevent a reasonable first solution from becoming a chain of directionless patches.

4. Verify and preserve

The work is not finished when Claude says it is finished. Run tests, linters, type checks, visual checks or business tests. The result should live in a commit, pull request, document or artefact that someone else can review.

Claude Code’s speed shows in execution. Quality is decided before and after: in the context it receives and in the verification we require.

3. First steps: how to get started without turning it into magic

The first session should take place in a real project, but with a low-risk task. The most useful sequence is:

1. Open the terminal in a repository you know and can restore with Git.
2. Ask Claude to explain the architecture and cite the files where it found each answer.
3. Request a small, explicit change, such as a test or a localised improvement.
4. Have it run the project’s checks and show you the diff.
5. Correct its assumptions before giving it a larger task.

Installation varies by operating system and authentication method. Follow the official Claude Code documentation for the current command. Afterwards, the important question is not “what prompt should I write?” but “what does it need to know to work like someone who has just joined my team?”.

A useful initial instruction would be: Explore the repository, explain how it runs, identify the risks of this task and ask me any questions you need before proposing changes. It is a simple way to make the agent understand before acting.

4. Context and configuration: the system starts in the files

The difference between a generic session and one that seems to know the project is persistent context. Claude Code can read project rules, personal preferences and technical configuration. Each piece has a different function:

CLAUDE.md: less documentation, more decisions

A useful CLAUDE.md is not an endless manual or a copy of the framework’s public documentation. It is where you write down the things Claude should not have to guess: how to start the project, which commands pass in CI, which patterns are considered correct, which directories it must not touch and why an apparently strange decision exists.

In I3OS we apply a similar separation: Project = the context it remembers; Skill = the method it knows how to apply. In Claude Code, the project supplies the concrete reality and Skills turn the team’s experience into an activatable capability.

Permissions: graduated autonomy, not YOLO mode

Claude Code can read, edit, run commands and connect to services. Each permission expands capability and also the risk surface. Professional configuration starts with the minimum necessary:

• Allow read and test commands before destructive commands.
• Restrict access by command, directory, domain or tool type.
• Keep real credentials out of the repository, prompt and logs.
• Require human approval to publish, delete, deploy, send messages or touch sensitive data.
• Review permissions periodically: what was exceptional often becomes permanent.

Autonomy should increase through evidence, not enthusiasm. If a task fails unpredictably, the answer is usually not to give it more permissions. First improve the context, method or verification. This is also one of the conclusions from our work on human oversight.

5. Skills: turning team knowledge into a reusable method

A Skill is not a long prompt with a nice name. It is an operational recipe that explains when to use it, what context it needs, which steps it must follow, which tools it can use and how it should deliver the result.

A simple example would be a landing-page audit Skill:

---
name: auditar-landing
description: Revisa una landing en busca de problemas de conversión, accesibilidad y rendimiento.
---

1. Identifica el objetivo de negocio y la audiencia.
2. Revisa estructura, propuesta de valor y llamadas a la acción.
3. Comprueba accesibilidad, responsive y estados de error.
4. Ejecuta las pruebas disponibles y documenta la evidencia.
5. Devuelve hallazgos priorizados, no una lista genérica de opiniones.
6. No modifiques archivos sin pedir aprobación explícita.

The strength of a Skill is that it can improve with every use. If the agent forgets to check contrast, add it to the method. If a source is unreliable, set a rule. If a task needs client approval, turn it into a control point.

• Exploration Skill: understand a repository, client or account without touching anything.
• Production Skill: execute a procedure with clear inputs and outputs.
• Evaluation Skill: compare the result against a rubric and return evidence.
• Maintenance Skill: update documentation, tests or configurations when the system changes.

A Skill does not replace the professional: it packages a method so the professional can devote attention to difficult decisions. The more often a task is repeated, the more valuable it is to turn it into a shared, reviewable capability.

6. Hooks: the rules that do not depend on the model remembering

CLAUDE.md instructions guide the agent, but they are still instructions the model interprets. A Hook introduces deterministic automation at a specific point in the workflow: before a tool, after an edit, when a session ends or when the context changes.

• Run the formatter after editing.
• Run tests or static analysis after a change.
• Block secret patterns before saving a file.
• Record which tool was used and with what result.
• Notify that a task has finished without keeping a window open.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint",
            "timeout": 60
          }
        ]
      }
    ]
  }
}

The example is deliberately simple: the actual command depends on each stack and a slow Hook should not block the whole session. The practical rule is to put in Hooks what must always happen and leave in Skills what requires interpretation.

For a company, the decisive question is: which errors do we want to prevent by design, even if the model proposes an apparently correct solution?

7. MCP: when Claude stops working with a copy of the world

The Model Context Protocol connects Claude Code to external tools and sources through structured interfaces. Instead of manually copying a Slack conversation, document, issue or metric, the agent can query the authorised system and work with information closer to the source.

• Documentation and knowledge: consult a repository of decisions, a wiki or project documents.
• Product and operations: read issues, tasks, calendars or deployment status.
• Quality: open the application, capture a screen, query logs or run a check.
• Business: connect internal data and processes only with permissions, traceability and a defined purpose.

MCP is not an excuse to connect everything. Each server adds tools, context, permissions and another dependency. The right connection is the one that reduces the work of reconstructing information without creating a disproportionate risk surface.

In practice, start by connecting a source that has an owner, relatively clean data and a specific use case. Then measure whether it improves the result. If the information still needs to be copied, interpreted or manually validated, the problem probably will not be solved by adding another server.

The difference between a generic API and a contextual tool server is that the agent can work with an interface prepared for querying and acting. In the I3OS model, this layer is equivalent to connecting AI to the client’s real data and systems, rather than asking it to improvise with an outdated copy.

8. Subagents: dividing the work without losing accountability

A subagent is a specialised session that works in an isolated context and returns a summarised result to the main agent. It is useful when a task can be separated by objective: investigating a dependency, reviewing security, analysing logs, exploring part of the repository or running an independent evaluation.

• Explorer: finds where a feature lives and returns a map of files.
• Reviewer: analyses a diff against a specific rubric and changes nothing.
• Researcher: compares alternatives and documents trade-offs.
• Verifier: runs tests and provides evidence of what happens.

Subagents do not automatically multiply intelligence. They multiply work and cost if launched without a clear division. There is no point in putting five agents on the same files or asking them all to perform a generic audit. Parallelisation works when each agent has a small contract and a useful output.

For tasks that can modify code, Git worktrees make it possible to isolate branches and prevent several sessions from stepping on one another. Even so, final integration needs a shared review point. An agent can produce a change; the team decides whether that change belongs in the product.

The rule we carry over to I3OS is the same: each capability must have a purpose, a context source, a method and a responsible person.

9. Plugins and Agent Plugins: packaging capabilities so they can travel

When a team creates several Skills, Hooks, agents and MCP connections, a natural need appears: package them. Plugins make it possible to distribute a complete capability with a structure that other people can install, review and update.

The reference you shared from midudev’s LinkedIn post points to an important conversation: if each agent client packages extensions in a different format, teams end up duplicating work. The Agent Plugins Specification proposes an open, vendor-neutral contract for packaging components such as Skills and MCP servers.

Specification 1.0.0 defines a plugin.json manifest, a Skill structure with SKILL.md files and a schema for MCP configuration when the plugin includes it. This does not mean that every client automatically supports every plugin. It means the ecosystem has a common foundation on which to build portability and distribution.

mi-plugin/
├── plugin.json
├── skills/
│   └── auditar-landing/
│       └── SKILL.md
└── mcp.json

For Impulsa3, this development is particularly relevant. If a method for analysis, QA, onboarding or production becomes a well-documented capability, it should not remain tied to a single session or one person’s memory. A plugin can be the packaging; governance and judgement remain the organisation’s responsibility.

The specification presents itself as an open and neutral standard, developed publicly with the participation of different ecosystem actors. It is worth following as a signal of where agent distribution is going, without yet confusing a specification with a guarantee of complete interoperability.

10. Claude Code on your own computer: Remote Control and the compute debate

Remote execution introduces a distinction that should not be oversimplified. A Claude Code session can run on the provider’s cloud infrastructure, or it can run on your own computer and be controlled from another interface. They are not the same.

The Anthropic reference you shared, Run Claude Code sessions on your own compute, anticipates this direction. The current documentation describes it as Remote Control: you run Claude Code on your machine and use claude.ai or the mobile app to continue and supervise the session. The file system, local tools and MCP servers remain available in your environment.

# En una sesión nueva
claude remote-control

# O desde una sesión interactiva existente
/remote-control

This can be very useful for a team that needs to keep a private environment, internal tools or data it does not want to move to an ephemeral machine. But “runs on my computer” does not mean “no data leaves it”. The remote connection synchronises the conversation and activity so that you can view it from other devices. Review the data policy, permissions, physical access, laptop sleep settings and network availability.

The right decision depends on the risk and the work. An analysis that only needs a clean repository can run in the cloud. A task that needs your development server, local MCPs or internal data may require your own compute. In both cases, security is not delegated to the product name: it is designed through credentials, limits and review.

11. The bridge to I3OS: from a programming tool to a working system

The I3OS case helps show the difference between using Claude Code individually and building an organisational capability. In our system, the goal is not for each person to learn a different collection of prompts. The goal is for work to preserve context, apply a method, consult the right sources and produce a reviewable result.

• Project: separates the context of each client, product or initiative.
• CLAUDE.md and rules: establish the conventions and decisions that must remain in place.
• Skills: turn an expert’s individual practice into a shared procedure.
• MCP and connectors: bring real data and tools closer to the workflow.
• Hooks and permissions: ensure that certain controls do not depend on the model’s memory.
• Subagents: separate research, execution and evaluation when the task warrants it.
• Human review: preserves accountability for the client, business and external communication.

In the I3OS case study we explain how an SEO pilot became an architecture connecting operations, technology, content, client squads and internal adoption. Claude Code fits this vision because it makes it possible to iterate quickly on methods: document them, test them, connect them and correct them.

An isolated agent automates a task. An agentic system improves how an organisation learns and delivers value.

12. A practical case: building a frontend review capability

Imagine an internal capability for reviewing a landing page before delivering it to a client. An immature workflow would be to ask: “review this page and tell me if it is okay”. A better-designed system separates the work:

1. The Project supplies the business goal, audience, brand identity and client constraints.
2. A Skill defines the rubric: value proposition, hierarchy, conversion, accessibility, responsive behaviour and performance.
3. MCP makes it possible to query analytics, open the page in a browser and retrieve related issues.
4. A Hook runs linting and blocks secrets or basic errors before the agent delivers the result.
5. One subagent reviews accessibility and another compares the implementation with the design.
6. The responsible person receives a report with evidence, decides what to correct and approves the delivery.

The difference is not having a more sophisticated prompt. It is having designed a circuit where each piece has a function and the result can be reviewed. It is the same principle we apply to redesigning processes with AI: before automating, you need to understand the real process, its decisions, exceptions and quality criteria.

13. Governance: AI accelerates, but it does not sign

The more capable the agent, the more important it is to decide where its autonomy ends. At Impulsa3 we summarise this idea as follows: AI accelerates; it does not sign. The system can prepare, analyse and propose. Decisions affecting the client, business, sensitive data or reputation need a responsible person.

• Purposeful access: every tool should answer a concrete need in the workflow.
• Least privilege: the agent’s identity should have only the scope it needs.
• Accountable sources: data without a date, owner or known quality does not become reliable simply because it is connected.
• Review before execution: publishing, deleting, deploying, purchasing or communicating requires approval.
• Traceability: it should be possible to know what was consulted, what was changed, which tests were run and who validated it.
• Privacy by design: sensitive information should not enter a workflow simply because it is technically possible.

These rules connect with data quality, the AI committee and the need to move from pilots to controlled systems. Governance is not a bureaucratic layer that appears after innovation: it is part of the technical design.

14. How to implement Claude Code in a team without creating chaos

Responsible adoption can start with a single workflow and grow from evidence. This path is usually more robust than distributing licences and waiting for a methodology to emerge spontaneously:

1. Choose a repetitive, reviewable task. Research, documentation, QA, log analysis or maintenance are usually good starting points.
2. Define the outcome and the evidence. Before using the agent, decide what “done” means and how it will be checked.
3. Build the minimum context. Gather sources, commands, constraints, exceptions and owners.
4. Document the method as a Skill. Do not hide the right way to work inside a conversation.
5. Add deterministic controls. Use permissions and Hooks to prevent recurring errors.
6. Connect only the tools you need. Every MCP server should have a use case and an owner.
7. Measure and improve. Record time, quality, rework, errors, cost, interventions and team satisfaction.
8. Scale the capability, not the noise. If it works, package the method, train the team and decide whether it deserves to become a plugin or shared service.

The goal is not to prove that an agent can do many things. It is to prove that a specific capability improves the work without losing control. Once the process is understood and measured, it makes sense to increase autonomy or parallelise with subagents.

15. What not to do

• Do not start with the most autonomous mode. Start by observing how it reasons and which assumptions it makes.
• Do not fill CLAUDE.md with information the agent can infer. Reserve the context for decisions, limits and conventions.
• Do not connect MCP by accumulation. More tools can mean more cost, more noise and a larger attack surface.
• Do not run agents in parallel on the same files. Speed does not compensate for conflicts that are difficult to review.
• Do not measure success by the number of prompts or Skills. Measure it by results, quality and capacity freed up.
• Do not hide uncertainty. A report that distinguishes facts, hypotheses and questions is more valuable than a confident but fragile answer.

Frequently asked questions about Claude Code

Is Claude Code only for programmers?

It is designed around working with code and the terminal, but its model is broader: read context, apply a method, use tools and produce a reviewable result. It can be useful for technical documentation, QA, data analysis or operational automation whenever there is a clear environment and a responsible person.

Do I need to use Skills, Hooks, MCP and subagents from day one?

No. Start with a local session, a short CLAUDE.md and a task you can verify. Add Skills when the method is repeated, Hooks when controls must always run, MCP when you need external data and subagents when there is a genuine division of work.

Does Remote Control run Claude in the cloud?

Remote Control lets you control from the web or mobile a Claude Code session that continues running on your machine. It is different from a Claude Code session in the cloud. Even so, the conversation and activity are synchronised so the interfaces can stay connected, so you need to review your organisation’s data policy.

Does Agent Plugins already guarantee that everything works in every client?

No. The specification provides a common format for packaging extensions and a foundation for portability. Real compatibility depends on each client implementing the standard and on the specific capabilities it supports.

How do I know whether a process is ready to become agentic?

When you can explain its goal, sources, steps, exceptions and quality criteria, and when a second person can review the result. If nobody can describe how the task is done, it must first be redesigned and documented.

Conclusion: the multiplier is not Claude, it is the system

Claude Code represents a significant leap because it brings AI to where work happens: the repository, terminal, tests, services and processes. But the value is not in asking it to do more things without supervision. It is in designing a workflow where it can work with context, method and limits.

The pieces fit together like this: CLAUDE.md provides memory; Skills provide method; MCP provides connection; Hooks provide determinism; subagents provide specialisation; plugins provide distribution; Remote Control provides continuity; human review provides accountability.

That is what we are exploring with I3OS at Impulsa3: turning artificial intelligence into an organisational capability, not a collection of isolated tools. The ultimate goal is not to produce more code, more content or more automation. It is to free up capacity to understand the business better, solve complex problems and deliver more value to clients.

If you want to identify which processes in your company can become agentic, design an architecture with context and governance or support your team in adoption, we can help you turn the opportunity into a practical, measurable working system.