Field manual · intermediate to advanced
The master agent is Claude, set up to run real work — sites, documents, research, overnight builds — in supervised sessions on your own computer. This page is the exact playbook, start to finish: do part 00 once, then follow the parts in order and copy the prompts as you go. Practice rounds at the end are optional.
Picked from your browser. Every command and file path on this page follows this choice, and you can change it any time.
Part 00 · read first · set up once ever
The master agent is Claude — Anthropic's AI — set up to work like a staffed control room on your computer. You tell one chat (Dispatch) what you want, in plain English. It opens isolated working sessions on your machine that do the work and report back. Do this part once; parts 01–03 are the loop you run forever.
Builds and deploys full websites and funnels. Writes documents, decks, spreadsheets and PDFs. Researches with cited sources. Plans marketing campaigns, audits SEO, and writes ad, email and landing-page copy. Runs multi-hour builds unattended overnight while you sleep.
Deploy, publish, send, email, purchase, or delete — those always wait for your explicit go-ahead. It never invents numbers, testimonials, or results. Part 01 bakes these rules into every workspace you create.
Four words you will see everywhere.
Cowork is the tab in the Claude app where agent work lives. Dispatch is the chat inside it — the front desk, and the only thing you ever talk to. A session is one isolated worker that Dispatch opens for one job; sessions share nothing except files on disk. A skill is a step-by-step playbook a session loads for a kind of job — site build, SEO audit, spreadsheet. You install the library of them once, below; sessions pick from it on their own.
Download the app at claude.ai/download and sign in. Windows 10 or later. The Linux app is a beta for Ubuntu 22.04+ and Debian 12+; install it from Anthropic's apt repository so it updates itself. Other distributions are not supported yet. Cowork needs a paid plan; Max is the right one here because overnight runs eat usage. Everything runs locally, so the app must be open and the computer awake whenever sessions work — your phone is only a remote control. No Cowork tab in the app? Update the app, then check the plan.
Also install Git for Windows (git-scm.com). Code sessions use it for git and for running their commands.
Dispatch, the phone-to-desktop chat, is confirmed on Mac and Windows. We could not confirm it on the Linux beta. If you see Cowork but no Dispatch, paste every prompt in this manual into a new Cowork task instead. Computer use is not in the Linux beta either.
Two files, 80 skills, free. Without them, sessions still run but miss the playbooks this whole manual assumes.
Download skill-library.zip Download agent-brain-code.zip
1 · skill-library.zip — in Claude Desktop, go to Customize → Skills → Upload and upload the zip as it is (do not unzip it). This is the library Dispatch task sessions see.
2 · agent-brain-code.zip — this holds a .claude folder for your home folder. It gives code sessions the same 80 skills, the skill finder, and the standing rules. Open the Terminal appPowerShell (Start menu, type "PowerShell")a terminal and paste this line. It adds the files and never overwrites anything you already have:
unzip -n ~/Downloads/agent-brain-code.zip -d ~
tar -xkf "$env:USERPROFILE\Downloads\agent-brain-code.zip" -C "$env:USERPROFILE"
tar is built into Windows 10 and 11. The k in -xkf keeps every file you already have. The folder lands at %USERPROFILE%\.claude.
If it says unzip is not found, run sudo apt install unzip first.
If you already had a ~/.claude/CLAUDE.md, yours is kept; open the one inside the zip and copy its "Skill routing" section into yours. The finder runs on Node.js: if typing node -v in the same window prints an error instead of a version number, install the LTS from nodejs.org or your package manager.
The pack bundles open-source skills from other authors alongside original ones. Credits and licences are in the LICENSES folder inside each zip.
Finished guides and reports come back as live hosted links, published on Vercel (vercel.com, free tier is fine). The first deliverable will ask you to log in once; after that it is silent.
Open Dispatch (Claude app → Cowork → Dispatch) and paste this. Expect READY. Along the way you will get a one-time folder approval; approve it. macOS may also offer to install its developer tools for git; accept. If it reports git is missing, install Git for Windows (step 1) and run the check again. If it reports git is missing, run sudo apt install git and run the check again.
Setup check. Change nothing, install nothing. 1. How many skills can you see? Name five, and confirm live-interactive-deliverable is among them. 2. Create the folder ~/Projects/setup-check if it does not exist, then start a code task there that runs: node ~/.claude/skill-router/find-skill.js "build a landing page" and report its top match. 3. Confirm sessions run on this machine and that guides and reports come back as live hosted links. End with READY, or NOT READY plus the one thing to fix first.
The node ~/.claude/… line keeps its ~ on purpose: the session runs that command in Git Bash, where ~ means your home folder.
NOT READY, or anything confusing? Screenshot it and send it to whoever shared this guide with you. Do not push past a broken setup check.
Part 01 · do this once per project
Sessions are isolated. They share nothing except what is on disk, so the folder has to tell any new session what is going on.
Keep the path plain: no # or odd characters, they break some build tools.
It creates the two files every later session depends on: CLAUDE.md (standing rules, read automatically by code sessions) and PROJECT-STATE.md (what is done, what is next).
Set up [FOLDER PATH] as a project workspace. Project (one sentence): [WHAT WE ARE BUILDING] 1. Create CLAUDE.md: who I am, standing rules, where things live. Under 60 lines. First line: "Read PROJECT-STATE.md first. Update it before you stop." 2. Standing rules must include: never deploy, send, purchase, or delete without my explicit yes; never invent numbers or results; ask before adding a dependency. 3. Create PROJECT-STATE.md with sections: Milestones (the build steps in order, numbered M1, M2, …), Done, In progress, Next, Decisions, Open questions. 4. Create docs/ and scratch/ folders. git init if this is not a repo yet. 5. Do not install anything or touch files outside this folder. Finish by showing me the tree and the full text of both files.
The first session in a new folder needs a one-time approval, and the prompt appears right in the Claude app. Approve it now, at the desk. If it first comes up at 2 AM, the overnight run stalls at step zero.
Pre-flight check for an unattended run in [FOLDER PATH]. Change nothing. Report: 1. Can you read and write here without a new approval prompt? 2. Do CLAUDE.md and PROJECT-STATE.md exist and agree with each other? 3. Which commands in the plan will need my approval? List them. 4. Is the git tree clean? What branch? End with GO or NO-GO and the one thing I should fix first.
Part 02 · every task
You talk to Dispatch. Dispatch opens the session, and the session works out which skill the job needs. You never have to know a skill name.
Claude app → Cowork → Dispatch, from your phone or the desktop. Every prompt in this manual gets pasted into Dispatch — you never talk to a session directly. Claude Desktop must be open on your computer and the computer awake, because sessions run on your machine; the phone is just a remote. On the Linux beta, if there is no Dispatch, start a Cowork task and paste the prompt there.
Goal, context, guardrails, deliverable. Switch them on and watch a weak prompt become one that holds.
Strength 0/4 — "Fix the landing page."
Fix the landing page.
GOAL: [ONE SENTENCE: what done looks like] CONTEXT: [who it is for, what exists already, files or links to read first] GUARDRAILS: - Cite a source for every number. No source, no number. - Do not send, publish, or email anything. - If something is ambiguous, pick the sensible default and note it. DELIVERABLE: [what I get back. Leave the format open for a live hosted link, or name one: PDF, DOCX, XLSX, CSV]
GOAL: [ONE SENTENCE: the change, and how we know it works] CONTEXT: Folder [PATH]. Read CLAUDE.md and PROJECT-STATE.md first. Relevant files: [PATHS]. GUARDRAILS: - Work on a new branch in a git worktree. Do not touch main. - Do not deploy, push, or delete. Do not change copy. - Ask before adding a dependency. DELIVERABLE: Passing build and tests, a summary of what changed, and [SCREENSHOTS / DIFF]. Update PROJECT-STATE.md.
You do not choose any of this. It is here so you know what is happening.
Research and writing go to a task session (start_task). Anything in a repo goes to a code session (start_code_task), which can run on its own model and in its own git worktree so parallel sessions don't collide.
Every session starts with the catalogue of installed skills and matches your request against it. Ask for a landing page and it reaches for the site-building skill; ask why a page is not converting and it reaches for the conversion-audit skill.
You do not need to know skill names. There are far too many to remember, and that is the point of having them organised.
How it works: the session reads its skill list and picks by description. With the part 00 skill pack installed, sessions are also instructed to run a skill finder that searches the full description of every installed skill when nothing obvious fits, and to tell you in one line which skill they chose.
Name a skill only to override a choice you disagree with.
Say it in words: "use Haiku for this" or "run this on Fable".
| Model | Ask for it when | Relative cost |
|---|---|---|
| Haiku | Bulk simple work: classify, summarize, rename, extract | $ |
| Sonnet | Everyday work: routine edits, drafts, simple pages | $$ |
| Opus | Heavy reasoning: builds, debugging, strategy. The usual default | $$$$ |
| Fable | The hardest, longest jobs only: multi-repo architecture, work Opus stalled on | $$$$$$$$$$ |
Cost follows API list prices as of Sept 2026 (Haiku $1, Sonnet $2, Opus $4, Fable $10 per million input tokens). On a subscription you do not pay per token — a heavier model simply burns your plan's usage limit faster.
To add or change something, tell Dispatch to pass it to that session ("tell the course-site session to also fix the footer"). It uses send_message, so the session keeps everything it already knows. Don't start a new one for a follow-up.
Guides, reports, checklists, summaries and "what to do next" come back as a hosted interactive page on Vercel — the account you connected in part 00 — with the URL handed to you, not loose files on your machine (the live-interactive-deliverable skill does this on its own). Name a format, or ask for integration code, and you get that file instead.
Part 03 · while it runs
A session left alone drifts. The job is short check-ins: see what it did, correct it in one line, move on. Everything below gets pasted into Dispatch, same as part 02.
Dispatch reads the session's transcript (read_transcript) and tells you what it actually ran. Look for repeated work, skipped tests, and a plan that quietly changed.
Status on the [PROJECT] session. Read its transcript; do not start new work. - Milestone it is on, and roughly how far - Last command it ran and the result - Which skill it is using - Anything it skipped or assumed - Anything waiting on me
Say what is wrong and what is true. You still don't need a skill name: tell it the approach is off and to pick again.
Tell the [PROJECT] session: stop what you are doing. You are [WHAT IT IS DOING WRONG]. Per PROJECT-STATE.md, [WHAT IS TRUE]. If the skill you picked does not fit this, find the one that does and tell me which. Then do [NEXT CONCRETE STEP] only and report back.
Sessions choose their own skill and say which. If the status check shows the wrong one, or none, tell it what kind of job this is. A skill name is optional.
Tell the [PROJECT] session: you are using [SKILL IT NAMED, or "no skill"] and that is the wrong fit. This job is [KIND OF JOB: a site build / an SEO audit / a bug hunt / a report for the team]. Search your installed skills for the one built for that, tell me which you picked and why, then redo [THE STEP] with it.
"Done" is a claim. Have Dispatch show you the build output and screenshots from the transcript, and open the live link yourself.
Milestones are the numbered M1, M2, … items PROJECT-STATE.md has carried since part 01. Before bed: Mac plugged in, lid open, automatic sleep off (System Settings → search "sleep")PC plugged in, sleep set to Never while plugged in (Settings → System → Power)machine plugged in, automatic suspend off (on GNOME: Settings → Power → Automatic Suspend), Claude Desktop running. A sleeping computer pauses every session.
This is an unattended overnight run in [FOLDER PATH]. GOAL: Complete milestones [M2–M4] in PROJECT-STATE.md, in order. RULES: - After each milestone: run the build and tests, then update PROJECT-STATE.md with what is done and what is next. - If you are blocked, write the blocker in PROJECT-STATE.md and move to the next milestone that does not depend on it. - Do not deploy, push, send, purchase, or delete anything. - If you stop for any reason, the state file must already be current.
Your plan caps how much the sessions can do in a stretch; at the cap they pause. Nothing is lost. Limits reset on a schedule, and the limit message in Dispatch says when. After the reset, resume that session. A new one would start cold and redo work.
The usage limit has reset. Tell the [PROJECT] session to continue. 1. Re-read PROJECT-STATE.md and the last thing it was doing. 2. Report in three lines: what is finished, what was in progress, what is next. 3. Carry on from the in-progress item. Do not redo finished milestones. Same rules as before: no deploy, push, send, or delete.
Ask for status again, correct any drift, and give the go-ahead for anything outward-facing (deploys, sends) yourself.
You never have to type these. This is only so the one-line "I'm using X" from a session means something to you.
| When the job is… | The session usually picks |
|---|---|
| Build or redesign a site or funnel | cinematic-web-builder |
| Shape an idea, then plan it | brainstorming, writing-plans (Superpowers) |
| A bug or a failing test | systematic-debugging, test-driven-development (Superpowers) |
| Keep the code and the token bill small | ponytail (always on) |
| Ads, outreach and email sequences | ads, ad-creative, cold-email, emails |
| Why a page is not ranking or not converting | seo-audit, cro, copywriting |
| Offers, pricing, a launch plan | offers, pricing, launch, marketing-plan |
| A guide, report, checklist or summary with no format named | live-interactive-deliverable |
| Documents, decks, sheets, PDFs | docs, docx, pptx, xlsx, pdf |
| Mail, calendar, Drive | google-workspace |
| Recurring or timed runs | schedule |
| Turn a routine into a reusable skill | skill-creator |
| Nothing installed fits | It searches skills.sh and proposes one for your approval |
Superpowers is the name of a skill pack (planning, debugging, test-driven development); ponytail is a plugin that keeps code and token spend small. Superpowers arrives with your part 00 install. Ponytail is an optional extra that is not in the pack; if your sessions never mention it, nothing is broken.
Seeing words like swarm, LiteLLM or tier-cheap in a transcript? That is the experimental layer in part 07. You do not need it day to day. The setup Chris actually runs every day is part 05.
Part 04 · make it yours
The pack has no on-camera coach and no script auditor, on purpose. Those two only work when they are built around one person, so you build your own. It takes one interview and two prompts.
A speaking coach has to know how you sound on a good day: your pace, your phrases, the audience you talk to, the things you never say. A canned one coaches you toward somebody else's voice.
Every field has claims you cannot make and facts you must get right. A script auditor is only useful if it checks your field's rules, written down by you, before the camera rolls.
| Skill | What it does for you |
|---|---|
| Your on-camera coach | Shapes a script so it sounds spoken, preps you before a recording, reviews a take and names the three fixes that matter most, and answers delivery questions with one drill. |
| Your script auditor | Checks a written script before filming: runtime at your reading pace, read-aloud hazards, a scored review, and a pass against your accuracy and compliance rules, with anything that must be fixed first marked as a blocker. |
Open Dispatch and paste this. It asks a few questions at a time and ends by saving a speaking profile. Answer in your own words; rough answers are fine. If you have a script or a transcript of yourself, hand it over when asked. Real samples beat descriptions.
Interview me so we can build two personal skills: an on-camera speaking coach and a teleprompter script auditor, both made for me and nobody else. Ask a few questions at a time and wait for my answers. Push back when an answer is vague. Do not write any skill yet. Cover, in this order: 1. What I record: the kinds of video (sales video, lesson, short clip, webinar), typical length, where it is published. 2. My audience: who they are, what they already know, what they are skeptical about. 3. My voice: how I sound when I am at my best, phrases I use, phrases I never use, how formal I am. Ask me for a script or transcript of me and study it. 4. My delivery: my natural pace (time me reading 150 words if I do not know), where I rush, my habits and filler words, what feedback I have had before. 5. My setup: camera, teleprompter or notes, how many takes I usually do. 6. Structure I trust: how my videos open, how they make the case, how they close, what I ask the viewer to do. 7. Accuracy rules for my field ([MY FIELD]): facts, figures and terms that must be exactly right, and who or what is the source of truth. 8. Compliance rules for my field: claims I must never make, words I must avoid, disclaimers that must be said, anything that needs sign-off before publishing. If I am not sure, list what I should ask my compliance contact, and mark those items as unconfirmed. 9. People whose speaking I want to learn from, and what specifically I want to borrow from each. 10. Hard lines: persuasion tactics I refuse to use. When we are done, save everything as speaking-profile.md in [FOLDER PATH]: my answers organised under those ten headings, direct quotes of my real phrasing, and a list of open questions. Show me the file and ask me to correct it.
Read the profile, fix anything wrong in it, then paste this.
Build me a personal skill called [MY-NAME]-speaker-coach from [FOLDER PATH]/speaking-profile.md. Use your skill-creation skill and follow it, including writing a few test cases. The skill coaches my on-camera delivery. It must work in four modes and pick the right one from what I give it: 1. Script coach: I have a script or an idea. Give a verdict on the structure, then a speakable, marked-up version (pauses, emphasis, breaths) in my voice. 2. Pre-record prep: I have a final script and a session coming. Give a one-screen run sheet: setup, warm-up, marks, take plan. 3. Take review: I have a recording or its transcript. Measure what can be measured (pace, pauses, filler words, length), then name the three fixes that matter most. No long lists. 4. Coach on call: I ask a delivery question. Answer briefly with one drill. Put the detail in reference files the skill reads only when needed: - structure: how my videos open, make the case and close, from my profile - delivery: lens, energy, pace, pauses, voice, face, hands, warm-ups - teleprompter: reading without sounding read, script marking, recovering from stumbles - storytelling: the kinds of stories and examples that fit my audience - persuasion ethics: for each technique, the honest use and the manipulative version, with my hard lines on top - accuracy and compliance: the rules from my profile, word for word. Items I marked unconfirmed stay marked unconfirmed. - sources: where each piece of advice came from and how solid it is Rules for the skill itself: - It coaches toward how I sound at my best, using my real phrases. It never rewrites me into a generic presenter. - It never adds a number, a promise or a claim I did not make. - Every review ends with a compliance line: none, or a list with timestamps or line numbers. - If a rule in my profile is unclear, it asks me. It does not guess. Install it where my code sessions can use it, and also give me a zip I can upload at Claude Desktop → Customize → Skills. Then run its test cases and show me the results.
Build me a personal skill called [MY-NAME]-script-auditor from [FOLDER PATH]/speaking-profile.md. Use your skill-creation skill and follow it, including writing a few test cases. The skill audits a WRITTEN script before I film it. It reads only; it never edits my script unless I ask. It works in two layers: Layer 1, measure. Write a small script that takes a file or folder and reports: - runtime at my reading pace of [MY WORDS PER MINUTE] and at 20 faster - sentence and paragraph length - read-aloud hazards: numerals and symbols, parentheticals, tongue-twisters, phrasing that reads fine but is awkward to say, stray markup - how the script opens and what it asks the viewer to do at the close - pause and cue density - a wording scan against the claims and words my profile says to avoid Mark each finding BLOCKER (do not film), FIX (change before filming) or WATCH (a person should look). The scan only matches wording, so the skill must treat its output as places to look, not as the verdict. Layer 2, judge. Read the whole script and score it 0 to 3, with a one-line reason each, on: structure, hook strength, clarity, read-aloud readability, pacing and runtime, strength of the call to action. Then run the accuracy and compliance pass from my profile and give PASS, FIX or BLOCKER. Every audit comes back in this shape: - the score table - Must fix before filming - Worth fixing - Accuracy and compliance notes - What is working Put the scoring anchors and my accuracy and compliance rules in reference files, word for word from my profile. Items I marked unconfirmed stay marked unconfirmed, and the skill says so in every audit that touches them. Rules for the skill itself: - It never softens a blocker and never invents a rule I did not give it. - It never rewrites my voice. Suggested lines use my phrasing from the profile. Install it where my code sessions can use it, and also give me a zip I can upload at Claude Desktop → Customize → Skills. Then audit [PATH TO ONE OF MY REAL SCRIPTS] and show me the result.
From here you never name them. Say "check this script before I record" or "review this take" and the session picks your skill. When it gets something wrong about you, tell it, and add: "update my skill so this sticks." The skill is only as good as its last correction.
These skills help you prepare. They do not replace your field's compliance or legal review. If a rule matters, have the right person confirm it and put the confirmed wording in your profile.
Part 05 · run it like Chris · once parts 01–03 feel routine
This is the setup Chris runs every day. Dispatch never does the work itself. It routes each job to its own session, keeps follow-ups in that session, checks the transcript before it answers, and won't say "done" without proof. Several sessions run in parallel, each in its own folder, on the cheapest model that can do the job. Timers check in overnight, standing rules live in memory, and nothing outward-facing happens without your yes.
Paste this into Dispatch once and ask it to save it as a standing rule. From then on it runs every job this way.
Save these as standing rules for every job I give you: 1. ROUTE: every job goes to its own session. Code work goes to a code session in that project's folder; research and writing go to a task session. You don't do the work yourself. 2. FOLLOW UP IN PLACE: a follow-up on a job goes to the session that did it (send_message). Never start a fresh session for a follow-up. 3. READ BEFORE YOU ANSWER: before you tell me the status of a job, read that session's transcript. Report what it actually ran, not what it planned. 4. VERIFY BEFORE DONE: "done" needs evidence: the build or test output, a read-back of what changed, a screenshot, or the live URL answering. No evidence, no "done". 5. ASK FIRST: no deploy, send, publish, purchase or delete without my explicit yes for that action. 6. COMMIT BEFORE HANDOFF: every project is a git repo. Each session or account works on its own branch (a git worktree when they share a repo), and commits and pushes before it hands work to another session, another account, or me. The next one pulls first. 7. REPORT SHORT: lead with problems and anything waiting on me.
Give every project its own folder under ~/Projects%USERPROFILE%\Projects, and give each code session its own folder. Two sessions in one folder overwrite each other's files, trip over the same git branch, and fight over the same dev-server port. Each one then "fixes" what the other just did. If two jobs must touch the same repo, have Dispatch run the second one in a git worktree: a separate copy of the folder on its own branch.
| Folder | Session | Running at the same time |
|---|---|---|
~/Projects/landing-page | Site rebuild (code) | Yes |
~/Projects/crm-scripts | Follow-up script fix (code) | Yes |
| (none) | Market research report (task) | Yes |
~/Projects/landing-page worktree | A second change to the same site | Yes, on its own branch |
Every project folder is a git repo with a private GitHub remote from the first session. That's what lets several sessions and a second account work on the same project at once without overwriting each other, and it gives you an undo for every change. Three rules:
git worktree add ../landing-page-audit -b audit). A second-account job's cwd: points at its own worktree, never at the folder a live session is using..gitignore that excludes .env* files, keys and tokens, node_modules, downloaded data, job outputs and anything with client details. Scan for secrets before the first push. If a secret ever lands in a commit, stop and rotate it; deleting the file isn't enough.Git-back the project in [FOLDER PATH]. Stop for my yes before you create anything on GitHub. 1. If it isn't a git repo yet, run git init with the default branch main. 2. Write a .gitignore that excludes .env* (except an empty .env.example), keys and tokens, node_modules, build output, downloaded data, job outputs and anything with client details. Show it to me. 3. Stage everything, list the staged files, and scan them for secrets and personal data (gitleaks if installed, otherwise a grep for keys, tokens, emails and phone numbers). If you find a secret, stop and tell me. Don't commit. 4. Commit. Then, with my yes, create a PRIVATE GitHub repo with gh repo create --private and push main. 5. Report: the local path, the remote URL, and the default branch.
Dispatch and the sessions choose a model, and you overrule them in plain words ("run this on Haiku"). Use the cheapest model that does the job well. A heavier model burns your plan's usage limit faster.
| Model | Use it for | Don't use it for |
|---|---|---|
| Haiku | Bulk simple work: sort, tag, rename, summarize, extract, status checks, overnight check-ins | Anything that needs judgement or a multi-step plan |
| Sonnet | Everyday work: drafts, routine edits, simple pages, most second-account jobs | Hard debugging, architecture |
| Opus | Builds, debugging, strategy, the overseer itself. The usual default for real work | Bulk chores Haiku can do |
| Fable | The hardest, longest jobs only: multi-repo architecture, or a problem Opus has already stalled on | Anything routine. It costs several times Opus |
When a session makes a mistake you never want repeated, turn it into a hard rule. Write the rule, then one line on why: the incident behind it. Code sessions read ~/.claude/CLAUDE.md%USERPROFILE%\.claude\CLAUDE.md at the start of every session. In Dispatch, say "remember this as a standing rule". Keep the list short; every rule costs a little on every prompt.
Add a hard rule to my standing rules (your memory, and the "Hard rules" section of ~/.claude/CLAUDE.md; create that section if it's missing). Show me the exact text before you save it. RULE: [WHAT MUST ALWAYS OR NEVER HAPPEN, in one line] WHY: [THE INCIDENT THAT CAUSED IT, in one line]
The skills habit. Every prompt is a skill prompt. The ~/.claude/CLAUDE.md from part 00 tells every session to pick a skill before any real task, run the skill finder when nothing obvious fits, and say in one line which skill it chose. If a session reports "no skill", that's a cue to ask why.
A scheduled task is a prompt the Claude app runs on a timer. The overseer pattern is a check-in every hour or two overnight: read the running sessions, nudge one that has stalled, and write a morning summary. It never starts new outward-facing work. Run check-ins on Haiku or Sonnet: they only read and report. Timers only run while the Claude app is open and the computer is awake. A missed run fires the next time the app opens.
Create a scheduled task named "overnight-check-in" that runs every 2 hours from 11 PM to 7 AM my time, on Haiku. Each run: 1. Read the transcript of every session that is running or was active in the last 2 hours. 2. If one is stuck (same error twice, no progress, waiting on a question), send it one line to get it moving, or write the blocker into its PROJECT-STATE.md. 3. Append a 3-line status per session to ~/Projects/OVERNIGHT.md. 4. Never deploy, send, publish, purchase or delete, and never start a new job. Show me the schedule before you save it.
Read ~/Projects/OVERNIGHT.md and give me the summary. Then pause every overnight scheduled task, and list any timer that is still switched on.
Timers you forget about keep spending your usage. Check your scheduled tasks once a week, and delete any you no longer need.
Chris queues long unattended jobs (audits, data crunching, overnight builds) to a second Claude account, so his main account stays free for live work. Dispatch writes a job file into an inbox folder, and a small script picks it up every 2 minutes and runs it with the second account's token. Skip this unless you have a second paid plan of your own. Never share a login, and stay inside Anthropic's terms.
Download second-account-runner.zip
| Piece | What it does |
|---|---|
inbox/ → running/ → done/ | Each job is a .md file: settings at the top, the prompt below. The output lands in done/<job>.out.md, and STATUS.md is the one-glance summary. |
after: and not_before: | Gates. after: a.md, b.md waits until those jobs are done. not_before: waits until a set time. Chains run in order, one job at a time. |
max_turns, timeout_min, one retry | Anti-loop. Every job has a turn cap (default 40) and a time cap (default 60 minutes). A failed job is retried once, then goes to failed/, and the jobs that depend on it stay put. |
limited/ and LIMIT_UNTIL | The usage-limit wait. When the second account hits its limit, the job goes to limited/ and isn't retried there, and the runner pauses until the reset time. Dispatch picks the job up on the main account. |
| Blocked commands | Unattended jobs can't push, publish or deploy. You review the output, then do the outward step yourself. |
--- cwd: ~/Projects/landing-page model: sonnet max_turns: 40 timeout_min: 60 after: build-site.md --- Audit the built site for broken links and missing alt text. Change nothing. Write the findings to AUDIT.md, worst first.
Set up the second-account job runner from the Master Agent Field Manual (part 05). Stop for my approval before you install the timer. 1. Unzip second-account-runner.zip from Downloads into my home folder, so the runner is at ~/second-account-jobs/run.mjs. Don't overwrite anything. 2. Tell me to create the token myself: run "claude setup-token" signed in as my SECOND account, copy .env.example to .env and paste the token there. Never ask me to paste it into this chat, and never print it. 3. Run: node ~/second-account-jobs/run.mjs --dry and confirm it shows the hello job with "token": "present". 4. With my yes, install the 2-minute timer for this computer as the README says. Then wait until inbox/0-hello.md reaches done/, and show me done/0-hello.out.md. 5. Teach yourself the habit: to queue a job, write a .md file into ~/second-account-jobs/inbox/. Check STATUS.md before you answer about a queued job, and take over anything in limited/ on the main account.
Part 06 · TFG agents
The Hive Console is TFG's command center on top of GoHighLevel: it drafts and answers your lead texts in your voice, runs the follow-up drip inside the legal calling and texting hours, writes your call wrap-ups into GHL, and gives you a ranked list of the people most likely to close today. Three steps get you set up.
Same two files as part 00. Do the parts for the Claude you use. Doing both is fine.
Download skill-library.zip Download agent-brain-code.zip
Claude desktop app: open Claude, go to Customize → Skills → Upload, and pick skill-library.zip from Downloads. Upload the zip as it is; do not unzip it.
The Claude desktop app is not available for Linux. On Linux, install for Claude Code below.
Claude Code (the terminal app, on MacWindowsLinux): close any open Claude Code windows, then run this. It puts 80 skills in ~/.claude/skills%USERPROFILE%\.claude\skills and keeps any files you already have.
unzip -n ~/Downloads/agent-brain-code.zip -d ~
tar -xkf "$env:USERPROFILE\Downloads\agent-brain-code.zip" -C "$env:USERPROFILE"
ls ~/.claude/skills | wc -l
(Get-ChildItem "$env:USERPROFILE\.claude\skills" -Directory).Count
Use PowerShell (Start menu, type PowerShell), not Command Prompt: the commands above are PowerShell. Claude Code on Windows also needs Git for Windows (git-scm.com). tar is built into Windows 10 and 11.
If unzip is not found, run sudo apt install unzip first.
Then start Claude Code again (claude) and ask it: "Which skills do you have for GoHighLevel and follow-up texting?" It should name them.
The connector lets your Claude look up your Hive contacts and read your campaigns, and lets admins run Training and the reply simulator. It signs in as you, so it sees exactly what you see in the Hive Console. It never sends a text or changes anything in GoHighLevel. The address is the same on every computer:
https://hive-mcp.chrisb-financial.workers.dev/mcp
Claude desktop app (macOSWindows):
TFG Hive. URL: https://hive-mcp.chrisb-financial.workers.dev/mcp. Leave the advanced settings empty and choose Add.On a Team or Enterprise plan, an owner adds the connector once in the organization's settings; you then only choose Connect and sign in.
The Claude desktop app is not available for Linux. Use Claude Code below.
Claude Code (on MacWindowsLinux): add it once, then sign in from inside Claude Code.
claude mcp add --transport http --scope user tfg-hive https://hive-mcp.chrisb-financial.workers.dev/mcp
Start Claude Code (claude), type /mcp, pick tfg-hive and choose Authenticate. Your browser opens the same Hive sign-in: use your GoHighLevel email and your Hive password, then choose Approve. --scope user makes it work in every folder.
What each tool does
contacts_search finds your contacts by name, email or phone.contacts_get shows one contact's details and filled custom fields.campaigns_list lists your campaign buckets and the room left under the daily drip cap.campaigns_stats shows today's texts against GoHighLevel's 600-a-day limit. Admins only.training_stages lists the conversation stages Training can practice. Admins only.training_run lets you play the lead for one practice turn and shows the reply the Hive would send. Nothing sends. Admins only.sims_run runs up to 5 simulated conversations and reports which passed. Nothing sends. Admins only.Try it: ask Claude "Use TFG Hive to find my contact Jane Smith." If a tool answers "Not allowed", that record or tool isn't open to your account. To disconnect, remove the connector in Claude; Chris can also revoke it in the Hive Console under Settings → Connected apps.
Open tfg-crm-edge.pages.dev in your browser (it moves to crm.triumphantfg.com soon). It works the same on Mac, Windows and Linux.
The connector in step 2 uses the same email and password. If the sign-in sends you to the Hive dashboard instead of the Approve screen, go back to Claude and choose Connect again.
Part 07 · optional · experimental
Optional and experimental. The day-to-day setup is part 05: Dispatch overseeing sessions, plus the second-account runner if you need more capacity. This LiteLLM and ChatDev swarm is still being built, and you don't need it.
Everything so far is you supervising sessions. The swarm is the next step: several agents with fixed roles pass a job down a line on your own machine, an orchestrator checks every hand-off, and you only step in for decisions that matter. Come here only once parts 00–06 feel routine.
One worker per job. You open it, check in, correct it, approve the result. Best for anything where your judgement is part of the work.
A pipeline of role agents (planner, architect, builder, tester, critic) that runs queued tasks without you. Best for repeatable jobs where a test or a check, not your eye, can tell whether the result is right.
| Part | What it does |
|---|---|
| Model gateway (LiteLLM, self-hosted) | One door to every model. Agents ask for a tier, never a vendor model: tier-local (free, runs on your computer), tier-cheap (fast default), tier-strong (hard tasks only). Swapping the model behind a tier is a one-line change. It listens only on your own machine, not your network. |
| Role agents | Planner, architect, builder, tester and critic, each with its own instructions, built on the open-source ChatDev framework. The tester writes checks from the task before the builder starts. |
| Orchestrator | Watches an inbox of queued tasks, runs each one down the line, scores every hand-off, and serves a dashboard on your own machine. Daily and monthly spend caps stop paid model calls when they are reached. |
| Sandbox | Generated code runs in a locked container: no network, no secrets, read-only files, hard memory and CPU limits. |
| Evals | A standing set of tasks with known answers, re-run after changes, so "it got better" is measured rather than claimed. |
The swarm may act alone only where something other than a model's opinion can tell it that it was wrong, or where being wrong is cheap to undo. Every action has a tier, set in code and never decided by a model:
| Tier | Examples | What happens |
|---|---|---|
| T0 · observe | Read files, search, compute, run code in the sandbox | Automatic |
| T1 · reversible | Write files in the workspace, create drafts, open a local branch | Automatic, logged, undoable |
| T2 · consequential | Send a message as you, publish, spend money, delete, change an outside account, touch a live system | Queued for your approval while the swarm keeps working on everything else |
An action nobody has given a tier is treated as T2. That is the same "nothing outward-facing without your yes" rule from part 00, enforced in code instead of by asking nicely.
The swarm is not in the skill pack. It is software you run, not instructions, and it is still being built on the original setup, so treat it as a project, not an install. You need:
Help me build a small agent swarm on this computer, step by step. Stop for my approval before each step. Folder: ~/Projects/agent-swarm 1. Check that Docker is installed and running. If not, tell me exactly what to install and stop. 2. Model gateway: run LiteLLM in Docker, pinned to a specific image version, listening on 127.0.0.1 only. Define three tier aliases: tier-local (a free local model, optional), tier-cheap and tier-strong. Agents must only ever ask for a tier. 3. Secrets: put my API key and the gateway's master key in a .env file that is git-ignored. Never print them. 4. Spend caps: a daily and a monthly dollar limit that block paid tiers when reached. Start at [DAILY $] and [MONTHLY $]. 5. Sandbox: generated code runs in a container with no network, no secrets, a read-only filesystem and memory and CPU limits. 6. Roles: planner, architect, builder, tester (writes checks from the task before the builder starts) and critic, on the open-source ChatDev framework. 7. Orchestrator: an inbox folder of queued tasks, a log of every hand-off with a score, and a local dashboard. 8. Action tiers: T0 observe and T1 reversible run automatically; T2 (send, publish, spend, delete, touch any outside account) is queued for my approval. Anything without a tier is T2. Build no T2 actions yet. 9. Prove it: run one demo task end to end, show me the dashboard and the spend, then write a one-page README with the start, stop and submit-a-task commands. Keep PROJECT-STATE.md updated after every step. Do not deploy or publish anything.
Expect this to take several sessions, and run it overnight with the pattern from part 03 if you like. When the demo works, start with one repeatable job you already do by hand, and add a T2 action only once you trust the T0/T1 results.
Optional · practice
Nothing here is required to use the system. Each round says which part it tests. Your best score in each counts toward your rank.
In real use Dispatch and the session make these choices for you. Here you sit in their seat: a task comes in, you pick the session type, the model and the skill, so you can recognise a good choice when you see one.
One night, four decisions.
Ten questions, 50 XP each.