Jarvis OS (sistema personal de archivos, reglas y memoria de trabajo) es la forma portable de tu contexto. Claude Cowork (entorno de trabajo con Claude y archivos) es una superficie posible para operarlo, no la fuente de tu soberanía.
The method for your digital office
Build your Jarvis
Turn Claude Cowork into a knowledge-work office that remembers your context, works on your files and helps you decide better. This playbook shows how to stop starting from zero without depending on one tool forever: your context, files and judgment start working with you. Method First, (Gen)AI Next.
Build a useful first version before you try to automate anything. You will learn how to organize your context in five sectors, choose the first stations that matter to your work, and use cadences so the system keeps helping after the first session. The goal is simple: less restarting, more traceability, better human decisions.
8core capabilities
5horizontal sectors
12adoption levels
12 wkfull proficiency
4h
Active reading with Claude open
4-8h
Complete Jarvis setup
4h × wk
Sustained cadence until Q
12 wk
Consolidate full proficiency (1 quarter)
Your job is not to write better prompts conversation by conversation; it is to build your Jarvis once and keep it alive.
Stop starting from zero
You are here because you do not need another prompt list. You need to stop starting from zero every time you work with AI: artificial intelligence, a tool that generates or transforms information. Your work depends on files, decisions, commitments, history, constraints and judgment.
Digital sovereignty is not knowing every tool. It is having enough method for your context, files and criteria to travel with you. Claude Cowork can be a useful surface, but the product is not the system. The system appears when your rules, memory, projects and cadences keep working after the first conversation.
AI accelerates what you describe. If the method is weak, it accelerates disorder. If the method is clear, it helps organize information, compare options, spot gaps and prepare better conversations with yourself, your team or your clients.
You delegate operational friction, not responsibility. The AI does not decide for you. A prompt, meaning a written instruction, is only useful when it carries context, role, task, format, limits and evidence back to human judgment.
A clear explanation is not validation. Small tasks need lightweight review; important decisions need proportional evidence, traceability and judgment before action.
This playbook is Copyleft because useful knowledge should travel. Adapt it to your role, your constraints and your tools. Keep what reduces friction; discard what does not improve a decision, a deliverable or a conversation with your team.
Method First, (Gen)AI Next. Less restarting. More reusable context. Better human decisions.
Open §1 and choose one concrete decision: what minimum system do you need to build first?
Glosario inicialPrimeras palabras técnicas
Skill (receta reutilizable de trabajo), workflow (flujo de trabajo repetible), MCP (Model Context Protocol: estándar para conectar IA con herramientas y fuentes) y agente (IA configurada para ejecutar pasos con objetivo, límites y revisión humana) se usan aquí solo cuando ayudan a gobernar mejor el trabajo.
OverviewWhat you will build
Your knowledge work is earned co-creating a system, not writing better prompts. This playbook gives you the method to design your Jarvis on Claude Cowork with the eight core capabilities, the structure of five operational sectors, and a mental model triangulated against verifiable sources. You build once, keep it alive, (r)evolve with cadence.
- P1(R)Evolution
- P2Intention before intensity
- P3Technology as an ally
Between trying prompts and operating a reliable workspace, the difference is context. This playbook shows the habits, files and decisions that make Claude useful for real knowledge work. It is supported by public knowledge on Claude Cowork [13][14], the complementary paradigm of Hyperspecific Apps and plugins [15], and the practical model of tokens, context and memory.
MetodologIA Manifesto · guiding framework
Co-creating environments of abundance by democratizing digital and professional sovereignty.
Method First, (Gen)AI Next. Enablers of disruption.
Movement I of V
I
Foundation
Method First, (Gen)AI Next.
§1Executive Summary
What this playbook is. It is a practical foundation for turning Claude Cowork into a workspace that carries context across sessions. You will see the eight product capabilities, the five sectors that organize your work, the stations that map to recurring needs, and the cadences that keep everything alive. The point is not to admire the architecture; it is to know what helps you make better decisions with less friction.
Trajectory · four phases · 4h × week sustained. An operating manual that is applied with Claude open. Phase 1 (4h): active reading with exercises. Phase 2 (4-8h): base setting installed. Phase 3 (12 weeks · 48h total): polishing until full proficiency. Phase 4: live operation with monthly audit and quarterly QBR.
What value does it generate. Three practical gains: your files can be available without pasting them again, memory can reduce repeated explanations, and supervised cadences can prepare triage, reviews and decisions before the meeting starts. The benefit is not magic automation; it is a cleaner handoff between your context and the AI.
Central idea: knowledge work improves when your context is organized, portable and easy to reuse. Start with §3 to choose the simplest level that solves today's problem, then use §15 if you need a short adoption path.
Nomenclature. Claude Desktop = app hub on your PC with three modes: Chat (conversational), Cowork (sustained knowledge work · files · memory · MCP · projects · scheduled tasks) and Code (technical agentic). "You live in Cowork" = Cowork mode within Claude Desktop.
About plans and licensing (May 2026 · subject to change). Claude Desktop is a free download on macOS and Windows. The free experience is useful for learning the structure and building the first plain-text files. Cowork, Code, Office surfaces, the Chrome extension, Projects, persistent memory, scheduled tasks and MCP connectors depend on current plan and availability. This playbook recommends Cowork from experience when you are ready to treat it as knowledge infrastructure. The cost/benefit decision remains yours: it improves when you have a real workflow, reusable context and enough discipline to maintain the system. Verify current prices and terms at claude.com/pricing before committing a budget.
Optional accelerators while you read. You can read this playbook alone, with your own study method, or supported by assistants. The assistants do not replace the method: they help you turn a dense section into self-study questions, a research plan, or a cleaner prompt for your own context. Open them in another tab, paste the section you are studying, and ask for help without sharing private data.
Use it when a section is conceptually dense. Ask it to convert the section into retrieval questions, practice exercises, flashcards, and a short self-study plan.
Use it when the playbook opens a topic you want to investigate: MCP, memory, governance, skills, scheduled tasks, or digital sovereignty.
Use it when you want to adapt a prompt from the playbook to your own role, project, cadence, or station without losing structure.
Use it when you need a general thinking partner to decide how to read, what to prioritize, or what to turn into practice first.
Use NotebookLM when you want to study with your own sources and traceable citations. Use the catalogs if you prefer to choose another assistant.
§1bWhere do I start based on my role?
The Jarvis OS is the same architecture for everyone · what changes is the adoption sequence. Five reader profiles with different pain points · different initial priorities · different first sectors to seed. If your role doesn't fit exactly · choose the closest one and adjust.
| Your role | Main pain point | First sector to seed | Recommended plan |
|---|---|---|---|
| Knowledge worker in a company | Email overload · meetings without minutes · contexts lost between apps | Sector I (minimum identity) + Sector II Emails + Sector II Deliverables (minutes) | Express Plan 4 weeks · visible output in 2 weeks |
| Team leader | Lost decisions · manual status reports · feedback without a system | Sector I + Sector II Deliverables (ADRs + status) + Sector V Cadences (WBR first) | Full Plan 12 weeks · adoption 1 ritual/month |
| Independent consultant / freelance | Mixing work from various clients · losing hours on setup · inconsistent brand voice | Sector I (voice + brandbook) + Sector III (one project per client) + Sector II Documents | Full Plan 12 weeks · priority on voice + commercial templates |
| Academic / student | Scattered notes · unsynthesized papers · lack of transfer to application | Sector I + Sector II Study (library) + Sector IV Lab (falsifiable hypotheses) | Slow Plan 3 months · researcher cadence (1 sector/month) |
| Content creator / personal brand | Inconsistent voice · lack of rhythm · "I don't know what to post today" | Sector I (full voice + brandbook) + Sector II Publications (1/week cadence) | 4-Week Express Plan · first piece by day 14 |
Any role starts with Sector I Foundations · it cannot be skipped. What changes is which Sector II to seed first and what cadence to adopt. If after 2 weeks your first sector hasn't produced an output worth saving · review your choice before continuing.
§2The surface ecosystem · where Claude lives in your day
Anthropic distributes Claude via a desktop hub (Claude Desktop) that hosts three modes (Chat, Cowork, Code) plus satellite surfaces (web, mobile, Office, Chrome). This playbook lives in Cowork within Claude Desktop · the heart of sustained knowledge work.
Disclaimer · illustrative wireframes
The diagrams and layouts appearing in this playbook are illustrative wireframes made in May 2026, based on actual product screenshots at the time. Anthropic updates Claude Desktop frequently; when you read this playbook in the distant future, the exact order of icons, tab names, and panel layouts may have changed. The intent of the wireframes is not to be a faithful photograph but a mental map: so you can locate where each mode lives and what kind of things you'll find when you open the product. For the exact current version, open Claude Desktop or consult the official documentation at docs.claude.com.
A well-polished assistant frees up your time. What used to be pasting the same prompt every turn, adjusting it, repeating it, and praying for consistent performance · is now a single tap on the assistant that already has quality assured. Consistent output on the first turn · zero cognitive rework · one hour of polishing once saves you hours every week thereafter. The number of assistants you have (one or several) is secondary · what's important is that each one frees up real, measurable time.
A single Claude Desktop, three modes of operation. The right choice costs minutes · the wrong one costs hours.
2.1 · Claude Desktop · the hub
Claude Desktop is the app you download and install on macOS or Windows. It houses the three modes under one roof like an IDE for knowledge work: Chat (conversational without local files), Cowork (sustained with files · memory · MCP · skills · projects · scheduled tasks) and Code (technical agentic). The installer can be used to learn the method; advanced surfaces depend on the plan and availability in force (see licensing callout in §1). The playbook assumes Cowork unless otherwise noted.
2.2 · Chat Mode · conversational + Chat Projects
The Chat is a pure conversational interface. Available on Claude Desktop, Claude.ai (web), iOS, and Android. Optimal for one-off questions, quick exploration, validation, specific drafting, or thinking out loud. It does not access local files. The mobile apps add hands-free voice.
Within Chat, there are Chat Projects: thematic containers in the cloud with their own instructions and a handful of reference files. The promise is direct · a well-polished assistant finally frees up your time. What used to take a while and several prompts iterating to get the output you wanted, is now resolved in a single interaction, with quality assured by the custom instructions you polished the first time. Each assistant you build and mature is an hour invested today that gives you back hours every week later · that is the real operational leverage, not the number of assistants you end up having. Ideal uses for the pattern — specialized assistant (coach, copy editor, critical reader, depending on the role) · standard format generator (status report, meeting minutes, one-pager) · recurring low-complexity tasks that don't require local files or memory between sessions. The difference between having a mental prompt you recite poorly every time versus a polished assistant that performs consistently is night and day for your cognitive productivity · start with one, validate it for two weeks, and only then add the next one when a specific pain point calls for it.
2.3 · Cowork Mode · where your Jarvis lives
Cowork adds eight core capabilities to Chat (§6): local files, persistent memory, MCP connectors, skills, Cowork Projects, browser extension, scheduled tasks [25] and Dispatch (in beta · §6.8) which extends the office to your mobile [23]. It is the right tool for almost all recurring knowledge work with persistent artifacts and memory between sessions.
Chat Projects vs Cowork Projects. It's not about prestige · it's about cost and depth. Chat Projects: cheap on tokens, max ~20 reference files, no filesystem. Cowork Projects: more expensive but unlimited — they read your entire folder, remember via MEMORY.md, invoke MCP, run scheduled tasks, and produce artifacts on disk.
| Task | Chat Project | Cowork Project |
|---|---|---|
| Specialized assistant design (coach, editor, critical reader) | ✅ Ideal · cheap · custom instructions are enough | Overkill · you waste context you don't need |
| Standard-format document generator from inputs (status, minutes, one-pager) | ✅ Ideal · upload 5-10 reference files + template in instructions | Only if the document requires consulting your actual filesystem |
| One-off question or quick exploration | ✅ Sufficient · without opening a Project | Unnecessary |
| Recurring client work that produces persistent artifacts and requires history | Insufficient · you lose memory between sessions | ✅ Ideal · MEMORY.md accumulates knowledge |
| Analysis of large local files (CSV, long PDFs, client folders) | Doesn't access your filesystem | ✅ Ideal · the only real option |
| Automation with scheduled tasks (morning triage, pre-status draft) | Doesn't support them | ✅ Only option |
| Co-creation with Claude on a limited task (review text, brainstorm title, adjust tone) | ✅ Cheaper and sufficient | Overkill |
| Corporate template encoded as a skill | Skills don't live in Chat | ✅ Skills only in Cowork |
The mental rule of thumb: if the task is recurring, multi-file, and requires memory between sessions, Cowork. If it's limited, self-contained, and benefits from a template declared in instructions, Chat Project. If it's a single question, direct Chat without a Project.
2.4 · Code Mode · technical agentic
Code is Claude for programming: it builds, debugs, and deploys from the terminal or IDE. Available in CLI, VS Code, JetBrains, Slack. If you have a development team, knowing it allows you to realistically calibrate timelines. Without direct technical supervision, it is outside the scope of this playbook.
2.5 · Microsoft Office · Claude lives inside your apps
It's not about external "integrations." It's about Claude is inside Excel, inside PowerPoint, inside Word — already installed, ready to operate without you leaving the app you have open. When you're in a spreadsheet, Claude is right there: it helps you with formulas, analysis, charts. When you're putting together a presentation, Claude is there: it drafts slides, generates structure, edits content. When you're writing a long document, Claude is there: it accompanies your writing turn by turn, reformulates, revises, suggests. The difference with copy-pasting between Cowork and Office is that there is no translation: the AI operates on the native file, sees the exact cell, the exact slide, the exact paragraph. For financial analysis roles, this same residency extends to specialized sources (Daloopa, S&P Global, Moody's, LSEG, FactSet, PitchBook) accessible from the panel without opening another tab.
2.6 · Chrome extension · agentic satellite
It brings Claude inside the browser to navigate, click, and fill out forms under supervision. Useful for portals without an API, regulatory forms, internal dashboards. Currently slow and prone to mid-task failures (§6 chap 06). Limit it to exploratory use until it matures.
2.7 · How to choose the surface
Mental rule: ask where you are and what you're doing. Mobility → Mobile Chat. Office open → Claude inside the app. Web portal → Chrome ext. Programming → Code. Rest of the knowledge work → Cowork on Desktop. Not mutually exclusive: in one day, you might touch three or four. Forcing the wrong surface is costly.
2.8 · Visual Gallery · Claude on every surface
Six places where Claude lives. Same model, different incarnation depending on the context of the moment. The wireframes are illustrative · May 2026 · the product evolves, the surface logic remains.
Wherever you are, Claude is. The question is no longer “how do I write the prompt” and becomes “from which surface do I attack the task”.
The gallery makes it explicit why the rule of choice matters. Web and mobile are the quickest receptions—you go in, ask, and get out. Excel, PowerPoint and Word host Claude as a resident panel that sees the exact cell, slide, and paragraph. The Chrome extension provides agentic capabilities over any webpage without requiring an API. Code operates from the terminal or IDE for technical tasks. And above all, Cowork within Claude Desktop is the hub where your Jarvis lives—the only place where local files, persistent memory, MCP, skills, projects, and scheduled tasks intersect.
§5bWhen NOT to build a Jarvis
Building a personal Jarvis isn't for everyone or for every moment. There are five scenarios where the method says don't start now · and recognizing them beforehand saves months of friction with no return.
| Scenario | Why NOT now | What to do instead |
|---|---|---|
| Your work is 100% manual with no digital component | The Jarvis is an operating system for knowledge work. Without a textual / decisional / cross-tool component · the ROI is zero. | Build non-digital systems (notebooks · analog rituals · physical boards). Return to Jarvis if your role evolves towards knowledge work. |
| Your privacy does not allow for persistent context | Regulated roles (legal · health · defense) where persistent context outside the corporate environment violates compliance. | Wait for an authorized corporate version · or use Jarvis only for personal life strictly separate from work. |
| Your organization explicitly prohibits it | Corporate security policy that blocks external connectors · agents with filesystem access · generative AI. | Respect the policy. Build a personal Jarvis for use outside of work (life · side projects · post-employment). |
| You don't have a sustainable 4h/week for 12 weeks | The Jarvis is built in one quarter. If your schedule doesn't allow for that cadence · starting it and abandoning it halfway costs more than not starting at all. | First, resolve the root cause of the saturation (delegate · say no · simplify your schedule) · then return to Jarvis. |
| You are in an acute crisis (work · personal · health) | Building systems requires cognitive bandwidth · an acute crisis consumes it completely. A failed system in a crisis = a double defeat. | Address the crisis · stabilize · then build the Jarvis with recovered clarity (3-6 months post-stabilization). |
If none of the five scenarios apply to your situation · the Jarvis is viable. If one applies partially · adjust the plan (slower · smaller scope · personal life only · etc.) before investing the 4 hours of the first session.
The method is the catalyst. AI operated with a method takes you further, faster, with more precision, quality, and scale. Without a method, the best AI in the world becomes just another open tab.Thesis of Movement I · the catalyst effect
§3The twelve levels of adoption · from use to sovereignty
Cowork is not the only option. It's worth stating that the adoption map this playbook describes does not specifically require Claude Cowork. The same conceptual design can be assembled with other agentic tools on the market: Google's Antigravity, Microsoft's Visual Studio Code with Copilot, OpenAI's Codex. Cowork isn't better because it's unique; it's better because of the operational friction it removes when you work with local files, persistent memory, and MCP connectors on a daily basis. If your main pain point is different, another tool might be the reasonable choice.
Think of the tools as levels of work. Each level adds capability and also adds complexity. The rule is simple: use the simplest level that solves the task well, and move up only when the work demands it. Adding complexity too early consumes energy; staying with a simple surface when you need more context, files, or automation creates frustration and poor output. This section shows the twelve levels in three movements: first you solve with what is already available, then you work with your computer files, and finally you build your own components when a friction becomes recurrent.
The most common mistake when choosing a tool is to go by habit or by the tab you had open, not by criteria. This makes you spend an hour in direct Chat doing something that a Chat Project could have solved in five minutes without installing anything, or trying to do a deep analysis of client files from your mobile when a direct Cowork session on your desktop would have solved it in one sustained session. The level map turns that decision into something replicable because it always makes you ask the same question: what is the simplest surface this task requires?
3.1 · Five horizontal sectors · two intersecting axes
The Jarvis level map has two axes that move in different and complementary directions. The vertical axis is adoption depth: the twelve levels progress from direct Chat to migrating your setting to another tool, and they are learned one after another because each level demands more operational capacity than the previous one. The horizontal axis is the five sectors, which all exist from day one and are available at any point in the flow. They are not unlocked with maturity—they are always open, ready to be used according to what the task demands at this moment. Moving up a level is gaining capacity. Entering a sector is choosing from which layer of your architecture you are operating right now.
The twelve levels are not memorized one by one. They are easier to remember when grouped into five horizontal sectors — bands that cross the full map and answer the only question that matters when you choose a tool: in which sector am I operating now? You can be on level one using Direct Chat and at the same time have Sector V Maintenance available because you already have your root CLAUDE.md capable of migrating to another tool. The three narrative movements (solve · work · build) describe the progression over time; the five sectors describe the always-unfolded map on which that progression occurs.
Each sector is also a layer of your information architecture. When I talk about "layers," I'm referring to the physical equivalent of the sector in your filesystem: the folder where the context Claude needs to operate in that sector lives. Sectors and layers are the same reality seen from two angles. The sector is the experience of the work you are doing. The layer is the folder that supports that experience. The five layers coexist from the moment you assemble the root scaffolding; what changes over time is not how many are available, but how populated they are with useful context.
| Horizontal Sector | Layer · scaffolding folder | What it's for |
|---|---|---|
| I · Foundations | N0 · Root + 00_Recursos/ | Identity, brand, governance — what doesn't change |
| II · Base | N1 · Estaciones/ | Daily operations — Emails, Pre-sales, Deliveries |
| III · Core | N2 · Projects/ | Live files — clients, initiatives, projects by code (P-NNN according to your numbering · e.g., P-001, P-002, P-003) |
| IV · R&D+i | N3 · Lab/ | Research, development, and innovation — orchestrator stations, mini-apps, own skills in development |
| V · Maintenance | N4 · Cadencias/ | Rhythm and portability of YOUR context — scheduled tasks, provider independence, your system (CLAUDE.md, MEMORY.md, voice, projects, history) travels with you (Digital Sovereignty) |
The core idea: your filesystem is the information architecture of your Jarvis. The five root folders are not a cosmetic convention — they are five signals that Claude reads when starting any session on your workspace, which automatically notify it where everything is and how it connects. When you open Cowork on Trabajo en Claude Desktop/, Claude doesn't need you to explain the system because the system is written in the names themselves. 00_Recursos/ says "this is identity and reference". 01_Estaciones/ says "daily operations live here". 02_Proyectos/ says "active records are here". 03_Lab/ says "Here I experiment without breaking production". 04_Cadencias/ says "Here is what runs by itself".
That turns hard drive organization into passive context: documentation that you don't write but that Claude understands. A CLAUDE.md in the root formalizes it with explicit rules, but the folders already speak for themselves. That's why the naming rule in kebab-case with a numeric prefix isn't an aesthetic decision—it's the interface through which your intention becomes legible to an AI without you having to repeat it in every conversation. Renaming a folder from misc/ to 02_Proyectos/ doesn't move a single byte of information, but it gives Claude a map it didn't have before.
From now on, we will use two terms with discipline. Sector when we talk about the horizontal band you are currently operating in—there are always five available, and you can move between them as the task requires. Layer when we talk about the materialization of the sector in your filesystem as a folder with its CLAUDE.md, its MEMORY.md, and its own context. The five sectors coexist from day one; what ascends over time is your work within them, until Sector V Maintenance—where automatic cadences and the portability of YOUR context (info, projects, developments, preferences, history · it's all yours, not the product's) live—is no longer an empty folder and delivers the Digital Sovereignty: proof that the entire system no longer depends on the provider.
3.2 · Movement One · Entry levels
The first movement resolves from the cloud. Three floors in Claude Chat: the simple, the curated, the focused. Sufficient for most questions that don't require your local files.
The floor one is Direct Chat on the claude.ai website or mobile app. One question, one answer, no ceremony. The fastest entry point: exploration, validation, voice memos while you walk between meetings.
The floor two is Chat with high-performance prompts. You stop improvising and start operating with your personal library of proven templates: summarizing minutes, breaking down problems, drafting executive emails. MCP is optional for looking outside the chat.
The floor three is Chat Projects: themed containers in the cloud with their own instructions and reference files. Your first specialized assistant—for pre-sales, committees, feedback—without touching the local filesystem.
You move up to Cowork when the task requires your computer: local files, persistent memory via MEMORY.md, deep MCP, artifacts on disk.
3.3 · Movement Two · The Jarvis Apartments
The second movement works on your files. Cowork maintains its own persistent memory and MCP. Two floors for sustained knowledge work.
The floor four is Direct Cowork: a desktop app over a working folder. One-off sessions with local files that don't yet warrant a formal Project—ad hoc analysis, PDF (R)Evolution, legacy conversion.
The floor five is Cowork Projects: containers with instructions, curated files, and persistent memory via MEMORY.md. Recurring work with a client, initiative, or program—each with its own role, tone, and memory.
You step up to build when repetition calls for automation: the same template three weeks in a row, the same risk flow every time, the same sprint-closing routine. That's the signal.
3.4 · Movement three · own branches
The third movement builds your pieces. When a pattern repeats, you materialize it as a reusable piece. Seven floors in ascending order of sophistication and organizational scope.
The floor six is Skills: reusable instructions that Cowork loads on demand. A status report template as a shortcut, a risk entry as a flow, a retrospective as a command. Rule of three — if it repeats three times, it's worth materializing.
The floor seven are Plugins: packages that combine skills, commands, and MCP into an installable unit. Where a skill serves one, a plugin serves the team. Private or public store with versioning.
The floor eight are mini apps via vibe coding: you describe the intent in natural language, the AI writes the code. Hyperspecific Apps that solve a bottleneck of yours and yours alone.
The floor nine is versioned plugin engineering. When a mini-app is used by two or more colleagues, it is promoted to an official plugin with a CHANGELOG, semver, tests, and peer review.
The Floor Ten is Orchestrator Station Project: directs various skills and plugins in an entire area. Emails, Deliveries, Pre-sales — each station with its role and its orchestra.
The Floor Eleven is deployed web mini-apps: your personal app becomes a URL accessible to colleagues and clients without Cowork. A private tool becomes a shared interface.
The twelfth floor is port YOUR context to another agentic tool · you don't migrate the product, you migrate what's yours: your files, your CLAUDE.md, your MEMORY.md, your voice-principles, your projects, your history, your way of working. If you can reproduce the complete Jarvis in Antigravity, VS Code, Codex, or any substitute in less than a Q, you have achieved real portability.
The top level · Digital Sovereignty. The twelfth floor brings you to the highest point of the map: Digital Sovereignty. Having Digital Sovereignty means being able to create custom dedicated work environments, with all your context, on the agentic tool that best serves the moment. Your CLAUDE.md, your MEMORY.md, your voice principles, your glossary, your five-level structure · all of that is yours, not Anthropic's. When a provider raises prices, depreciates capabilities, or changes terms, you move without losing the system. That is the ultimate reason for building your Jarvis with a method: not to serve Claude better, but for Claude (or whoever replaces it) to serve you better.
3.5 · The level map at a glance · 12 floors · 5 sectors · 1 destination
Twelve levels to progress at your pace. Starting simple is not giving up on advanced work · it's the path.
Each level expands on the previous one; each sector groups levels that share an operational nature. The vertical axis increases adoption depth · the horizontal axis is always open (the five sectors coexist from day one).
| # | Step | When to get on | Natural Output |
|---|---|---|---|
| 1 · Ground Floor | Direct Chat | Single question, exploration, mobility | Text in chat |
| 2 | Chat with high-performance prompts | Repeating patterns · personal library of curated prompts | Reusable templates + optional MCP connectors |
| 3 | Chat Projects | Focused thematic task without local files | Text + artifacts in project |
| 4 | Direct Cowork | Single productive session that touches files | Files in filesystem |
| 5 | Cowork Projects | Recurring work with a client or initiative | Project with instructions + MEMORY.md |
| 6 | Skills | Pattern repeats three or more times | Installable Skill |
| 7 | Plugins | Pattern repeats across two or more knowledge workers | Versioned plugin in store |
| 8 | Mini apps · vibe coding | Specific personal bottleneck | Hyperspecific App in Project |
| 9 | Plugin engineering | A validated mini-app is worth promoting to official | Plugin with CHANGELOG and tests |
| 10 | Project station | Entire area with multiple components | Orchestrator station |
| 11 | Web mini-apps | Useful for colleagues or clients without Cowork | URL accessible from a browser |
| 12 | Porting YOUR context to other tools | Your mature Jarvis · a portability test for what's yours | Setting reproduced in Antigravity / VS Code / Codex |
| ↑ Sector V · Maintenance delivery Digital Sovereignty · custom environments with all your context, on any agentic tool | |||
Why NotebookLM appears in a Claude guide. This playbook is a guide about Claude, Claude Cowork, and how to turn it into your personal Jarvis, so the inclusion of NotebookLM (which is a Google product, not from Anthropic) deserves clarification. The choice is ad hoc, not due to ecosystem affinity. Of all the options available on the market to build a second brain anchored to sources with traceable citations, NotebookLM was chosen for its specific power in deep research with citation discipline: the ease of loading diverse sources, the quality of responses with traceable citations to the exact source, and the ability to integrate it with Cowork via MCP make NotebookLM an exceptional complement to Jarvis. NotebookLM is not one of the twelve Anthropic levels; it is the first recommended MCP integration for Cowork.
3.6 · Mental rule of thumb · only move up when the current level is not enough
The operating rule that completes the level map is straightforward. Before each task, ask yourself three questions: what is the simplest surface that can solve this? If it works, stay there. If the output is poor because the task needs more context, files, memory, or automation, move to the next surface and try again. A realistic progression for a knowledge worker is one to three levels per month. The point is not to climb fast; it is to remove friction for real work without adding unnecessary setup.
The mindset shift behind the level map. Before having this map, most professionals choose out of habit or based on the tool they have open at the moment. This leads to two opposite mistakes. One is moving up too quickly: someone who just installed Cowork and already wants to build deployed web mini-apps, which results in a showcase-Jarvis that looks impressive in a screenshot but isn't used. The other is never moving up: someone who lives in direct Chat for years because they are afraid of the desktop, which leaves them wasting an hour every time they paste the same document into a new conversation. The map turns that choice into an explicit habit and frees up real cognitive capacity for the work that only a human can do.
3.7 · The repo layer · from the file cabinet to the vault
Levels 6 to 12 share a substrate the map never named: the git repository. Until now your Jarvis lives as plain-text Cowork folders — perfect for light knowledge work. But some commission needs dated history, parallel drafts, off-site backup or code. That commission graduates: it stops being a folder and becomes an armored dossier with its own vault. That is the repo layer. The ladder has four rungs: (1) Margin note → a line in TAREAS.md; (2) Commission folder → _tasks/T-NNN-slug/ in Cowork; (3) Armored dossier · task repo → a git repo at ~/Documents/workspace/<slug> with a private vault, which has an end and gets archived; (4) Headquarters · project repo → a long-lived git repo with multiple deliverables and collaborators.
Task repo vs. project repo. A task repo (T-NNN) is a commission with a start and an end — you build it, work it, deliver it, and archive it. A project repo (P-NNN) is a headquarters — long-lived, multi-deliverable, with its own house rules and review cadence. The difference is the lifecycle, not the technology. The vault doorman: before graduating a folder to a repo, run six triggers — code? branches/parallel drafts? dated history? external sharing? parallel work (worktrees)? portability beyond Cowork? Zero triggers → keep it a Cowork folder; one or more → make it a standalone repo. Once it is a repo you gain parallel desks (worktrees): a second workbench on the same dossier so a risky draft never smudges the good version. Each repo is born with a private vault (private GitHub) and auto-generated translated copies (AGENTS.md, GEMINI.md) you never edit by hand — digital sovereignty in its strongest form. The Runbook executes this in four steps: Step 27 (does it deserve a repo?), Step 28 (turnkey scaffold), Step 29 (parallel desks), Step 30 (vault, mirrors, archiving).
§4Fundamental mental model · how Claude thinks
Imagine Claude sitting at the desk you set up for him in your digital office. On the desk, he places your question, the files you uploaded, the conversation history, and the tools he invokes—from there, he thinks about the answer. The desk has a maximum surface area: that is the context window. What fits on the desk are tokens. When the session is closed, the desk is cleared; only what you explicitly asked to be remembered survives, in a colleague's separate notebook: the persistent memory. Three ideas, a minimal mental model · consistent with the digital office metaphor from §5 (you direct · Claude operates at the desk).
4.1 · Tokens · the economic unit
A token is a sub-word unit [1]. A practical rule of thumb in Spanish: ~3 characters ≈ 0.75 words. Useful equivalencies—a 100-word paragraph: ~140 tokens · a dense A4 page: 500-700 · 1-hour meeting minutes: 1500-2500 · a 20-page BRD: 12-17K. Tokens consume space in the window and quota from the plan [11]. Optimizing them means optimizing quality and cost simultaneously.
4.2 · The context window · a finite desk
It's the maximum number of tokens the model "sees" in one turn [1][10]: system, files, history, tools, prompt, and response. Cowork has a larger window than Chat [14]; the limits vary by plan. What's critical is not the absolute size but that everything that goes in competes for attention · each additional token dilutes the others.
The lost in the middle [1] effect [1] shows that models pay more attention to the beginning and end of the context, degrading accuracy in the middle. Guideline: what's important goes at the beginning of the prompt or at the end of the history · never buried in the middle.
4.3 · Persistent memory · what survives
Three distinct mechanisms that shouldn't be mixed. Conversation context: tokens from the current chat, which evaporate upon closing. Cowork persistent memory: summaries that are injected into future sessions [14]. Projects: containers with instructions and reference files that apply to all their conversations without using up the window. Three mechanisms, three optimal uses · they materialize in the five sectors of §7.
4.4 · Attention and silent degradation
Filling the window to its maximum worsens the responses. Near the limit, three degradations occur: the lost in the middle effect is accentuated [1], the response is shortened because output competes for the same budget, and latency grows non-linearly. The human side: a focused conversation conserves mental load [7] instead of spending it tracking context. Conversation hygiene is not optional.
4.5 · The layer protocol · how much paper you put on the desk per stage
If the desk is finite (§4.2), the practical question is which papers you put up and in what order. Interpretable Context Methodology (ICM, arXiv:2603.16021) answers with a strong idea: the folder structure IS the assistant's architecture. You don't need a framework orchestrating context in code; you need each stage to read only the files it requires. Context organizes into five layers, most-stable to most-volatile: Layer 0 CLAUDE.md (~800 tok, "Where am I?") · Layer 1 CONTEXT.md (~300, "Where do I go?") · Layer 2 stage context (200-500, "What do I do here?") · Layer 3 reference material (500-2k, "What rules apply?") · Layer 4 working artifacts (varies, "What am I working with?"). Layer 3 is the recipe (brand, voice, conventions — internalized as constraints); Layer 4 is the ingredients (today's draft — processed as input). The payoff is control without programming: to reorder a stage you rename a folder instead of editing orchestration code; to change a prompt you edit a markdown file; anyone with a text editor can do it. It is the antidote to the §4.4 lost in the middle: load by layers, the critical at the edge, no filler in the middle. The Runbook pushes this when a CLAUDE.md grows: it splits it into a lean control panel plus on-demand canon-*.md (Step 24).
§5Integrated concept map · digital office
The metaphor that unites everything: your Cowork is a digital office. Cowork is your personal office where you are the management. The office has reception areas where you enter (web, mobile, desktop, Office, browser, IDEs); it has digital staff that executes tasks; it has departments by area of responsibility; and you can add your own branches that you build when a friction becomes recurrent.
The map condenses the complete structure. In the upper band is the director (you with your intention and professional judgment). In the middle band is Jarvis with four layers: receptions where you enter, digital staff that executes, departments where the context lives, and your own branches that you build. In the lower band is the world where the work lands. The arrows mark the virtuous cycle: intention descends, execution delivers, feedback ascends, memory learns.
Closing Mov. I
You arrive with the substrate clear: tokens, window, memory. → Next: Capabilities · eight services that multiply what you already understand.
Movement II of V
II
Capabilities
Co-creating environments of abundance.
§6The eight core capabilities · the Anthropic seal
The eight core capabilities are the Anthropic seal in your digital office — the eight services the staff knows how to do for you: archive local documents, remember between sessions, access email or calendar, execute saved instructions, organize contexts by client, peek into the browser, schedule tasks that trigger automatically, and extend the office to mobile with Dispatch (in beta · §6.8). Everything else (skills, plugins, agents, mini apps) is built by combining these eight capabilities. How to organize them into five sectors that turn the product into a personal operating system · that is the proposal of MetodologIA, developed in §7.
The eight are distributed across the twelve levels (§3): each upper level composes capabilities from lower levels. Skill (floor 6) = Projects + memory + files; plugin (floor 7) adds MCP; orchestrator station (floor 10) coordinates all eight at once. Configuration order by dependency: files and memory first, projects in parallel, connectors in week 2, skills and scheduled tasks when there are stable templates, browser extension at the end with caution [24]; Dispatch comes in at the end with a note about its beta status (§6.8).
Each capability enables a type of work that is simply not possible without it. Activate the eight capabilities, combine them, and multiply measurable productivity. What's missing after mastering them isn't functionality—it's operational discipline.
CAP 01 · Local File Access
In Chat, you paste content every turn; in Cowork, you authorize a folder, and Claude reads it when needed. Your client folder with twelve status reports, meeting minutes, the current plan, and the risk register remains permanently available. Estimated savings: 15-30 min per productive session.
CAP 02 · Persistent Memory
Persistent memory is the difference between an assistant that learns with you and an assistant with amnesia. CLAUDE.md Declare your role, methodology, tone conventions, brands, key stakeholders; Claude reads it at the beginning of each session [13].
CAP 03 · Tools & Connectors (MCP)
MCP connectors allow Claude to read email, calendar, tickets, Notion, and Asana without copy-pasting. The highest-value workflow unlocked: morning inbox triage with prioritization [13]. Start with two connectors; add a third only when the first two have become a habit.
CAP 04 · Claude Skills
A Skill is a reusable instruction set: rules, templates, and optionally scripts that Claude loads upon detecting the task. There are official Skills (Word, PPTX, XLSX, PDF) and custom Skills. It's the cleanest way to encode corporate templates with specific tone, format, and mandatory fields.
CAP 05 · Cowork Projects
This capability structures everything else. One Project per client, optionally one per internal initiative, and a cross-cutting "Toolbox" project. The exact hierarchy within Projects resides in §7 (five levels).
CAP 06 · Claude Browser Extension
Turns any tab into context for Claude: read a web RFP, synthesize a report on the fly, operate dashboards without an MCP. Agentic capability · requires awareness of what you authorize. Do not use with exposed sensitive information.
CAP 07 · Scheduled Tasks
They turn Claude from reactive to proactive. Two high-leverage automations: morning inbox classification with prioritization + a weekly pre-drafted status report on Thursdays [13]. Only automate stable templates; automating a bad one sets the problem in stone.
CAP 08 · Dispatch BETA
Dispatch is the piece of the digital staff that comes closest to having a remote assistant · the digital office no longer ends where your desk ends. Anthropic keeps it in beta as of this edition's closing [23], which means its behavior may change between Cowork versions · the method asks you to adopt it but to validate the flow every time you update the app. Canonical usage pattern: in transit, in a waiting room, or while walking, capture specific edits to the filesystem that would otherwise be lost between the moment of the idea and returning to the desk. Typical cases · adjusting a line on a resume before an interview · adding a point to the TAREAS.md of an active project · scheduling a follow-up at the end of a pending conversation · seeding persistent memory with fresh learning. The operation with canonical prompts lives in the Runbook · superficies emergentes.
§7The structure · five sectors in the personal office
The eight capabilities of Anthropic (§6) by themselves are loose ingredients. The division into five sectors is the proposal of MetodologIA that brings them together in a coherent architecture. Let's go back to the level map of your virtual office introduced in §3: twelve levels where you choose the right adoption depth for the task at hand. The five sectors are available at every level — they are horizontal bands that cross the whole map, accessible from day one regardless of which level you are operating on. They are not floors: they are the coexisting resources that the map offers simultaneously.
The five sectors receive your intention and materialize it in their corresponding context layer. Foundations houses the stable professional identity that defines who you are before each task. Base houses the active areas of responsibility — Mail, Delivery, Pre-sales — where your day-to-day operates. Core houses the live files by client, initiative, or piece under construction. R&D houses the ideation sessions that do not yet deserve a formal Project but could become one. Maintenance houses the temporary rituals (daily, weekly, QBR) and automated cadences that keep the system alive between sessions.
This five-sector architecture maps to the five-layer physical structure of Cowork, which is the heart of the framework for turning Claude Cowork into a personal Jarvis. The public body of knowledge organizes the product with three structural layers (Root, Estaciones, Projects) described as the backbone of the Jarvis [13]; to that base, MetodologIA adds two functional layers that extend the system: Lab for ideation sessions that are not yet projects, and Cadencias for the temporary rituals that keep the system alive. Each layer is a Cowork Project; each sector is the experience of operating in that layer when the task requires it.
7.1 · Four COOL principles · guiding framework
Before descending to the five sectors, it is worth anchoring the framework that gives them meaning. COOL is the framework that organizes the life cycle of any piece of knowledge into four principles. Clarify (Clarify) is to absorb what happens outside (emails, meetings, decisions, data, documents) into the system without loss and with a timestamp, making the context and intention explicit. Organize (Organize) is to place each capture in the correct place in the system according to a stable taxonomy, naming without technicalities, and predictable conventions. Optimize (Optimize) is to validate how to execute with precision before acting · activate the tools the task requires, load the right context, choose the appropriate model and skill, and calibrate the scope. It is the pre-execution filter that ensures each Liberate comes out right the first time. Liberate (Liberate) is to produce and deliver the artifact that the rest of the world needs (status report, minutes, communication, documented decision) with the precision that Optimize has already validated.
The core O·O (Organize + Optimize) is the stable engine of the framework — every element of the system goes through organization to find its place and through optimization to validate its execution. The C at the input and the L at the output are contextual: they adapt their semantics to the domain (Capture in notes, Compose in mail, Care in well-being, Craft in writing). The structural virtue of Jarvis is that each principle finds its exact home within the five sectors of the system. Clarify lives in the root MEMORY.md and in the MEMORY.md files of the stations (Foundations and Base sectors). Organize lives in the routing map of the root CLAUDE.md and in the naming discipline. Optimize lives in the moment before each action · activation of the correct MCP connectors, loading of relevant skills, choice of plan and model, validation of the loaded context. Liberate lives in the Projects of the Core sector and in the skills that produce the deliverables.
7.2 · How to understand the sectors · scaffolding, not categories
Three clarifications that should be established before going down into the hierarchy, because they are the difference between using the framework fluently and getting confused at the first ambiguous case.
1 · The levels are scaffolding, not feature categories. Each level describes the hierarchical depth from which you operate on an artifact, not a fixed class of thing. The same object can live on different levels depending on the verb you exert on it. Example: creating a plugin is the work of the Core sector (Project with custom instructions, test files, versioning cycle); using that same plugin appears as a tool within a Station of the Base sector (Mail that invokes the drafts plugin in your voice). Same plugin, two sectors, two verbs.
2 · To the machine, everything is a path.Claude doesn't natively understand "Station" or "Project." What it sees are folders, files, and CLAUDE.md at different depths of the filesystem. The five sectors are a framework humanfor you to organize coherently; the machine reads them as a directory tree and resolves by proximity. The level is our language, the paths are its. That's why naming discipline (kebab-case, numeric prefixes, README.md per level) matters more than conceptual elegance: that's where the two planes meet.
3 · Each level materializes as a Cowork Project.They are not loose folders or metaphors. Root is a Cowork Project with its own root CLAUDE.md and identity instructions. Each Station is a Cowork Project with its own area-specific custom instructions. Each Project in the Core sector is a Cowork Project with custom instructions for the client or initiative. Each Lab session is a Cowork Project with its four canonical files. Each Cadence is a Cowork Project (the one for daily planning) or a group of scheduled tasks. Same atom, different roles.This is what makes the framework concrete: turning Claude Cowork into a personal Jarvis is exactly creating a tree of Cowork Projects that respects the five sectors, where each one inherits context from the parent and specializes the child.
With that lens ready, the five sectors cease to be labels and become operational instructions: create a Cowork Project for your Root, another Cowork Project for each Station, another Cowork Project for each client or initiative, another Cowork Project for each open Lab session, another Cowork Project for your cadences. Done · you've started your Jarvis.
Digital Sovereignty in a nascent state · your Jarvis fits in a folder tree that no provider can take away from you. Each active project has its own TAREAS.md (5-column Kanban · NOW ≤ 3) · each level is an autonomous workstation.
_ESTRUCTURA.md. Five sectors (00 to 04) plus a self-extending memory. The 8 stations of Sector II live inside 01_Estaciones/. The DBR-ABR pyramid generates traceable artifacts in its subfolders. MetodologIA · Personal Jarvis OSFive sectors that separate what doesn't change (your identity) from what moves each month (your active files). The self-extending memory stitches everything together and grows on its own between sessions.
7.3 · Sector I · Foundations · Root · stable identity
Sector I · Foundations
Materialization: a Cowork Project named 00_Root with your stable professional identity. Content: a global CLAUDE.md with role, seniority, main methodology, tone and format conventions, language per document type, principles for stakeholder communication, prudence rules (do not send without review, do not fabricate figures, mark assumptions). Inherits to: all Stations.
7.4 · Sector II · Base · Stations · areas of responsibility
Sector II · Base
Materialization: a Cowork Project for each stable area of responsibility. Typical for a knowledge worker: Delivery (active delivery), Pre-sales (proposals and RFPs), People (coaching and feedback), Comms (steering and direction), optional Learning (relevance auditing). Content: a sub-CLAUDE.md with area conventions + skills + scheduled tasks + plugins in use. Inherits from: Root. Inherits to: the Projects in the next sector.
7.5 · Sector III · Core · Projects · active files
Sector III · Core
Materialization: a Cowork Project for each active file in your three professional life dimensions · client (consulting, freelance, advisory), employment (internal work projects, initiatives with your employer) and entrepreneurship (own projects, side projects, products in development). Typical content: charter, current plan, status reports, risk register, stakeholder organization chart, internal glossary, custom instructions with adopted tone and domain format. Inherits from: the corresponding Station. When the file is closed, the Cowork Project is archived as a reference for post-mortems or new opportunities; it is not deleted.
The virtue of this structure is that it separates the stable from the changing. Your identity as a knowledge worker (Foundations sector) does not change with each client; your areas of responsibility (Base sector) change over years; your active files (Core sector) change over months. When the context is organized this way, the model always has the correct information without you having to repeat it, and it never crosses information between clients that could confuse a meeting minute or a communication.
7.6 · Sector IV · R&D+i · Lab · ideation sessions
Sector IV · R&D+i
Materialization: a Cowork Project for each open Lab session. Content: four canonical files · notas.md (exploratory notes), hipotesis.md (what is being tested and what happens if it works or not), referencias.md (cited sources) and decision.md (graduate to Project · close as a learning · wait for a trigger). Inherits from: the corresponding Station. Transversal nature: it operates on the three structural sectors (Foundations · Base · Core) without belonging to any of them.
Sector IV introduces an explicit space for everything that is not yet a formal Project but could become one. The operational question that motivates its existence is: where do ideas that are worth exploring but do not yet deserve a commitment of time, budget, and stakeholders live? Without Lab, these ideas live in scattered chats or get lost. With Lab, each idea has its own Cowork Project with the minimum discipline to graduate to a formal Project or be cleanly closed, preserving the learning.
A Lab session is a unit of exploration with four canonical files. The first file is notas.md, where free-thinking notes are accumulated during the exploratory phase. The second is hipotesis.md, where it is explicitly stated what is being tested, what would happen if the idea works, and what would happen if it does not. The third is referencias.md, where consulted sources with traceable citations are accumulated. The fourth is decision.md, where the session's outcome is documented: graduate to Project, close as preserved learning, or wait pending an external trigger. The folder structure follows the convention Lab/YYYY-MM-tema-corto/ within the corresponding Station.
A typical Lab session lasts between two and twenty hours distributed over one to four weeks. If in four weeks the session is not closed or graduated, an alarm from the cadence system marks it as deadwood and proposes it for archiving in the next review. Graduating from Lab to Project requires meeting three minimum criteria: the hypothesis was validated with empirical evidence and not just intuition, there is an explicit time commitment from the person responsible, and there is an identified sponsor or stakeholder who validates the progress. When all three criteria are met, the Lab folder is moved to the Projects folder with a promotion file that documents the historical context and accumulated learning.
7.7 · Sector V · Maintenance · Cadences · temporal rituals
Sector V · Maintenance
Materialization: a Cowork Project named 04_Cadencias that hosts the six canonical rhythms and their activation methods. Content: six recurring rituals with their own discipline · DBR (Daily Business Review · 10 min) · WBR (Weekly Business Review · 45 min) · MBR (Monthly Business Review · 60 min) · QBR (Quarterly Business Review · 90 min) · ABR (Annual Business Review · 120 min) · Audit monthly (15 min · 6-question rubric). Nature: unlike the previous sectors, which are containers, Cadences are recurring moments that make Jarvis touch your system again, ask you what is necessary, and leave a record. Adoption: calendar first, guided prompt later, scheduled task when the habit is already stable.
Sector V delivers Digital Sovereignty through rhythm. While the other sectors ensure the system is well-organized, Maintenance ensures that the system is alive over time. The cadence is not "another prompt": it is a ritual with a set time, a conversational guide, and written evidence. Your Jarvis acts as a facilitator: it opens the right conversation, asks the minimum necessary, summarizes what was decided, and leaves an artifact in 04_Cadencias/.
| Activation Layer | What it solves | How to use it | When to adopt it |
|---|---|---|---|
| Calendar | Book the time and prevent the cadence from depending on memory or motivation. | DBR/WBR/QBR agendas with recurrence and a description of the ritual. | From day one. |
| Assisted Prompt | It simplifies the session: the AI guides you, asks what's necessary, and produces the record. | You open Cowork at the scheduled time, execute the Runbook prompt, and validate the artifact. | When you are learning the habit or adjusting the method. |
| Recurring Task | Turns the AI into a proactive facilitator: it shows up, prepares context, and asks for your confirmation. | Cowork scheduled task in supervised mode: it asks, summarizes, proposes, and records; it doesn't send or delete anything without an OK. | After 2 weeks of stable manual execution. |
The three layers don't compete. They stack. The calendar protects the time; the prompt lowers the cognitive load; the scheduled task professionalizes facilitation once you know what should happen. The adoption rule is prudent: first manual DBR until you have five real executions, then WBR to close the week, and only then convert the DBR or WBR into a recurring task.
The first ritual is the DBR, which occurs every morning for ten minutes. Its function is to triage the day with a maximum of three priorities, prepare for meetings, and detect risks. The second ritual is the Daily Close, which occurs at the end of the day: it captures learning, updates memory, and sets the stage for tomorrow's plan. The third ritual is the WBR, which gathers the daily plans and produces a weekly reading of compliance, patterns, and adjustments. The Weekly Retro complements the WBR with three reflective questions. The QBR audits the entire system and decides what to archive, open, or refactor for the next quarter.
Sector ↔ Step Equivalence. The Playbook groups the method into 5 sectors with Roman numerals. The Runbook executes the method in steps with Arabic numerals. This table translates from one map to the other.
| Sector (Playbook) | Steps in Runbook | Operational Outcome |
|---|---|---|
| Pre-flight | Step 0 | Folder + Authorized Cowork |
| I · Foundations | Steps 1-2 | Root CLAUDE.md + MEMORY.md + voice-principles |
| II · Base · Universal | Step 3 · Mail · Step 4 · Documents · Step 5 · Deliveries | Universal stations (mail · doc creation · deliverables) |
| II · Base · Dedicated | Steps 6-10 · Personal Finance · Performance · Study · Job Search · Publishing | Dedicated stations with sensitive data |
| III · Core · Chat Projects | Step 11 · Chat Projects (cloud · no filesystem) | Thematic project in the Anthropic cloud |
| III · Core · Cowork Projects | Step 12 · Cowork Project P-NNN | Living file per client or initiative |
| IV · R&D+i | Step 13 · Lab session · Step 14 · Mini-app | 4 canonical files + vibe-coded mini-app |
| V · Cadences | Step 15 · 6 rhythms (DBR · WBR · MBR · QBR · ABR · Audit) · Step 16 · Scheduled task | Automatic rhythm and portability of your context |
| Optimization | Steps 17-21 · Skills · Connectors · Capabilities · Configuration · Audit | Disciplined growth of the Jarvis |
| Advanced · TAREAS canon | Steps 22-26 · TAREAS.md · sub-task T-NNN · CLAUDE.md decomposition · external plugin · Excellence Loop | Autonomous task control when 3+ live projects |
| Advanced · repo layer | Steps 27-30 · deserve a repo? · turnkey scaffold · worktrees · vault + mirrors + archiving | Commission graduated to a git repo with private vault, parallel desks and portability |
7.8 · Your Jarvis by trade · three office templates
The five sectors are the skeleton; your trade gives it a face. The §4.5 (ICM) lesson is vivid here: the layers don't change, the labels do. The routing CLAUDE.md, each station's CONTEXT.md (voice + process), the skills that plug in where needed — that architecture stays the same. What changes is what each station is called, what its context says, and which skills are wired in. Three real offices:
- Content creator — stations
/script-lab(idea→script),/production(script→piece),/distribution(piece→channels). Each with its ownCONTEXT.md(voice, process, per-channel rules). - Freelancer / consultant — one station per client (
/client-alpha,/client-beta) with isolated context (no bleed), plus/templatesand/business-dev. Onboarding a new client = copy the structure, write aCONTEXT.md, add one routing line. - Developer —
/planning,/src,/docs,/ops. The routing table adds a Skills column (Layer 3 of §4.5): wire testing/doc skills only into the station that needs them.
The station-boundary heuristic: if you ever wish Claude would forget what it just did and focus on something else, that's a station boundary. Build yours in four steps: (1) list your 2-4 stations; (2) write a one-page CONTEXT.md each; (3) write the root CLAUDE.md with a routing table + naming conventions; (4) start and adjust — context files are living working notes, not finished documents.
§8Operational implementation · concrete structure
The how lives in the Runbook. This Playbook explains the what, what for, and why · what files make up the textual substrate, how the rules are stacked, what the logic of levels is. The templates .md, the prompts in SPEC with inputs {[snake_case]} and the executable checklists live in the Runbook · Personal Jarvis OS (file jarvis-os-claude-runbook-jarvis-os.html in your folder). Both form a pair · each stands on its own.
The previous sections established what Cowork is, why its structure differs from Chat, and how it is organized into five levels. This section gets into how to build the system concretely, step by step, with the folder structure, the files that make up the Jarvis's textual substrate, the initial configuration prompts, the flows by capability, and the operational efficiency rules that keep the system healthy. The mental rule when reading this chapter is: replicate first, optimize later.
8.1 · CLAUDE.md and MEMORY.md · the two pieces that support the Jarvis
The Jarvis's textual substrate lives in two plain text files that Cowork reads at the beginning of each session. The first, CLAUDE.md, is the instruction manual that tells Cowork how to behave: stable role, conventions, rules of prudence, and references to other files when more detail is needed. The second, MEMORY.md, is the notebook that saves what Cowork should remember between sessions: learnings, captured preferences, active projects, decisions made. Both are plain text files with no exotic format or convoluted syntax; any editor can open them, any human can read them, and Cowork writes them for you during the first few conversations, so you don't need to know advanced Markdown to build your system.
The central insight is that these two files together operate as a personal operating system. CLAUDE.md sets the rules of the game and points to detail files only when needed, which keeps the model's context clean. MEMORY.md accumulates the intelligence captured in each session, which makes Cowork perform better over time instead of remaining static. The more you ask Cowork to remember something, the richer the system becomes.
8.2 · Folder structure · building your Work in Claude Desktop from scratch
The first operational step is to create a dedicated folder that will be the backbone of the Jarvis. In your Documents folder, create a folder named exactly Trabajo en Claude Desktop and inside it, place three items: the file CLAUDE.md root, the file MEMORY.md root, and a subfolder named 00_Recursos where the detailed documentation lives, such as your voice principles file, glossaries, templates, and technical references. The prefix 00_ in the Resources folder is an alphabetical ordering convention that ensures this folder appears first in the listing and is visually distinguished as the base of the system.
Once the structure is created, open Cowork, select the Trabajo en Claude Desktop folder as the working directory and mark it with a star so that Cowork loads it by default in each new session. A complementary recommendation that is worth the minute it takes: install the free editor Obsidian and open the Trabajo en Claude Desktop folder as a vault, which gives you a much more readable view of the Markdown files than what plain text editors offer. An important operational note on permissions: Cowork is strict about file access. The files must be inside the previously selected working directory for Cowork to detect them. This restriction is not a bug but a security feature.
8.3 · Root CLAUDE.md · the three critical sections that make it work
The root CLAUDE.md file contains three sections that turn it from an ordinary text into the operational heart of the system. The first section is the Memory System, which materializes in two simple sentences: an instruction that says "at the beginning of each session, read MEMORY.md before responding" and another that says "when I say remember this, write it to MEMORY.md". These two sentences are what activate persistence between sessions; without them, MEMORY.md is just another file with no function. The second section is the Routing Map, a table that tells Cowork which station folder to load for which type of task, which allows that when you ask it to "draft an email" Cowork knows to load Mail, and when you ask it to "categorize these expenses" it loads Personal Finance. The third section is References, a block of file pointers from the Resources directory that Cowork only reads when needed, keeping token consumption low in each session.
The root MEMORY.md file, a complement to the previous one, has two canonical sections. The Memory section is where Cowork writes the learnings and preferences you ask it to remember over time. The Active Projects section is where Cowork tracks what you are working on and its progress. These two sections evolve on their own: every time you finish a productive session with the audit covered in §8.10, Cowork extracts what it has learned and writes it in the correct section.
8.4 · Voice principles · extracting your voice so Cowork can write like you
One of the system's highest-leverage levers is teaching Cowork how you write so it can draft emails, documents, and communications that sound like you and not like a generic AI. The standard public approach provides a voice extraction prompt template that can operate in two ways. If you have Gmail connected, the prompt instructs Cowork to read your last thirty sent emails and extract your writing patterns from them. If you do not have Gmail connected, a variant of the template asks you to directly paste five representative samples of your writing.
The result of the extraction is written to a file voz.md inside your 00_Recursos folder. That file grows over time: every time you edit a draft that Cowork provides and ask it to "compare my version with yours and save these preferences," Cowork adds a new entry to the file. As a reference for magnitude, a mature voice principles file is usually around one hundred and fifty lines long. The operating rule is: always edit the output with human judgment, and explicitly ask Cowork to update the voice file when you notice your edit was substantive.
8.5 · Stations · universal and dedicated
Once the root level is seeded, the next step is to build the Level 1 stations. The operational distinction between station types defines how the system's intelligence is organized. The universal stations handle activities that cross all areas of your life or role, where the archetypal example is Mail because you write emails to your team, your clients, your suppliers, your friends, and your family, and the rules for how you write emails apply in all those contexts. The dedicated stations handle a specific area with its own rules and data, and the archetypal examples are Personal Finances, Newsletter HQ, or Performance Reviews. Each station, whether universal or dedicated, replicates the structure of the root level.
8.6 · Mail · a step-by-step universal station
The process of creating Mail illustrates the pattern that repeats for any station. You take the Mail prompt from the public template library, paste it into a new Cowork conversation, and Cowork automatically creates the subfolder Correos inside your Claude Desktop Workspace, with its own CLAUDE.md and MEMORY.md. Next, the same prompt instructs Cowork to search your last four weeks of sent emails via the Gmail connector and extract specific email patterns from them: your default greeting, your usual signature, your typical level of formality, the filler words you use and those you avoid, and the average lengths of your emails by recipient.
The key concept that this station activates for the first time in the system is rule stacking. When you ask Cowork to draft an email, it first reads your voz.md root to know that you write directly and transparently and avoid corporate jargon, then it reads the CLAUDE.md from Mail to apply specific email conventions like greeting and signature. The result is an email that sounds like you and respects your channel conventions.
8.7 · Personal Finance · a dedicated step-by-step station
Personal Finance illustrates the dedicated station pattern and also opens the conversation about sensitive data privacy. The operational process is straightforward. You share your credit card statements from the last twelve months with Cowork, either as PDF files or CSV exports, in a new conversation. You paste the Personal Finance prompt from the public template library, and Cowork automatically creates the station with its CLAUDE.md, MEMORY.md, and Resources, reads each transaction, proposes a taxonomy of spending categories, breaks down your spending by category, and builds a master spending tracker in spreadsheet format that is saved inside the station.
The system performs better with every corrected error. If Cowork classifies a Canva subscription as a "freelancer payment," you correct it once by explicitly telling it "this is not a freelancer, it's a subscription tool," and Cowork writes that rule to Personal Finance/MEMORY.md. The next time it loads the new month's statements, it will categorize Canva correctly. This dynamic of correction becoming a persistent rule is what differentiates an assistant that learns with you from one with amnesia. A privacy note worth stating explicitly: the decision to share financial data with Cowork is strictly personal and depends on your risk appetite, your plan's policies, and, if you work in a corporate organization, the applicable Compliance guidelines. If you are not comfortable, do not do it and build the station with synthetic data as a learning exercise.
8.8 · Workspace growth · start slow, scale by necessity
The most important operational advice for someone just setting up their Jarvis is to build slowly. A mature workspace can have thirty or more stations, but getting there always starts from a core of two or three well-built ones. The common trap of initial enthusiasm is trying to set up the entire system in a weekend, which produces a demonstration-only Jarvis that looks impressive in a screenshot but isn't used. The disciplined rule is: build Mail and another station in your most frequently used area, live with them for two or three weeks, and only create a new area when a specific pain point demands it.
8.9 · Three levels of usage complexity · concrete examples
Once the structure is seeded, the queries you make to Cowork operate at three ascending levels of complexity. The simple level solves a specific problem using the routing map. If you take a screenshot of a sales copywriting framework and tell Cowork "save this where it belongs," Cowork consults the routing map in the root CLAUDE.md, identifies that the correct file is the copywriting frameworks reference, and archives the screenshot within the correct file without you having to tell it where.
The intermediate coordinates two or three capabilities to produce a usable deliverable. Imagine you finish a meeting and tell Cowork, "I just got out of a meeting, draft the follow-up email to all attendees." Cowork checks your calendar to identify the most recent event, reads the transcript if it exists, loads the station corresponding to the meeting type, applies the email voice rules, and produces a draft follow-up email that respects your usual tone and format.
The advanced orchestrates the entire system to produce a composite artifact. You tell Cowork, "the client just approved phase two, set up the project in Asana." Cowork creates the standard epics and stories from your template, assigns owners according to your conventions, sets the dates based on the current plan, and leaves the board ready for refinement. This final layer, possible only when the full system's rule stack is live, is what justifies the initial setup effort.
8.10 · Session Audit · /session-audit
The disciplined closing of each session is the ritual that keeps Jarvis alive over time. The recommended practice is to run an audit at the end of each productive conversation that scans the entire conversation for principles and preferences that Cowork should remember for future sessions. The public body of knowledge provides a skill called /session-audit that automates this sweep. Without this ritual, learnings evaporate when the chat is closed, and the cognitive investment you made in polishing the response is lost for the next session.
8.11 · Three rules for token and cost efficiency
The system scales well if it respects three operational rules. The first rule is to keep the root CLAUDE.md under three hundred lines. Cowork loads it in every session, so every unnecessary line is a recurring cost. The second rule is not to repeat the same rule in multiple files. If your root voice principles file already says "do not use corporate jargon," do not re-declare that rule in Emails or Newsletter HQ; each rule has a single home, and the other files inherit it through rule stacking. The third rule is to use the balanced model by default and reserve the higher-capacity model for tasks with three or more interdependent steps. Sonnet is sufficient for most daily work and operates at a fraction of the cost of Opus.
8.12 · Capabilities in action · canonical examples by capability
Capability one · creating and editing local files
Canonical case: one hundred photos of receipts placed in the workspace folder, with the instruction to generate an expense report in Excel with fields for date, vendor, category, amount, and a totals row, marking with the VERIFY tag the rows where the OCR was not clear. Cowork reads each image, extracts the structured information, produces the Excel file directly in the folder, and leaves the rows that require human review flagged.
Capability two · persistent memory as an active exercise
Canonical adoption exercise: share a meeting transcript with Cowork and ask it to "summarize this transcript in a maximum of two hundred words." Edit the delivered output to adjust it to your actual preference, and then ask it to "compare your version with mine and save these preferences so you remember them next time." Cowork detects the changes you made, infers the underlying preferences, and writes them to MEMORY.md.
Capability three · combined connectors
The true power of connectors emerges when two or more operate in the same query. Canonical case: comparing the meeting transcript from Drive against the notes taken in Notion. You ask Cowork, "compare the transcript from Drive with the notes in Notion and tell me what commitments were made in the conversation but didn't make it into the notes." Cowork reads both sources through the corresponding connectors, performs a cross-comparison in a single pass, and delivers the list of omissions.
Capability Four · Skills Built by Pattern Extraction
The canonical pattern: execute the flow manually with three real examples of the work you want to automate, provide iterative feedback until the output is exactly what you want, and only then ask Cowork to go back over the conversation and create a skill that captures that flow. Three rules: enable the Anthropic skill-creator in Customize, Skills, before you start; back up your skills in Drive; and always confirm the manual flow first before codifying it.
Capability Five · Cowork Projects That Write to Their Files
The most concrete operational difference between Cowork Projects and Chat projects is the direct writing to instruction files. In Cowork, it's enough to say "codify this principle," and Cowork writes directly to the Project's instruction file. The result: your Projects become more intelligent with each productive conversation instead of remaining static.
Capability Six · Browser Extension Warnings
The browser extension is a beta capability with its own risks of operating websites on behalf of the user [24]. The operational recommendation is not to rely on it for critical flows until you validate its behavior in your environment: start with supervised tasks, explicit authorized domains, and no sensitive information exposed.
Capability Seven · Scheduled Tasks That Compose Capabilities
The highest-value canonical case is the morning inbox classification, which combines three previous capabilities. Capability one comes in when Cowork takes your inbox zero workflow and saves it to a Markdown file. Capability three comes in when Cowork reads your emails through the Gmail connector. Capability two comes in when you give feedback during the first week and Cowork writes those corrections to MEMORY.md. The operational rule: configure only one scheduled task at a time, run it for a week in trial mode, and only then let it run automatically.
8.13 · Operational Differences Chat vs. Cowork · Comparative Summary
Before closing the implementation section, it's worth establishing three concrete operational differences between Chat and Cowork that appear time and again in daily work and justify living in Cowork by default if your role involves sustained management.
| Dimension | Chat | Cowork |
|---|---|---|
| File and Window Access | Cloud upload · twenty files per conversation and thirty megabytes per file according to the public source [14] · limited window that triggers compaction quickly | Access to the local file system within the sandbox directory · without the previous quotas applying · larger window by product design |
| Output Delivery | Response in the chat window that you copy and download manually | File ready in the working folder · ability to operate within external platforms like Notion, Drive, Gmail, Asana via connectors |
| Prompting Style | Task-oriented language · "review these photos and recommend a naming convention" | Result-oriented language · "I have fifteen photos in this folder, organize them into subfolders by theme with descriptive names" |
The most important mindset shift when moving from Chat to Cowork is in prompting. With Chat, you formulate the cognitive task ("recommend," "analyze," "evaluate") because the model can only think and return text. With Cowork, you formulate the desired result ("organize them," "convert to Excel," "send it as a draft") because the model can execute actions on your system. This phrasing inversion is the most valuable practical lever for getting the most out of Cowork from day one.
8.14 · Cadences · actionable prompts for six starting rhythms
Cadences are recurring rituals that keep Jarvis alive. They are not just prompts and they are not only calendar reminders. A cadence reserves time, guides a conversation, asks the minimum necessary, and leaves a traceable record. The goal is simple: reduce the friction of starting, closing, reviewing, and improving knowledge work.
The three activation practices are cumulative, not exclusive. Calendar protects the space. Guided prompt makes the session easier and more consistent. Scheduled task lets Cowork act as a supervised facilitator once the habit is already stable.
Daily Planning · 10 min
What it is. The morning ritual that turns the day into at most three outcomes.
What the AI asks. What changed, what matters today, what can be deferred, what blocks you, and what starts first.
Log. 04_Cadencias/planes/YYYY-MM-DD-daily-plan.md
Use. Start manually. Add a calendar reminder. Convert it to a scheduled task after five real executions.
Daily Close · 10 min
What it is. The closing ritual that prevents open loops from becoming tomorrow's noise.
What the AI asks. What closed, what remains open, what was learned, what tomorrow inherits, and what decision should be recorded.
Log. 04_Cadencias/planes/YYYY-MM-DD-daily-close.md
Use. Works well as a calendar block at the end of the day; automate only when you actually read the close.
Weekly Review · 45 min
What it is. A weekly reading of progress, stalled work, repeated friction, and next-week focus.
What the AI asks. What moved, what stalled, what created leverage, what repeated, and what should change.
Log. 04_Cadencias/repasos-semanales/YYYY-WW-weekly-review.md
Use. Schedule it first. Run the prompt manually for two or three Fridays before delegating facilitation.
Weekly Retro · 20 min
What it is. The learning ritual that turns the week into rules, templates, skills, or better constraints.
What the AI asks. What helped, what created friction, what should become a rule, what should stop, and what to improve next.
Log. 04_Cadencias/repasos-semanales/YYYY-WW-weekly-retro.md
Use. Pair it with WBR on Fridays or Sundays. Automate only if you are willing to validate memory updates.
QBR · 90 min
What it is. The quarterly governance ritual for stations, projects, labs, skills, connectors, and priorities.
What the AI asks. What changed in your context, what remains alive, what should be archived, and what the next quarter should prove.
Log. 04_Cadencias/repasos-trimestrales/YYYY-QN-qbr.md
Use. Always calendar it. Keep it manual until your weekly records are solid.
Monthly Audit · 15 min
What it is. A health check that removes unused projects, noisy tasks, stale memory, and unnecessary permissions.
What the AI asks. What is unused, what connector lost value, what task creates noise, what skill needs care, and what template is stale.
Log. 04_Cadencias/auditorias/YYYY-MM-monthly-audit.md
Use. Good candidate for a supervised scheduled task after two clean manual audits.
Implementation note. Start with Daily Planning, Daily Close, and Weekly Review. MBR and ABR remain mature extensions of the cadence pyramid, but they do not need to be your first prompts. First prove that the system can ask, summarize, and log with your confirmation; then convert the stable ritual into a supervised scheduled task.
§8bFive operative pieces of the TAREAS canon
The eight core capabilities are those that come with Cowork from Anthropic. The following five pieces belong to the Jarvis OS method and are not product capabilities: an operating pattern (Always Task Control), a principle (Markdown is canon and plugins are mirrors), a rule (NOW ≤ 3), an architectural pattern (control panel + dedicated canon), and a quality gate (Excellence Loop). They were empirically validated in the author's repo during the first elevation of May 2026, but their editorial role remains separate from the capabilities inventory.
8b.1 · Always Task Control
What. Every workspace in the Jarvis—root, sector, station, project, cadence—is autonomous workstation. Opening any level immediately reveals what is running there, without needing an external tool. The canonical file that materializes this is TAREAS.md with an inline Kanban of five columns: NOW · NEXT · BACKLOG · DONE · KILLED.
For what. Operational sovereignty applied to daily life. Eliminating the friction of "I have to open another app to know what I'm doing today." Any level of the system serves as a work interface at any time.
Why. Memory, routing, and cadences are not useful if there is no easy way to see what is active at the level where one is working. This pattern closes the loop between stable knowledge (CLAUDE.md + MEMORY.md) and live execution (TAREAS.md). It turns the Jarvis into an operating system where every level is operable as a front-end.
8b.2 · Markdown is canon · productivity plugin is an optional mirror
What. The method recommends keeping an external productivity plugin connected to the Jarvis—the reader chooses based on affinity: the one their team uses, the one that fits their visual flow, the one they already have connected. The rule when adopting it: Markdown is canon, plugin is mirror. Abstract sync convention — plugin ID as an inline suffix on each task (format [PROVIDER-ID]), manual sync during the weekly review (WBR), never automatic bidirectional.
For what. Digital sovereignty applied to productivity. Avoids SaaS lock-in and the trap of two sources of truth. If the plugin fails, changes its licensing, or is deprecated, the Jarvis remains operational from the local markdown.
Why. SaaS productivity rewards lock-in by design. The Jarvis OS neutralizes it by contrary design, without giving up the visual and collaborative value of the plugin when scale merits it. Coded trigger to authenticate the plugin: number of active cross-portfolio tasks above 20 sustained for 4 weeks, or the appearance of multi-person collaboration.
8b.3 · Anti-WIP · NOW ≤ 3
What. No workspace has more than three tasks in the NOW column simultaneously. If a fourth one arrives, one must first be closed or postponed. The repo's health-check automatically flags it with a WIP overload alert if the rule is broken in two consecutive weekly reviews.
For what. Focus enforcement. Eliminate the illusion of simultaneous progress on many fronts and return the operator to the mode of actually closing tasks.
Why. Sustained WIP > 3 is the documented root cause of the feeling "I work a lot but make no progress." The rule is anti-burnout applied to the execution plane, complementary to Rule 9 anti-burnout on the architectural plane (constitutions ≤ 200 lines).
8b.4 · Control panel + dedicated canon
What. Any CLAUDE.md that exceeds its target (≤ 200 root lines, ≤ 70 project lines, ≤ 50 station lines) is broken down into two: a control panel lean with routing anchors + rules + explicit pointers, and files *-canon.md or canon-operativo.md with the deep detail loaded on-demand via protocol in the MEMORY.md of the level. Zero loss of depth, 100% traceability via pointers.
For what. Scalability without cognitive collapse. The Jarvis grows in coverage without any file becoming unreadable. Decomposition is experienced as a sign of system health, not failure.
Why. The 200-line target was impossible without this pattern. Empirical validation in the author's repo (1633 lines distributed into 918 lines + 17 dedicated canon files, -44% without losing a single paragraph of content) confirmed this during May 2026. The pattern is replicable to any textual system that grows with use.
8b.5 · Excellence Loop
What. Internal rubric of ten criteria — foundation, veracity, quality, density, simplicity, clarity, precision, depth, coherence, value. Applied to the output, iterate until scoring 10/10 on each criterion. Deliver only the final version, with no traces of the iterative process.
For what. Internal version of the NotebookLM gate (D-05) when everything is sustained in the context window and external search does not apply. It sets the quality bar high even when there is no external evidence to request.
Why. High internal stakes (constitutions, canonical ADRs, contracts, formal letters, brand canon) deserve the same rigor as high external stakes (publications, major financial decisions, signatures). D-05 covers external verification; the Excellence Loop covers internal verification. They are complementary and coexist in the method.
Closing Mov. II
You have the eight core capabilities, the five operational pieces of the TAREAS canon, the five levels, and the canonical prompts in hand. → Next: Practice · six concrete ways to operate with discipline.
Co-create environments of abundance by democratizing digital and professional sovereignty, to the extent possible.Mission MetodologIA · canon
Movement III of V
III
Practice
Enablers of disruption.
§9Operational Glossary
Para el glosario operativo de ejecución (términos del día a día con su uso concreto), ver el Runbook · Glosario.For the execution-level operational glossary (day-to-day terms with concrete usage), see the Runbook · Glossary.
- Repository (repo)
- A git version-controlled folder. In the Jarvis, the rung a commission graduates to when it needs dated history, branches, off-site backup or code (§3.7).
- Task repo (T-NNN)
- Repo for a commission with a start and an end: built, worked, delivered and archived with its history intact.
- Project repo (P-NNN)
- Long-lived repo (the headquarters): multi-deliverable, with collaborators and its own cadence; it persists.
- Armored dossier
- Office metaphor for the task repo: a dossier with dated minutes (git history) and a private vault.
- Vault
- The private remote repository (private GitHub): off-machine backup with an audit trail of who changed what and when.
- Worktree (parallel desk)
- A second workbench on the same repo: test a draft on one desk without touching the good version on another. One scope per desk; cleared when done (§3.7 · Runbook Step 29).
- Mirrors
AGENTS.md/GEMINI.mdfiles auto-generated fromCLAUDE.md· never hand-edited.- ICM
- Interpretable Context Methodology (arXiv:2603.16021): the folder structure is the assistant's architecture. Grounds the §4.5 layer protocol.
- Context layers (Layer 0-4)
- ICM layered-loading model: 0
CLAUDE.md(where am I?) · 1 routing · 2 stage · 3 reference (the recipe) · 4 artifacts (the ingredients). The critical at the edge, no filler in the middle. - Digital Sovereignty
- Ability to carry YOUR context (CLAUDE.md, MEMORY.md, voice-principles, projects, history, preferences, way of working) to any available agentic tool. You don't migrate the product · you migrate your own stuff. If Anthropic raises prices, deprecates capabilities, or disappears, your Jarvis survives because your context is flat files on your disk.
- Context Portability
- Technical sub-dimension of Digital Sovereignty. Your setup is plain text (Markdown) on your filesystem · any AI IDE with file access can read it and operate on it without retraining or reconfiguring you.
- Token
- Sub-word unit that the model's tokenizer processes. In Spanish, approximately three characters equal one token.
- Context Window
- Maximum capacity in tokens that the model can process in a single turn [1].
- Lost in the middle
- Empirical phenomenon demonstrating that LLMs pay less attention to information located in the middle of the context[1].
- Claude Cowork
- Anthropic's desktop application that turns Claude into a knowledge work operating system[14].
- CLAUDE.md
- Instruction file that Claude reads at login, used as a formal vehicle for stable memory and global rules[13].
- Jarvis
- Colloquial term spread in the Cowork community to describe a well-configured Claude Cowork that functions as an AI second brain[13].
- Project
- Cowork container that groups reference files, custom instructions, and conversations under a specific domain.
- Station
- Intermediate level of Jarvis · groups stable areas of responsibility on which Projects live[13].
- Skill
- Reusable package of instructions, templates, and scripts that Claude loads on-demand according to the task.
- MCP server
- Server that implements the Model Context Protocol and exposes external tools (email, calendar, managers) for Claude to invoke.
- Connector
- Specific integration between Claude Cowork and an external tool, materialized as an MCP server.
- Scheduled Task
- Task that Claude Cowork executes on a defined schedule without the user manually triggering it[14].
- Hyperspecific App
- A tiny, specific application that resolves a personal workflow bottleneck[15].
- Vibe Coding
- AI-assisted programming where the human describes the intent and the AI implements it[15].
- Context Engineering
- The discipline of designing the context provided to the model to optimize the quality of the responses[16].
- Lab
- Level 3 · ideation session with four canonical files (notes, hypothesis, references, decision) that graduates to a Project based on three criteria: empirical evidence, time commitment, and an identified sponsor.
- Cadences
- Level 4 · six canonical rhythms (DBR · WBR · MBR · QBR · ABR · Monthly Audit) that keep the system alive. Physical materialization in
04_Cadencias/{planes,repasos-semanales,repasos-mensuales,repasos-trimestrales,repasos-anuales,auditorias}/. - Daily Planning
- A ten-minute morning ritual that produces a daily plan with a maximum of three priorities.
- Weekly Review
- A thirty-minute Friday or Sunday ritual that reviews the week as a whole.
- QBR
- Quarterly Business Review · a ninety-minute quarterly ritual that audits stations, projects, lab sessions, skills, and connectors.
- Plugin
- Installable package that combines skills, commands, and MCP connectors into a single reusable unit across the team.
- Plugin Engineering
- The discipline of building plugins with explicit quality contracts, unit tests, versioning, deprecation policies, and peer review before promotion to official.
- Agent
- An autonomous AI worker assigned an objective that plans, executes, and validates the steps on its own within defined limits.
- Guardrails
- Explicit restrictions that limit what a model or agent can do. Autonomy without guardrails is a risk, not a benefit.
§10The six operating practices
Six operating practices that act on the technical substrate (tokens, context, attention), valid in any product evolution.
| Practice | Core capability it activates | Impact |
|---|---|---|
| 10.1 Conversation hygiene · close and reopen with discipline | Applies across the board, no product eliminates it | High · zero effort |
| 10.2 Put the context at the beginning · critical information at the start of the prompt | Directly mitigates the effect lost in the middle [1] | High · low effort |
| 10.3 Well-configured Projects · one per client or initiative | Capability #5 · Cowork Projects | High · medium effort |
| 10.4 Actively curated memory · periodic seeding and cleaning | Capability #2 · Persistent memory, conveyed in CLAUDE.md | Medium-high · low effort |
| 10.5 Artifacts · deliverables outside the conversational flow | Applies across the board | Medium · low effort |
| 10.6 Files over pasting · when it exceeds a thousand tokens | Capability #1 · Access to local files | Medium · zero effort |
§11The complementary practice · Apps, plugins, and agents
Think of the complementary paradigm as three levels of building. A Hyperspecific App solves a very specific personal friction: it does not need to serve anyone else and can change quickly. A plugin packages a proven pattern so several people can use it with the same quality. An agent executes a complete flow with greater autonomy, under explicit limits and human supervision. The three levels exist for one purpose: turning domain expertise into tools that reduce real friction.
The complementary paradigm to Jarvis materializes in three distinct but related artifacts: Hyperspecific Apps (personal tool), plugins (reusable package), and agents (supervised autonomous operator). All three start from the same philosophical point: deep experience in a specific domain is the critical skill for building powerful AI workflows [17].
11.1 · Hyperspecific Apps · the individual node
The Hyperspecific Apps are tiny, highly specific applications built through vibe coding, that is, a description of human intent followed by implementation delegated to AI, to solve a specific bottleneck in a personal workflow [15]. The core virtue is that they are built by the domain professional, not the engineering team, in hours or days instead of sprints. An App solves a problem that you feel and that only you understand with the necessary depth. It lives in your workspace, operates for your specific role, and is discarded at no organizational cost when it no longer serves you. The documented process has five verifiable steps: identify the problematic flow, map it in its entirety, identify the exact point where the app will add value, build it with AI assistance, and deploy it where the flow needs it [15].
For a knowledge worker, typical cases of a Hyperspecific App are pieces like a mini-form that captures a committee's decisions and archives them in a lightweight ADR format within the client's Project, a script that rotates retrospective templates among three formats to keep the team engaged, or a tool that takes the risk list from several parallel projects and classifies them according to a common scheme. The difference from looking for a commercial app is that the Hyperspecific App is made exactly for your flow and only for your flow, which eliminates the friction of adapting a general tool to a particular case.
11.2 · Plugins · the organizational node
The plugins are installable packages that combine skills, commands, and MCP connectors into a single reusable unit across the team, and are distributed via official or private stores with versioning discipline. Where an App serves one professional, a plugin serves multiple professionals on the same team or in the same area. Plugins support more sophisticated strategies for designing agentic work environments (what is colloquially known as plugin engineering): definition of explicit quality contracts, unit tests for critical behavior, a semantic versioning cycle with a CHANGELOG, scheduled retirement policies, integration with testing pipelines, and peer review before promotion to official.
The dual track for building plugins is important. Vibe coding produces functional plugins quickly but they are fragile to changes in the underlying product. The design of agentic work environments, in its most sophisticated form, produces plugins that are slow to build but robust to evolution, making them legitimate candidates for an organizational store with maintenance SLAs. The operating rule is: vibe coding for experimentation and rapid prototypes, agentic environment engineering when the piece is promoted to official.
11.3 · Agents · the autonomous node
The agentsare autonomous AI workers to whom you assign a high-level objective, and they plan, execute, and validate the steps on their own, without you guiding them step by step. You tell it, 'monitor my inbox every two hours and let me know if a critical email from my main client comes in using these three criticality criteria,' and the agent does it alone, deciding when to escalate to you and when to continue.
Building a reliable agent requires what is called design of agentic work environments, a discipline with five minimum components. First, a clear definition of the objective and success criteria. Second, explicit provision of the set of tools the agent can use. Third, explicit guardrails for what not to do (do not send emails to clients without human confirmation, do not delete files, do not expose sensitive information). Fourth, structured memory that allows the agent to learn from errors between executions. Fifth, an evaluation harness that measures if the agent is performing well and triggers alarms when it is not.
For a knowledge worker, typical agent use cases are pieces like an agent that monitors the program's risk register every Monday and automatically escalates risks that change in probability or impact, a deep research agent that, given a topic, looks for four to six verifiable sources and produces an initial brief, or a weekly closing agent that orchestrates the daily close, the weekly review, and the weekly retro in a single pass on Fridays.
11.4 · The natural progression · App, then plugin, then agent
The natural progression in the system is to first build as a Hyperspecific App to validate the pattern with minimal cost, observe if the friction the App resolves is repeated in two or more team colleagues for two to four weeks, invest the effort to package it as an installable plugin only when there is evidence of shared use, and promote the plugin to an autonomous agent only when the flow is predictable enough and the cost of error is bounded by solid guardrails.
The critical operational distinction is that Hyperspecific Apps are individual disciplines, plugins are organizational disciplines, and agents are autonomous automations with human supervision. An App can live in your workspace forever without anyone else knowing it exists; a plugin requires documentation, a quality contract, a distribution method, and an owner with maintenance responsibility; an agent requires all of the above plus operational guardrails, an evaluation harness, and a rollback plan. Confusing an incipient App with an immature plugin leads to over-engineering what should be lightweight.
11.4 · The four foundational skills of Jarvis
There are four personal skills that apply to any role, any domain, and any Station. They are the non-negotiable foundation of Jarvis and are installed before any domain skill. Each one resolves one of the four most common friction fronts in a serious interaction with a language model: understanding the input, not inventing data, structuring the output, and harvesting learnings before closing. The four follow the SPEC format (Situation · Prompt · Execution · Criteria) and the step-by-step prompts to create them with /skill-creator live in the Runbook · Personal Jarvis OS (Block B). Here in the Playbook, it is enough to understand what they do, when they are activated, and why they are the non-negotiable foundation.
F1 · input
skill · input-analysis · so Claude always understands you
For what. Before executing anything, Claude understands exactly what I asked for. It corrects typos, disambiguates intent, and enriches with context from the active Front. It prevents it from launching into doing something different from what I needed. It applies three strict passes: superficial correction, intent disambiguation (presents options when in doubt and waits for my choice), semantic enrichment from the active Front or MEMORY.md.
When it activates on its own. Any input with detected ambiguity, unusual abbreviation, multiple intents, implicit reference to previous context, or a high volume of heterogeneous information pasted at once.
F2 · veracity
skill · veracity-checker · zero signed hallucinations
For what. When the response contains figures, quotes, proper names, or specific claims, Claude marks with labels [SUPOSICIÓN] and [ESTIMACIÓN] everything that is not verifiable and proposes a source or next step to validate. It avoids signing off on deliverables with invented data. It closes each response with a brief section "Next verifiable step" of a single concrete action.
When it activates on its own. Any output with numbers, percentages, exact dates, textual quotes, URLs, DOIs, or bibliographic references. It never invents URLs, DOIs, ISBNs, or bibliographic citations.
F3 · structure
skill · frontload-prompt · optimal structure before processing
For what. When I am about to paste a long document or an extensive payload, Claude reorganizes the prompt before processing so that the important parts are at the beginning (role, task, constraints) and the material is at the end. It mitigates the 'lost in the middle' effect without me having to learn how to structure prompts. If the material exceeds 1000 tokens, it suggests uploading it as a file instead of pasting it.
When it activates on its own. When it detects a pasted document of more than 500 characters, an extensive JSON or CSV payload, a block between triple quotes, or when I explicitly say 'I'm going to paste' or 'here is this text'.
F4 · closure
skill · conversation-closure · harvest and close cleanly
For what. When the conversation reaches a threshold or changes topic, Claude proposes to close the chat and open a new one, first leaving an executive summary as an artifact and persisting the new principles that appeared in MEMORY.md. It avoids the anti-pattern of 'dumpster conversations' and turns each session into harvested learning.
When it activates on its own. Fifteen messages in the same conversation, semantic detection of a topic change, or the explicit command /cierre or /session-audit.
The step-by-step detail of how each one is created with /skill-creator, the parameterizable placeholders, and the test cases live in the Runbook · Personal Jarvis OS § Block B. The rule of Jarvis is not to add any domain skill before having these four installed and tested. Official Skills documentation at claude.com/skills.
11.5 · Official Plugins and Managed Agents · status May 2026
Two recent official announcements from Anthropic should be incorporated into the map because they define the operational frontier of Jarvis. First, the launch of official plugin support in Cowork (research preview, January 30, 2026) with eleven open-source plugins built by the Anthropic team itself:Productivity, Enterprise search, Plugin Create/Customize, Sales, Finance, Data, Legal, Marketing, Customer support, Product management, and Biology research. They serve as an educational base and as an example of how to compose a plugin with critical mass. The formal announcement lives at claude.com/blog/cowork-plugins, the gallery can be browsed at claude.com/plugins, and the developer repository is at github.com/anthropics/knowledge-work-plugins.
Second, the three new features in Managed Agents (May 2026) that change the economics of delegating agentic work. Dreaming is a scheduled process that reviews past sessions and agent memories, extracts patterns (recurring errors, flows where agents converge, shared preferences), and curates the memory so the agent improves between sessions; it is the systematized equivalent of a manual monthly audit. Outcomes allows writing a rubric of what "good" means, and an independent grader evaluates the agent's output against that rubric in its own context window; in internal benchmarks, it improved task success by up to ten points over a standard loop. Multiagent orchestration allows a lead agent to break the task into pieces and delegate to parallel specialists with their own model, prompt, and tools, with each step traceable in the console. Official documentation at platform.claude.com/docs/en/managed-agents/overview with dedicated sections for dreams, outcomes and multi-agent.
Today, Jarvis operates as a single conversation with many capabilities. The jump to multi-agent makes sense when a recurring task meets three conditions: it has clearly separable parts, these parts benefit from different models (Haiku to coordinate, Opus to produce), and there is a written quality criterion that a grader can evaluate. As long as these three conditions are not met, a well-structured conversation with skills and plugins is simpler and faster. Moving to multi-agent prematurely is the equivalent of buying industrial machinery for a home bakery.
11.6 · Claude Design · when the deliverable is visual
Anthropic Labs launched Claude Design on April 17, 2026, as a product in research preview available for Pro, Max, Team, and Enterprise. It runs on Claude Opus 4.7, the most capable vision model in the family. It is not a Cowork capability or a plugin: it is a separate surface, with its own environment, specifically designed to produce polished visual work such as designs, interactive prototypes, slides, one-pagers, and marketing material. For my Jarvis, it is an emerging piece worth knowing because it changes the economics of producing visual deliverables without opening Figma or Canva.
⚠ Operational notice · intense token consumptionClaude Design is powerful but intense in token consumption. The Opus 4.7 model costs more than Sonnet per turn, visual projects involve dense iteration with a lot of back-and-forth, and each inline refinement consumes its share of the budget. I use it when the visual deliverable justifies the cost, not as a default environment. For conversational or file-based work, I stick with Cowork. For code, I stick with Claude Code. Design is the lab I open intentionally, not the everyday kitchen.
The natural workflow is to describe what I need and let Claude build a first version. From there, I refine through conversation, inline comments on specific elements, direct edits, or custom sliders that Claude itself generates to tweak spacing, color, and layout live. When I give it access to the codebase or design files during onboarding, it automatically builds a design system with my colors, typography, and components, and that system is applied to every new project without me having to re-specify it. It imports from text, images, DOCX, PPTX, XLSX documents, codebase, or from the web with its web capture tool, and exports to PPTX, PDF, HTML, or directly to Canva. The cases where it shines most for Jarvis are pitch decks and presentations for the Delivery Front (from a rough outline to a complete on-brand deck in minutes), interactive prototypes for validating ideas, wireframes that are then passed to Claude Code for implementation, and marketing material for the Publications and Social Media Front. Announcement at anthropic.com/news/claude-design-anthropic-labs, app at claude.ai/design.
§12Application catalog for management
The catalog presents the ten classic project management cases (weekly status report, meeting minutes, risk register, PERT estimation, RFP analysis, retrospective, difficult communication, QBR preparation, written coaching, lightweight ADR) and two additional categories that require the specific capabilities of Cowork.
12.1 · Automated morning email classification · Mail
This workflow is publicly known as "Mail" in the open public use cases [13] and it is probably the biggest daily time-saver a knowledge worker can automate. The basic form: every morning, a scheduled task reads your inbox from the last sixteen hours using the mail connector, separates the emails into three categories (urgent action, requires response today, FYI), drafts initial replies for those requiring a response today in your learned voice via CLAUDE.md, and delivers a summary at the start of your day with everything actionable. You review, adjust, and send. Time spent in the inbox: on the order of fifteen to thirty minutes a day instead of the usual two hours.
12.2 · Newsletter or recurring communication "that sounds like me"
One of the best-known public use cases is generating newsletter drafts that maintain a personal voice [13]. The adaptation is the recurring communication to your main client or your team, where a consistent voice is part of the value. The technique: upload ten to fifteen examples of your previous communications that you consider well-written to the Project, declare the rules of your voice in custom instructions, and optionally create a specific Skill if the format is stable. From there, each new communication is drafted in a short conversation within the Project and comes out as an artifact ready for review.
§13Configuration · your Jarvis control panel
The complete operation lives in the Runbook. This section provides the mental framework of the configuration · summary by capability, three-color traffic light, monthly rubric, ISO 27001 roles. The copyable prompts (SPEC · inputs {[snake_case]}), the templates .md, and the step-by-step checklists live in the Runbook · Personal Jarvis OS (file jarvis-os-claude-runbook-jarvis-os.html in your folder).
The .md templates are the portable surface of Jarvis. A template is not decoration: it is context written once so you do not have to explain it again. Each file lowers friction because Cowork can read the role, rules, inputs, and expected output directly from your folder. It also protects Digital Sovereignty: if you later choose Claude Code, Codex, Antigravity, VS Code, or another agentic tool, your operating context travels as plain Markdown.
Configuration that fine-tunes Jarvis over time. Summary by core capability, key cross-cutting areas (plan, model, language, privacy), action traffic light, ISO 27001 roles, and monthly rubric.
13.1 · Configuration by capability · summary
| Capability | Critical configuration | Operating rule |
|---|---|---|
| 1 · Local files | Root directory · permission policy | Dedicated folder (not the full home directory). Read+write by default, execution only where required. |
| 2 · Persistent memory | Memory panel + root CLAUDE.md | Plain text, 500-1500 words, with professional identity [13]. |
| 3 · MCP Connectors | Scope · account · filters · token retention | Start with two. Validate for 2 weeks. Revoke after 60 days of non-use. |
| 4 · Skills | Official skills enabled + custom skills | Word/PPTX/XLSX/PDF from day one. Custom skills in a versioned repo. |
| 5 · Projects | Custom instructions · default model · 5-10 curated files | Not 30 files without a filter · attention gets diluted [1]. |
| 6 · Browser extension | Authorized domains · capture mode · cross-page persistence | Work domains only. Manual selection at the start. Persistence off by default. |
| 7 · Scheduled tasks | Cadence · trigger · actions · notification · rehearsal | Minimum 15 days in rehearsal or draft before using the "send" scope. |
13.2 · Cross-cutting configuration
Four cross-cutting areas that deserve a monthly review: plan and billing (which quotas are active, what new features have been added [11]); global default model (balanced Sonnet, each Project can override); language and region (aligns with the actual operating environment); privacy and data (opt-out of training, retention, deletion path · validate with Legal before pasting sensitive information even if the plan declares exclusion).
13.3 · Three-color traffic light
The most sensitive decisions on the control panel are best managed with an explicit traffic light system that classifies each action into three categories: what you can do with low risk, what you should do with reinforced judgment, and what you must not do under any circumstances until professional validation.
| Green · can | Yellow · should with judgment | Red · do not |
|---|---|---|
| Activate persistent memory and seed a stable professional profile | Activate Gmail and Calendar connectors after validating minimum scopes | Activate a connector that writes to client systems without human confirmation |
| Create Projects per client with custom instructions and reference files | Activate scheduled tasks in rehearsal or draft mode for at least two weeks | Activate scheduled tasks with a send scope without a prior rehearsal |
| Enable official Word, PPTX, XLSX, and PDF skills for deliverables | Upload documents classified as internal to the local filesystem | Upload signed contracts, personally identifiable information, or information classified as confidential without Compliance approval |
| Configure keyboard shortcuts and preferred appearance mode | Configure the browser extension with a scope limited to work domains | Configure the extension without domain restriction or with cross-tab capture permissions |
| Audit memory and file permissions monthly | Share a specific conversation after validating it contains no sensitive data | Share a conversation with a public link without previously auditing its content |
13.4 · Five access roles for a shared Cowork (ISO 27001)
When a station or a Project is shared among knowledge workers, it is advisable to establish explicit roles analogous to the five roles documented in the corporate Drive governance practice.
| Role | Capabilities | When to assign it |
|---|---|---|
| Manager | Creates, edits, shares, archives, and deletes · revokes MCP tokens · audits the system | Owner of the Jarvis · only seniors with explicit responsibility |
| Content Manager | Creates, edits, archives content but cannot delete or revoke tokens · can activate and deactivate connectors | Operators who keep stations alive |
| Contributor | Edits existing files and adds new content · cannot create stations | Personnel in training or temporary consultants |
| Commenter | Only adds comments and feedback · no write access | External stakeholders who validate deliverables |
| Viewer | Read-only · cannot execute tasks or invoke connectors | Auditing, internal demonstration use cases |
The operational rule for assignment is to scale permissions cautiously and revoke them with discipline. Start with the minimum role the person needs for their specific task, observe their usage for one to two weeks, and only then elevate the role if actual usage requires it. When a person leaves the team or changes roles, revoke their access the same day.
13.5 · Monthly configuration audit rubric
Each month, during the relevance audit, add fifteen minutes to go through the configuration panel with a mental checklist of six questions. First, does the persistent memory reflect my current professional situation, or is it outdated? Second, are there any unused Projects that should be archived? Third, has any connector been authorized for more than sixty days without being used? Fourth, is any scheduled task producing output that I no longer read or that is no longer useful to me? Fifth, has any of my own skills failed in recent weeks and needs review? Sixth, has a new feature appeared in my plan that I haven't explored yet and could give me leverage?
Mental rule for touching Cowork configuration.Every new capability activated is a new surface for errors and permissions to monitor; activate only what your next specific workflow requires and revoke what you don't use. The difference between a productive Jarvis and a Jarvis that becomes a risk lies in the disciplined use of the configuration panel, not in its sophistication. A small, lively Jarvis is worth more than a large, cold one.
§13bThe five drawers of the director's desk · how each workstation is configured
Each level of Jarvis—root, sector, station, project, cadence—is an autonomous workstation (§8b.1) · read as, "an independent operational workstation with everything necessary to work at that level without borrowing from the one next to it". And each workstation, when opened as a Cowork Project (the unit Cowork uses to group instructions, files, and conversations for a domain), offers five operational drawers that the director (you) configure so that the station operates coherently from the very first session. The drawers are not loose files: they are the five decision spaces that separate an orderly digital office from a pile of scattered notes.
The trick isn't to activate all five at once, but to know which drawer lives at which level and why. A root level needs all five. A small station can get by with three. A sub-task can get by with one. The method sizes the drawers to the actual friction of the level, not to the potential sophistication of the Cowork dashboard.
| Drawer | What lives here | Canonical Jarvis OS files | When to open it |
|---|---|---|---|
| 13b.1 · The regulations · the workstation's rules | The custom instructions (the written rules that Cowork reads when opening the Project · the "what this workstation does and how") of the level's Cowork Project · who operates here, with what tone, under what guardrails (the red lines that the workstation does NOT cross · what is forbidden to do here, without exceptions) · the workstation's operating system. | INSTRUCCIONES-PROYECTO.md · CLAUDE.md of the level · identity header · routing map · inherited operational declarations. |
Always · the regulations are non-negotiable. Without explicit regulations, the invisible director (Claude) improvises with the parent's heuristics, which may not apply to the level. Initial setup time · 10-25 minutes per new level. |
| 13b.2 · The files · what the workstation knows | The reference files that the workstation loads at the start of each session · contracts, briefs, templates, the living canon of the domain · the file cabinets with a view of the desk. | MEMORY.md of the level · 00-resources/ · canon-operativo.md · _INDICE.md · pointers to parent files that apply. |
When there is material that is reused in 80% of the level's sessions. If you need it always, it goes in the drawer. If you need it sometimes, don't contaminate the file · ask Cowork for it when you need it, don't leave it attached to the station. Anti-pattern · filling the drawer with everything you have; a bulky drawer degrades the model (lost-in-the-middle effect · when the desk is cluttered, what's in the middle goes unnoticed · §4.2). |
| 13b.3 · The staff switchboard · who the station talks to | The MCP connectors (the standardized "pipes" that Cowork uses to talk to external services), plugins (packages that add capabilities · they can come from Anthropic or your organization) and skills (reusable instruction sets that Claude loads on demand) that the station invokes to go out into the world · the phone panel that connects to email, calendar, managers, browser · the agentic satellite (§2.6 · browser extension that acts for you inside the browser). | Connectors activated in the level's Cowork panel · installed plugins applicable to the domain · own and official skills registered in memory/contexto/stack-tooling.md. |
When the level's flow crosses the desk's boundary. The Mail Station opens the switchboard to Gmail. The Personal Finance Station leaves it almost closed (sensitive data lives on disk, not in a connector). Rule · activate only what you will use this week; revoke what is not invoked in 60 days (§13.5). |
| 13b.4 · The colleague's notebook · what Claude remembers about you | The persistent memory that Cowork accumulates between sessions at this level · the seeded preferences, the learned principles, the mistakes it no longer repeats. The colleague with selective memory (§1). | The memory/ root folder that grows on its own with real use · shadow trackers (parallel tracking · one card per live project · lightweight summary of the current state) in memory/proyectos/ · distilled learnings in memory/aprendizajes/{tecnico,metodologico,humano,personal}/ · ADRs transversal (Architecture Decision Records · short records of each major decision that affects several levels) in memory/decisiones/. |
It is seeded on the first day with an explicit persistent memory ("remember this") and is harvested at the end of each session with the ritual /session-audit (§8.10). The notebook grows on its own if the director respects the ritual; it dies if it is not harvested. |
| 13b.5 · The cadence clock · the rituals that trigger themselves | The level's scheduled tasks · the scheduled reminders · the automatic triggers for the last Friday's MBR · the Sector V rituals that affect this level. | Cowork scheduled tasks pointing to this level (scheduled tasks that trigger automatically at the time you define) · 04_Cadencias/{planes,repasos-*,auditorias}/ with canonical prompts · cross-link to TAREAS.md of the level so that each cadence can re-prioritize the Kanban (the NOW/NEXT/BACKLOG board where the level's work lives). |
When there is a task that repeats with a stable frequency and predictable output · morning inbox classification, Thursday status report draft, Friday retrospective. Rule · only one scheduled task at a time; run it for two weeks in trial mode before scaling (§6 capability #7). |
13b.6 · Sizing the drawers to the level
Not all levels need all five drawers open. The method sizes according to the workstation type. Read the following table as a natural progression · the root level opens all five because everything is inherited from there, a sub-task level opens one because its life is short and its context is inherited from above.
| Level | Mandatory Drawers | Optional Drawers | Why |
|---|---|---|---|
Root (00 · Trabajo en Claude/) |
1, 2, 3, 4, 5 · all five | — | The root is the single source of truth for the system. Regulations, files, switchboard, notebook, and clock live here from day one because all lower levels inherit from here. |
| Sector (00_Recursos, 01_Estaciones, 02_Proyectos, 03_Lab, 04_Cadencias) | 1 · sector regulations (what lives here, what doesn't) | 2, 5 · files if the sector has a stable canon; clock if it has its own ritual (case 04_Cadencias). | The sector is organizational, not operational. Its job is declare the sector's contract and delegate operations to stations, projects, etc. |
| Station (Mail, Documents, Studio…) | 1, 2, 3 · regulations, files, switchboard | 5 · clock if the station has its own cadence (e.g., morning Mail sorting). | A station is a recurring channel with its own tone. It needs regulations (tone), files (templates), and a switchboard (mail, calendar). Drawer 4 is handled by the root. |
| Project (P-NNN-slug) | 1, 2 · project regulations and files | 3, 5 · switchboard if the project interfaces externally (client); clock if it has its own ritual (weekly status). | A project is a living file with TAREAS.md and concrete outputs. Drawer 4 is handled by the root; drawer 3 is inherited from the station, if any. |
| Lab session (YYYY-MM-topic) | 1, 2 · minimum regulations (hypothesis) and files (4 canonical files) | _ · Lab sessions last for days or weeks and die upon completion · drawers 3, 4, and 5 are inherited from the root. | The Lab is for bounded exploration. Its value is the final decision, not the infrastructure. A heavy setup kills the Lab's speed. |
| Sub-task (T-NNN-slug within a project) | 1 · mini-regulation (task.md with outcome) | _ · everything else is inherited from the parent project. | A sub-task is a multi-session chunk of work. The rule is to inherit as much as possible and operate lightly. |
The bulging drawer anti-pattern. Filling drawer 2 (files) with everything that could be useful. Cowork loads that drawer at the start of each session · every extra document is a token spent and diluted attention. The rule of the method · a file goes into the drawer when it is reused in 80% of the level's sessions. If you only use it sometimes, it stays in 00-resources/ and is loaded on demand (you ask Cowork to open it when you need it, you don't leave it attached to the station).
§14Critical Anti-patterns
Four anti-patterns apply across the board to any use of Claude (conversation-dump, pasting without framing, trusting eloquence, delegating judgment), and a fifth appears specifically when someone adopts the Jarvis paradigm without the necessary discipline.
Anti-pattern five · Showcase-Jarvis. Setting up a flawless Cowork design with all the Stations, all the Projects, all the connectors, and all the Skills, but not using it in actual work because the friction of configuration consumed the energy meant for using it. Symptom: five empty Projects, twelve authorized connectors that are never invoked, three Skills that sounded promising but you never tested if they work. Antidote: configure only what you will use this week, expand when a specific pain point requires it, not before. A small, living Jarvis is preferable to a large, cold one.
Closing Mov. III
You know the configuration, the catalog, the anti-patterns. → Next: Adoption · how to incorporate all this into your actual week.
My success is when my presence is no longer necessary.Ethical North of Movement IV
Movement IV of V
IV
Adoption
Four hours per week, twelve weeks, one Q.
§15Express Plan · 4h × week until the Q of full competency
The Express plan adopts the Cowork lens in eight blocks distributed over two initial weeks at 4 hours per week, for a total of 8 hours. The first four hours (week 1) install the three structural levels of the framework. The following four hours (week 2) activate the intermediate capabilities along with the functional levels (Lab and Cadences). Starting from week 3, you enter a sustained cadence of 4 hours per week for 10 more weeks, completing a quarter (12 weeks (1 quarter)) in which you achieve full competency with Jarvis.
Recommended cadence · four hours per week. One hour four days, or two hours two days, or four hours straight one day, depending on your schedule. What's critical is not the intra-week distribution but maintaining the 4 hours every week without interruption for the entire Q. Skipping a week costs two: one to regain context and another to move forward. The mental rule: 4h × week × 12 weeks (1 quarter) of full competency.
Block 1 · 30 min · Differentiation
Confirm you are working in Cowork, not Chat
If you still primarily use Claude in the browser, now is the time to migrate your knowledge work to the desktop app. The difference between Chat and Cowork is not aesthetic but architectural: the eight capabilities in §6 only exist in Cowork.
Block 2 · 60 min · Level 0 · Root
Create your global CLAUDE.md with a stable professional identity
Write in a plain text file what you want Claude to always keep in mind: role, seniority, methodology, domains, tone conventions, communication principles, rules of prudence. Keep it between five hundred and fifteen hundred words.
Block 3 · 60 min · Level 1 · Stations
Define three main Stations (Delivery, Pre-sales, People)
Create three folders or Projects that represent your areas of responsibility. For each one, write a sub-CLAUDE.md with the specific conventions for that area.
Block 4 · 90 min · Level 2 · First real Project
Set up a Project for your most active client within Delivery
Upload the charter, current plan, last three status reports, risk register, and internal glossary. Write specific custom instructions. Run a test conversation asking for a status draft; validate that it uses the Project's context correctly without you having to re-explain anything.
Block 5 · 60 min · Capability #1 and #6
Enable access to local files and, optionally, the browser extension
Configure the client's folder so Claude can read it. If you use the browser for client portals or web RFPs, install the extension and test it with a real page. Don't enable everything at once.
Block 6 · 60 min · Capability #3 · Connectors
Connect email and calendar, validate read access
Authorize the connectors for your corporate email and calendar. Give Claude a first test query: "summarize what's in my inbox from the last twenty-four hours and my schedule for today, in three sentences."
Block 7 · 60 min · Capability #7 · First Scheduled Task
Configure the highest-leverage scheduled task: morning triage
Configure a single scheduled task to start: have Claude prepare a summary of your inbox from the last sixteen hours and your day's agenda, with prioritization, every workday at seven in the morning.
Block 8 · 60 min · Defend · Feynman + audit
Full comprehension test and schedule a monthly audit
Explain to a colleague, without notes, the following points: the difference between Chat and Cowork, the eight core capabilities, the five-level structure, and which three operational practices you are being most disciplined in applying. If you hesitate at any point, that's your next gap. Schedule a recurring thirty-minute monthly meeting to audit your Jarvis.
Completion criteria.You will have completed the Express + Sprint plan when you can do five things without consulting this playbook: explain the difference between Chat and Cowork to a colleague, show your Level 0 CLAUDE.md, navigate to a real Project with its files and custom instructions configured, receive your functioning automated morning summary, and describe what automations you will add in the next thirty days.
§15bPlan alternatives · Slow and Accompanied
The Express Plan (4 weeks · 4h/week) is the default path. For those who don't have that intensity or prefer a different pace · there are three canonical alternatives · each with its own cadence · depth and commitment.
15b.1 · Full Plan · 12 weeks (default · already documented)
The standard method. 4h/week × 12 weeks = one quarter. Output at completion: a complete Jarvis · 5 populated sectors · 1 adopted cadence (DBR) · 1 active project. See §15 for detail.
15b.2 · Slow Plan · 3-Month Gradual
Cadence: 1 sector every 3-4 weeks · no pressure for quarterly closing. Total: ~3 calendar months but with a dedication of ~1-2h/week. Ideal for researchers · academics · people with fluctuating schedules.
| Month | Sector to seed | Minimum Output |
|---|---|---|
| Month 1 | Sector I Foundations | Root CLAUDE.md · MEMORY.md · extracted voz.md · 1 tested operational template |
| Month 2 | Sector II Stations · 2-3 depending on role | One active universal station (Emails or Documents) + one dedicated to the role |
| Month 3 | Sector III Project + Sector V Cadences · DBR | 1 active P-001 project + 5 consecutive DBR streaks |
Trade-off: takes 3× longer than the Express but allows for establishing a real habit without sacrificing other responsibilities. Pivot trigger: if Sector I is not consolidated in month 1 · review if it is the right time to build the Jarvis (see §5b).
15b.3 · Accompanied Plan · with a mentor or peer
Structure: 6 sessions with someone who has already built their Jarvis · one session per sector + one for closing. The mentor reviews outputs · points out anti-patterns · validates cadence. The companion does the work · they do not delegate construction.
| Session | Focus | Expected Output |
|---|---|---|
| 1 · Onboarding (60 min) | Pre-flight + Sector I seeded | CLAUDE.md + root MEMORY.md + voz.md |
| 2 · Stations (45 min) | 2-3 stations activated depending on role | CLAUDE.md per station + 1 real output produced |
| 3 · Project (60 min) | P-001 with outcome + DoD + TAREAS.md | Active project + first T-NNN executed |
| 4 · Cadences (45 min) | DBR + WBR adopted | 5 DBR files + 1 WBR executed |
| 5 · Audit + Configuration (45 min) | Health-check + 6-question rubric | First monthly audit executed |
| 6 · Closing + 90-day plan (60 min) | Post-onboarding maintenance plan | Consolidated cadence · next 3 milestones |
Trade-off: requires finding an available mentor (personal network · MetodologIA community · Ambassador program when it exists). Accelerates adoption by ~30% and lowers the dropout rate. If there is no mentor: Express or Full Plan · returns to the Accompanied plan in an audit session with a peer.
15b.4 · Comparison table of the 4 plans
| Plan | Duration | Intensity | Ideal for | Main risk |
|---|---|---|---|---|
| Express | 4 weeks | 4h/week high | Knowledge worker with bandwidth · first piece on day 14 | Burnout · dropping out in month 2 without a cadence |
| Full (default) | 12 weeks | 4h/week sustained | The majority · quarterly cadence · complete output | Perceived slowness in months 2-3 without visible checkpoints |
| Slow | 3 months | 1-2h/week fluctuating | Researchers · variable schedule · no crisis | Loss of momentum if the 3 months stretch to 6 |
| Accompanied | 6 sessions (~6 weeks) | 1h/wk + asynchronous | Those who learn best with peers · high historical dropout rate | Mentor dependency · steep post-mentorship curve |
Choose the plan at the start · change it if the first checkpoints show the pace doesn't fit. The method itself is a Jarvis: it iterates with evidence · not with willpower.
§16Adoption pace · three paths to 4h × week
All three paths share the base cadence of 4 hours per week. They differ only in how many weeks you sustain that cadence and what level of mastery you achieve.
Why cadence beats the sprint. Four hours per week sustained over 12 weeks yield more than 48 hours concentrated in an intense weekend. The reason is operational, not moral: Jarvis learns with you through the corrections you make in actual use, and for those corrections to exist, you need to have used the system under real pressure between configuration sessions. The concentrated sprint produces a showcase-Jarvis; the sustained cadence produces a living Jarvis.
§17Mastery Levels · User Rubric
Knowing where you are on the system's adoption curve allows you to plan the next steps realistically and avoids the frustration of comparing your incipient Jarvis with a mature one. This section provides a five-level rubric with verifiable criteria. Honest self-assessment against this rubric is the piece that sustains learning over time and should be performed quarterly as part of the systemic audit.
| Level | Name | Weeks at 4h | Time Milestone | Verifiable Criteria |
|---|---|---|---|---|
| 0 | Initiated | Week 1 | Day 0 | Root CLAUDE.md exists with the three critical sections · root MEMORY.md exists seeded with a professional profile · at least one productive conversation executed in the system |
| 1 | Operational | Weeks 1-2 | End of week 2 | Two well-configured stations · active voz.md with real sample extraction · one proprietary skill built by pattern extraction · monthly system audit scheduled on the calendar |
| 2 | Advanced | Weeks 3-6 | Month 1.5 | Four or more live stations with weekly use · at least one scheduled task operating flawlessly after a two-week trial · three proprietary skills installed and maintained · the twelve-level map applied as an explicit criterion for tool selection |
| 3 | Master · Q of full competence | Weeks 7-12 | End of Q (week 12) | Bridge architecture between NotebookLM and Cowork operating with documented handoffs · Project with COOL sub-folders replicated in at least three clients · Cowork risk register maintained quarterly · one team member trained by you to level 1 · first QBR executed |
| 4 | Multiplier | Weeks 13-24+ | Q2 and beyond | Two or more people trained by you to level 2 · proprietary skill published to the organization's private store · meta-charter contribution incorporated into the body of knowledge · measurable cultural change in your team |
Timelines for leveling up · 4 sustained hours per week.From Level 0 to Level 1 takes 1-2 weeks (4-8 hours) if you replicate the structure of the public template body without customizing it during the first month. From Level 1 to Level 2 takes another 4-5 weeks (weeks 3 to 6) because it requires the skills and scheduled tasks to accumulate evidence of real use. From Level 2 to Level 3 takes another 6 weeks (weeks 7 to 12), closing the Q with the first QBR executed and the first person trained to Level 1; at the close of week 12, you achieve full competence. From Level 3 to Level 4 takes one to two additional Qs because the component of training multiple people is outside your unilateral control. Impatience with these timelines is the strongest predictor of abandoning the system before it yields maximum performance.
The philosophical closure of Level 4.The multiplier level is not measured by how many skills you published, but by how many people you trained so they no longer need you. The MetodologIA playbook takes this as its ethical north star: my success is when my presence is no longer necessary. If your Jarvis makes you indispensable, it is poorly built; if it makes you dispensable because others have learned to build their own, it has fulfilled its mission.
§18Things that seem like a good idea but don't work
Explicitly listing what we have already tried and did not work saves time for subsequent adopters. These seven practices sound good at first but reveal hidden costs in actual use.
One · Inflated root CLAUDE.md.Temptation to put all role knowledge into the root file "so Claude always has it in mind." Real cost: every token in the root CLAUDE.md is loaded in every session, so the large file pays a toll in every conversation, slows down the response, and dilutes the model's attention. Antidote: keep it under three hundred lines and delegate the details to files in 00_Recursos that are loaded only when needed.
Two · ten connectors activated on the first day.Temptation to take advantage of the setup moment to connect everything connectable. Real cost: each connector brings its own error surface, its own adoption curve, and its own window of friction. Ten connectors on the same day produce a Jarvis that doesn't perform because none are validated. Antidote: two connectors at the start, validate for two weeks, add a third only when a specific pain point demands it.
Three · skills created from scratch by intuition.Temptation to write the skill file directly because you think you know what's needed. Real cost: skills created without first operating the manual flow capture the author's assumptions instead of real work patterns. Antidote: execute the flow manually with three real examples, provide iterative feedback, and only then request the pattern's extraction into an installable skill.
Four · scheduled task with send scope from day one.Temptation to automate one hundred percent to "see the full savings." Real cost: a scheduled task that sends without human supervision introduces a reputational risk disproportionate to the time saved, and if its behavior deviates, it causes damage before it's detected. Antidote: two to four weeks in trial or draft mode, daily observation of the output, and only then scale to automatic sending with subsequent auditing.
Five · persistent memory without auditing.Temptation to let Claude remember everything automatically. Real cost: memory accumulates obsolete content and eventually poisons every conversation because the model infers from an outdated profile. Antidote: a thirty-minute monthly audit where you review, delete what's obsolete, and explicitly add what's new.
Six · a thirty-station workspace in one weekend.Temptation of initial enthusiasm. Real cost: the demonstration-only Jarvis where setup friction consumes the energy that was meant for using it. Antidote: two or three stations at the start, live with them for two to three weeks, add the next one only when a specific pain point asks for it.
Seven · pasting contracts or sensitive data "because the plan says they don't train on it."Temptation to trust the contractual clause. Real cost: even if the plan declares exclusion from training, the information entered is stored temporarily, travels through external infrastructure, and a data leak event is not covered by a toggle. Antidote: any information you wouldn't be willing to show an unsigned external consultant does not go into Jarvis.
§19Phased adoption plan · from zero to full proficiency
The system described in this document is not static. This section provides a structured improvement plan in four quarterly waves that prioritizes return per unit of effort and keeps the system alive over time.
19.1 · Wave one · adoption of proven patterns
The first wave transfers to the system all patterns that are already validated in adjacent bodies of knowledge and only require replication. It is the wave with the highest return per unit of effort because the work is predominantly copywriting and layout design.
Wave one deliverables. Visual identity aligned with the brand body · bilingual ES/EN structure incorporated · complete tool-level map (twelve levels) published as a complete piece · Configuration chapter rewritten with a three-color traffic light system and the five ISO 27001 roles · glossary expanded to a tri-lingual format with one hundred consolidated terms · four COOL principles incorporated as a guiding framework.
19.2 · Wave two · adaptation of prompting, meetings, and reports
The second wave digests the first six elements that require modification before being adopted. It covers the bulk of daily work and produces visible savings from the first week of use.
Wave two deliverables.Thirteen use cases redesigned specifically for result-oriented prompts · curated library of thirty result-oriented prompt patterns · meta-skill creation documented · end-to-end meeting flow with scheduled tasks · lightweight canonical ADR prompt · installable VR-AID-report skill that produces executive reports directly as an artifact.
19.3 · Wave three · research, visualization, second brain, and security
The third wave completes the eight remaining elements of the adaptation inventory. It is the most technically dense wave, and it is advisable to operate it with an accompanying security sub-team.
Wave three deliverables. End-to-end Deep Research add-on with MCP connectors and a minimum of four cited sources · visualization pipelines with native XLSX and PPTX skills · equivalence table between Google's second brain system prompt and the root CLAUDE.md · final twelve-level map with verifiable criteria refined with feedback · appendix for migration between AI ecosystems · security audit protocol with MCP token lifecycle.
19.4 · Wave four · meta-innovations and store
The fourth wave releases the nine innovations that only emerge after seeing the entire ecosystem as a whole. The most demanding piece is the meta-primer that synthesizes the expanded body of knowledge, positioning Cowork as the ecosystem's command center.
Wave four deliverables.Project template with COOL sub-bookings as an installable skill · native bilingual skill with ES/EN toggle · tri-lingual glossary completed with one hundred consolidated terms · Cowork risk register with forty cataloged risks · tiered mastery rubric as an interactive instrument · meta-primer that closes the BU2 body · private store launched with ten versioned official skills.
19.5 · Plan governance
The plan is kept alive with three explicit governance mechanisms: a monthly audit of thirty minutes where the owning team reviews which deliverables have progressed and which are stuck; a semi-annual review where the entire ecosystem is confronted with the state of the product; and an open feedback cycle where any active user can propose a new candidate element.
19.6 · Plan success metrics
The plan's success is measured by six indicators that touch on real productivity, not the number of documents produced. The skill adoption rate among active users measured quarterly. The average time to reach level one mastery after induction. The number of security incidents on the Cowork sandbox (ideally zero). The satisfaction level with the master document. The tri-lingual glossary coverage. The use of the twelve-level map as an explicit, self-reported tool-choice criterion by users.
Closing Mov. IV
You have the plan, the routes, the mastery rubric, and the anti-patterns. → Next: Closing · schedule the rituals and keep the system alive.
Between using Claude like a Ferrariand use it like just another AI, only more expensive—that gap is closed with method.MetodologIA Thesis
Movement V of V · closing
V
Closing
What I build, I share.
§20Activate Cadences · what, why, what for, and how
Everything you need to start your personal Jarvis is in this document. Cadences are the recurring rituals that keep the system alive: they connect your real work with your files, your memory, your board, and your decisions. This section does not treat the calendar as a substitute for the method: the calendar reserves the space, the prompt guides the session, and the recurring task turns Cowork into a facilitator once the habit is proven. The three practices are cumulative, not exclusive.
20.1 · Cadences Context
| Question | Operational Answer | What it prevents |
|---|---|---|
| What are they | They are recurring conversations with a fixed structure: review status, decide focus, detect blockages, extract learnings, and leave a traceable record in 04_Cadencias/. | That Jarvis becomes a static library that no one ever opens again. |
| Why they exist | Because context ages. Your priorities change, projects appear, WIP accumulates, and memory becomes disorganized if there are no update rituals. | Accumulation of tasks, obsolete memory, and scattered decisions. |
| What they are for | They help maintain daily focus, weekly learning, monthly/quarterly governance, and continuous system improvement without relying on occasional motivation. | Working hard without knowing what changed, what you learned, or what's next. |
| How to activate them | First, schedule the time; then, run the guided prompt in Cowork; once the ritual is established, convert it into a supervised scheduled task so the AI can ask, summarize, propose, and await confirmation before logging. | Premature automation without established habits or human judgment. |
20.2 · Three layers of activation
| Layer | Role in the cadence | What the AI does | Expected log |
|---|---|---|---|
| Calendar | Block the time and protect the ritual. | It doesn't intervene yet; it just sets up the reminder. | Recurring event with a description of the ritual. |
| Guided prompt | Makes execution simple. | Asks, organizes, summarizes, and leaves the artifact in 04_Cadencias/. | DBR, WBR, or QBR in Markdown, validated by you. |
| Scheduled task | Activates the AI facilitator without you needing to paste the prompt. | Prepares context, starts the conversation, asks for confirmation, and logs only with supervision. | Proposed artifact + log of confirmed decisions. |
20.3 · Calendar events · downloadable
Each link downloads an .ics file that can be imported into your calendar with a click. Use it as the first layer; once the ritual has traction, return to Runbook Step 7 to run the guided prompt or configure the recurring AI facilitator.
Available commitment levels.
20.4 · Copiable template · root CLAUDE.md
20.5 · Copiable template · root MEMORY.md
20.6 · Copiable template · voice.md
Ready to start. Choose the combination that serves you today: human calendar reminder, guided prompt in Cowork, or recurring AI facilitator once the habit is proven. They are not mutually exclusive paths. Start with DBR, Daily Close, and WBR; when you have evidence of use, convert the stable cadence into a supervised scheduled task so the AI asks, summarizes, proposes, and waits for your confirmation before logging.
§21Footnotes · acronyms and technical terms
This section defines the acronyms and technical terms that appear in the body of the document, in simple language. The intention is for the document to be read smoothly without an acronym slowing you down.
- Note 1 · Personal operating system
- The operating system is the base software of your computer (Windows, macOS, Linux). Here we use the metaphor because a well-configured Cowork functions as a base layer on which you install tools, define routines, and delegate work.
- Note 2 · Tool-level map
- Twelve floors grouped into three movements. Movement one (solve with what's already there): Direct Chat, Chat with MCP connectors, Chat Projects. Movement two (work with what you have): Direct Cowork, Cowork Projects. Movement three (build what you need): Skills, Plugins, mini-apps via vibe coding, versioned plugin engineering, Project station, mini-apps deployed for the browser. NotebookLM is integrated as the first MCP connector for Cowork.
- Note 3 · Station
- A station in this system is a folder dedicated to an area of your work, with its own instruction file, its own memory file, and its own reference files. In operational terms, it is a stable area within your virtual office map: each station is a daily work domain (Mail, Delivery, Pre-sales) that occupies its Base sector in the system.
- Note 4 · NotebookLM
- A Google tool where you upload sources (PDFs, links, transcripts) and ask it questions, which the system answers by citing exactly which source each statement comes from. It is useful when the traceability of the citation matters more than speed.
- Note 5 · Claude Projects via Chat
- Focused thematic spaces that any user can create from claude.ai with their own instructions and uploaded reference files. The difference with Cowork Projects is that Chat projects live in the cloud and do not touch local files.
- Note 6 · Claude
- Claude is the name of the AI model made by Anthropic that operates in both Chat and Cowork.
- Note 7 · MCP
- MCP stands for Model Context Protocol. It is the technical standard that defines how Cowork connects to external applications like Gmail, Calendar, or Notion. The metaphor is that of a USB cable.
- Note 8 · Vibe coding
- A colloquial way of programming where the human describes what they want in natural language and the AI writes the code. The virtue is prototyping speed; the risk is fragility in the face of environmental changes.
- Note 9 · ADR
- ADR stands for Architecture Decision Record. It is a short, one-page note that documents a decision made, the alternatives considered, the expected consequences, and the date.
- Note 10 · PMO
- PMO stands for Project Management Office. It is the area within a company that defines methodology, templates, metrics, and common practices.
- Note 11 · CI/CD
- CI/CD stands for Continuous Integration / Continuous Deployment. It is the practice of automating software testing and deployment.
- Note 12 · SLA
- SLA stands for Service Level Agreement. It is the explicit commitment regarding the availability, response time, and quality of a service.
- Note 13 · Guardrails
- Guardrails literally translates to protection rails. In AI, they are the explicit restrictions that limit what a model or an agent can do.
- Note 14 · Evaluation harness
- In AI, an evaluation harness is the set of tests and metrics that automatically assess whether a model, plugin, or agent is working well.
- Note 15 · Deep research
- Deep research is the practice of in-depth, AI-assisted investigation where the system searches multiple sources (a minimum of four is recommended), cross-references them, and produces a brief with traceable citations.
§22Risks, limits, and validation
Three areas require active validation. Numerical data for Anthropic products (exact window, quotas, connectors per plan, prompt cache) are labeled as assumptions · verify in official documentation [11] before making plan or investment decisions. Cited public content was extracted from verified descriptions and indexes, not complete transcripts · watch the videos directly for operational details. Pace of change of the Cowork product is high · review this playbook semi-annually.
Sensitive domain: in crisis communications, formal feedback, contractual decisions, or matters with legal, labor, or reputational consequences, validate with Legal, People, or Compliance. The AI is an assistant, not a legal or human resources advisor. Recurring emails and communications require sustained human supervision for the first few weeks.
MetodologIA deontological filter · hard gates before publishing
Every piece produced with Jarvis's assistance (email, status report, proposal, documented decision, communication to steering) must pass the four questions before going out into the world. If any answer is no, the piece is not published.
- Method · is there a diagnosis before the assertion, or am I applying a tool without understanding the flow?
- Sovereignty · is the reader more autonomous after reading this, or more dependent on me or the system?
- Dignity · am I glorifying hustle, permanent sprinting, always-on, or am I treating the reader as an adult who deserves time and attention?
- Evidence · Is there a number with context and a verifiable source, or am I just throwing out adjectives without measurement?
If all four pass, you publish. If one fails, you rewrite. The playbook applies this same filter to itself; any section that doesn't pass it must be flagged in the open feedback of §19.5 to be rewritten in the next wave.
§23Bibliographic references
References in APA 7th edition format. Those marked with [check current edition] are corporate or professional standard sources whose editorial details are updated frequently.
- Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the middle: How language models use long contexts (arXiv:2307.03172). arXiv. https://arxiv.org/abs/2307.03172
- Bjork, E. L., & Bjork, R. A. (2011). Making things hard on yourself, but in a good way: Creating desirable difficulties to enhance learning. In M. A. Gernsbacher, R. W. Pew, L. M. Hough, & J. R. Pomerantz (Eds.), Psychology and the real world: Essays illustrating fundamental contributions to society (pp. 56–64). Worth Publishers.
- Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute. [check current edition]
- Ericsson, K. A., Krampe, R. T., & Tesch-Römer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100(3), 363–406. https://doi.org/10.1037/0033-295X.100.3.363
- Ericsson, A., & Pool, R. (2016). Peak: Secrets from the new science of expertise. Houghton Mifflin Harcourt.
- Karpicke, J. D., & Roediger, H. L. (2008). The critical importance of retrieval for learning. Science, 319(5865), 966–968. https://doi.org/10.1126/science.1152408
- Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285. https://doi.org/10.1207/s15516709cog1202_4
- Brown, P. C., Roediger, H. L., & McDaniel, M. A. (2014). Make it stick: The science of successful learning. Harvard University Press.
- Knowles, M. S. (1980). The modern practice of adult education: From pedagogy to andragogy (Revised edition). Cambridge Adult Education.
- Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). Attention is all you need. In Advances in Neural Information Processing Systems (Vol. 30, pp. 5998–6008). Curran Associates. https://arxiv.org/abs/1706.03762
- Anthropic. (2026). Claude documentation and support center. Anthropic. https://docs.claude.com and https://support.claude.com [check current version when consulting]
- Montaño, J. Learn · Apprehend · (R)Evolve: Playbook MetodologIA [Internal manuscript]. MetodologIA. CC BY-NC-SA 4.0.
- Su, J. (2026, April 28). Claude Cowork for beginners: Build your own Jarvis [Video]. https://www.jeffsu.org/claude-cowork-build-your-own-jarvis/
- Su, J. (2026, April 7). Learn 80% of Claude Cowork in under 20 minutes [Video]. https://www.jeffsu.org/learn-80-of-claude-cowork-in-under-20-minutes/
- Huang, T. (2026, March 17). My favourite AI workflow nobody talks about [Video]. YouTube. https://www.youtube.com/watch?v=kKG5MDF_234
- Huang, T. (n.d.). Context engineering clearly explained [Video]. YouTube. Tina Huang Channel. https://www.youtube.com/c/TinaHuang1/videos
- Bodnar, K., & Flanagan, K. (Hosts). (2025, December 30). Episode 388 [with Tina Huang]. Marketing Against the Grain [Audio podcast]. HubSpot Podcast Network. https://www.youtube.com/watch?v=A5aIMGDfvK8
- Bharath, S. (n.d.). The ultimate guide to Claude Cowork: Create your personal AI assistant. Sid Bharath Blog. https://sidbharath.com/blog/ultimate-guide-claude-cowork/
- Forbes, R. (n.d.). Build your personal AI assistant with Claude Code. Ron Forbes Blog. https://www.ronforbes.com/blog/build-your-personal-ai-assistant-with-claude-code
- Forbes, R. (n.d.). Your second brain is not optional anymore. Ron Forbes Blog. https://www.ronforbes.com/blog/your-second-brain-is-not-optional-anymore
- Medin, C. (2026). Full guide: Build your own AI second brain with Claude Code [Video]. YouTube.
- Claude and Notion just automated my entire product workflow. Improving Blog.
- Anthropic. (2026). Assign tasks from anywhere in Claude Cowork. Claude Help Center. https://support.claude.com/en/articles/13947068-assign-tasks-from-anywhere-in-claude-cowork
- Anthropic. (2026). Get started with Claude in Chrome. Claude Help Center. https://support.claude.com/en/articles/12012173-get-started-with-claude-in-chrome
- Anthropic. (2026). Schedule recurring tasks in Claude Cowork. Claude Help Center. https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork
- Anthropic. (2026). Get started with Claude Cowork. Claude Help Center. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork
- Anthropic. (2026). Organize your tasks with projects in Claude Cowork. Claude Help Center. https://support.claude.com/en/articles/14116274-organize-your-tasks-with-projects-in-claude-cowork
Mov. V Close · Document Closure
You've reached the end. → What follows is outside the playbook: open Cowork, seed your CLAUDE.md, and begin your full competency Q. What I build, I share.
A
Appendix · Author's Cases
What follows are specific decisions the author made in their repo during the May 2026 elevation. They are cited as a reference to inspire the reader's own solution, not as a canon to be replicated. The criterion for something to live in this appendix and not in the body of the playbook is clear: if it assumes the author's specific configuration, it lives here; if it is replicable by any reader with a functional Jarvis, it lives in the body.
A.1 · Multi-agent Stack · AGENTS.md as a mirror
The author operates a multi-agent stack in the same repo: Claude (Cowork, Claude Code, Claude Desktop) coexists with Codex, Cursor, Copilot, Gemini CLI, and other agents that follow the convention of AGENTS.md (reference: github.com/agents-md). To ensure all agents read the same canon without having to maintain two files by hand, AGENTS.md is regenerated mirror of CLAUDE.md via a script (scripts/sync-agents-md.sh) that runs after each structural edit of CLAUDE.md. The rule is: the canon is CLAUDE.md, the mirror is AGENTS.md, never the other way around.
Why it is NOT inherited into the canon. The pattern assumes an active multi-agent stack. The typical reader operates with a single agent. Forcing the pattern adds complexity without being useful. If the reader eventually operates multi-agent, this appendix serves as a reference to inspire their own solution. Full pattern detail: ADR memory/decisiones/20260513_root_agents-md-multi-agent-paralelo.md in the author's repo.
A.2 · Productivity plugin ecosystem · temporary snapshot
Current list at the time of writing this appendix (May 2026). This is not a recommendation—the reader should verify availability in their Claude/Cowork client at the time of adoption, and choose the tool their team uses or that fits their visual workflow. The productivity ecosystem changes approximately every 18 months; any nominal list ages quickly. Keeping the choice abstract in the body of the playbook protects the reader from adopting a deprecated tool or avoiding a new one that did not exist when the guide was written.
Snapshot May 2026. In the productivity and tasks category: Linear, ClickUp, Asana, Monday, Notion. In the enterprise-search and documents category: Atlassian (Jira/Confluence), Guru, MS365 (Outlook/SharePoint/Teams), Slack. The sync convention (canonical markdown, mirror plugin, suffix [PROVIDER-ID] inline, manual sync in WBR) is the same for all. The difference is how well each one fits the reader's workflow.
A.3 · IIKit as Jarvis infrastructure
The author adopted Intent Integrity Kit (IIKit) as the conceptual infrastructure for Jarvis during May 2026. The five IIKit rules live as a module in 00_Recursos/iikit-reglas-adoptadas/ at a philosophical level, and the operational implementation was piloted in the project Runbook OS (P-006) using a vendored tile via Tessl. Adoption into the author's other projects is gradual and will be evaluated in QBR Q3 2026 with real metrics.
Why it is NOT inherited into the canon. Author's personal decision based on specific validation of their context. The reader evaluates for themselves whether IIKit or another phase discipline framework is useful. Full detail: ADR memory/decisiones/20260511_root_adopcion-iikit-dos-planos.md.
A.4 · Pristino · lineage of the author's own agents
The author maintains an umbrella brand ("Pristino") for their own agents with six slots and differentiated licensing per incarnation. The slots are: Pristino-NPC (historical role origin), Pristino-Brand (previous brands), Pristino-Venture (failed venture turned into a lesson), Pristino-MOAT (OSS technical pattern), Pristino-Jarvis (this Cowork assistant), and a reserved slot for future incarnations. Each slot has its own architecture and license without contaminating the others.
Why it is NOT inherited into the canon. Author's personal branding decision. A reader building their own lineage of agents will see this as inspiration, not an obligation. Full detail: 00_Recursos/marca-personal/pristino-linaje.md and ADR memory/decisiones/20260511_root_pristino-linaje.md.
The operational criterion for writing a new appendix: if the decision assumes the author's configuration, it goes here; if it is replicable by any reader with a functional Jarvis, it goes in the body of the playbook. The difference matters because the inheritable canon must be executable without the author's context.