N1 — Operator Foundations
LEVEL 1 · MOONKEY LAB

Operator
Foundations

Build the foundation for operating Claude Code, GitHub, automations and AI systems. 8 practical modules with real exercises and concrete deliverables. No prior code. At your pace.

8
modules
~3h
total
0
prior code
100%
practical

Diagram — How the basic system works

YOU

Operator with context and objectives

Claude Code

AI in your local environment

CLAUDE.md + context + prompts

The instructions that guide the work

GitHub + files + automations

Where work lives and is versioned

Output: pages, systems, documentation, workflows

The concrete, deliverable result

Glosario rápido

12 términos

Consulta los que no conozcas. No hace falta memorizar ninguno ahora.

CLI

Command Line Interface. La terminal. Una pantalla de texto donde escribes comandos directamente al ordenador, sin botones ni menús. Es la forma más directa de controlar un sistema.

Terminal

El programa que da acceso a la CLI. En Mac es Terminal o iTerm2. En Windows es PowerShell o Windows Terminal. Desde aquí lanzas herramientas, navegas por carpetas y ejecutas scripts.

VS Code

Visual Studio Code. El editor de código más usado del mundo. Gratuito y extensible. Desde aquí escribirás, editarás y revisarás casi todos tus proyectos. Claude Code funciona dentro de él.

Git

Sistema de control de versiones. Registra cada cambio que haces en tus archivos con un mensaje de qué cambiaste y por qué. Si algo se rompe, puedes volver a cualquier punto anterior.

GitHub

Plataforma donde subes tus repositorios Git. Es la nube de tu código. Sirve para guardar, colaborar, publicar proyectos y conectar con herramientas como Cloudflare Pages o Vercel.

Repo

Repositorio. La carpeta de tu proyecto con todo su historial de cambios. Puede ser local (en tu ordenador) o remoto (en GitHub). Ambos se sincronizan con git push y git pull.

Commit

Un punto de guardado con mensaje. Cada commit es una foto del estado de tu proyecto en ese momento. "Añadí la sección de glosario." "Arreglé el bug del header." Úsalos con frecuencia.

API

Application Programming Interface. Una puerta de acceso a una herramienta o servicio externo. Le envías una solicitud y recibes una respuesta. Así los programas se comunican entre sí.

MCP

Model Context Protocol. Un estándar que permite a Claude conectarse con herramientas externas: sistemas de archivos, GitHub, bases de datos, navegadores. Convierte a Claude de asistente a operador de sistemas reales.

CLAUDE.md

Archivo de instrucciones para Claude. Le dice qué es el proyecto, cómo debe trabajar, qué hacer y qué evitar. Es el contrato entre tú y tu asistente IA. Sin él, Claude trabaja sin contexto.

Deploy

Publicar un proyecto para que esté accesible en internet. Convierte código local en una URL real. Para proyectos estáticos, plataformas como Cloudflare Pages, Vercel o Netlify lo hacen gratis y en minutos.

Cloudflare Pages

Plataforma de hosting gratuito para proyectos estáticos. Conectas tu repo de GitHub, configuras el comando de build y cada vez que haces git push, tu sitio se actualiza automáticamente.

M0

Prepare context

15 min

When done

You have a document with your operational context ready to give Claude at the start of any project.

Claude has no memory between sessions. Without context, it works generically. With context, it works precisely. This module teaches you to create that context before starting any task.

Why it matters

Most mediocre AI outputs don't come from the tool — they come from lack of context. A well-written document saves half an hour of corrections per session.

PRO TIP

Write context as if you were explaining your work to an expert contractor who just arrived. Dense, precise, no tutorials. One line per point. If it exceeds 30 lines, trim it.
PROMPT M0 Extract operational context from previous conversations
I have work history with you in previous conversations.

Extract a structured summary with these blocks:
- Name of my project or main work area
- Tools I regularly use
- My current objectives
- My preferred working style with AI
- What I DON'T want you to do when we work together
- Any working rules we've established together

Format: Markdown. Maximum 30 lines. No decoration or filler.
See exercise step by step

Objective

Create a personal operational context document you can give Claude at the start of any project.

Before you start

Open VS Code or any editor. No installation needed for this module.

Steps

  1. 1 Create a file called mi-contexto.md in a folder of your choice.
  2. 2 Write these sections: Who I am, Active projects, Tools I use, How I prefer to work, What I DON'T want Claude to do.
  3. 3 Be specific. One line per point. No unnecessary paragraphs.
  4. 4 If you have history on Claude.ai, use the prompt above to extract the context automatically.

Expected result

A mi-contexto.md file of 20–30 lines with dense, useful information about you and your work.

Common mistake

Writing too much. Context must be precise, not exhaustive. If it exceeds 30 lines, trim it.

How to know it's done right

You can give the file to Claude in a new session and it knows how to work with you without needing basic explanations.

Deliverable: mi-contexto.md
Claude understands your work without repeated explanations
↑ index
M1

Work environment

20 min

When done

Terminal open, practice folder created and VS Code running with your first file.

You can't operate digital systems without knowing the environment where they live. The terminal is the cockpit from which you control everything. VS Code is where you edit and review. This module gives you the minimum tools to get started.

Why it matters

Many beginners avoid the terminal for months. It's the most expensive mistake you can make. Everything you'll do in the following modules requires moving through it with basic fluency.

See exercise step by step

Objective

Open the terminal, create a practice folder and open the work environment in VS Code.

Before you start

Download and install VS Code from code.visualstudio.com if you don't have it yet.

Steps

  1. 1 Open the terminal. Mac: Cmd+Space → "Terminal". Windows: Windows key → "PowerShell".
  2. 2 Run mkdir operador-practica to create your practice folder.
  3. 3 Run cd operador-practica to enter it.
  4. 4 Run touch README.md (Mac/Linux) or ni README.md (Windows) to create a file.
  5. 5 Run code . to open the folder in VS Code.

Expected result

VS Code open with the operador-practica folder and README.md visible in the side explorer.

Common mistake

Using folder names with spaces. Avoid them: use dashes instead of spaces (operador-practica, not operador practica).

How to know it's done right

You see the README.md file in VS Code's left panel and can edit it.

Deliverable: operador-practica/README.md
You know how to create folders and files from the terminal
↑ index
M2

Claude Code

20 min

When done

Claude Code installed and used to generate real documentation inside your project.

Claude Code is not a chatbot. It's an assistant that works inside your project: reads files, writes code, executes actions and proposes solutions in context. It knows what's in your folder. That changes everything.

Why it matters

Using Claude from a web chat and using it from Claude Code are two completely different experiences. One answers questions. The other executes work inside your project.

PRO TIP

Claude Code reads your real folder. When you ask it something, it knows which files exist, what's inside them and what has changed. That completely changes what you can ask it and how it responds.
PROMPT M2 Ask Claude to document your project
Act as a technical documentation writer.

Analyze this project and create a README.md that includes:
- What this project does in a single line
- Why it exists
- How to install and run it
- Relevant file and folder structure
- Next steps or how to contribute

Tone: clear and direct. No unnecessarily technical language.
See exercise step by step

Objective

Install Claude Code and complete your first real task: generate documentation for your project.

Before you start

You need Node.js installed. Check with: node --version. If no number appears, download it at nodejs.org.

Steps

  1. 1 Install Claude Code: npm install -g @anthropic-ai/claude-code
  2. 2 Navigate to your folder: cd operador-practica
  3. 3 Start Claude Code: claude
  4. 4 Use the prompt above or write directly: "Create a README.md explaining that this is my practice folder for learning to operate AI systems."
  5. 5 Read the full result. Edit anything that is incorrect or doesn't represent your project well.

Expected result

A README.md with content generated by Claude and reviewed by you. The file makes sense and contains no invented information.

Common mistake

Accepting Claude's output without reading it. Claude can invent details that don't exist. Always review before saving.

How to know it's done right

The README accurately describes what your practice folder is and contains no false statements.

Deliverable: README.md reviewed and correct
Claude Code installed and working in your project
↑ index
M3

GitHub and security

25 min

When done

First repository uploaded to GitHub with clear commits and .gitignore configured to not expose sensitive information.

Git records every change with a message. GitHub stores those records in the cloud. Without Git, your work has no history and can't be deployed easily. Without .gitignore, you can accidentally upload API keys or passwords.

Why it matters

Git is not just for programmers. It's for anyone who wants to not lose work, collaborate with others or publish projects on the internet. .gitignore security is not optional: an API key leaked on GitHub can generate bills of hundreds of euros in hours.

COMMON MISTAKE

Always check git status before running git add . If a .env file or credentials appear, create .gitignore first. An API key in a public repo can generate debt in minutes.
See exercise step by step

Objective

Initialize Git in your project, make a safe first commit and upload the repo to GitHub.

Before you start

Create a free account at github.com if you don't have one yet.

Steps

  1. 1 Inside operador-practica, run git init
  2. 2 Create a .gitignore file and add these lines: .DS_Store, node_modules/, .env
  3. 3 Run git add . then git commit -m "init: operator practice folder"
  4. 4 On github.com, create a new empty repo called operador-practica. Copy the URL.
  5. 5 Run git remote add origin YOUR_URL then git push -u origin main

Expected result

Your operador-practica folder visible on github.com with the README and at least one commit with a clear message.

Common mistake

Making the first commit without .gitignore. If you upload a .env with API keys before adding .gitignore, those keys remain in history even if you delete them later.

How to know it's done right

You open the repo URL on GitHub from another browser and see your files with no .env or credential files.

Deliverable: Public repo on GitHub with at least 1 commit
Your work is in the cloud with version history
↑ index
M4

CLAUDE.md and memory

20 min

When done

A CLAUDE.md file in your project that gives Claude persistent context without you having to repeat it every session.

Claude doesn't remember between sessions, but it can read files. A well-written CLAUDE.md is your project's instruction manual. Claude reads it at startup and knows exactly how to behave: what to do, what to avoid, how to speak.

Why it matters

Without CLAUDE.md, every session starts from zero. With CLAUDE.md, every session starts aligned with your objectives, your style and your rules. The difference accumulates in hours saved.

REMEMBER

The first CLAUDE.md doesn't have to be perfect. Write it and start using it. Claude will tell you (implicitly, through its responses) what's missing. It improves session by session, not in one afternoon.
PROMPT M4 Generate a CLAUDE.md for your project
Act as a project architect.

Create a CLAUDE.md for this project with:
- Description and main objective
- Technical stack used
- Style or code conventions
- What you should NOT do in this project
- How to add modules or new sections
- Project tone and voice if applicable

Be concise. No filler. Maximum 40 lines.
See exercise step by step

Objective

Create a CLAUDE.md for operador-practica with objective, stack, style and constraints.

Before you start

Think of 3 things you want Claude to know about this project before starting to work on it.

Steps

  1. 1 Open operador-practica in VS Code.
  2. 2 Create a CLAUDE.md file in the project root.
  3. 3 Use the prompt above in Claude to help fill it in.
  4. 4 Review the result. Adjust anything that doesn't fit your real project. Remove what is generic.
  5. 5 Commit: git add CLAUDE.md && git commit -m "add CLAUDE.md"

Expected result

A CLAUDE.md of 20–40 lines with clear rules and useful context. In the next session, Claude reads the file and already knows how to work.

Common mistake

"Be helpful". Rules must be specific: "don't add dependencies without justification", "always use English".

How to know it's done right

You open a new Claude Code session in the same folder and, without explaining anything, it already knows what the project is and how to work on it.

Deliverable: CLAUDE.md with commit
Claude works with project context without repetitions
↑ index
M5

Operative prompts

20 min

When done

You know how to structure requests that produce directly usable work, not generic responses that need rewriting.

A generic prompt produces generic results. An operative prompt has role, context, structure and limits. The difference can be half an hour of extra correction work or a deliverable you use as-is.

Why it matters

Most people use AI as if it were a search engine. AI is not a search engine. It's a collaborator that needs briefing. Without briefing, it produces generic work. With briefing, it produces specific work.

PRO TIP

Minimum structure for an operative prompt: ROLE (who Claude is for this task) + TASK (what exactly) + FORMAT (how you want the output) + LIMIT (max X lines, no Y, etc.). Four elements. Everything else is optional.
PROMPT M5 Audit a repetitive task and map its automation
Act as a workflow analyst.

Analyze this repetitive task: [describe the task in detail]

Answer:
1. The steps that compose it, broken down without omitting any
2. Which steps are automatable and which are not, with justification
3. What tool would solve each automatable part
4. Which parts require mandatory human supervision
5. Estimated time saved if the automation were implemented

Be specific. Don't generalize.
See exercise step by step

Objective

Transform a vague request into an operative prompt and compare the results side by side.

Steps

  1. 1 Think of a specific task you want to delegate to Claude. For example: drafting an email, summarizing a document, creating a to-do list.
  2. 2 Write the vague version in one line: "Write me an email for a client", "Summarize this text".
  3. 3 Now rewrite it adding: Claude's role, who the recipient is, expected tone, output format, maximum length.
  4. 4 Send both versions to Claude and compare the results side by side.
  5. 5 Which would you use without editing? Which part of the context changed the output most?

Expected result

An operative prompt written by you that produces output you would use directly, without significant editing.

Common mistake

Adding context that isn't relevant to the task. Context must be dense and pertinent, not extensive.

How to know it's done right

The operative prompt's output doesn't need rewriting to be used. The vague prompt's output does.

Deliverable: Your own operative prompt that produces usable output
You distinguish between vague and structured requests
↑ index
M6

Automations

25 min

When done

You have identified at least one task in your work that can be systematized and have a map of how to do it.

Automating doesn't mean programming. It means thinking in steps: what do I do, what part can a machine do, what do I need to supervise. This module is about designing before building.

Why it matters

Most people automate before understanding what they're automating. The result is fragile systems that break when something changes. Mapping first saves hours later.

INSIGHT

Automating doesn't eliminate work: it redistributes it. Less repetitive execution, more design and supervision. The operator who doesn't understand what's behind it can't supervise or improve it when it fails.
See exercise step by step

Objective

Map one of your own repetitive tasks and detect which parts are automatable, which need supervision and which require human judgment.

Steps

  1. 1 Choose a task you do at least once a week. The more specific, the better.
  2. 2 Write all the steps of that task, in order, without omitting any. Include even the smallest ones.
  3. 3 For each step, put a label: automatable, supervised, or human.
  4. 4 Identify the step that consumes the most time or mental energy.
  5. 5 Design how that step would look if Claude executed it. What information would it need? What would it produce? How would you review it?

Expected result

A document with the task map, labeled by type (automatable / supervised / human) and a proposed improved flow.

Common mistake

Trying to automate everything at once. Start with the most repetitive, least critical step. Small systems that work are worth more than large ones that don't finish.

How to know it's done right

You can describe the system in 5 lines and explain to someone how it would work without using technical words.

Deliverable: Task map with labels and automation proposal
You distinguish task, process, system and automation
↑ index
M7

Publish and improve

20 min

When done

Something published with a real URL, accessible from any browser, and a list of documented improvements for the next version.

Publishing closes the cycle. It turns private work into real work. Learn to deploy something small in under 10 minutes. Then write what you would change: that's how iteration starts.

Why it matters

Projects that don't get published don't receive feedback, don't improve and eventually get abandoned. The imperfect thing that works and exists is always worth more than the perfect thing that never ships.

REMEMBER

Publish at version 0.1, not 1.0. The first URL exists so that it exists. Real feedback starts when something is published. So does iteration.
See exercise step by step

Objective

Deploy operador-practica on Cloudflare Pages and document improvements for v2.

Before you start

Make sure the project has at least one content file and is uploaded to GitHub.

Steps

  1. 1 Go to dash.cloudflare.com → Workers & Pages → Create → Pages.
  2. 2 Connect your GitHub account and select the operador-practica repo.
  3. 3 If static HTML: leave Build command empty, output directory /. If Astro: Build command npm run build, output dist.
  4. 4 Click Save and Deploy. In ~60 seconds you have a public URL.
  5. 5 Create mejoras-v2.md with at least 3 concrete things you would change or add.

Expected result

Active public URL that loads from any browser, plus a mejoras-v2.md file with at least 3 concrete points.

Common mistake

Waiting until it's "perfect" to publish. There is no perfect before publishing. There is the imperfect that receives feedback and improves.

How to know it's done right

The URL loads in a browser that isn't yours. The mejoras-v2.md file has specific, not vague, points.

Deliverable: Active public URL + mejoras-v2.md
You closed the cycle: build → document → publish → improve
↑ index
LEVEL 1 — SUBMIT YOUR PROOF Proof pending

Level 1 is not completed by watching content. It is completed by submitting public evidence.

Your final proof is a public repo + a live URL. All deliverables (context, CLAUDE.md, prompts, automation map, improvements) live in a single repository: operador-practica.

Before submitting, make sure you have:

  • mi-contexto.md in the operador-practica repo
  • README.md generated with Claude Code and reviewed by you
  • CLAUDE.md committed to the repo
  • .gitignore with at least 1 commit (no secrets)
  • Your own operative prompt saved in the repo
  • Automation map for a real task
  • mejoras-v2.md with 3+ concrete points
  • The project deployed to a live public URL