# George's Agent Framework v0.2 (2026-11-06), all modules in one file Source: https://andersoncollab.github.io/george-kit/ . Each section below is one file; its path is in the heading comment. # 00 · Start Here > One page that tells you, George's Claude, what this framework is, the order to run it in, and the first thing to do. **Run it:** `Read 00-START-HERE from my framework and tell me the plan.` **Needs first:** nothing **Time:** about 10 minutes · **GEORGE's part:** read your one-paragraph plan and say "go" ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{GEORGE_GITHUB_PERSONAL}} | The personal GitHub account that will hold the brain repo | Ask George once | | {{SETUP_MACHINE}} | The laptop where the first setup runs | Ask George once | | {{FRAMEWORK_URL}} | Where this framework lives | The address you fetched this file from | | {{ACCOUNT_EMAIL}} | The one email used for **every** account George creates in this framework (Cloudflare, 1Password, Claude Console, any data service) | The handoff George pasted names it; confirm with George and write it in `BRAIN.md` | ## Why this matters George relearns the same things over and over because nothing his agents learn is written down where the next agent can find it. He is also the production line for every video, article and update, and drafts from AI tools don't always sound like him. This framework fixes those three things in a set order. Each module is a template: you fill its slots from what you already know about George or by asking him once, then you run its steps and prove each one. You are expected to know things we don't, such as what **G's Plan** is. Wherever you see `{{GS_PLAN_...}}`, fill it from your own knowledge of George and confirm with him. ## Steps 1. **Read the three standing rules.** They apply to every module, every session, every agent. - **Drafts, George decides.** Nothing is sent, posted, published or paid without an Approve from George or someone he named. - **If it isn't in the brain repo, it didn't happen.** Every session starts by reading `george-os` and ends by writing a handoff to `main`. - **No secrets in chat, ever.** Use a connector or 1Password. A key that lands in a chat is treated as leaked. *Check:* repeat the three rules back to George in your own words. 2. **Read the run order below and the module format in [01](./01-HOW-THIS-FRAMEWORK-WORKS.md).** *Check:* you can say which modules need George's hands. 3. **Open the session on George's laptop.** The first setup runs in the Claude desktop app, **Code** tab, as a **local** session, because some steps install things on his computer. Later work can run in the cloud. *Check:* you can run a harmless command such as `git --version`. 4. **Write George a one-paragraph plan.** Say which modules you will run today, what you need from him, and roughly how long. *Check:* George says "go". 5. **Start with module 04.** It finds what Claude already knows about George before anything new gets built. *Check:* 04's interview batch is ready to show him. ## The run order | # | Module | What it gets George | Needs first | |---|---|---|---| | 00 | [Start Here](./00-START-HERE.md) | This page | nothing | | 01 | [How This Framework Works](./01-HOW-THIS-FRAMEWORK-WORKS.md) | How to prompt, re-run and change modules | 00 | | 02 | [Ground Rules](./02-GROUND-RULES.md) | The rules every agent follows | 01 | | 03 | [System Map](./03-SYSTEM-MAP.md) | One picture of how the pieces fit | 02 | | 04 | [Inventory and Interview](./04-INVENTORY-AND-INTERVIEW.md) | Everything Claude already knows, gathered once | 03 | | 05 | [Profile](./05-PROFILE.md) | Who George is, written down for every agent | 04 | | 06 | [Brain Repo](./06-BRAIN-REPO.md) | The private repo that is the single source of truth | 04, 05 | | 07 | [Memory Ritual](./07-MEMORY-RITUAL.md) | Start and end every session the same way | 06 | | 08 | [Claude App Setup](./08-CLAUDE-APP-SETUP.md) | Projects, memory, connectors, Pro plan settings | 06, 07 | | 09 | [Passwords and Secrets](./09-PASSWORDS-AND-SECRETS.md) | 1Password, with no keys in chats | 08 | | 10 | [Skills Adoption](./10-SKILLS-ADOPTION.md) | The george-* skills installed and his to change | 06, 09 | | 11 | [Skills Catalog](./11-SKILLS-CATALOG.md) | What each skill does and when to use it | 10 | | 12 | [Voice Guide](./12-VOICE-GUIDE.md) | George's real voice, written down | 06, 07 | | 13 | [Anti-Slop](./13-ANTI-SLOP.md) | A check every draft must pass | 12 | | 14 | [Design Standard](./14-DESIGN-STANDARD.md) | Pages and graphics that look designed | 06 | | 15 | [Dashboard: What and Why](./15-DASHBOARD-WHAT-AND-WHY.md) | One place to see and approve everything | 04, 05 | | 16 | [Dashboard Build](./16-DASHBOARD-BUILD.md) | The approval dashboard, built and locked | 09, 15 | | 17 | [Dashboard Data Sources](./17-DASHBOARD-DATA-SOURCES.md) | His numbers pulled in | 09, 16 | | 18 | [Team Access](./18-TEAM-ACCESS.md) | His team signs in once, sees only their part | 16 | | 19 | [Automation Chooser](./19-AUTOMATION-CHOOSER.md) | Which job runs where | 04, 07, 16 | | 20 | [Scheduled Tasks](./20-SCHEDULED-TASKS.md) | Weekly jobs that run without him | 06, 07, 16, 19 | | 21 | [Managed Agents Setup](./21-MANAGED-AGENTS-SETUP.md) | Always-on agents on the Claude API, with a cap | 06, 09, 19 | | 22 | [Managed Agents Recipes](./22-MANAGED-AGENTS-RECIPES.md) | Ready agent recipes for recurring work | 21, 23 | | 23 | [Autonomy Ladder](./23-AUTONOMY-LADDER.md) | What runs alone and what waits for Approve | 16, 19 | | 24 | [Weekly Rhythm](./24-WEEKLY-RHYTHM.md) | His week, with two approvals and a recording | 16, 20, 23 | | 25 | [G's Plan Playbook](./25-GS-PLAN-PLAYBOOK.md) | G's Plan run by the system | 04, 05, 06, 07, 23 | | 26 | [TOI Playbook](./26-TOI-PLAYBOOK.md) | The Overseas Initiative run by the system | 04, 05, 06, 07, 12, 23 | | 27 | [Other Work Boundaries](./27-OTHER-WORK-BOUNDARIES.md) | Personal and work systems kept apart | 02, 04, 06 | | 28 | [Publishing Channels](./28-PUBLISHING-CHANNELS.md) | What publishes itself and what stays a paste | 09, 12, 13, 16 | | 29 | [Control and Scoreboard](./29-CONTROL-AND-SCOREBOARD.md) | Five checks that prove it works | 07, 16, 17, 20 | | 30 | [Troubleshooting](./30-TROUBLESHOOTING.md) | What to do when something breaks | nothing | | 31 | [Iteration Loop](./31-ITERATION-LOOP.md) | How George and Trevor improve this framework | 06, 10 | | 32 | [Prompt Library](./32-PROMPT-LIBRARY.md) | Copy-paste prompts for daily use | nothing | | 33 | [Command Center](./33-COMMAND-CENTER.md) | Run everything with a few short commands | 07, 10, 16, 23, 28 | | 34 | [Meta Social (Facebook and Instagram)](./34-META-SOCIAL.md) | Facebook and Instagram, owned by him, checked before posting | 09, 12, 13, 16, 18, 28 | | 35 | [Meta Ads](./35-META-ADS.md) | Meta ads with a hard spend cap; a person launches every ad | 09, 16, 18, 23, 34 | | 36 | [Email Marketing](./36-EMAIL-MARKETING.md) | Email list and newsletters, test-sent and checked before sending | 04, 09, 12, 13, 16, 18, 28 | | 37 | [GEO and SEO Strategy](./37-GEO-SEO-STRATEGY.md) | Get named and cited by AI engines for the topics he teaches | 12, 13, 16, 28 | Three more things come with this framework: - **Skills:** [./skills/](./skills/README.md), the george-* skills with an installer. Module 10 installs them. - **Dashboard starter:** [../dashboard-proto/](../dashboard-proto/), a blank, polished dashboard shell. Module 16 turns it into George's own dashboard. - **Templates:** [./templates/](./templates/BRAIN.md), the starter files for the brain repo. Module 06 copies them. ## GEORGE does - Reads the one-paragraph plan and says "go". - Answers module 04's questions in one sitting. ## Done when - [ ] George's agent has repeated the three standing rules. - [ ] George approved today's plan. - [ ] Module 04 is next. ## Writes to - Nothing yet. The brain repo doesn't exist until module 06. ## Next - [04 Inventory and Interview](./04-INVENTORY-AND-INTERVIEW.md), after a quick read of 01 to 03. --- **The first prompt George gives his Claude:** > Read my framework starting at 00-START-HERE ({{FRAMEWORK_URL}}). Follow the module format, fill the slots from what you already know about me and ask me the rest in one batch, and run the modules in order. Stop only for the steps marked GEORGE. Start by telling me today's plan. # 01 · How This Framework Works > George learns one way to drive his agent through any module, and the agent learns one way to run them. **Run it:** `Run module 01 from my framework.` **Needs first:** 00 **Time:** about 5 minutes · **GEORGE's part:** learn the five prompts below ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{FRAMEWORK_VERSION}} | The version of this framework George is running | `CHANGELOG.md` next to this framework, top entry | ## Why this matters George is an advanced user and doesn't need hand-holding. What he needs is a fixed shape to hold his agent to, so that every job ends the same way: proven, written down and handed off. When every module looks the same, he can tell at a glance whether his agent skipped something. And when he and Trevor change the framework, they change one module without breaking the rest. ## Steps 1. **Learn the module shape.** Every module has the same sections in the same order: - **Run it:** the prompt that starts it. - **Needs first:** modules that must be done before it. - **Time** and **GEORGE's part:** how long it takes, and what only George can do. - **Fill in first:** the `{{SLOTS}}` to fill before any step runs, and where each answer comes from. - **Why this matters:** the problem it solves. - **Steps:** numbered, and each one has a *Check* that proves it worked. - **GEORGE does:** the human-only parts, such as signing up, approving and choosing people. - **Done when:** checkboxes. The module isn't done until every box is ticked. - **Writes to:** the files in the brain repo it creates or updates. - **Next:** where to go after. *Check:* name the sections in order without looking. 2. **Learn how slots work.** A slot such as `{{GS_PLAN_WHAT_IT_IS}}` is a blank only George's world can fill. Fill slots in this order: (a) the brain repo, if it exists; (b) what you already know about George from his Claude memory and Projects; (c) ask George. **Ask in one batch per module, never one question at a time.** Write every filled slot into the brain repo (module 06) so it is never asked twice. *Check:* you can show where a filled slot was saved. 3. **Learn the five prompts George uses.** | George says | You do | |---|---| | `Run module NN.` | Fill the slots, run the steps with checks, tick Done when, write the handoff. | | `Show me the slots for NN.` | List each slot, your proposed answer, and its source. Change nothing yet. | | `Re-run NN with these changes: ...` | Apply his changes to the steps, run again, and note the change in `WORKLOG.md`. | | `Where are we?` | Read `NOW.md` and the newest handoffs; answer in five lines or fewer. | | `Make NN mine.` | Copy the module into `george-os/framework/NN-*.md`, apply his edits, and use his copy from then on. | *Check:* George runs `Show me the slots for 05` and gets a clean table. 4. **Prove every step.** A step is done only when its *Check* passes, and you say what the check showed in one line. "Should work" doesn't count. *Check:* your report after each module lists one line per step. 5. **Keep his copy as the one that counts.** This framework is published by Trevor and will get updates. George's copy in `george-os/framework/` is his, and it wins over the published one. New versions arrive as proposals (module 31). *Check:* `george-os/framework/` exists after module 06. 6. **Expect to iterate.** George and Trevor will improve this framework several times. Anything that felt wrong, slow or unclear goes in `FEEDBACK.md` the moment it happens (template: [FEEDBACK](./templates/FEEDBACK.md)). Module [31](./31-ITERATION-LOOP.md) turns that feedback into the next version. *Check:* `FEEDBACK.md` exists in the brain repo. ## GEORGE does - Tries the five prompts once. - Adds a line to `FEEDBACK.md` any time a module annoys him. ## Done when - [ ] George has used `Show me the slots for NN` and `Where are we?` at least once. - [ ] The agent reports module results as one proven line per step. ## Writes to - `george-os/FEEDBACK.md` (created in 06 if missing) - `george-os/framework/` (George's own copies of modules) ## Next - [02 Ground Rules](./02-GROUND-RULES.md) # 02 · Ground Rules > The rules every agent, skill and automation follows, written into the brain repo so no agent ever has to guess. **Run it:** `Run module 02 from my framework.` **Needs first:** 01 **Time:** about 10 minutes · **GEORGE's part:** read the rules and change any he disagrees with ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{APPROVERS_DEFAULT}} | Who besides George may approve, if anyone | Ask George once (default: George only) | | {{SCRIPTURE_TRANSLATION}} | The Bible translation George quotes | His Claude memory or recent posts; confirm with George | | {{QUIET_HOURS}} | Hours when no automation should message him | Ask George once (default: 9pm to 6am Central) | ## Why this matters Agents repeat mistakes when the rules live in someone's head. Written once, these rules travel with every session, every skill and every automation. They also stop the three things that hurt most: something published that George didn't see, a key leaked in a chat, and personal and work systems tangled together. ## Steps 1. **Write the ten rules into the brain repo** as `decisions/0001-ground-rules.md`, using the [DECISION template](./templates/DECISION.md): 1. **Drafts, George decides.** Nothing is sent, posted, published or paid without an Approve on the dashboard from George or someone in {{APPROVERS_DEFAULT}}. 2. **The brain repo is the memory.** If it isn't in `george-os` on `main`, the next agent won't know it. Write it down. 3. **Same start, same end, every session.** Pull and read at the start; handoff and push at the end (module 07). 4. **No passwords or keys in chat.** Use a connector or 1Password (module 09). A key that lands in a chat is leaked: change it, then log it in `WORKLOG.md`. 5. **Personal and work stay apart.** This system is George's personal and ministry system on his own accounts. His agency and sales jobs have their own work systems. Don't copy their data in here, and don't connect these agents to theirs (module 27). 6. **No made-up facts.** No invented quotes, dates, numbers, endorsements, reviews or scripture references. Quote scripture as text, with book, chapter and verse, in {{SCRIPTURE_TRANSLATION}}. Mark anything unsure `[check]`. 7. **His voice, never "AI voice".** Every draft passes `george-slop-check` before it reaches the dashboard (module 13). 8. **His kit, his rules.** The george-* skills and his framework copies are his. Updates arrive as proposals and are never applied over his edits (module 10). 9. **Prove it.** Every step reports what its check showed. A green message is not proof; the result is. 10. **Quiet hours.** No automation messages George during {{QUIET_HOURS}} unless something is broken and costing money. *Check:* the file exists on `main` and opens cleanly. 2. **Put a short copy where every agent sees it.** Add the ten rules, one line each, to the top of `BRAIN.md` and to the `CLAUDE.md` file at the root of `george-os`, which Claude Code reads automatically. *Check:* a new Code session in the repo can quote rule 4 without being told where to look. 3. **Show George the rules.** Ask him to strike or change anything. Record every change as a new decision file. *Check:* George says "these are mine". ## GEORGE does - Reads the ten rules and changes any he wants. - Names anyone else who may approve, if anyone. ## Done when - [ ] `decisions/0001-ground-rules.md` is on `main`. - [ ] `BRAIN.md` and `CLAUDE.md` both carry the short version. - [ ] George has confirmed the rules. ## Writes to - `george-os/decisions/0001-ground-rules.md` - `george-os/BRAIN.md` (top section) - `george-os/CLAUDE.md` ## Next - [03 System Map](./03-SYSTEM-MAP.md) (If the brain repo doesn't exist yet, hold these files in the session and write them when module 06 creates the repo.) # 03 · System Map > One picture of George's whole system, so every agent knows where things live and which way work flows. **Run it:** `Run module 03 from my framework.` **Needs first:** 02 **Time:** about 5 minutes · **GEORGE's part:** none ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{BRANDS}} | The brands the system serves, for example George Shamblin (author and teaching), G's Plan, TOI | Module 04 answers; this module can use the default list until then | ## Why this matters Without a map, each agent invents its own idea of where things are, and memory splits into pieces. This map is short on purpose. It shows the one source of truth, the places work happens, and the one door every finished piece passes through before it reaches the public. ## Steps 1. **Learn the map.** ``` george-os (private GitHub repo, branch main = THE source of truth) BRAIN · NOW · WORKLOG · handoffs · people · projects · decisions · voice · calendar · framework │ │ │ claude.ai Projects Claude Code Scheduled tasks (one per brand) (desktop Code tab or (cloud, on his Pro plan) READ the repo claude.ai/code) draft and stage weekly work via GitHub sync WRITES the repo WRITE the repo │ │ │ │ Managed Agents (Claude API, separate credits, capped) │ always-on jobs, brief from AGENT-BRIEF, results to the dashboard └──────────── george-* skills (his kit, his to change) ───────────┘ │ Dashboard (one private link, Google sign-in, 30-day session) approvals by version · his numbers · team per brand │ Publish: Webflow (automatic) · Substack, YouTube, socials (ready-to-paste) Secrets: 1Password with op run (laptop) · network secrets (cloud). Never in chat. ``` *Check:* you can say which surfaces can **write** to the brain (Claude Code, scheduled tasks, Managed Agents through a repo step) and which only **read** (claude.ai Projects). 2. **Learn the four flows.** - **Memory flow:** every session pulls `main`, reads, works, writes a handoff, and pushes to `main`. - **Work flow:** a skill drafts, `george-slop-check` checks, the draft goes to the dashboard as a version, a person approves, and the publish step claims that exact version. - **Data flow:** his numbers (site, YouTube, Substack, and giving totals only if George permits) come into the dashboard on a schedule (module 17). - **Change flow:** George or Trevor changes the framework, the change lands as a proposal, and George decides (module 31). *Check:* trace one Thursday article through the work flow out loud. 3. **Save the map** as `george-os/SYSTEM-MAP.md` with {{BRANDS}} filled in. *Check:* the file is on `main` once module 06 exists. ## GEORGE does - Nothing. ## Done when - [ ] The agent can trace memory, work, data and change flows. - [ ] `SYSTEM-MAP.md` is saved (after 06). ## Writes to - `george-os/SYSTEM-MAP.md` ## Next - [04 Inventory and Interview](./04-INVENTORY-AND-INTERVIEW.md) # 04 · Inventory and Interview > Gather everything Claude already knows about George in one place, ask him the rest once, and never ask again. **Run it:** `Run module 04 from my framework.` **Needs first:** 03 **Time:** about 45 minutes (20 of them with George) · **GEORGE's part:** open his existing Claude memory and Projects, then answer one batch of questions ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{GEORGE_GITHUB_PERSONAL}} | Personal GitHub account for the brain repo | Ask George | | {{GEORGE_GITHUB_WORK}} | Any other GitHub account he uses (for skill repos or work) | Ask George | | {{GS_PLAN_WHAT_IT_IS}} | What G's Plan is, in George's words | **Your own knowledge of George first**, then confirm with him | | {{GS_PLAN_AUDIENCE}} | Who G's Plan serves | Same | | {{GS_PLAN_RECURRING_WORK}} | The jobs G's Plan needs every week or month | Same | | {{GS_PLAN_TOOLS}} | Where G's Plan lives today (sites, docs, apps, lists) | Same | | {{TOI_ROLE}} | George's role at The Overseas Initiative | Your knowledge, then confirm | | {{TOI_RECURRING_WORK}} | TOI's recurring jobs (updates, trips, donors, prayer lists) | Same | | {{TOI_LANGUAGES}} | Languages TOI work goes out in | Same (expected: English and Spanish) | | {{OTHER_THINGS}} | Anything else George runs that the system should know | Ask | | {{TEAM_PEOPLE}} | People who help him, with what they help with | Ask | | {{ACCOUNTS_HE_CAN_SIGN_INTO}} | Webflow, Substack, YouTube Studio, Meta Business Suite, Google, Cloudflare, 1Password | Ask | ## Why this matters George's biggest problem is relearning things over and over. Part of the cure is never starting from zero. Claude may already hold years of context in his memory, his Projects and his past chats, and he already has skill repos on GitHub. This module gathers all of it before anything new is built, so the brain repo starts full instead of empty and nothing gets built twice. **G's Plan and TOI are George's two main things.** We don't know what G's Plan is. You likely do. Fill those slots from what you know, and let George correct you. ## Steps 1. **Read what Claude already remembers.** Ask George to open Settings and show you his Claude memory (or paste it), and to list his claude.ai Projects. For each Project, note its name, what it's for, its instructions and its files. *Check:* a list in the session with every Project and the key memory items. 2. **Inventory both GitHub accounts.** List repos in {{GEORGE_GITHUB_PERSONAL}} and {{GEORGE_GITHUB_WORK}}. Note especially any skill repos he already has (skill packs, starter kits). Mark each one **reuse**, **reference** or **leave alone**. Work-related repos stay **leave alone** (module 27). *Check:* a table of repos with a mark on each. 3. **Inventory his public channels.** georgeshamblin.com (blog, videos, books, the Spanish pages), Substack, YouTube, the podcast, Facebook and Instagram, and the TOI site. Note how often each one posts. *Check:* a table with the channel, link and cadence. 4. **Inventory his docs and notes.** Ask George where he keeps notes, plans, sermon files, mission trip docs and donor records (Google Drive, Notes, Docs, a giving platform). **Donor names, amounts and giving history never go in george-os or any git repo.** Record only a pointer to where they live, who may see them, and any totals George permits. *Check:* a list of locations with an owner for each. 5. **Draft every slot you can answer yourself.** Fill G's Plan and TOI slots from your own memory of George and his past chats. Mark each answer **known** (you're sure), **likely** (you think so) or **unknown**. *Check:* a draft slot table with a confidence mark on every row. 6. **Ask George one batch.** Show him the draft table and the list of unknowns together, as one message. Ask him to correct the knowns, confirm the likelies and fill the unknowns. Keep it to one sitting. *Check:* every slot is confirmed or filled. 7. **Write the results down.** When the repo exists (module 06), save: `inventory/claude-memory.md`, `inventory/projects.md`, `inventory/repos.md`, `inventory/channels.md`, `inventory/docs.md`, and the confirmed slots in `BRAIN.md`, `projects/gs-plan.md` and `projects/toi.md`. *Check:* a fresh session can answer "What is G's Plan?" from the repo alone. 8. **List what to import, then import it.** Anything current from his Claude memory and Projects that the repo should hold goes in as files with a source line. Don't build a second brain next to one that already exists; fold it in. *Check:* George sees the import list and nothing he already has is duplicated. ## GEORGE does - Opens his Claude memory and Projects for the agent. - Answers the one batch of questions. - Says where his private docs and donor records live, who may see them, and which totals (if any) may be shown. ## Done when - [ ] Every slot in this module is confirmed by George. - [ ] Repos are marked reuse, reference or leave alone. - [ ] Inventory files and slot answers are written (after 06). - [ ] A fresh session can explain G's Plan and TOI from the repo. ## Writes to - `george-os/inventory/*.md` - `george-os/BRAIN.md` - `george-os/projects/gs-plan.md`, `george-os/projects/toi.md` - `george-os/people/*.md` (one per person in {{TEAM_PEOPLE}}) ## Next - [05 Profile](./05-PROFILE.md), then [06 Brain Repo](./06-BRAIN-REPO.md) (06 writes what 04 and 05 gathered) # 05 · Profile > Who George is, written once so every agent starts out knowing him. **Run it:** `Run module 05 from my framework.` **Needs first:** 04 **Time:** about 15 minutes · **GEORGE's part:** read the profile and fix anything wrong ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{GS_PLAN_ONE_LINE}} | G's Plan in one sentence | Module 04 | | {{TOI_ONE_LINE}} | George's work at TOI in one sentence | Module 04 | | {{OTHER_ROLES}} | Other roles George wants agents to know about | Module 04 | | {{AUDIENCES}} | Who reads, watches and gives | Module 04 and his channels | | {{BELIEFS_PAGE}} | Link to his beliefs page | georgeshamblin.com | | {{NEWEST_BOOK}} | His newest book | georgeshamblin.com/books | ## Why this matters Every chat that starts with "who am I talking to?" wastes George's time. The profile answers it before the first message. Keep it short: a page an agent reads in under a minute. Details go in `projects/` and `people/`. ## Steps 1. **Start from the public facts.** Seed `BRAIN.md` (from the [BRAIN template](./templates/BRAIN.md)) with what is public: - George Shamblin, Birmingham, Alabama. Pastor, Christian author, Bible teacher, former seminary professor. - Author brand: georgeshamblin.com (with Spanish pages at /es), Substack, YouTube @georgeshamblinauthor, a Spotify podcast, Facebook and Instagram. - His promise to readers: "I answer hard Bible questions every week. Tuesday videos and Thursday articles, both free." - Books: *The Four Faces of Christ*, *The Relay* and *Inerrancy* ({{NEWEST_BOOK}} first). - Series: Torchbearers (church history videos), Systematic Theology Shorts, Bible Questions Answered, Wild Game Tame Garden (outdoor devotionals), mission week diaries. - Co-founder of The Overseas Initiative (TOI): missions in Cuba and Latin America. - Pastor at The Center for Executive Leadership. *Check:* every line here matches his site. 2. **Add his two main things from module 04.** A "Main things" section with **G's Plan**: {{GS_PLAN_ONE_LINE}}, and **TOI**: {{TOI_ONE_LINE}}, each linking to its `projects/` file. *Check:* both lines are in George's words, not yours. 3. **Add audiences and roles.** {{AUDIENCES}} and {{OTHER_ROLES}}, one line each. Work roles get one line and a pointer to module 27; their details stay in his work systems. *Check:* no client or work data appears. 4. **Add how George likes to work.** From 04 and from your memory of him: how he likes updates (short or full), when he works, what annoys him. Keep it to five lines. *Check:* George agrees with every line. 5. **Keep it under one page.** If it grows, move detail into `projects/` and leave a link. *Check:* `BRAIN.md` reads in under a minute. ## GEORGE does - Reads the profile and corrects anything wrong. ## Done when - [ ] `BRAIN.md` has the public facts, both main things, audiences, roles and work style. - [ ] George confirmed it. - [ ] It fits on one page. ## Writes to - `george-os/BRAIN.md` ## Next - [06 Brain Repo](./06-BRAIN-REPO.md) # 06 · Brain Repo > One private GitHub repo becomes George's single source of truth, which every agent reads first and writes last. **Run it:** `Run module 06 from my framework.` **Needs first:** 04, 05 **Time:** about 30 minutes · **GEORGE's part:** approve GitHub sign-in once ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{GEORGE_GITHUB_PERSONAL}} | Personal GitHub account | Module 04 (ask George) | | {{BRAIN_REPO}} | Repo name | Default `george-os` | | {{BRANDS}} | Brands for Projects and folders | Module 04 | ## Why this matters Memory in a chat dies with the chat. Memory in one Claude Project doesn't reach Claude Code or a scheduled task. A private Git repo is the one place every surface can read, it keeps history, and it shows exactly what changed and when. Plain files come first because they work everywhere. A knowledge graph can come later if the files ever outgrow what a Project can hold. ## Steps 1. **Create the repo in his personal account.** Make `{{GEORGE_GITHUB_PERSONAL}}/{{BRAIN_REPO}}`, **private**, with default branch `main`. Never create it inside an organization: members of an organization can often read every repo in it. *Check:* the repo page shows Private, and the owner is his personal account. 2. **Lay out the folders** using the [templates](./templates/BRAIN.md): ``` george-os/ CLAUDE.md the ten rules and the session ritual (Claude Code reads this automatically) BRAIN.md who George is, his main things, rules summary (templates/BRAIN.md) NOW.md this week: what's in flight, owner, due, status (templates/NOW.md) WORKLOG.md append-only, one line per session (templates/WORKLOG.md) SYSTEM-MAP.md from module 03 FEEDBACK.md what to improve in the framework (templates/FEEDBACK.md) CONTROL.md the five checks (templates/CONTROL.md) handoffs/ one file per session (templates/HANDOFF.md) projects/ gs-plan.md, toi.md, one per ongoing thing (templates/PROJECT.md) people/ one per person who matters (templates/PERSON.md) decisions/ 0001-ground-rules.md and on (templates/DECISION.md) voice/ VOICE.md, gold/, banned.md (templates/VOICE.md) calendar/ CALENDAR.md, the editorial and ministry calendar (templates/CALENDAR.md) inventory/ from module 04 agents/ one brief per automated agent (templates/AGENT-BRIEF.md) skills/ a copy of the george-* kit (module 10) framework/ George's own copies of modules he has changed upstream/ dated proposals from Trevor, never applied automatically ``` *Check:* `git ls-tree -d main` lists every folder. 3. **Write in what 02, 03, 04 and 05 gathered.** Ground rules, map, inventory, profile, `projects/gs-plan.md`, `projects/toi.md`, and `people/`. *Check:* every file has a source line saying where its facts came from. 4. **Set the branch rule.** `main` is the only branch that counts for memory. Every session ends with `git pull --rebase origin main && git push origin main`. Work for websites and code can use other branches; **memory can't**. *Check:* `git log origin/main -1` shows your latest commit. 5. **Leave out what doesn't belong.** No passwords or keys (module 09). No donor names, amounts or giving history, ever, in this or any git repo; record only a pointer to where they live and any totals George permits. No data from his work systems (module 27). *Check:* run `grep -riE "password|api[_-]?key|sk-|secret" .` and get no real hits. 6. **Test it cold.** Open a brand-new Claude Code session in the repo (cloud is fine) and ask: "What is G's Plan, what's in flight this week, and what did we do last?" *Check:* it answers from the files without George explaining anything. ## GEORGE does - Approves the GitHub sign-in when Claude asks. ## Done when - [ ] Private `george-os` exists in his personal account, default branch `main`. - [ ] All folders and starter files are in place, filled from 02 to 05. - [ ] The cold test passes. ## Writes to - The whole `george-os` repo ## Next - [07 Memory Ritual](./07-MEMORY-RITUAL.md) # 07 · Memory Ritual > Every session starts and ends the same way, so no agent forgets what another did and long jobs never lose their place. **Run it:** `Run module 07 from my framework.` **Needs first:** 06 **Time:** about 20 minutes · **GEORGE's part:** none ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{CHECKPOINT_MINUTES}} | How often long jobs save progress | Default 30 | | {{HANDOFFS_TO_READ}} | How many recent handoffs each session reads | Default 3 | ## Why this matters George named two ways agents fail him: one agent doesn't know what another did, and long sessions forget how they started. Both come from the same gap: nothing is written down at the right moments. This ritual closes that gap with three habits: read before starting, save while working, write before stopping. ## Steps 1. **Write the start ritual** into `CLAUDE.md` and `specs/S-1-session-start.md`: - `git pull` on `main`. - Read `BRAIN.md`, `NOW.md` and the {{HANDOFFS_TO_READ}} newest files in `handoffs/`. - Say in one line what you picked up and what you think is next. *Check:* a fresh session opens with that one line without being asked. 2. **Write the checkpoint habit** into `CLAUDE.md` and `specs/S-2-checkpoint.md`. Any job longer than one sitting gets a `projects/.md` from the [PROJECT template](./templates/PROJECT.md): the goal, a checkbox per step, and "where I am". Every {{CHECKPOINT_MINUTES}} minutes, tick the boxes, update "where I am", commit and push to `main`. *Check:* during a long job, `git log` shows checkpoint commits. 3. **Write the end ritual** into `CLAUDE.md` and `specs/S-3-session-end.md`: - Append one line to `WORKLOG.md`: date, surface (laptop, cloud, scheduled task, managed agent), what was done, link. - Write `handoffs/-.md` from the [HANDOFF template](./templates/HANDOFF.md): done, where I stopped, next, open questions. - Update `NOW.md`. - `git pull --rebase origin main && git push origin main`, and report the commit. *Check:* the commit is on `origin/main`. 4. **Handle claude.ai Projects, which can't write.** Projects read the repo through GitHub sync but can't save to it. Put this in every Project's instructions: "Read BRAIN.md, NOW.md and the newest handoffs first. You can't save to the brain. If we decide or make anything worth keeping, end with a handoff note for me to file in Code." George pastes that note into a Code session and says "file this". *Check:* a test Project chat ends with a handoff note, and Code files it. 5. **Handle scheduled tasks and Managed Agents.** Cloud scheduled tasks push to `claude/` branches by default. For `george-os` only, turn on **unrestricted branch pushes** in the task's repository settings, so memory lands on `main` (module 20). Managed Agents end every run by writing their handoff through the same steps (module 22). *Check:* two scheduled runs in a row, where the second names what the first did. 6. **Run the two-session test.** Session one (cloud) does a small job and ends with the ritual. Session two (on the laptop) starts with the ritual. *Check:* session two names session one's work without George saying anything. ## GEORGE does - Nothing. If an agent ever starts cold, he says "Run the start ritual." ## Done when - [ ] `CLAUDE.md` holds start, checkpoint and end rituals. - [ ] `specs/S-1` to `S-3` exist. - [ ] Every Project's instructions carry the read-only note. - [ ] The two-session test passes. ## Writes to - `george-os/CLAUDE.md` - `george-os/specs/S-1-session-start.md`, `S-2-checkpoint.md`, `S-3-session-end.md` ## Next - [08 Claude App Setup](./08-CLAUDE-APP-SETUP.md) # 08 · Claude App Setup > George's Claude Pro account is set up so Projects, memory, connectors and Claude Code all point at the same brain. **Run it:** `Run module 08 from my framework.` **Needs first:** 06, 07 **Time:** about 30 minutes · **GEORGE's part:** click through settings and connector sign-ins ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{BRANDS}} | One Project per brand | Module 04 (for example George Shamblin author and teaching, G's Plan, TOI) | | {{EXTRA_USAGE_CHOICE}} | Whether extra usage credits are on, and the cap | Ask George (default: off) | ## Why this matters George is on **Claude Pro**, which includes Claude Code (the desktop app's Code tab and claude.ai/code), cloud sessions, custom Skills, Projects with their own memory, and scheduled tasks. Pro has lower usage limits than higher plans, so the setup stays lean: one Project per brand, skills that do one job each, and automations that do their work and stop. Each surface has one job: Projects are reading rooms, and Claude Code is the workshop that writes to the brain. ## Steps 1. **Check the plan.** Settings shows Pro. Note the usage page and when limits reset. *Check:* George sees his plan and usage. 2. **Decide extra usage.** Settings > Usage: if extra usage credits are on, automations keep running past the plan limit and bill per use. Record {{EXTRA_USAGE_CHOICE}} in `NOW.md`. Default is off, so automations simply stop at the limit. *Check:* the setting matches what George chose. 3. **Turn on code execution and memory.** Settings > Capabilities: turn on code execution and file creation (skills need it). Turn on memory. Each Project keeps its own memory; the repo carries what must cross between them. *Check:* both toggles are on. 4. **Create one private Project per brand.** For each of {{BRANDS}}, create a **private** Project. In project knowledge, add `george-os` through the GitHub integration. Paste into the instructions: "Read BRAIN.md, NOW.md and the newest handoffs first. You can't save to the brain. If we decide or make anything worth keeping, end with a handoff note for me to file in Code." GitHub sync works only in private Projects, and it is manual: click **Sync now** at the start of a chat if the brain changed. *Check:* in each Project, "What is this brand and what's in flight?" gets an answer from the repo. 5. **Add connectors.** Customize > Connectors: Google Drive, Gmail, Google Calendar, GitHub, and Webflow (its connector lives at mcp.webflow.com). Connectors sign in with OAuth, so no key ever touches a chat. Depending on what George grants, a connector may be able to draft or send email, create or change events, or edit files. **The rule that nothing is sent, created or published without an Approve is ours, not a technical limit**, so agents follow it whatever the connector allows. For unattended scheduled tasks and agents, remove every connector the job doesn't need. *Check:* a Project chat can read one calendar event and one Drive doc. 6. **Set up Claude Code.** In the desktop app, open the **Code** tab. A local session runs on the laptop (needed for installs). A cloud session runs at claude.ai/code and keeps going with the laptop closed. Connect GitHub through the browser onboarding so cloud sessions can open `george-os`. *Check:* one local and one cloud session can both read `BRAIN.md`. 7. **Point every surface at the ritual.** Confirm `CLAUDE.md` in the repo carries the rules and ritual (module 07); Claude Code reads it automatically. *Check:* a new Code session opens with the one-line pickup. ## GEORGE does - Clicks the settings toggles and connector sign-ins. - Chooses extra usage on or off. - Creates the Projects if the agent can't (it will tell him the exact clicks). ## Done when - [ ] Code execution and memory are on; the extra usage choice is recorded. - [ ] One private Project per brand, synced to `george-os`, with the read-only note. - [ ] Drive, Gmail, Calendar, GitHub and Webflow connectors work, and unattended jobs carry only the connectors they need. - [ ] Local and cloud Code sessions both open the brain. ## Writes to - `george-os/NOW.md` (extra usage choice) - `george-os/inventory/projects.md` (the new Project list) ## Next - [09 Passwords and Secrets](./09-PASSWORDS-AND-SECRETS.md) # 09 · Passwords and Secrets > George's logins live in 1Password, his team shares only what they need, and agents use keys without ever seeing or printing them. **Run it:** `Run module 09 from my framework.` **Needs first:** 08 **Time:** about 45 minutes · **GEORGE's part:** create the 1Password account and vaults ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{ONEPASSWORD_PLAN}} | Families (just family) or a team plan (team shares logins) | Ask George; team plan if anyone in {{TEAM_PEOPLE}} shares logins | | {{VAULTS}} | Vault list | Default: Personal, Author, G's Plan, TOI, Agents | | {{VAULT_ACCESS}} | Who sees each team vault | Module 04's {{TEAM_PEOPLE}} | ## Why this matters Keys typed into a chat end up in transcripts and logs, where anyone who reads them can use them. A helper who signs in with George's shared password sees everything. 1Password fixes both: each person gets only the vaults they need, and agents run commands with keys injected at the moment of use. Best of all is no key at all: a connector that signs in with OAuth leaves nothing to leak. ## Steps 1. **Prefer connectors.** Before storing any key, check whether a connector does the job: Gmail, Calendar, Drive, GitHub and Webflow all sign in with OAuth (module 08). *Check:* a list of what still truly needs a key; it should be short. 2. **Create the account.** George creates a 1Password account on {{ONEPASSWORD_PLAN}}, installs the browser extension and phone app, and moves his logins in. *Check:* George signs in to one site through the extension. 3. **Create the vaults.** {{VAULTS}}. Share each team vault only with the people in {{VAULT_ACCESS}}. `Agents` holds only the few keys agents truly need. *Check:* each vault's member list matches the slot. 4. **Connect the CLI to the 1Password app on the laptop.** In a **local** Code session, install the 1Password CLI (`op`). Then George opens the 1Password desktop app > Settings > Developer and turns on **Integrate with 1Password CLI**. From then on `op` unlocks with Touch ID through the app, so no token sits in any file or chat. *Check:* `op vault list` works after a Touch ID prompt. 5. **Use keys without seeing them.** Agents never print a secret. Put `op://Agents//credential` references in an env file and run the command that needs the key under `op run --env-file=.env -- `. That hands the key to that one command and masks it if it shows up in output. **Never use a bare `op read` in an agent session**, because it prints the secret into the transcript. **Optional, only for unattended local scripts:** a 1Password **service account** that can read only `Agents`. If you use one, George stores its token (`OP_SERVICE_ACCOUNT_TOKEN`) in macOS Keychain, and a small wrapper script reads it from Keychain at run time; it is never printed, typed into chat or saved in a file. *Check:* `op run` works with no token in any file. 6. **Run the dummy test.** Create an item in `Agents` with the value `DUMMY-123`. Run a command that uses it under `op run`. *Check:* the command succeeds and the string `DUMMY-123` appears nowhere in the session transcript. Store real keys only after this passes. 7. **Set up cloud secrets.** Scheduled tasks run in the cloud. Keys they need go in the cloud environment's **network secrets**, so the session never sees them. Don't use plain environment variables there; anyone using that environment can read them. Managed Agents get their credentials as module 21 describes. *Check:* a scheduled test task uses a network secret without it appearing in output. 8. **Write the leak rule.** Add to `decisions/`: "A key seen in any chat is leaked. Change it at the source, update 1Password, and log the change in `WORKLOG.md`." *Check:* the decision file is on `main`. ## GEORGE does - Creates the 1Password account and installs the apps. - Creates the vaults and invites the right people. - Turns on Integrate with 1Password CLI in the 1Password app (and approves Touch ID). - Creates a service account only if an unattended local script needs one. ## Done when - [ ] Logins live in 1Password; team vaults are shared correctly. - [ ] `op` works through the 1Password app with Touch ID; any service account reads only `Agents` and its token lives only in Keychain. - [ ] The dummy test passed with `op run`. - [ ] Cloud keys are network secrets. - [ ] The leak rule is a decision on `main`. ## Writes to - `george-os/decisions/0002-secrets.md` - `george-os/inventory/accounts.md` (which accounts exist and where their login lives; **never the logins themselves**) ## Next - [10 Skills Adoption](./10-SKILLS-ADOPTION.md) # 10 · Skills Adoption > The george-* skills get installed everywhere George works, become his to change, and never overwrite his edits or anyone else's skills. **Run it:** `Run module 10 from my framework.` **Needs first:** 06, 09 **Time:** about 30 minutes · **GEORGE's part:** upload the zips in the Claude app if the agent can't ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{REUSE_REPOS}} | Repos marked "reuse" in module 04 | `inventory/repos.md` | | {{SKILLS_TO_SKIP}} | Any george-* skill George doesn't want | Ask after showing the catalog (module 11) | ## Why this matters A skill is a saved playbook: one sentence from George runs a whole job the same good way every time. That is how output stops drifting and how George stops re-explaining. These skills come from working skills Trevor's team uses, rewritten for George's work. They are his copies. He can rename, rewrite or delete any of them, and an update will never overwrite a change he made. ## Steps 1. **Get the kit.** Download the skills folder from this framework ([skills/README](./skills/README.md)) or the framework zip, and copy it into `george-os/skills/`. *Check:* `george-os/skills/` holds one folder per george-* skill, each with a `SKILL.md`, plus `install.sh`. 2. **Read before you switch anything on.** Anthropic doesn't review uploaded skills. Read every `SKILL.md` and confirm each one only does what it says: no hidden sends, no keys, no outside links you don't recognize. *Check:* a one-line verdict per skill. 3. **Install for Claude Code.** In a local Code session: `bash george-os/skills/install.sh`. It copies only `george-*` folders into `~/.claude/skills/` and touches nothing else. It keeps a fingerprint of what it installed. On a re-run it **keeps any george-* skill George has edited** (reported as `kept (edited)`) and writes the kit's new version into `george-os/upstream/skills/` as a proposal instead. Untouched skills update normally. *Check:* `ls ~/.claude/skills | grep george-` lists the kit, and nothing else in that folder changed. 4. **Install for the Claude app (web and desktop chat).** Run `bash george-os/skills/install.sh --zip` to make one zip per skill. With code execution on (module 08), George uploads each zip at **Customize > Skills** and switches it on. *Check:* in a Project chat, "Weekly brief, please." triggers george-weekly-brief. 5. **Fold in his existing skills.** For each repo in {{REUSE_REPOS}}, list skills that overlap with george-* ones. Keep the better one and note the choice in `decisions/`. Don't install two skills that do the same job, or Claude won't know which to use. *Check:* a short overlap table with a decision per row. 6. **Prove an edit survives.** Edit the **installed** copy: open `~/.claude/skills/george-voice/SKILL.md` and make a small change George asks for (a phrase he never uses, a step he wants). Re-run `bash george-os/skills/install.sh`. *Check:* the installer reports `kept (edited)` for george-voice, the edit is still there, and the kit's version appears as a proposal in `george-os/upstream/skills/george-voice/`. **Then prove updates still flow.** Change one line in the source of a skill nobody has touched (in `george-os/skills/`), re-run install. *Check:* that skill shows `updated` and the installed copy has the new line. Revert the test change afterward. 7. **Explain updates.** When Trevor improves the kit, new versions land in `upstream/` with a date. The agent reads them, shows George a short diff, and George decides. Nothing updates on its own. *Check:* `upstream/README.md` explains this in three lines. ## GEORGE does - Uploads the zips in Customize > Skills if the agent can't. - Asks for one change to george-voice for the edit test. - Strikes any skill he doesn't want ({{SKILLS_TO_SKIP}}). ## Done when - [ ] Every george-* skill was read and given a verdict. - [ ] Installed in Claude Code and uploaded in the app. - [ ] Overlaps with his existing repos are decided. - [ ] An edit to the installed george-voice survived a re-install as `kept (edited)`, with a proposal in `upstream/skills/`. - [ ] A source change to an untouched skill installed as `updated`. ## Writes to - `george-os/skills/` - `george-os/upstream/README.md` - `george-os/decisions/0003-skills.md` ## Next - [11 Skills Catalog](./11-SKILLS-CATALOG.md) # 11 · Skills Catalog > Every george-* skill on one page: what it does, the sentence that runs it, and the module it belongs to. **Run it:** `Run module 11 from my framework.` **Needs first:** 10 **Time:** about 15 minutes · **GEORGE's part:** try five of the sentences ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{SKILLS_TO_SKIP}} | Skills George struck in module 10 | `decisions/0003-skills.md` | | {{GS_PLAN_ONE_LINE}} | G's Plan in one line, used by george-gsplan | `BRAIN.md` | ## Why this matters George shouldn't have to remember skill names. He says what he wants in plain words and Claude picks the skill. This page exists so the agent knows the whole set, and so George can see what's possible and strike what he doesn't need. ## Steps 1. **Learn the catalog.** **Memory and running the system** | Skill | What it does | Try saying | Module | |---|---|---|---| | george-session-start | Pulls `main`, reads the brain and the newest handoffs, says what it picked up | "Start the session." | 07 | | george-handoff | Worklog line, handoff file, NOW update, push to `main` | "Wrap up." | 07 | | george-brain | Adds or updates a fact, person, project or decision with its source; never duplicates | "Remember that the Cuba trip moved to March." | 06 | | george-coach | Runs a big job: plan, a checkbox per step, proof for each, checkpoints | "Use george-coach to move my book pages to the new design." | 07 | | george-weekly-brief | Sunday: what shipped, what's due, what's stuck, any session without a handoff | "Weekly brief, please." | 24 | **Writing in his voice** | Skill | What it does | Try saying | Module | |---|---|---|---| | george-voice | Writes like George, from `voice/VOICE.md` and his gold posts | "Say this the way I would." | 12 | | george-slop-check | Flags AI tells, rewrites them in his voice, attaches a pass/fail report | "Slop check this." | 13 | | george-weekly-article | Thursday article: a hard Bible question answered up front, told the way he tells stories, verse as text | "Draft Thursday's article on why there are four Gospels." | 24 | | george-video-package | Tuesday video: script, title, description, chapters, thumbnail words, pinned comment | "Build Tuesday's video package on Jan Hus." | 24 | | george-repurpose | Turns an article or video into Substack, social captions and podcast notes | "Repurpose this week's article." | 28 | | george-sermon-to-article | A sermon or teaching transcript into an article draft and three shorts | "Turn Sunday's sermon into an article." | 24 | | george-interview-pitch | Pitches to radio and podcast hosts | "Pitch me to three Christian radio shows about The Relay." | 25 | | george-book-promo | Posts, emails and talking points for his books; never invents reviews or numbers | "Book promo for The Four Faces of Christ this month." | 25 | | george-email | Draft-only emails in his voice from the right identity; never sends | "Draft a thank-you to the host from yesterday." | 02 | **G's Plan and TOI** | Skill | What it does | Try saying | Module | |---|---|---|---| | george-gsplan | A template skill George's Claude fills with how G's Plan works ({{GS_PLAN_ONE_LINE}}) | "Run my G's Plan weekly job." | 25 | | george-missions-update | TOI prayer and partner update in English and Spanish | "Draft the TOI update from this week's trip notes." | 26 | | george-donor-thanks | Thank-you notes to TOI partners, warm and specific; reads names from the giving system at run time, never stores donor names or amounts in the repo | "Draft thank-yous for this month's new partners." | 26 | | george-trip-planner | Mission trip plan: dates, team, packing, schedule, prayer list, update cadence | "Plan the spring Cuba trip." | 26 | **Pages, design and the site** | Skill | What it does | Try saying | Module | |---|---|---|---| | george-premium-page | Builds or redesigns a page so it looks designed: a one-page design brief first, then a separate review | "Redesign the books page." | 14 | | george-design-check | Reviews any page or graphic for template look, weak type and stock layouts | "Design check the TOI homepage." | 14 | | george-site-update | Webflow drafts through the Webflow connector: clean rich text, no empty spacer paragraphs, published only after Approve | "Put Thursday's article in Webflow as a draft." | 28 | **Dashboard, automation and safety** | Skill | What it does | Try saying | Module | |---|---|---|---| | george-approval-queue | Posts a version to the dashboard, checks its status, acts only on Approved | "Send this to the dashboard for approval." | 16 | | george-dashboard-data | Pulls his numbers into the dashboard on a schedule | "Refresh this week's numbers." | 17 | | george-managed-agent-brief | Writes the brief for a Managed Agent from the AGENT-BRIEF template | "Write the brief for a TOI updates agent." | 22 | | george-secrets | How to use 1Password and cloud secrets; refuses any key typed into chat | "How should this task get the Webflow key?" | 09 | **Marketing command center** | Skill | What it does | Try saying | Module | |---|---|---|---| | george-command | Answers George's short commands ("status", "what's going out this week", "what did my reviewer flag") from the brain and the dashboard, and turns requests into dashboard items | "Status." | 33 | | george-meta-post | Facebook and Instagram post packages: caption per platform, assets, alt text, link, scheduled time; a person schedules them in Meta Business Suite | "Posts for Thursday's article, Friday morning." | 34 | | george-meta-ads | Complete Meta ad briefs and weekly results; never launches, edits or changes spend | "Write an ads brief to promote The Relay." | 35 | | george-email-campaign | Newsletters and sequences for {{EMAIL_PLATFORM}}, test send to George and {{REVIEWER}} first; never sends | "Write a three-email welcome sequence." | 36 | | george-ai-visibility | Monthly AI visibility check with his Rank Prompt access: non-brand visibility per theme, compared with last month, recommendations verified against the live page, fixes sent to the dashboard | "Run the monthly AI visibility check." | 37 | *Check:* you can name the skill for any plain-words request George makes. 2. **Strike what he doesn't want.** Remove {{SKILLS_TO_SKIP}} from this table in George's copy (`george-os/framework/11-SKILLS-CATALOG.md`). *Check:* the table in his copy matches what's installed. 3. **Have George try five.** He picks five sentences from the table and says them. *Check:* each one triggers the right skill on the first try. If one doesn't, sharpen that skill's description and log it in `FEEDBACK.md`. ## GEORGE does - Tries five sentences. - Strikes any skill he won't use. ## Done when - [ ] His copy of the catalog matches what's installed. - [ ] Five sentences triggered the right skills. ## Writes to - `george-os/framework/11-SKILLS-CATALOG.md` - `george-os/FEEDBACK.md` (any misfires) ## Next - [12 Voice Guide](./12-VOICE-GUIDE.md) # 12 · Voice Guide > A written guide to how George actually sounds, built only from his own writing, so every draft starts in his voice instead of a machine's. **Run it:** `Run module 12 from my framework. Build my voice guide from my own posts.` **Needs first:** 06, 07 **Time:** about 45 minutes · **GEORGE's part:** pick 3 or 4 more favorite posts, read the guide, edit it, take the blind test ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{GOLD_POSTS}} | 6 to 8 posts George wrote himself, before he used AI on them | the three named below, plus ask George once for his favorites | | {{SCRIPTURE_TRANSLATION}} | The Bible translation George quotes from | his recent posts, or ask George | | {{SIGNATURE_PHRASES}} | Phrases and turns that are his | read from the gold posts | | {{GS_PLAN_VOICE_NOTES}} | Any voice differences for G's Plan writing | his Claude memory or Projects, or ask George | | {{TOI_VOICE_NOTES}} | Any voice differences for The Overseas Initiative (donors, Spanish readers) | ask George; past mission-week posts | ## Why this matters Readers can tell when a post was written by a machine, and they stop trusting it. George's older posts sound like a person: they open on his son, a hurricane, a deer stand, and they are funny and specific. If AI drafting has pulled his newer posts toward a generic explainer cadence, step 1 measures it privately, so the fix rests on his own numbers. This guide keeps the substance and puts his own voice back in front, and every writing skill reads it first. ## Steps 1. **Measure the baseline (private).** Pick his 3 most recent articles and 3 older ones he wrote himself. For each, count em dashes and stock phrases from the banned list in module [13](./13-ANTI-SLOP.md), and note how the piece opens. Record the counts only in `voice/baseline.md` in george-os, which is private. Never put these numbers on any public page. *Check:* `voice/baseline.md` has six rows with counts, titles and dates. 2. **Collect the gold posts, verbatim.** Copy these three into `voice/gold/` exactly as published, with title, date and URL at the top: - *Pray Until You Pray* (April 2024), which opens on his son George Jr. home from a prayer retreat. - *The Hunting Woods* (November 2025), opening day, pine needles that "hiss" or "shush." - *Showing Up Post-Isaias*, a hurricane story from Pensacola with LSU Cajuns and a kettle of jambalaya. Then ask George for 3 to 5 more he is proud of and add them. Never add anything an AI helped write. *Check:* `voice/gold/` holds 6 to 8 files, each with its source URL, and George confirmed every extra pick. 3. **Read for patterns, not topics.** For each gold post, note how it opens, how it turns to scripture, where the humor lands, how long the sentences run, and how it ends. Write these notes in `voice/notes.md`. *Check:* every gold post has at least five observations, each quoting a line from the post. 4. **Write `voice/VOICE.md`** from the template at [./templates/VOICE.md](./templates/VOICE.md). Cover these sections: - **Openings:** a person, a place, a moment. Name them. - **Rhythm:** long, winding sentences broken by a short punch line. - **Humor:** where and how he uses it (self-aware, family, Southern specifics). - **Scripture:** quoted as text with book, chapter and verse in {{SCRIPTURE_TRANSLATION}}, woven into the story, never dropped in as a decoration. - **Signature phrases:** {{SIGNATURE_PHRASES}}, each with the post it came from. - **Endings:** how he lands a piece (a turn back to the opening scene, a plain charge to the reader). - **Per-brand notes:** {{GS_PLAN_VOICE_NOTES}}, {{TOI_VOICE_NOTES}}. For Spanish, note that TOI readers get a natural Spanish version, not a word-for-word translation. *Check:* every rule in VOICE.md cites a gold post line as its example. 5. **Link the banned list.** VOICE.md points to `voice/banned.md`, which module [13](./13-ANTI-SLOP.md) maintains. *Check:* the link resolves. 6. **George edits.** Show George VOICE.md on one screen. He strikes what is wrong and adds what is missing. *Check:* his edits are committed with a WORKLOG line that says "voice guide edited by George." 7. **Blind test, three rounds.** Pick a topic George has written about. Have the `george-voice` skill write one paragraph. Put it next to a real paragraph of his on the same subject, unlabeled, order randomized. Ask George which is his. Repeat three times with different topics. *Check:* the skill passes when George cannot reliably pick his own (he guesses right no more than 2 of 3). If he picks his own every time, ask him what gave it away, add that to VOICE.md, and run the test again. 8. **Wire it in.** Confirm `george-voice`, `george-weekly-article`, `george-video-package`, `george-repurpose`, `george-missions-update` and `george-email` all read `voice/VOICE.md` first. *Check:* each SKILL.md names the file in its first step. ## GEORGE does - Picks 3 to 5 more favorite posts he wrote himself. - Reads and edits VOICE.md. - Takes the blind test. ## Done when - [ ] `voice/gold/` has 6 to 8 verbatim posts with URLs, all chosen or confirmed by George - [ ] `voice/VOICE.md` exists, every rule backed by a quoted line - [ ] George has edited and approved it - [ ] Blind test passed (George right on 2 or fewer of 3) - [ ] Every writing skill reads VOICE.md first ## Writes to - `voice/baseline.md`, `voice/gold/*.md`, `voice/notes.md`, `voice/VOICE.md`, `WORKLOG.md`, a handoff ## Next - [13 · Anti-Slop](./13-ANTI-SLOP.md) - Re-run step 7 every quarter, or whenever George says a draft "doesn't sound like me." # 13 · Anti-Slop Standard > A hard gate that catches machine-sounding writing before anything reaches George's approval queue, plus the procedure to fix it in his voice. **Run it:** `Run module 13 from my framework. Set up the slop check and test it on my last three posts.` **Needs first:** 12 **Time:** about 30 minutes · **GEORGE's part:** add any tells that bug him to the banned list ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{TEST_POSTS}} | George's three most recent published articles | georgeshamblin.com | | {{CLEAN_POST}} | One pre-2026 post that should pass | `voice/gold/` (for example *Pray Until You Pray*) | | {{GEORGE_PET_PEEVES}} | Phrases George personally can't stand | ask George once | | {{SCRIPTURE_TRANSLATION}} | His Bible translation | `voice/VOICE.md` (module 12) | ## Why this matters A reader who smells AI stops reading and stops trusting. The tells are learnable and countable, so they can be caught by a check instead of by George's eyes. This gate runs on every draft from every skill. Nothing enters the approval queue without a pass, which means George spends his time on substance, not on scrubbing dashes. ## Steps 1. **Create `voice/banned.md`** with these tells, each with an example and the fix: - **Em dashes.** Zero allowed. Fix: a period, a comma, or parentheses. - **"Not X, but Y" frames.** ("Not as a bait and switch, but as a lure.") Fix: say the true thing straight. - **Throat-clearing openers:** "Here is…", "Here's the thing", "Let's unpack", "Let's dive in", "In today's world". Fix: start with the scene or the answer. - **Stock section headers** that sound like a listicle ("Two questions that break the standard reading"). Fix: a plain header or none. - **Neat triads** used for rhythm (three adjectives, three parallel clauses). Fix: keep the strongest one. - **Tidy moral-summary endings** ("Ultimately…", "The takeaway is…"). Fix: end on the image or a plain charge. - **Buzzwords:** journey, profound, powerful reminder, delve, unlock, seamless, robust, navigate (figurative), testament to. - **Stacked one-line paragraphs** for drama. Fix: merge into real paragraphs. - **Spacer paragraphs** in Webflow (empty `

` lines used for space). Fix: real spacing in the design, not empty lines. - **Scripture as an image.** Verses must be on the page as text with book, chapter and verse, so readers, screen readers and AI answer engines can all read them. - {{GEORGE_PET_PEEVES}} *Check:* every entry has a bad example and a fixed example. 2. **Keep what works.** Write at the top of banned.md: question-first titles with the plain answer in the first two sentences are correct for search and AI answer engines. Keep that format. The fix is the voice, not the format. *Check:* the note is present. 3. **Set the scoring rubric** in `voice/rubric.md`. Every draft gets scored: | Check | Pass rule | |---|---| | Hard tells (em dashes, scripture images, spacer paragraphs) | zero | | Soft tells (everything else in banned.md) | 2 or fewer per 1,000 words | | Voice match | opens on a person, place or moment, or on the plain answer for question posts; at least one concrete detail per section from George's life or the text | | Facts | every quote, date, number and verse reference checked or marked `[check]` | | Scripture | quoted as text in {{SCRIPTURE_TRANSLATION}} with reference | A draft passes only if every row passes. *Check:* rubric file exists and `george-slop-check` reads it. 4. **The rewrite procedure** (what `george-slop-check` does on a fail): list every hit with its line, rewrite only those sentences using VOICE.md, re-score, and attach the before and after report. Do not rewrite passing paragraphs. Do two passes at most; if it still fails, send it to the queue marked "needs George" with the report, rather than looping. *Check:* the skill's steps match this. 5. **Calibrate on real posts.** Run the check on {{TEST_POSTS}} and on {{CLEAN_POST}}, and compare with the private baseline in `voice/baseline.md` (module [12](./12-VOICE-GUIDE.md)). Record results only in george-os. {{CLEAN_POST}} should pass; any recent post the baseline flagged should fail for the same reasons. *Check:* results match the baseline. If the clean post fails, the rubric is too strict; loosen the soft-tell threshold and re-run. 6. **Wire the gate.** Every item posted to the dashboard carries `voice_check` (pass or fail) and the slop report. The dashboard refuses an item without them. *Check:* see module [16](./16-DASHBOARD-BUILD.md), test "item without voice_check is refused." ## GEORGE does - Adds the phrases that bug him to {{GEORGE_PET_PEEVES}}. - Can override a fail with a written reason on the dashboard. The reason is logged. ## Done when - [ ] `voice/banned.md` and `voice/rubric.md` exist with examples - [ ] Calibration: recent posts fail for the right reasons; the clean post passes - [ ] `george-slop-check` attaches a report to every draft - [ ] Dashboard refuses items without a voice check ## Writes to - `voice/banned.md`, `voice/rubric.md`, `WORKLOG.md`, a handoff ## Next - [14 · Design Standard](./14-DESIGN-STANDARD.md) - Add to banned.md any time George flags a new tell. The list grows; it never shrinks without his say. # 14 · Design Standard > A short design brief and a separate review pass so George's pages, graphics and dashboard look designed, not generated. **Run it:** `Run module 14 from my framework. Write my DESIGN.md and review my homepage against it.` **Needs first:** 06 **Time:** about 40 minutes · **GEORGE's part:** approve the DESIGN.md ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{BRAND_COLORS}} | The 2 or 3 colors George's site actually uses | read from georgeshamblin.com CSS | | {{BRAND_FONTS}} | Fonts in use on his site | same | | {{GS_PLAN_LOOK}} | Any separate look for G's Plan | his Claude memory or Projects, or ask George | | {{TOI_LOOK}} | The Overseas Initiative's look (logo, colors) | theoverseasinitiative.org, or ask George | | {{NEVER_DO}} | Looks George dislikes | ask George once | ## Why this matters Generated pages share a look: centered hero, gradient blob, three icon cards, a stock photo of hands on a laptop, everything the same weight. People recognize it in a second and assume nobody cared. Designed pages make choices: one strong idea per section, a real photo of George, type with contrast, generous space, and restraint. The rule that keeps quality up is simple: write the brief before building, and never let the pass that built a page also approve it. ## Steps 1. **Write `design/DESIGN.md`** before any page or graphic, one page long: - **Brand:** {{BRAND_COLORS}}, {{BRAND_FONTS}}, per-brand variations ({{GS_PLAN_LOOK}}, {{TOI_LOOK}}). - **Type scale:** 3 sizes plus a small label size; headings set tight, body at a comfortable reading width (about 65 to 75 characters). - **Spacing:** one base unit (for example 8px) and its multiples only. - **Color rules:** brand color only for actions and small accents, never large fills; status colors only on status. - **Imagery:** real photos of George, his family, Cuba and the people TOI serves (with permission), his book covers. No generic stock people. - **Never do:** {{NEVER_DO}}, plus gradient blobs, glassmorphism, three-icon-card rows, emoji as icons, centered everything, walls of identical cards. *Check:* every rule is specific enough that a reviewer can say yes or no. 2. **Run the generated-versus-designed review** on his current homepage with `george-design-check`. Score each section: | Sign of generated | Sign of designed | |---|---| | Everything centered, same weight | Clear hierarchy, one focal point per section | | Stock imagery | His own photos and covers | | Decorative gradients and blobs | Flat, intentional color | | Icon-card triplets | Content shaped to the content | | Vague headlines | Specific promise ("Tuesday videos and Thursday articles, both free") | | Spacer paragraphs and uneven gaps | One spacing system | *Check:* a report with a screenshot per section at phone and desktop width, saved to `design/reviews/`. 3. **Build with `george-premium-page`.** Any new page, landing page, book page or graphic starts from DESIGN.md, one section at a time. *Check:* the skill's first step reads DESIGN.md. 4. **Review as a separate pass.** After a build, start a fresh session (or a different skill run) that only reviews with `george-design-check` at full resolution, phone and desktop. The builder never approves its own work. *Check:* the review file names a different session than the build. 5. **Apply to the dashboard.** The dashboard shell at [../dashboard-proto/](../dashboard-proto/) already follows a calm, polished system. When George customizes it, change only `config.js` colors and names first, and keep its spacing and type scale. *Check:* the customized dashboard passes `george-design-check`. ## GEORGE does - Reads DESIGN.md and approves or edits it. - Names anything he never wants to see. ## Done when - [ ] `design/DESIGN.md` exists and George approved it - [ ] Homepage review saved with phone and desktop screenshots - [ ] Build and review always run as separate passes ## Writes to - `design/DESIGN.md`, `design/reviews/*.md`, `WORKLOG.md`, a handoff ## Next - [15 · Dashboard: What and Why](./15-DASHBOARD-WHAT-AND-WHY.md) # 15 · Dashboard: What and Why > One private web address where George and his helpers see everything in flight, approve work, and track his numbers, so nothing depends on George remembering it. **Run it:** `Run module 15 from my framework. Explain my dashboard plan back to me and confirm who it's for.` **Needs first:** 04, 05 **Time:** about 15 minutes · **GEORGE's part:** confirm the screens and the people ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{DASHBOARD_NAME}} | What George wants to call it | ask George (default: "G's Desk") | | {{BRANDS}} | The areas of his work to organize by | G's Plan, TOI, Author, CEL; confirm with George | | {{HELPERS}} | People who help him and should see it | ask George | | {{TOP_NUMBERS}} | The 5 to 8 numbers George actually cares about | ask George | | {{REVIEWER}} | The teammate who double checks everything going out | ask George | ## Why this matters Right now George is the dashboard: the plan lives in his head, approvals happen in text threads, and every helper asks him where things stand. That is why he is too hands-on and why things get relearned. A dashboard moves the state out of his head and into one place his agents write to and his team reads from. He opens one link, sees what needs him, taps Approve or Request changes, and goes back to his real work. ## Steps 1. **Explain the screens to George** in plain words, using the shell at [../dashboard-proto/](../dashboard-proto/) so he can click through it: - **Home:** what needs him today, what shipped this week, what is late. - **Approvals:** each item shows a preview, the slop-check report, and buttons for Approve, Request changes (with a comment) and Reject. An approval covers one exact version; any edit sends it back. - **Calendar:** the weekly rhythm from module [24](./24-WEEKLY-RHYTHM.md), with each slot's status. - **Brands:** one page per area in {{BRANDS}}: what is in flight, its numbers, its people. - **Going out:** everything scheduled for the next 7 days across Facebook, Instagram, Meta ads, email, Substack, the website and YouTube, in time order. This is where George's reviewer ({{REVIEWER}}, module [18](./18-TEAM-ACCESS.md)) double checks every package before it leaves. Ad spend still waits for George. - **Memory:** `NOW.md`, the newest handoffs and the work log, readable on a phone. This is the cure for relearning. - **Automations:** every scheduled task and Managed Agent, its last run, its result, and an off switch. - **Data:** {{TOP_NUMBERS}} over time, pulled in daily (module [17](./17-DASHBOARD-DATA-SOURCES.md)). - **Team:** who can see and who can approve, per brand (module [18](./18-TEAM-ACCESS.md)). *Check:* George has clicked through the shell and said which screens he wants first. 2. **Confirm the people.** List {{HELPERS}} with the brands each should see and whether they approve or only view. *Check:* the list is written to `people/` and to `projects/dashboard.md`. 3. **Confirm the numbers.** Write {{TOP_NUMBERS}} with where each comes from. Leave out any number with no source yet; don't invent one. *Check:* each number has a named source in module 17's list. 4. **Write the brief** to `projects/dashboard.md` using [./templates/PROJECT.md](./templates/PROJECT.md): goal, screens in order, people, numbers, and the build steps from module 16 as checkboxes. *Check:* the file exists and is pushed to `main`. ## GEORGE does - Clicks through the shell and picks the screens he wants first. - Names his helpers and what each can do. - Names the numbers he cares about. ## Done when - [ ] George has seen the shell - [ ] `projects/dashboard.md` lists screens, people, roles and numbers - [ ] Every number has a source ## Writes to - `projects/dashboard.md`, `people/*.md`, `WORKLOG.md`, a handoff ## Next - [16 · Dashboard Build](./16-DASHBOARD-BUILD.md) # 16 · Dashboard Build > Turn the blank dashboard shell into George's live, private dashboard: sign-in for his team, an approval queue his agents fill, and a log of everything that shipped. **Run it:** `Run module 16 from my framework. Build my dashboard from the shell, step by step, and run every test.` **Needs first:** 09, 15 **Time:** about 2 to 3 hours across two sessions · **GEORGE's part:** create a free Cloudflare account with {{ACCOUNT_EMAIL}} if he has none; name his people ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{DASHBOARD_NAME}} | Name on the dashboard | `projects/dashboard.md` | | {{PROJECT_SLUG}} | Cloudflare Pages project name, lowercase with hyphens | derive from the name (for example `gs-desk`) | | {{ACCENT_COLOR}} | His main brand color | `design/DESIGN.md` | | {{BRANDS}} | G's Plan, TOI, Author, CEL (confirmed list) | `projects/dashboard.md` | | {{PEOPLE_ROLES}} | Email, brand, viewer or approver | `people/` and module 18 | | {{TIMEZONE}} | Time zone for all schedules | America/Chicago unless George says otherwise | | {{REVIEWER}} | The teammate who double checks everything going out | module [18](./18-TEAM-ACCESS.md) | ## Why this matters A dashboard that anyone can open, or that lets an agent approve its own work, is worse than none. This build is deliberately strict in four places: only signed-in people George named can open it, only approvers can approve, an approval covers one exact version, and nothing publishes twice. Everything else stays small: one page, a few tables, three buttons. Small is what keeps it running when nobody is watching. ## Steps 1. **Start from the shell.** Copy [../dashboard-proto/](../dashboard-proto/) into a new folder `dashboard/` in a new private repo `{{PROJECT_SLUG}}` in George's personal GitHub account. The shell is static HTML, CSS and JavaScript: `config.js` holds names, colors and navigation; `data.json` holds sample data; each screen reads data through one function you will point at the API. Set `config.js`: name {{DASHBOARD_NAME}}, accent {{ACCENT_COLOR}}, brands {{BRANDS}}. *Check:* opening `index.html` locally shows his name, color and brands, still on sample data. 2. **Cloudflare account and Pages project.** GEORGE creates a free Cloudflare account (or signs in). Create a Pages project `{{PROJECT_SLUG}}` connected to the repo. Use the free `{{PROJECT_SLUG}}.pages.dev` address for now; a custom address can come later. *Check:* the shell loads at the production address. (It is public for a few minutes; do step 3 right away and put no real data in until then.) 3. **Lock it with Cloudflare Access.** In Cloudflare Zero Trust (free up to 50 users), create a **self-hosted application** that covers both the production hostname `{{PROJECT_SLUG}}.pages.dev` and the preview hostnames `*.{{PROJECT_SLUG}}.pages.dev`. The Pages "preview access" toggle alone does not protect production. Identity: Google sign-in, plus a one-time email code as backup. Session duration: 30 days. Two policies on the application: - **People policy (Allow):** only the emails in {{PEOPLE_ROLES}}. - **Agent policy (Service Auth):** only the one Access service token made for George's agents. Agents send it as the headers `CF-Access-Client-Id` and `CF-Access-Client-Secret`. This policy admits no people and no other tokens. *Check:* in a private browser window, the production address, a preview address and `/api/items` all show the Cloudflare sign-in, not the page. 4. **Create the database.** Make a D1 database and bind it to Pages Functions as `DB`. Tables: - `jobs`: id, name, brand, **level** (0 to 4, from module [23](./23-AUTONOMY-LADDER.md)), **paused** (true or false), updated_by, updated_at. Only an approver for that brand (or George as owner) can change `level` or `paused`; every change is logged in `events`. Agents can read jobs but never write them. - `items`: id, created_at, brand, kind (article package, video package, email, page, missions update, other), title, **job_id** (the job that made it), current_version, status (pending, changes, approved, ready_for_person, publishing, published, rejected), publish_url, published_at - `versions`: id, item_id, n, body_md, assets_json, **channel** (facebook, instagram, meta_ads, email, substack, website, youtube, other), **scheduled_for** (in {{TIMEZONE}}), destinations_json (exactly where each piece goes, including the account), for meta_ads: **budget**, **daily_cap**, **dates** (start, end), content_sha256, voice_check, slop_report, created_by, created_at. **The content hash covers the body, assets, channel, scheduled time, destinations, budget, daily cap and dates.** Versions are never edited. Any change to any of these makes a new version, which voids every review and approval on the old one. The server **rejects a meta_ads version without structured `budget`, `daily_cap` and `dates`.** - `decisions`: id, item_id, version_id, content_sha256, decision (approve, changes, reject), comment, decided_by (signed-in email), decided_at - `reviews`: id, item_id, version_id, content_sha256, reviewer (signed-in email), checklist_json (each check from module [18](./18-TEAM-ACCESS.md) with pass or fail), result (passed or failed), at - `people`: email, brand, role (viewer, reviewer or approver), owner flag (George only) - `delegations`: brand, channel (or all), person, power (final_approval or spend), decision_ref (the file in `decisions/`), created_by (George), created_at - `events`: append-only log of every change (created, new version, decision, claim, published, failed, "context lost" taps, automation runs) - `metrics`: date, source, brand, name, value (filled by module [17](./17-DASHBOARD-DATA-SOURCES.md)) *Check:* `wrangler d1 execute` lists every table above. 5. **Verify identity in every Function, fail closed.** Every Pages Function reads the `Cf-Access-Jwt-Assertion` header and verifies it against the Access team's public keys (issuer and audience must match). No valid token, no response. People are identified by the email in the token; agents by an Access **service token**. *Check:* a request with no token, or a forged one, gets 401 or 403. 6. **Build the endpoints.** | Endpoint | Who | What it does | |---|---|---| | `GET /api/items?status=&brand=` | person or agent | lists items the caller may see (people see only their brands) | | `POST /api/items` | agent | creates an item with version 1 for a `job_id`; **refuses it without `voice_check`, `slop_report` and a valid `job_id`**; any level the agent sends is ignored | | `GET /api/items/:id` | person or agent | returns the item with `job_id`, **`job_level` (derived from the job on the server)**, status, current version, decisions and receipts | | `POST /api/items/:id/versions` | agent | adds a new version; sets status back to pending | | `POST /api/items/:id/reviews` | **person with reviewer or approver role for that brand** | records the checklist and passed or failed **on the current version and its content hash**; service tokens are refused | | `POST /api/items/:id/decision` | **George, or a person holding a final_approval delegation for that brand and channel** | records approve, changes or reject **on the current version and its content hash**; service tokens are refused | | `POST /api/items/:id/claim` | agent | atomically moves approved to publishing for that exact version; **reads the level from the item's job and refuses anything below level 3, or a paused job**; a second claim fails | | `POST /api/items/:id/mark-published` | **person with reviewer or approver role for that brand** | for a `ready_for_person` item: records the live URL, moves it to `published`, and writes a receipt naming the person; agent tokens are refused | | `POST /api/items/:id/published` | agent only | records the live URL and the platform receipt; status becomes published | | `POST /api/events` | person or agent | logs a "context lost" tap or an automation run | | `GET /api/outgoing?days=7` | person | everything scheduled to go out in the next N days across all channels, only for that person's brands, sorted by `scheduled_for`; feeds the **Going out** screen | | `GET /api/automations` | person | lists every job with its level, paused flag and last runs | | `PATCH /api/automations/:id` | **approver for that brand or George as owner** | sets `paused: true` or `paused: false`; logged in `events`; agent tokens are refused | | `POST /api/automations/pause-all` | **George as owner** | pauses every job and every channel publisher at once; logged in `events` | | `GET /api/me` | person | the caller's email, roles per brand (viewer, reviewer, approver), delegations and owner flag; the shell uses it to switch on reviewer mode and hide buttons the caller can't use | | `POST /api/metrics` | agent | writes metric rows; **restricted to the brands that agent job is set for** (used by `george-dashboard-data`) | | `GET /api/metrics` | person | numbers for the Data screen, only for that person's brands | | `GET /api/jobs/:id/status` | agent (only its own job) | returns the job's level and `paused` flag; the stop rule calls this first | | `GET /api/rhythm` | person | this week's schedule, built from jobs and items, for that person's brands | | `GET /api/kpis` | person | headline numbers for the Home screen, from `metrics`, for that person's brands | | `GET /api/memory` | person | `NOW.md`, the newest handoffs, recent WORKLOG lines and decision titles, read from george-os on GitHub by the Function with a **read-only** fine-grained token kept as a Cloudflare secret | | `GET /api/activity` | person | recent `events` for that person's brands | | `GET /api/people` | person | people and their roles, limited to brands the caller can see | **Every endpoint the shell reads must exist before `demo: false`** (the shell's README lists them); a missing one shows an error screen. *Check:* with `demo: false`, every screen loads real data or a designed empty state, never an error. **Release rule, two people (server-side).** An item is released (level 2 moves to `ready_for_person`; level 3 fires the publish trigger) only when the **current version** has BOTH: - a **passed review** by a person with reviewer or approver role, and - an **approval** by George, or by a person holding a `final_approval` delegation for that brand and channel, and the reviewer and the approver are **two different people**. {{REVIEWER}} may give final approval only where George delegated it in a decision record; then George or another person does the review. The server checks this on every release; the shell only reflects it. **Ad spend rule.** Every `meta_ads` item needs **George's own approval**. A spend delegation counts only if a record in `decisions/` (mirrored in `delegations` with power `spend`) names that person for that brand. A reviewer's passed review on an ad covers the creative only. The claim must be a single conditional update that joins the item's job: set status to publishing where id matches, status is approved, the job's level is 3 or more, the job is not paused, current_version matches the approved and reviewed version, the two-person rule holds for that version, **and the version's `scheduled_for` is now or earlier** (nothing publishes before its time). The publish trigger and the hourly poll also read the level and paused flag from the job, never from the item or the agent. *Check:* each endpoint has a test in step 10. 7. **What Approve does depends on the job's level.** - **Level 2 and below** (read from the item's job): once the release rule holds, the item moves to `ready_for_person`. The item shows a publishing handoff: the ready text and assets, where each piece goes, and a "Mark published" button that calls `mark-published` with the live URL. **No trigger fires.** - **Level 3 and up:** once the release rule holds, the item waits as `approved` until its `scheduled_for` time. If that time has already come, the server calls the publish trigger with the item id right away; otherwise the hourly run picks it up when it is due (approving next Thursday's item today never publishes it today). **Build the trigger hook as a setting that starts empty and disabled:** `PUBLISH_TRIGGER_URL` and its token as Cloudflare secrets, plus an on/off flag. This module does not need any scheduled task to exist. Module [20](./20-SCHEDULED-TASKS.md) creates the publish task later, fills in its trigger URL and token, and turns the hook on. An **hourly poll as backup** (also set up in module 20) picks up any approved level 3+ item the trigger missed. All times in {{TIMEZONE}}. *Check:* approving a level 3 test item scheduled for tomorrow leaves it `approved` and the claim refuses it until then; with the hook off, approving a due level 3 test item leaves it `approved` and logs "trigger not configured"; approving a level 2 item lands at `ready_for_person` with the handoff shown. 8. **The off switch (kill switch).** The Automations screen shows every job from `GET /api/automations` with a pause toggle that calls `PATCH /api/automations/:id`. **Stop rule for every scheduled task and every Managed Agent run:** the first step calls `GET /api/jobs/:id/status`; if `paused` is true, it writes a short handoff ("paused, did not run") and exits. For Managed Agents on a schedule, pausing also calls that schedule's own pause action (module [21](./21-MANAGED-AGENTS-SETUP.md)), so no session starts at all. **Pause everything:** George has one button that calls `POST /api/automations/pause-all`. **It does not stop anything already scheduled or running outside the dashboard:** Meta ads that are live, posts already scheduled in Meta Business Suite, and emails already scheduled in the email platform. A person must pause or unschedule those where they live. Meta ads keep spending until a person pauses them in Meta Ads Manager; the dashboard then shows a "Paused in Ads Manager?" check per live ad, and the person confirms it with what Ads Manager shows (status and time). *Check:* pause a test job, trigger its next run, and confirm it exits with the handoff and does nothing else; pause-all pauses every job. 9. **Point the shell at the API.** Replace the shell's sample-data function with calls to the endpoints. Keep `data.json` as a demo mode switch in `config.js`. *Check:* the Approvals screen shows real queue items after sign-in. 10. **Run the test list** and save results to `projects/dashboard-tests.md`: - Anonymous requests to production, a preview address and `/api/items` are refused. - A viewer cannot review or approve. - An approval alone does not release an item; a review alone does not release it; both on the current version by two different people does. - The same person cannot both review and give final approval on one version. - {{REVIEWER}}'s approval counts as final only where a `final_approval` delegation exists for that brand and channel. - Changing the channel, scheduled time, destination, budget, daily cap or dates makes a new version and voids its reviews and approvals. - A meta_ads version without structured budget, daily cap and dates is rejected. - Pause-all pauses every job; the screen states that running Meta ads must be paused in Ads Manager and asks for confirmation. - `GET /api/me` returns the caller's roles per brand, and reviewer mode shows only review actions. - The agent service token (sent as `CF-Access-Client-Id` and `CF-Access-Client-Secret`) can create items and versions, write metrics for its brands, and post receipts. - The agent service token is refused on the decision endpoint. - The agent service token cannot write metrics for a brand it isn't set for. - An item without a valid `job_id` is refused; a level the agent sends is ignored; the claim endpoint refuses an item whose job is level 2. - Only an approver or George can change a job's level; the change shows in `events`; an agent token is refused. - A person with approver role can mark a level 2 item published; an agent token is refused on `mark-published`. - Pausing a job stops its next run: the run checks the job at start, writes a handoff and exits; claim refuses its items while paused. - A viewer or agent token cannot pause or unpause a job. - `GET /api/outgoing?days=7` returns only the caller's brands, across every channel, in time order. - An approval on a meta_ads item by anyone other than George does not count; with a spend delegation on file, the named person's approval counts. - When any API call fails, the screen shows an error message, never an empty list. - Approving a level 2 item lands at `ready_for_person` with no trigger call. - An item without a voice check is refused. - Editing an approved item (new version) sends it back to pending, and the old approval does not carry over. - Two claims on the same approved version: one succeeds, one fails. - A published item has a passed review and an approval on the same version and content hash, by two different people, before its claim and receipt. - An approver signs in on a phone, and on a second visit is not asked to sign in again. *Check:* every test passes; any failure blocks going live. 11. **Store the service token.** The agent service token goes in 1Password `Agents` for laptop sessions and as a cloud **network secret** for scheduled tasks (module [09](./09-PASSWORDS-AND-SECRETS.md)). Never in the repo, never in chat. *Check:* a dummy-value test proves it stays out of transcripts. ## GEORGE does - Creates or signs in to a free Cloudflare account. - Confirms the people and their roles. - Signs in once on his phone to try it. ## Done when - [ ] Production and preview addresses require sign-in - [ ] Every test in step 10 passes, results saved - [ ] Job levels and pause live in the server's `jobs` table, changed only by approvers or George - [ ] Two-person release rule and George-only ad spend enforced by the server - [ ] Pause-all works, and running Meta ads have a confirm-paused-in-Ads-Manager step - [ ] Approve on level 2 items ends at a ready-for-person handoff that a person marks published; the level 3+ trigger hook exists, starts disabled, and is activated in module 20; double publish is impossible - [ ] Service token stored only in 1Password and network secrets - [ ] George and one helper have signed in on a phone ## Writes to - new repo `{{PROJECT_SLUG}}`, `projects/dashboard.md`, `projects/dashboard-tests.md`, `decisions/` (record the stack choice), `WORKLOG.md`, a handoff ## Next - [17 · Dashboard Data Sources](./17-DASHBOARD-DATA-SOURCES.md) - [18 · Team Access](./18-TEAM-ACCESS.md) - If the dashboard ever becomes a chore to keep running, a shared board with the same columns (title, version, status, approver, URL) is the fallback. Record that in `decisions/`. # 17 · Dashboard Data Sources > Pull George's real numbers into the dashboard every day, so he and his team see how things are going without logging into seven sites. **Run it:** `Run module 17 from my framework. Connect my data sources one at a time and start the daily snapshot.` **Needs first:** 09, 16 **Time:** about 20 to 40 minutes per source · **GEORGE's part:** sign in and approve access for each source ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{TOP_NUMBERS}} | The numbers George chose in module 15 | `projects/dashboard.md` | | {{YOUTUBE_CHANNEL}} | His channel (@georgeshamblinauthor) | public channel | | {{GA4_PROPERTY}} | Google Analytics 4 property for his site, if any | ask George, or check the site's tags | | {{SEARCH_CONSOLE_PROPERTY}} | Search Console property for georgeshamblin.com, if any | ask George | | {{TOI_DONATION_PLATFORM}} | Where TOI takes gifts (and who may see totals) | ask George; his Claude may already know | | {{GS_PLAN_SOURCES}} | Where G's Plan's numbers live | his Claude memory or Projects, or ask George | | {{PODCAST_HOST}} | Where the podcast is hosted (Spotify or another host) | ask George | | {{EMAIL_LIST_SOURCE}} | Where his email list lives (Substack, Webflow forms, other) | ask George | ## Why this matters Numbers George has to go look up are numbers nobody looks at. A daily snapshot puts them in one table the dashboard reads, so trends are visible and his agents can reason from facts ("Thursday articles with a story opening got more reads") instead of guesses. Each source is connected once, with the right kind of sign-in, and then runs by itself. ## Steps 1. **List the sources** for {{TOP_NUMBERS}} in `projects/dashboard-data.md`, one row each: number, source, how to read it, how often, who may see it. Connect one source per session, most useful first. *Check:* every top number has a row; any with no source is marked "manual for now." 2. **Use the right access for each source.** Prefer a sign-in connector (OAuth), so no key exists. Where a key is unavoidable, it lives in 1Password `Agents` for laptop runs and as a cloud network secret for scheduled runs (module [09](./09-PASSWORDS-AND-SECRETS.md)). *Check:* no key appears in any file or transcript. 3. **Connect the sources:** | Source | What to pull | How | |---|---|---| | YouTube | views, watch time, subscribers, per-video views for the week | YouTube Data API for public counts; YouTube Analytics API (Google sign-in with his channel's account) for watch time | | Substack | subscribers, open rate, post views | no official API: George downloads the subscriber and post CSV exports weekly into a Drive folder the agent reads, plus the public RSS feed for new posts | | Webflow | published posts, form submissions (subscribe, contact) | Webflow connector or API with a site token | | Google Analytics 4 | sessions, top pages, sources, for {{GA4_PROPERTY}} | GA4 Data API with Google sign-in | | Search Console | clicks, impressions, top queries, for {{SEARCH_CONSOLE_PROPERTY}} | Search Console API with Google sign-in | | TOI giving | gift count and total this week and month, new donor count (aggregates only) | {{TOI_DONATION_PLATFORM}} report or API; never names, single gifts or history | | G's Plan | {{GS_PLAN_SOURCES}} | his Claude fills this row | | Podcast | plays, followers | {{PODCAST_HOST}} stats export | | Email list | list size, new this week | {{EMAIL_LIST_SOURCE}} | *Check:* each connected source returns today's numbers in a test run. 4. **Build the daily snapshot job.** One scheduled task (module [20](./20-SCHEDULED-TASKS.md)) running the `george-dashboard-data` skill reads each connected source and writes rows (date, source, brand, name, value) with `POST /api/metrics`, using the agent service token (module [16](./16-DASHBOARD-BUILD.md)). That token may only write metrics for the brands the job is set for. People read the numbers with `GET /api/metrics`. It is read-only against every source. It logs a run event, including any source that failed. *Check:* after two days, the Data screen shows two points per number, and a deliberately broken source shows as "failed" instead of silently missing. 5. **Keep donor data out of everything we store.** Donor names, individual gift amounts and giving history never go in george-os, in any git repo, in the dashboard database, or in a chat. The snapshot pulls **aggregates only** from {{TOI_DONATION_PLATFORM}}: gift count and total for the week and month, and new donor count. Those aggregates are visible only to the TOI people George names. Thank-you letters and anything needing a donor's name are drafted inside the donation platform or from its export on George's own computer, then the export is deleted. *Check:* a search of george-os and the dashboard database finds no donor names; a viewer for another brand can't see TOI totals. 6. **Write the weekly read.** The Sunday brief (module [24](./24-WEEKLY-RHYTHM.md)) adds three plain sentences on what moved and why, citing the numbers. No hype, no invented causes; if the reason is unknown, say so. *Check:* the brief quotes real values from `metrics`. ## GEORGE does - Signs in and approves access for Google (YouTube, Analytics, Search Console), Webflow, and his giving platform. - Drops the Substack exports into the shared folder weekly until something better exists. - Decides who may see giving numbers. ## Done when - [ ] Every top number has a source or is marked manual - [ ] Daily snapshot writes to `metrics`, with failures visible - [ ] Giving shows aggregates only, restricted to TOI people; no donor names anywhere in george-os, git or the dashboard - [ ] No keys in files or chats ## Writes to - `projects/dashboard-data.md`, dashboard `metrics` table, `WORKLOG.md`, a handoff ## Next - [18 · Team Access](./18-TEAM-ACCESS.md) # 18 · Team Access > Give each of George's helpers exactly the access they need: one private link, their own Google sign-in, and viewer, reviewer or approver rights per area of his work. **Run it:** `Run module 18 from my framework. Set up my team on the dashboard.` **Needs first:** 16 **Time:** about 20 minutes, then 2 minutes per new person · **GEORGE's part:** decide who sees and who approves what ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{HELPERS}} | Each helper's name and Google-capable email | ask George | | {{BRANDS}} | G's Plan, TOI, Author, CEL (as confirmed) | `projects/dashboard.md` | | {{GS_PLAN_TEAM}} | Who helps with G's Plan | his Claude memory or Projects, or ask George | | {{TOI_TEAM}} | Who helps with The Overseas Initiative (co-founders, volunteers) | ask George | | {{CEL_TEAM}} | Who helps with his CEL pastor work | ask George | | {{REVIEWER}} | The teammate who double checks everything going out | ask George | | {{REVIEWER_BRANDS}} | Which brands the reviewer approves for | ask George | | {{SPEND_DELEGATE}} | Anyone besides George who may approve ad spend (default: nobody) | ask George | | {{AUTHOR_APPROVERS}} | Who besides George may approve author posts | default: George only | | {{DASHBOARD_NAME}} | The dashboard's name | `projects/dashboard.md` | ## Why this matters "Share a login" is how passwords leak and how nobody knows who approved what. The model here is one private link plus each person's own Google sign-in. Cloudflare remembers them for 30 days, so they aren't nagged. Every approval is tied to a real email, and removing someone takes one minute. Roles per area mean a mission volunteer can approve a TOI prayer update without seeing, or approving, anything else. ## Steps 1. **Fill the roles table** in `people/team.md`: | Person | Email | Brand | Role | |---|---|---|---| | George | his Google email | all | approver (owner) | | ... | ... | G's Plan / TOI / Author / CEL | viewer, reviewer or approver | Use {{GS_PLAN_TEAM}}, {{TOI_TEAM}}, {{CEL_TEAM}}, {{AUTHOR_APPROVERS}}. One row per person per brand. *Check:* George reads the table and says yes. 2. **Load the table** into the dashboard `people` table and into the Cloudflare Access policy allow list (both must match). *Check:* the Team screen shows the same people as the Access policy. 3. **Send each person the link** with one short note George approves, for example: "Here's the link to {{DASHBOARD_NAME}}. Sign in with your Google account. It remembers you for a month. You'll see the {{BRAND}} items. Tap Approve when something's ready, or Request changes and say why." George or his agent sends it from George's own email after George says send. Never share a password. *Check:* each person signs in once; their sign-in appears in the events log. 4. **Test each role** with a test item: a viewer sees it but has no Approve button; an approver for one brand cannot approve another brand's item. *Check:* results logged in `projects/dashboard-tests.md`. 5. **Offboarding.** To remove someone: delete their rows in `people`, remove them from the Access policy, and revoke their active Access sessions in Zero Trust. Their past decisions stay in the log under their email. *Check:* a removed test user is refused on the next request. 6. **The reviewer pattern.** {{REVIEWER}} gets the **reviewer** role for {{REVIEWER_BRANDS}}. Nothing goes out on one person's say: every package needs a passed review and a final approval on the same version, by two different people (module [16](./16-DASHBOARD-BUILD.md)). Final approval is George's. {{REVIEWER}} gives final approval only for brands and channels George delegates in a decision record, and then George or another person does the review. She signs in with her own Google account (30-day session, never a shared password). Her day: - Open **Going out** (`GET /api/outgoing?days=7`): every package scheduled in the next 7 days across Facebook, Instagram, Meta ads, email, Substack, the website and YouTube. - Check each package against this list: facts and numbers, names spelled right, every link works, scripture references match the verse text, images present with alt text, scheduled time right, going out from the right account. - Mark the review passed, or failed with a comment saying exactly what to fix. Any change to text, time, channel, account or budget makes a new version she reviews again. - **Ads:** she reviews the creative and copy. Every Meta ads item needs George's own approval for spend (budget, daily cap, dates), unless he records {{SPEND_DELEGATE}} in `decisions/`. The dashboard enforces this. Write the checklist into `people/reviewer.md` so she and the agents use the same one. *Check:* she reviews a test week of items; a test item with only her review does not release; a test ad stays waiting for George's approval. 7. **Quarterly review.** The Sunday brief once a quarter lists everyone with access and their last sign-in, so George can remove anyone idle. *Check:* the reminder is on the calendar in module [24](./24-WEEKLY-RHYTHM.md). ## GEORGE does - Decides who gets what, including the reviewer and her brands. - Decides whether anyone besides him may approve ad spend. - Approves the invite note. - Removes people when they step away. ## Done when - [ ] `people/team.md` matches the dashboard and the Access policy - [ ] Every helper has signed in once - [ ] Role tests pass - [ ] Offboarding tested once - [ ] Reviewer set up with her checklist; ad spend still waits for George ## Writes to - `people/team.md`, `people/reviewer.md`, dashboard `people` table, Access policy, `WORKLOG.md`, a handoff ## Next - [19 · Automation Chooser](./19-AUTOMATION-CHOOSER.md) # 19 · Automation Chooser > Decide, job by job, whether it runs by hand, as a scheduled task on George's Pro plan, or as a Managed Agent on the Claude API. **Run it:** `Run module 19 from my framework. List my recurring jobs and pick the right engine for each.` **Needs first:** 04, 07, 16 **Time:** about 30 minutes · **GEORGE's part:** confirm the job list and the monthly API budget ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{RECURRING_JOBS}} | Every job George does more than once a month, across G's Plan, TOI, Author & Teaching, CEL | `NOW.md`, `projects/`, module 25 and 26 playbooks, ask George once | | {{API_MONTHLY_CAP}} | The most George will spend on the Claude API per month (Managed Agents) | ask George; suggested start: $20 | | {{PRO_HEADROOM}} | How much of his Pro usage is left after his normal chatting | watch Settings > Usage for one week | ## Why this matters George relearns things because work lives in chats that end. Automation fixes that only if each job runs in the right place with the brain loaded. He has three engines, and picking wrong costs either money or reliability. Pro is already paid for but has a five-hour session limit and a weekly limit shared with his normal Claude use. Managed Agents cost a little per run but don't eat his Pro limits and can run as many jobs as his budget allows. ## The three engines | | **By hand** (a skill he triggers) | **Scheduled task** (Claude Code, on his Pro plan) | **Managed Agent** (Claude API) | |---|---|---|---| | Where | claude.ai or the desktop Code tab | claude.ai/code/routines, `/schedule`, or the desktop Scheduled page | platform.claude.com Console plus a tiny setup script | | Pays with | his Pro plan | his Pro plan (stops at the plan limit unless extra usage credits are on) | prepaid API credits, separate from Pro | | Starts by | George asking | a schedule, an API call or a GitHub event | a scheduled deployment (cron), an API call, or a webhook-driven script | | Good for | judgment calls, sermons, anything new | a few lean weekly jobs on the brain repo | jobs that run often, run long, or must not compete with his Pro limits | | Memory | reads the brain via Projects or Code | reads and pushes the brain repo | mounts the brain repo (GitHub resource) and pushes back; optional memory store | | Rough cost | included | included | about $0.25 for a 10-minute writing run on Sonnet; more with heavy context or web search | ## Steps 1. **List the jobs.** Pull every recurring job from the brain and the playbooks into a table: job, brand, how often, how long it takes George now, inputs, output, who approves. *Check:* George confirms the list is complete. 2. **Score each job.** For each, answer: does it need George's judgment every time (stay **by hand**)? Does it run weekly or less and take under 20 minutes (**scheduled task**)? Does it run daily or more, take long, need web search, or would it crowd his Pro limits (**Managed Agent**)? *Check:* every job has one engine and a one-line reason. 3. **Set its autonomy level** from module 23. Nothing starts above level 2 (drafts into the dashboard queue). *Check:* every row has a level. 4. **Set the money line.** Write `{{API_MONTHLY_CAP}}` into `decisions/` as a decision, and the per-run budget each Managed Agent job gets (module 21). Add up the estimated monthly runs times cost. *Check:* the estimate is under the cap with room to spare. 5. **Order the build.** Start with one job per engine, the one with the most hours saved. Only add the next once the first has run clean for two weeks. *Check:* `projects/automation.md` has the ordered list with checkboxes. ## Default picks for George (edit freely) | Job | Engine | Level to start | |---|---|---| | Sunday weekly brief | scheduled task | 3 (auto, read-only) | | Tuesday video package draft | scheduled task | 2 | | Thursday article package draft | scheduled task | 2 | | Publish an approved article to the website | scheduled task (API trigger from the dashboard) | 3 | | Daily data snapshot into the dashboard | Managed Agent (scheduled deployment) | 3 (read-only) | | TOI donor thank-you drafts after each gift batch | Managed Agent | 2 | | TOI monthly update in English and Spanish | Managed Agent | 2 | | G's Plan recurring jobs | decide in module 25 | 2 | ## GEORGE does - Confirms the job list. - Sets `{{API_MONTHLY_CAP}}` and decides whether extra usage credits stay off on his Pro plan (recommended: off). ## Done when - [ ] Every recurring job has an engine, a level, and a reason - [ ] The API cap and per-run budgets are written down as decisions - [ ] `projects/automation.md` lists the build order ## Writes to - `projects/automation.md`, `decisions/NNNN-automation-engines.md`, `decisions/NNNN-api-cap.md` ## Next - 20 for scheduled tasks, 21 and 22 for Managed Agents # 20 · Scheduled Tasks (on George's Pro plan) > Set up the lean weekly jobs that run in the cloud on George's Pro plan, read the brain first, and land drafts in his dashboard. **Run it:** `Run module 20 from my framework. Set up the scheduled tasks we chose in module 19.` **Needs first:** 06, 07, 16, 19 **Time:** about 45 minutes · **GEORGE's part:** approve GitHub access once and say yes to the dry week ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{SCHEDULED_JOBS}} | The jobs module 19 put on "scheduled task" | `projects/automation.md` | | {{TIMEZONE}} | America/Chicago unless George says otherwise | `BRAIN.md` | | {{DASHBOARD_API_URL}} | The dashboard's API base | module 16 | | {{EXTRA_USAGE}} | On or off (default off) | `decisions/` | ## Why this matters Scheduled tasks are Claude Code sessions that start on a clock or a trigger and run in the cloud, even with George's laptop closed. They come with his Pro plan, so the only cost is usage. They're a research preview and Pro has a five-hour session limit and a weekly limit shared with his chats, so keep them few, short, and focused. Each one must start from the brain and end with a handoff, or it becomes another agent that forgets. ## Steps 1. **Connect the repo.** Open claude.ai/code/routines (or the desktop app's Scheduled page). Connect GitHub and install the Claude GitHub App on the `george-os` repo. *Check:* the repo shows in the task's repository list. 2. **Let memory land on `main`.** Scheduled tasks push to `claude/` branches by default. For `george-os` only, turn on unrestricted branch pushes in the task's repository settings, so handoffs reach `main` where the next run reads them. *Check:* a test task writes `handoffs/test.md` and it appears on `main`. 3. **Add the secrets the right way.** In the task's cloud environment, add the dashboard's agent token (and any key a job needs) as a **network secret**, not a plain environment variable; plain variables are readable by anyone using that environment. *Check:* the test task calls the dashboard API successfully and the token never appears in its transcript. 4. **Write each task's prompt from the right template below**: the drafting template for jobs that make drafts, the publisher template for the one task that publishes approved items. Keep each prompt short; the skills and the brain carry the detail. *Check:* each prompt names its skill, its output, and its stop rule. 4b. **Strip connectors.** A new task can inherit George's connectors. Remove every connector the job doesn't need (a drafting job usually needs none; the publisher needs only the publishing channel's). Connectors may be able to send, post or change things whatever we intend, so an unattended task gets only what its job requires. *Check:* each task's connector list matches its job. 5. **Set the schedule** in {{TIMEZONE}}. Suggested: Saturday 6:00 for the Tuesday video package, Wednesday 6:00 for the Thursday article package, Sunday 17:00 for the weekly brief. The publish task has **no clock** of its own: it starts from the dashboard's API trigger when a person approves a level 3 item, with an **hourly** scheduled run as backup (cloud tasks can't run more often than hourly). This is where the dashboard's trigger, built and left switched off in module 16, gets its URL and is turned on. *Check:* the schedule list matches `projects/automation.md`. 6. **Run a dry week.** Every publish step stops at "draft" until George says the week looked right. *Check:* two runs in a row each name what the previous one did, read from the handoff on `main`. 7. **Watch the limits.** After the dry week, look at Settings > Usage. If tasks crowd George's own chats, move the heaviest job to a Managed Agent (module 21). *Check:* the usage note is added to `NOW.md`. ## Drafting task prompt template ``` You are running the "{{JOB_NAME}}" job for George Shamblin. 1. Pull main. Read BRAIN.md, NOW.md, voice/VOICE.md and the 3 newest handoffs. 2. Use the {{SKILL_NAME}} skill to make {{OUTPUT}} for {{WEEK_OR_ITEM}}. 3. Run george-slop-check. Fix until it passes. 4. Post it to the dashboard as a new version with george-approval-queue. Do not publish anything. 5. Write a handoff, add a WORKLOG line, pull --rebase, push to main. Stop if anything needed is missing; write what is missing in the handoff instead of guessing. ``` ## Publisher task prompt template ``` You are the publisher for George Shamblin's dashboard. You publish only what a person approved. 1. Pull main. Read BRAIN.md, NOW.md and decisions/ (autonomy levels, boundaries). 2. Get the item id from the trigger (or, on the hourly backup run, list items with status approved, job_level 3 or higher, and scheduled_for now or earlier). 3. For each item: confirm job_level is 3 or higher, the review and approval are for the current version and content hash, and its scheduled_for time has arrived. If not, skip it and note why. 4. Claim the item once (POST /api/items/:id/claim). If the claim fails, someone else has it: skip. 5. Publish exactly the approved version to its listed destinations, nothing else. Never edit the text. 6. Record the live URLs and platform receipts (POST /api/items/:id/published). 7. Write a handoff and a WORKLOG line, pull --rebase, push to main. Stop on any error, leave the item claimed with an error note, and say what failed in the handoff. ``` Level 2 items are never touched by the publisher: approving them ends in a publishing handoff a person completes (module 23). ## GEORGE does - Approves the GitHub connection once. - Says yes (or "change X") after the dry week. ## Done when - [ ] Each chosen job is a scheduled task with the template prompt - [ ] Handoffs from scheduled runs land on `main` - [ ] Secrets are network secrets; none show in transcripts - [ ] One clean dry week, and George has said yes ## Writes to - `projects/automation.md` (task names, schedules, last result), `handoffs/`, `WORKLOG.md` ## Next - 21 if any job belongs on a Managed Agent; 29 to track it # 21 · Managed Agents Setup > Give George his own always-on agents on the Claude API, with a hard budget, his brain repo mounted, and keys he never has to type into a chat. **Run it:** `Run module 21 from my framework. Set up Managed Agents with my budget, and stop before anything costs money until I say go.` **Needs first:** 06, 09, 19 **Time:** about 60 minutes · **GEORGE's part:** create the Console account, add credits, create the API key, approve the budget ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{API_MONTHLY_CAP}} | Monthly API ceiling | `decisions/` (module 19) | | {{PER_RUN_BUDGET}} | Budget per scheduled run | suggested: $0.50 for writing jobs, $0.25 for data snapshots | | {{MODEL}} | Model for routine jobs | suggested: Claude Sonnet 5.5 (`claude-sonnet-5-5`); use Opus 5.5 only for hard writing | | {{GITHUB_TOKEN}} | A fine-grained GitHub token scoped to `george-os` only | George creates it; it goes straight into a vault | | {{AGENT_JOBS}} | The jobs module 19 put on "Managed Agent" | `projects/automation.md` | | {{TIMEZONE}} | America/Chicago unless George says otherwise | `BRAIN.md` | | {{ACCOUNT_EMAIL}} | The email for every account George creates | `BRAIN.md` (set in module 00) | ## Why this matters Managed Agents are Claude agents that Anthropic hosts and runs for George: each run gets a fresh cloud sandbox, his skills, his brain repo, and tools, then stops. They don't use his Pro limits. They are a separate product on the Claude API with its own bill, currently in beta. That bill is small when the jobs are lean: model tokens at API rates, plus $0.08 per hour while a session is actually running, plus $10 per 1,000 web searches. A 10-minute Sonnet writing run is roughly $0.25. A budget on every run and a monthly cap keep it boring. ## Steps 1. **Console account (GEORGE).** Go to platform.claude.com and create an account with {{ACCOUNT_EMAIL}}. This is separate from his Pro subscription; Pro does not pay for API use. *Check:* he can see the Console dashboard. 2. **Credits and guardrails (GEORGE).** In Settings > Billing, buy a small amount of prepaid credit (for example $20). Leave auto-reload **off** for the first month, so the account can never spend more than what's in it. *Check:* the balance shows; auto-reload is off. 3. **API key (GEORGE).** In Settings > API keys, create a key named `george-agents`. Save it straight into 1Password in the `Agents` vault. Never paste it into a chat. *Check:* the key is in 1Password and nowhere else. 4. **Local setup (agent, local Code session on his laptop).** Install the Anthropic Python SDK (`pip install anthropic`). Run every script under `op run` with an env file that holds `ANTHROPIC_API_KEY=op://Agents/george-agents/credential`, so the key reaches the script without being printed. *Check:* a script that lists his agents runs and prints no key. 5. **Vault for credentials.** Create a Managed Agents **vault** and store the GitHub token there (and any other service credentials a job needs). The agent never sees the values; they are swapped in when the session talks to that service. *Check:* the vault lists the credential names, not values. 6. **Upload his skills.** Upload each `george-*` skill the agents need as a custom skill (zip upload to the skills endpoint), then note each `skill_id` in `projects/automation.md`. *Check:* the skills list shows them. 7. **Create one environment** (cloud, limited networking, only the hosts the jobs need: his dashboard API, GitHub, any data source). *Check:* the environment id is saved in `projects/automation.md`. 8. **Smoke test with one throwaway agent** using the example below and a one-line job ("write today's date into a handoff"). Real agents are built in module 22. *Check:* the test session reads the brain repo, pushes one handoff to `main`, posts one test item to the dashboard, stays under its budget, and the Console shows the cost of that one run. 9. **Schedule only after module 22.** When a real agent from module 22 is approved by George, create a **scheduled deployment** with a cron line, the {{TIMEZONE}} time zone, and {{PER_RUN_BUDGET}} as the per-run budget. *Check:* the deployment shows the next run time; pause works. 10. **Know when runs finish.** In the Console's Webhooks page, add the dashboard's webhook URL with a signing secret, for `deployment_run.succeeded` and `deployment_run.failed`. The dashboard records them on the Automations screen. Webhooks are beta and are dropped after three failed attempts, so the daily brief also checks the Console for runs. *Check:* the test run appears on the dashboard's Automations screen. 11. **Write the decision.** Record the cap, per-run budgets, model choice and the kill switch (pause every deployment from the dashboard or the Console) in `decisions/`. *Check:* George reads and approves it. ## Smoke-test example (Python) **Before writing any code, fetch these pages and use their current field names**, because Managed Agents is in beta and fields change: platform.claude.com/docs/en/managed-agents/quickstart, /github, /vaults, /skills, /budgets and /scheduled-deployments. The example below shows the shape; the `# FROM DOCS` lines must be filled from those pages. **Hard rule:** never start a session without a budget. Set the budget (from /budgets) on the session or agent before the first `sessions.create`, and set allowed hosts on the environment to exactly GitHub plus the dashboard's hostname. First create `brief_system_prompt.md` from [templates/AGENT-BRIEF.md](./templates/AGENT-BRIEF.md) with the one-line test job. ```python # run as: op run --env-file=agents.env -- python first_agent.py from anthropic import Anthropic client = Anthropic() # key comes from the environment, never from this file agent = client.beta.agents.create( name="George weekly brief", model="claude-sonnet-5-5", system=open("brief_system_prompt.md").read(), # built from templates/AGENT-BRIEF.md tools=[{"type": "agent_toolset_20260401"}], # FROM DOCS (/skills): attach the uploaded george-* skills this job needs by skill_id ) env = client.beta.environments.create( name="george-env", config={"type": "cloud", "networking": {"type": "limited", # FROM DOCS: allowed hosts = github.com and the dashboard hostname only }}, ) session = client.beta.sessions.create( agent=agent.id, environment_id=env.id, title="Smoke test", # FROM DOCS (/github): resources = the george-os repo, token from the vault or from the op-run environment # FROM DOCS (/vaults): the vault holding the dashboard agent token # FROM DOCS (/budgets): a budget of {{PER_RUN_BUDGET}} or less, set here at session creation; do not run without it ) with client.beta.sessions.events.stream(session.id) as stream: client.beta.sessions.events.send(session.id, events=[{"type": "user.message", "content": [{"type": "text", "text": "Run this week's brief."}]}]) for event in stream: if event.type == "agent.message": for block in event.content: if block.type == "text": print(block.text, end="") if event.type == "session.status_idle": break ``` *Check before running:* no `# FROM DOCS` line is still a comment, the budget is set, and the script prints no secret. ## GEORGE does - Creates the Console account, adds a small prepaid balance, keeps auto-reload off at first. - Creates the API key and the GitHub token and puts both in 1Password. - Approves the budget decision. ## Done when - [ ] The smoke-test agent ran once with a budget, posted a test item, pushed a handoff, and cost what the estimate said (scheduling real agents happens in module 22) - [ ] Keys live only in 1Password and the vault - [ ] Per-run budgets and the monthly cap are written down and visible on the dashboard - [ ] George knows how to pause everything ## Writes to - `projects/automation.md` (agent ids, environment id, skill ids, deployments), `decisions/NNNN-managed-agents.md`, `agents/` (one brief per agent) ## Next - 22 for the recipes; 29 to track spend against the cap # 22 · Managed Agent Recipes > Ready-made agent briefs for George's recurring jobs. Fill the slots, create the agent with module 21, start at level 2. **Run it:** `Run module 22 from my framework. Build the {{RECIPE}} agent.` **Needs first:** 21, 23 **Time:** about 20 minutes per agent · **GEORGE's part:** approve each brief before it runs on a schedule ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{RECIPE}} | Which recipe below | George, or module 19's order | | {{GS_PLAN_JOBS}} | G's Plan recurring jobs | module 25 | | {{TOI_DONOR_SOURCE}} | Where TOI gifts are recorded (the donation platform, or a restricted folder George controls) | module 26 | | {{DATA_SOURCES}} | Which metrics to pull | module 17 | ## Why this matters An agent is only as good as its brief. Every recipe below uses the same spine from `templates/AGENT-BRIEF.md`: load the brain, do one job with one skill, check it, put it in the dashboard, write a handoff, stop. No recipe publishes or sends anything on its own at the start. Promotion to a higher autonomy level comes later, with evidence (module 23). ## The spine every recipe shares ``` ROLE: You do one job for George Shamblin: {{JOB}}. START: Clone george-os (mounted). Read BRAIN.md, NOW.md, voice/VOICE.md, the 3 newest handoffs, and {{PLAYBOOK}}. DO: Use {{SKILL}}. Output: {{OUTPUT}}. CHECK: Run george-slop-check on anything written. Never invent facts, quotes, numbers or scripture references; mark [check]. DELIVER: Post the result to the dashboard as a new version (george-approval-queue). Do not publish or send. END: Write handoffs/-{{JOB_SLUG}}.md, add a WORKLOG line, pull --rebase, push to main. STOP RULES: Stop and report in the handoff if an input is missing, a credential fails, or the run would exceed its budget. ``` ## Recipes | Recipe | Trigger | Skill(s) | Output | Start level | |---|---|---|---|---| | **Daily data snapshot** | daily 5:30 | george-dashboard-data | metrics rows posted to the dashboard; anomalies noted in the handoff | 3 (read-only) | | **Weekly brief** | Sunday 17:00 | george-weekly-brief | brief posted to the dashboard Home | 3 (read-only) | | **Video package** | Saturday 6:00 | george-video-package, george-repurpose | script, title, description, chapters, pinned comment, captions | 2 | | **Article package** | Wednesday 6:00 | george-weekly-article, george-repurpose | article, Substack post, captions, podcast notes | 2 | | **TOI donor thanks** | weekly, Monday 6:00 | george-donor-thanks | reads the week's gifts from the donation platform or George's restricted folder through a connector at run time; one draft note per gift in English or Spanish, posted to the dashboard. Donor names, amounts and giving history never go into george-os or any git repo; the handoff records only counts | 2 | | **TOI monthly update** | 1st of month 6:00 | george-missions-update | update in English and Spanish, photo-story suggestions, prayer list | 2 | | **Trip prep** | 30 days before each trip on the TOI calendar | george-trip-planner | checklist, packing list, team brief, daily plan | 2 | | **Interview pitches** | 1st and 15th | george-interview-pitch | 3 to 5 tailored pitches with sources | 2 | | **G's Plan jobs** | from module 25 | george-gsplan plus others | as defined in module 25 | 2 | ## Steps 1. **Pick the recipe** and copy the spine into `agents/{{JOB_SLUG}}.md`, filling every slot. *Check:* no `{{` remains. 2. **Name the inputs.** List exactly what the agent reads (files, data sources) and what credentials it needs from the vault. Private data (donors, contacts) is read from its own system at run time and never copied into the repo. *Check:* every credential is already in the vault (module 21), and no input path points at private data inside george-os. 3. **Estimate cost.** Typical context size, minutes, model, searches. Compare with the per-run budget. *Check:* the estimate fits the budget. 4. **GEORGE approves the brief.** *Check:* his approval is recorded in `decisions/` or on the dashboard. 5. **Create, test, schedule.** Build the agent the way module 21's smoke test did (skills, repo, vault, allowed hosts, budget), run it once by hand, then create its scheduled deployment (module 21 step 9) with the per-run budget. Every agent checks the dashboard's paused flag at start and exits if paused. *Check:* one manual run passes the "Done when" list below before the schedule is turned on. 6. **Review after two weeks.** Look at drafts approved without changes, edits needed, cost per run. Promote, keep, or demote using module 23. *Check:* the review is a line in `projects/automation.md`. ## GEORGE does - Approves each brief before it goes on a schedule. - Reviews the two-week results. ## Done when - [ ] Each built agent has a brief in `agents/`, a test run, and a schedule - [ ] Every run ends with a handoff on `main` and a dashboard item - [ ] Cost per run is shown on the dashboard's Automations screen ## Writes to - `agents/*.md`, `projects/automation.md`, `decisions/` ## Next - 23 to promote jobs that earn it; 29 for the scoreboard # 23 · Autonomy Ladder > A clear rule for which jobs run on their own and which wait for George, and how a job earns more freedom (or loses it) based on its record. **Run it:** `Run module 23 from my framework. Place every recurring job on the ladder and show me.` **Needs first:** 16, 19 **Time:** about 30 minutes, then a 5-minute review monthly · **GEORGE's part:** approve each job's level and every promotion ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{RECURRING_JOBS}} | Every job that repeats (weekly article, video package, social captions, TOI updates, G's Plan jobs, data snapshot, inbox drafts) | `calendar/`, module 24, and his Claude memory | | {{GS_PLAN_JOBS}} | G's Plan's recurring jobs | his Claude memory or Projects, or ask George | | {{TOI_JOBS}} | TOI's recurring jobs (prayer updates, donor thanks, trip logistics) | ask George | | {{KILL_SWITCH}} | How any job is stopped at once | the Automations screen off switch (module 16) | ## Why this matters George wants things to run without him steering, and he also can't afford a wrong post or a wrong email under his name. The ladder resolves that. Every job starts low and climbs only on evidence, one rung at a time. Any miss drops it back down. George always knows exactly what can happen without him, because it's written down. ## Steps 1. **Learn the five levels.** | Level | Name | What runs alone | What waits for George | |---|---|---|---| | 0 | Manual | nothing | everything; George does it | | 1 | Draft | the agent drafts into `drafts/` | George reads it, decides, and does the rest | | 2 | Draft and queue | the agent drafts, slop-checks and posts to the dashboard | Approve; then the item sits at "ready for a person to publish" with the ready text, and George or a helper publishes and marks it published. No publish trigger fires. | | 3 | Auto with approve | everything up to Approve, and everything after: Approve fires the publish trigger, the agent claims the approved version, publishes and posts receipts | only the Approve tap | | 4 | Fully auto | the whole job, with receipts in the log and a daily summary | nothing, but {{KILL_SWITCH}} stops it instantly | *Check:* the table is copied into `decisions/autonomy-ladder.md`. **How it's enforced:** each job's level lives on the dashboard server in the `jobs` table (module [16](./16-DASHBOARD-BUILD.md)), and only an approver or George can change it. Every item points to its job, and the server derives the level from the job; whatever level an agent sends is ignored. The dashboard, not the agent, decides what Approve does: level 2 stops at a ready-for-person handoff that a person marks published, and the claim endpoint refuses anything below level 3. Promoting a job means George (or an approver) changing its level on the Automations screen, then recording it in `CONTROL.md` and `decisions/`. 2. **Place every job.** List {{RECURRING_JOBS}}, {{GS_PLAN_JOBS}} and {{TOI_JOBS}} in `CONTROL.md` with a starting level. Sensible starts: - Data snapshot (read-only): level 3, promote to 4 after two clean weeks. - Weekly brief to George only: level 4 from day one (it only reads and reports). - Thursday article package, Tuesday video package: level 2, aiming at 3. - Social captions: level 2 (inside the article and video packages). - TOI prayer or donor updates: level 2. Anything that goes to donors never goes above 3. - Any email sent as George: level 1 or 2. Never 4. - Anything that spends money or signs George up for something: level 0. *Check:* every job has a level and George has approved the list. 3. **Promotion rule.** A job moves up one level only when, over its last 4 runs (or 4 weeks, whichever is longer): zero hard slop tells, zero fact corrections, zero publishing errors, George approved without edits at least 3 of 4 times, and every run left a receipt. The agent proposes the promotion with that evidence; George approves it. *Check:* each promotion has an entry in `decisions/` citing the four runs. 4. **Demotion rule.** Any miss drops the job one level at once: a wrong fact, a slop tell that reached the public, a double post, a missed receipt, or George saying "that wasn't right." Two misses in a month drop it to level 1. Log the miss in `WORKLOG.md` and the demotion in `decisions/`. *Check:* the rule is in `CONTROL.md`, and the Sunday brief lists any demotions. 5. **Never-above lines.** Write these in `decisions/autonomy-ladder.md`: money, sign-ups, legal or doctrinal statements on George's behalf, anything to donors' private details, and anything from his work systems stay at or below the level George sets, regardless of record. *Check:* listed. 6. **Show it on the dashboard.** The Automations screen shows each job's level, its last 4 runs, and the off switch. Pausing a job sets its `paused` flag on the server; every run checks the flag first and, if paused, writes a handoff and exits. *Check:* George pauses a test job on his phone and its next run does nothing. ## GEORGE does - Approves each job's starting level. - Approves or declines each promotion. - Uses the off switch whenever something feels wrong. No reason needed. ## Done when - [ ] Every recurring job has a level in `CONTROL.md` - [ ] Promotion and demotion rules written and in use - [ ] Off switch works for every job - [ ] Monthly ladder review in the calendar ## Writes to - `CONTROL.md`, `decisions/autonomy-ladder.md`, `WORKLOG.md`, a handoff ## Next - [24 · Weekly Rhythm](./24-WEEKLY-RHYTHM.md) # 24 · Weekly Rhythm > George's week on one page: what runs when, what lands on the dashboard, and the few things only he does. **Run it:** `Run module 24 from my framework. Set up my weekly rhythm and calendar.` **Needs first:** 16, 20, 23 **Time:** about 30 minutes, then a dry-run week · **GEORGE's part:** confirm the days and times; record the video ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{TIMEZONE}} | Time zone | America/Chicago unless George says otherwise | | {{VIDEO_DAY}} / {{ARTICLE_DAY}} | His public promise | Tuesday videos, Thursday articles (from his homepage) | | {{RECORDING_TIME}} | When George usually records | ask George | | {{GS_PLAN_CADENCE}} | What G's Plan needs each week or month, and when | his Claude memory or Projects, or ask George | | {{TOI_CADENCE}} | TOI's rhythm (prayer updates, donor thanks, trip prep before mission weeks) | ask George | | {{CEL_CADENCE}} | Anything weekly for his CEL pastor work | ask George | | {{SERIES}} | Current series (Torchbearers, Bible Questions Answered, others) | `calendar/` and his site | ## Why this matters George promised readers Tuesday videos and Thursday articles. Keeping that promise shouldn't cost him every evening. A fixed rhythm lets the agents prepare work days ahead, put it on the dashboard with time to review, and publish on schedule. George's week shrinks to the parts only he can do: record, approve, and write from the heart. ## Steps 1. **Write `calendar/RHYTHM.md`** from [./templates/CALENDAR.md](./templates/CALENDAR.md). Start from this default, all times in {{TIMEZONE}}, then adjust with George: | When | What runs | Lands as | |---|---|---| | Saturday 6am | Draft the {{VIDEO_DAY}} video package: script, title, description, chapters, pinned comment, plus its social captions; slop check | "Video package" on the dashboard | | Before {{RECORDING_TIME}} | George approves the package, then records and uploads with the ready text | George's part | | Wednesday 6am | Draft the {{ARTICLE_DAY}} article package: article, Substack post, social captions, podcast notes; slop check | "Article package" on the dashboard | | On Approve | Level 3+ jobs: the publish trigger fires; the task claims the approved version, publishes what's automatic (the website), stages paste items, logs receipts. An **hourly poll** is the backup. Level 2 jobs: no trigger; the item waits as "ready for a person to publish" with the ready text | item marked published | | Daily 5am | Data snapshot (module [17](./17-DASHBOARD-DATA-SOURCES.md)) | numbers on the Data screen | | Sunday 5pm | Weekly brief: what shipped, what's next, what's stuck, numbers that moved, missing handoffs, demotions | short brief to George's phone | | {{GS_PLAN_CADENCE}} | G's Plan jobs | his Claude fills these rows | | {{TOI_CADENCE}} | TOI jobs: prayer update, donor thanks, trip prep checklists | TOI items on the dashboard | | {{CEL_CADENCE}} | CEL pastor-work prep, if any | CEL items | | First Sunday monthly | Ladder review (module [23](./23-AUTONOMY-LADDER.md)) and voice check refresh | review item | | First Sunday quarterly | Team access review (module [18](./18-TEAM-ACCESS.md)) and blind voice test (module [12](./12-VOICE-GUIDE.md)) | review item | *Check:* George confirms every row and time. 2. **Fill the topic calendar.** In `calendar/`, list the next 8 weeks: video topic, article question, series ({{SERIES}}). The agent proposes from his series and reader questions; George edits. *Check:* 8 weeks filled and approved. 3. **Create the scheduled tasks** for each row, per module [20](./20-SCHEDULED-TASKS.md). Each starts with `george-session-start` and ends with `george-handoff`. Keep Pro usage in mind: one task per job, lean prompts, no duplicate runs. *Check:* every row has a task, and the Automations screen lists them. 4. **Dry-run week.** For one full week, every publish step stops at "draft." On Sunday, George looks back and says whether the week was right. *Check:* two successive runs each read the other's handoff from `main`, and George says go. 5. **Go live** row by row at the levels set in module 23. *Check:* the first live week ships on {{VIDEO_DAY}} and {{ARTICLE_DAY}} with receipts. ## GEORGE does - Confirms days and times. - Approves the video package, records the video, uploads it with the ready title and description. - Approves the article package and pastes the Substack post (until it's automatic). - Reads the Sunday brief. - Taps "context lost" on the dashboard whenever he had to re-explain something. ## Done when - [ ] `calendar/RHYTHM.md` approved by George - [ ] 8-week topic calendar filled - [ ] Every row has a scheduled task - [ ] Dry-run week passed - [ ] First live week shipped on time ## Writes to - `calendar/RHYTHM.md`, `calendar/*`, `CONTROL.md`, `WORKLOG.md`, a handoff ## Next - [25 · G's Plan Playbook](./25-GS-PLAN-PLAYBOOK.md) - [26 · TOI Playbook](./26-TOI-PLAYBOOK.md) # 25 · G's Plan Playbook > A written playbook for G's Plan, one of George's two main things, so no agent ever has to relearn it. **Run it:** `Run module 25 from my framework. Fill the G's Plan playbook from what you already know about it, then ask me only what's missing.` **Needs first:** 04, 05, 06, 07, 23 **Time:** about 45 minutes · **GEORGE's part:** answer one batch of questions, then read and correct the finished playbook ## Fill in first This module is a template. Trevor's team doesn't know what G's Plan is, and that's by design. You (George's Claude) likely do, from past chats, his Claude memory, his Projects, or his files. Fill every slot from those sources first. Ask George only about what's still blank, all in one message. | Slot | What it is | Where the agent gets it | |---|---|---| | {{GS_PLAN_WHAT_IT_IS}} | One plain sentence: what G's Plan is | his Claude memory, Projects, past chats, then ask George | | {{GS_PLAN_WHY}} | Why George does it, in his words | past chats, his writing, then ask George | | {{GS_PLAN_AUDIENCE}} | Who it serves (be specific: who, where, what they need) | brain repo, past chats, ask George | | {{GS_PLAN_OFFERS}} | What people get from it (programs, content, products, meetings, resources) | his site, past chats, ask George | | {{GS_PLAN_RECURRING_JOBS}} | Every job that repeats: daily, weekly, monthly, yearly | past chats, his calendar (read-only connector), ask George | | {{GS_PLAN_CADENCE}} | When each job happens and its deadline | calendar, ask George | | {{GS_PLAN_PEOPLE}} | Who helps, their role, what they may see or approve | ask George; then a file per person in people/ | | {{GS_PLAN_CHANNELS}} | Where it shows up (site, email list, social, events, print) | his site, ask George | | {{GS_PLAN_TOOLS}} | Apps and accounts it uses (forms, payments, email list, docs) | inventory from module 04 | | {{GS_PLAN_METRICS}} | The 3 to 5 numbers that tell George it's working | ask George | | {{GS_PLAN_VOICE_NOTES}} | Anything about tone that differs from his main voice | voice/VOICE.md, ask George | | {{GS_PLAN_NEVER}} | Things that must never happen (topics, promises, people, sends) | ask George | | {{GS_PLAN_OPEN_QUESTIONS}} | What nobody knows yet | collected while filling the rest | ## Why this matters George keeps re-explaining G's Plan to every new chat, which eats his time and invites mistakes. Once the playbook is written down, every agent starts already knowing it. It also turns his recurring work into named jobs, and named jobs can be assigned to skills and automations instead of to George. And it gives George one place to correct what an agent got wrong, so the fix sticks. ## Steps 1. **Gather what you already know.** Search his Claude memory, every Project he has, his `george-os` files, and his site for anything about G's Plan. Write each fact with its source in a scratch list. *Check:* every fact in the list names a source. 2. **Fill the slots.** Put each fact in its slot above. Mark anything you inferred rather than read as `[check]`. *Check:* no slot holds a guess without `[check]`. 3. **Ask George once.** Send one message listing every empty or `[check]` slot as a numbered question. Keep it short enough to answer from his phone. *Check:* exactly one question message was sent, and George answered it. 4. **Write the playbook.** Create `projects/gs-plan/PLAYBOOK.md` using the layout below. *Check:* the file exists on `main` and every heading has content or an explicit "unknown, see open questions". 5. **Map every recurring job.** For each item in {{GS_PLAN_RECURRING_JOBS}}, add one row to the job map (below). Pick the skill (use `george-gsplan` when no specific skill fits), the autonomy level from [module 23](./23-AUTONOMY-LADDER.md), and the automation type from [module 19](./19-AUTOMATION-CHOOSER.md). *Check:* no recurring job is missing from the map, and no row is above level 2 until it has run cleanly for two weeks. 6. **Fill the gsplan skill.** Open `skills/george-gsplan/SKILL.md` in George's kit (it's a template). Replace its slots with the facts from the playbook, so the skill knows G's Plan without reading the whole brain. *Check:* `Use george-gsplan to tell me what G's Plan is and what's due this week.` answers correctly in a fresh session. 7. **Add the people.** One file per helper in `people/` from [the PERSON template](./templates/PERSON.md), including their dashboard role (viewer or approver for the G's Plan brand). *Check:* each person in {{GS_PLAN_PEOPLE}} has a file. 8. **Put the cadence on the calendar.** Add each recurring job to `calendar/` with its day and deadline. *Check:* the Sunday weekly brief from [module 24](./24-WEEKLY-RHYTHM.md) lists this week's G's Plan jobs. 9. **Add G's Plan to the dashboard.** Add "G's Plan" as a brand in the dashboard's brand list ([module 16](./16-DASHBOARD-BUILD.md)) and its metrics to [module 17](./17-DASHBOARD-DATA-SOURCES.md). *Check:* a test item tagged G's Plan appears under that brand. 10. **Show George.** Send him the playbook and the job map. Make his corrections. *Check:* George said it's right, and that's logged in `decisions/`. ### Playbook layout (`projects/gs-plan/PLAYBOOK.md`) ``` # G's Plan What it is: {{GS_PLAN_WHAT_IT_IS}} Why: {{GS_PLAN_WHY}} Who it serves: {{GS_PLAN_AUDIENCE}} What they get: {{GS_PLAN_OFFERS}} People: {{GS_PLAN_PEOPLE}} Channels: {{GS_PLAN_CHANNELS}} Tools: {{GS_PLAN_TOOLS}} Scoreboard: {{GS_PLAN_METRICS}} Voice notes: {{GS_PLAN_VOICE_NOTES}} Never: {{GS_PLAN_NEVER}} Open questions: {{GS_PLAN_OPEN_QUESTIONS}} Last confirmed by George: ``` ### Job map (in the same file) | Job | When | Skill | Autonomy level (23) | Automation (19) | Who approves | Output lands in | |---|---|---|---|---|---|---| | {{JOB}} | {{DAY/TIME, America/Chicago}} | george-… | 0 to 4 | manual, scheduled task, or Managed Agent | {{APPROVER}} | dashboard queue, Drive, draft email | ## GEORGE does - Answers the one batch of questions. - Reads the finished playbook and job map and corrects anything wrong. - Chooses who helps and whether each helper can view or approve. ## Done when - [ ] `projects/gs-plan/PLAYBOOK.md` exists on `main`, with no unsourced guesses - [ ] Every recurring job has a row in the job map - [ ] `george-gsplan` answers "what is G's Plan and what's due this week" correctly in a fresh session - [ ] Helpers have `people/` files and dashboard roles - [ ] G's Plan shows as a brand on the dashboard - [ ] George confirmed it, recorded in `decisions/` ## Writes to - `projects/gs-plan/PLAYBOOK.md` - `skills/george-gsplan/SKILL.md` (his copy) - `people/*.md`, `calendar/`, `decisions/`, `NOW.md`, `WORKLOG.md` ## Next - [26 · TOI Playbook](./26-TOI-PLAYBOOK.md) - Then [20 · Scheduled Tasks](./20-SCHEDULED-TASKS.md) for the first G's Plan job that earned level 2 # 26 · The Overseas Initiative Playbook > A written playbook for The Overseas Initiative, so updates, donor care and trips run on rails in English and Spanish. **Run it:** `Run module 26 from my framework. Build the TOI playbook from what you know, ask me what's missing, and map every recurring job.` **Needs first:** 04, 05, 06, 07, 12, 23 **Time:** about 60 minutes · **GEORGE's part:** answer one batch of questions, confirm the privacy rule, name who helps ## Fill in first What's public: The Overseas Initiative (theoverseasinitiative.org) does missions in Cuba and Latin America. George is a co-founder. It equips the next generation of men and women for ministry. Its work and audience are bilingual, English and Spanish. Everything else is a slot. Fill each one from George's Claude memory, his Projects and his files before asking him. | Slot | What it is | Where the agent gets it | |---|---|---| | {{TOI_MISSION_LINE}} | One sentence on what TOI does, in George's words | theoverseasinitiative.org, past chats | | {{TOI_COFOUNDERS}} | Co-founders and leaders, their roles, and who approves what | ask George | | {{TOI_DONOR_PLATFORM}} | Where gifts come in (giving platform, bank, checks), who can see donor records, and the restricted folder George controls for any exports | ask George | | {{TOI_DONOR_SEGMENTS}} | Groups that get different messages (monthly givers, first gifts, churches, trip alumni) | ask George | | {{TOI_NEWSLETTER}} | How updates go out (email tool, list names, frequency) | inventory from module 04, ask George | | {{TOI_TRIP_CALENDAR}} | Upcoming trips: dates, places (general region only), team size, leaders | ask George; calendar connector (read-only) | | {{TOI_PRAYER_LIST}} | Where prayer requests live and who can read them | ask George | | {{TOI_PARTNERS}} | Partner churches and ministries in the field, and what may be said publicly about each | ask George | | {{TOI_SPANISH_STANDARD}} | Who checks Spanish before it goes out, and the regional variety to use | ask George | | {{TOI_PHOTO_RULES}} | Consent rules for photos and stories (see the privacy rule below) | ask George to confirm | | {{TOI_METRICS}} | The 3 to 5 numbers that matter (monthly givers, update open rate, trip sign-ups, funds raised for a project) | ask George | | {{TOI_NEVER}} | Things that must never be said, shown or promised | ask George | ## Why this matters TOI work repeats on a steady beat: thank donors, send the monthly update, prepare trips, share prayer needs, and do it all in two languages. Each of those is easy to delegate once it's written down and painful to re-explain every time. The people in the field also need protecting: a careless photo or name can put someone at risk. A playbook makes the safe way the default way. ## The privacy rule (applies to every TOI output) - No names, faces or identifiable locations of people in Cuba, or anywhere sharing faith carries risk, unless that person gave explicit consent for that specific use and George confirmed it. - Use first initials or roles ("a pastor in central Cuba"), general regions only, and photos where faces are turned away or blurred, unless consent is on file. - Record consent in `projects/toi/CONSENT.md`: who, what use, date, who confirmed. No entry means no consent. - When unsure, leave it out and flag it `[check]` in the dashboard item. - Donor names and amounts never appear in public content. Thank-you notes go to the donor only. ## The donor data rule - Donor names, amounts and giving history **never go in george-os or any git repo**, and never into a dashboard item's stored text beyond the one draft note addressed to that donor. - They stay in {{TOI_DONOR_PLATFORM}} or in a restricted folder George controls (for example a private Drive folder). - Agents read them through a connector at run time, use them for that run only, and keep just a pointer ("gifts live in ") and permitted aggregates (count of new gifts this month, number of monthly givers) in the brain. - If no connector can reach the data, George or a named helper runs the thank-you job from inside that folder or platform; the agent doesn't copy the list into the repo. ## Steps 1. **Gather what you already know.** Read his Claude memory, Projects, `george-os`, and the TOI site. List each fact with its source. *Check:* every fact names a source. 2. **Fill the slots and ask once.** Fill what you can, mark inferences `[check]`, then send George one numbered list of questions for the rest. *Check:* one question message, answered. 3. **Confirm the privacy rule.** Show George the privacy rule above and ask him to approve or tighten it. Save the final version in `projects/toi/PRIVACY.md` and log the decision. *Check:* `decisions/` has an entry dated today for the TOI privacy rule. 4. **Write the playbook.** Create `projects/toi/PLAYBOOK.md` with: mission line, people and roles, where donor data lives (a pointer only, no donor names or amounts), newsletter, trips, prayer, partners, Spanish standard, scoreboard, never-list, open questions. *Check:* the file is on `main` and every section has content or "unknown, see open questions". 5. **Map the recurring jobs.** Fill the job map below. Use the skills named, the autonomy levels from [module 23](./23-AUTONOMY-LADDER.md), and the automation types from [module 19](./19-AUTOMATION-CHOOSER.md). Start every TOI job at level 1 or 2. *Check:* each job below has a row, and none is above level 2. 6. **Set up Spanish.** Every outward TOI piece is drafted in English and Spanish in the same dashboard item. The Spanish is a natural rewrite, not a word-for-word translation. A named person from {{TOI_SPANISH_STANDARD}} approves the Spanish. *Check:* a test item shows both versions and the Spanish approver is set. 7. **Add people and roles.** One `people/` file per co-founder or helper, with their dashboard role for the TOI brand. *Check:* each person in {{TOI_COFOUNDERS}} has a file and a role. 8. **Put the cadence on the calendar.** Monthly update date, thank-you turnaround, trip prep milestones (8 weeks, 4 weeks, 1 week, return). *Check:* the Sunday brief lists this week's TOI jobs. 9. **Add TOI to the dashboard.** TOI as a brand, with its scoreboard numbers in [module 17](./17-DASHBOARD-DATA-SOURCES.md). *Check:* a test TOI item appears under the TOI brand, visible only to TOI roles. 10. **Show George.** Send the playbook and job map. Make his corrections. *Check:* George confirmed it, logged in `decisions/`. ### Job map (in `projects/toi/PLAYBOOK.md`) | Job | When | Skill | Starting level (23) | Automation (19) | Approver | Notes | |---|---|---|---|---|---|---| | Donor thank-you notes | within 48 hours of a gift | george-donor-thanks | 1 (draft for approval) | scheduled task reads new gifts through a connector at run time, per the donor data rule | George or a named co-founder | personal, short, never a form letter; amount mentioned only if George wants it; nothing about the donor saved in george-os | | Monthly update (email and site) | {{DAY}} each month | george-missions-update | 1 | scheduled task drafts on day minus 5 | George, plus the Spanish approver | one story, one need, one prayer; English and Spanish | | Prayer update | weekly or as needed | george-missions-update | 1 | manual or scheduled | George | privacy rule applies | | Trip planning | from 8 weeks out | george-trip-planner | 2 (prepares checklists and timelines without approval; anything sent needs approval) | scheduled task at each milestone | trip leader | packing lists, forms, schedule, team briefing | | Packing and team lists | 4 weeks and 1 week out | george-trip-planner | 2 | scheduled | trip leader | nothing about people in the field | | Spanish versions | with every outward piece | george-missions-update | 1 | inside the same item | Spanish approver | natural Spanish, checked by a person | | Photo stories after a trip | within 2 weeks of return | george-missions-update | 1 | manual start, George supplies photos | George | consent file checked first; faces and places per the privacy rule | | Partner and church updates | quarterly | george-missions-update | 1 | scheduled | George | only what {{TOI_PARTNERS}} allows | ## GEORGE does - Answers the one batch of questions. - Approves or tightens the privacy rule. - Names the co-founders, helpers and Spanish approver, and their roles. - Supplies trip photos and confirms consent. ## Done when - [ ] `projects/toi/PLAYBOOK.md`, `projects/toi/PRIVACY.md` and `projects/toi/CONSENT.md` exist on `main` - [ ] A search of george-os finds no donor names, amounts or giving history - [ ] The privacy rule is approved by George and logged - [ ] Every job in the job map has a skill, a level and an approver - [ ] A test item shows English and Spanish side by side, with the Spanish approver set - [ ] TOI shows as a brand on the dashboard, visible only to TOI roles - [ ] George confirmed the playbook ## Writes to - `projects/toi/PLAYBOOK.md`, `projects/toi/PRIVACY.md`, `projects/toi/CONSENT.md` - `people/*.md`, `calendar/`, `decisions/`, `NOW.md`, `WORKLOG.md` ## Next - [27 · Other Work Boundaries](./27-OTHER-WORK-BOUNDARIES.md) - Then [20 · Scheduled Tasks](./20-SCHEDULED-TASKS.md) for the monthly update draft # 27 · Other Work Boundaries > Clear lines between George's personal and ministry system and his other jobs, so nothing leaks, crosses or gets sent from the wrong place. **Run it:** `Run module 27 from my framework. Write my boundaries file and check my setup against it.` **Needs first:** 02, 04, 06 **Time:** about 20 minutes · **GEORGE's part:** confirm the list of roles and which email address belongs to each ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{ROLES}} | Every role George holds (author and teacher, G's Plan, TOI, pastor at The Center for Executive Leadership, his agency and sales jobs, any others) | profile from module 05, ask George | | {{IDENTITY_PER_ROLE}} | The one email address and sign-in each role uses | ask George | | {{WORK_SYSTEMS}} | Where his agency and sales work lives (their own drives, CRM, chat, agents) | ask George; record names only in his private brain, never on any public page | | {{CEL_BOUNDARIES}} | What CEL work may live in his system (his own teaching and writing) and what stays with CEL (their records, their members, their accounts) | ask George | ## Why this matters George wears several hats, and each has its own inbox, team and data. When those blur, an email goes out from the wrong address, or one organization's private information ends up in another's files. His agency and sales jobs already have their own systems and agents; his personal setup must not reach into them, and they must not reach into his. Writing the lines down once means every agent follows them without being told. ## The rules 1. **Personal and ministry only.** `george-os` and his `george-*` skills cover his author and teaching work, G's Plan, TOI, and his own pastoral writing. That's the scope. 2. **Work systems stay separate.** His agency and sales work stays in those companies' own systems and with their own agents. Don't copy their client names, files, numbers or conversations into `george-os`. Don't connect his personal agents to their agents, inboxes, drives or CRMs. 3. **One identity per mailbox.** Each role has one email address. An agent drafts only from the address for the role it's working on. It never sends, and never drafts from a work address while doing personal or ministry work. 4. **CEL lines.** George's own sermons, teaching and writing are his and can live in `george-os`. CEL's member information, donor records, internal documents and accounts stay with CEL. 5. **Personal GitHub only.** `george-os` and his kit live in his personal GitHub account. If he uses another account for work, it stays for work repos. Never mix them. 6. **When unsure, stop.** If a task touches a work system or another organization's data, the agent stops and asks George which side it belongs on. ## Steps 1. **Write the boundaries file.** Create `decisions/0004-boundaries.md` with the rules above, filled with {{ROLES}}, {{IDENTITY_PER_ROLE}} and {{CEL_BOUNDARIES}}. Names of work systems go only in this private file. *Check:* the file is on `main` and lists every role with its one identity. 2. **Audit connectors.** List every connector and sign-in on his Claude account (Settings > Connectors) and in Claude Code. Mark each as personal, ministry or work. *Check:* a table in `decisions/0004-boundaries.md` shows each connector and its side. 3. **Fix crossings.** For any work connector inside a personal Project or a personal scheduled task, propose removing it and wait for George's yes. *Check:* after his yes, no personal Project or task has a work connector. 4. **Check Projects.** Each claude.ai Project serves one side only. Rename or split any that mix. *Check:* the list of Projects shows one side each. 5. **Add a guard to the skills.** Confirm `george-email` and `george-session-start` read `decisions/0004-boundaries.md`. *Check:* asking `Use george-email to draft a note to a work client from my personal address` gets a refusal and a question. 6. **Scrub the brain.** Search `george-os` for work client names, work files and work numbers. Propose moving anything found out of the repo. *Check:* the search finds nothing, or George approved each item that stays. ## GEORGE does - Confirms the list of roles and the one email address for each. - Says yes or no to removing any crossed connector. - Decides edge cases ("is this mine or CEL's?"). ## Done when - [ ] `decisions/0004-boundaries.md` exists with roles, identities and the connector table - [ ] No personal Project or scheduled task has a work connector - [ ] `george-email` refuses to draft from the wrong identity - [ ] The brain repo holds no work client data ## Writes to - `decisions/0004-boundaries.md` - `WORKLOG.md`, a handoff ## Next - [28 · Publishing Channels](./28-PUBLISHING-CHANNELS.md) # 28 · Publishing Channels > One page that says, for every place George publishes, what goes out automatically, what's handed to him ready to paste, and how to move a channel up later. **Run it:** `Run module 28 from my framework. Set up each publishing channel and tell me which ones are automatic.` **Needs first:** 09, 12, 13, 16 **Time:** about 45 minutes · **GEORGE's part:** sign in to Webflow once to connect it; record and upload videos ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{WEBFLOW_SITE}} | His Webflow site and the CMS collection for posts | Webflow connector after sign-in | | {{WEBFLOW_PUBLISH_RULE}} | Publish the item only, or the whole site, after Approve | ask George (default: the item only) | | {{SUBSTACK}} | His Substack (georgeshamblin.substack.com) and how he formats posts | his past posts | | {{YOUTUBE}} | His channel (@georgeshamblinauthor), series names, standard description footer | his channel page, past videos | | {{FACEBOOK_PAGE}} / {{INSTAGRAM}} | His author Page and Instagram account | his site's links | | {{PODCAST}} | His podcast host and episode notes format | his podcast page | | {{TOI_CHANNELS}} | TOI's email tool and site | module 26 | | {{GS_PLAN_CHANNELS}} | Where G's Plan publishes | module 25 | | {{POST_TIMES}} | When each channel goes out (America/Chicago) | ask George; default Tue video, Thu article | | {{REVIEWER}} | The team member who checks items before they go out | module 18 | | {{EMAIL_PLATFORM}} | Where emails go out | module 36 | ## Why this matters George shouldn't be the one moving every piece through every app. Some channels can publish on their own once he taps Approve, for jobs that have earned autonomy level 3. Others have no safe way to automate yet, so the next best thing is a package where every word is ready and he spends two minutes pasting. Being honest about which is which avoids broken automations and surprise posts. ## Channel table | Channel | Status at setup | What the package contains | How it goes out | |---|---|---|---| | Website (Webflow), this module | **Automatic** after Approve, only for jobs at autonomy level 3 or higher ([module 23](./23-AUTONOMY-LADDER.md)); at level 2 the approval ends in a publishing handoff with ready text | title, slug, body with clean rich text (no empty spacer paragraphs), summary, SEO title and description, featured image, alt text, scripture as text with reference, category | publish task claims the approved version, creates the CMS item, publishes it, writes the live URL back as a receipt | | Substack, see [module 36](./36-EMAIL-MARKETING.md) | **Paste** (no official publishing API) | the full post, formatted for Substack, subject line, preview line, link back to the site | George or a helper pastes it and hits Publish (about 2 minutes); the agent records the URL when told | | YouTube | **Paste** (George records) | title, description with chapters, tags, pinned comment, thumbnail words, end-screen note | George records and uploads, then pastes the ready text | | Facebook, see [module 34](./34-META-SOCIAL.md) | **Paste** (level 2) until module 34 step 8 is done | caption, images, alt text, link, scheduled time | {{REVIEWER}} checks, George approves, a person schedules in the Meta Business Suite Planner | | Instagram, see [module 34](./34-META-SOCIAL.md) | **Paste** (level 2) until module 34 step 8 is done | caption, first comment, alt text, image or carousel plan, scheduled time | {{REVIEWER}} checks, George approves, a person schedules in the Meta Business Suite Planner | | Podcast | **Paste** | episode title, show notes, links | paste in the podcast host | | Email ({{EMAIL_PLATFORM}}), see [module 36](./36-EMAIL-MARKETING.md) | **Person sends** (level 2); level 3 only through the platform's API | subject, preview, body (English and Spanish for TOI), list, send time | test send to George and {{REVIEWER}}, George approves, a person sends | | Meta ads, see [module 35](./35-META-ADS.md) | **Always a person** (ads stay level 2) | campaign brief: objective, audience, budget, dates, placements, three creative versions, landing page, tracking | {{REVIEWER}} reviews creative, George approves the spend, a person launches in Ads Manager | Every package passes `george-slop-check` and sits in the dashboard as one item until a person approves that exact version. ## Steps 1. **Connect Webflow.** Add the Webflow connector (mcp.webflow.com) and have George sign in once. Use OAuth, no API key. *Check:* the agent can list the posts collection without George pasting anything. 2. **Do a draft round trip.** Create a test CMS item as a draft, read it back, then delete it. *Check:* the draft appeared and was removed; nothing was published. 3. **Set the publish rule.** Record {{WEBFLOW_PUBLISH_RULE}} in `decisions/`. Default: publish the single item, never the whole site. *Check:* the decision file exists. 4. **Write the package templates.** For each paste channel, save a template in `projects/channels/.md` with the exact fields listed above. *Check:* one file per channel. 5. **Wire the dashboard.** Each item's `destinations_json` lists every channel the package goes to, so the approval covers exactly those. *Check:* a test item shows its destinations, and editing a destination resets approval. 6. **Add receipts.** After each publish or paste, the live URL is written back to the item as a receipt. For paste channels, the agent asks George or the helper for the URL in the weekly brief if it's missing. *Check:* a test item shows a receipt URL. 7. **Respect the level.** For each job, read its autonomy level. Level 3 or higher: the publish task publishes Webflow after Approve. Level 2: the approval ends in a publishing handoff (ready text and fields in the item) and a person publishes. *Check:* a level-2 test item produces a handoff and publishes nothing. ## Moving a channel from paste to automatic Do one channel at a time, using `george-coach`: 1. Find an official connector or API that can draft without publishing. 2. Store any needed key per [module 9](./09-PASSWORDS-AND-SECRETS.md) (connector first; otherwise `op run` or a cloud network secret). 3. Run four weeks of draft-only round trips with receipts. 4. George approves the switch in `decisions/`. 5. Update the channel table above and the autonomy level in [module 23](./23-AUTONOMY-LADDER.md). ## GEORGE does - Signs in to Webflow once. - Records and uploads videos. - Pastes paste-channel packages, or names a helper who does. - Approves any channel's move to automatic. ## Done when - [ ] Webflow connected through sign-in, with a clean draft round trip - [ ] A package template exists for every paste channel - [ ] Dashboard items list their destinations, and approval covers exactly those - [ ] Receipts are recorded for every publish - [ ] The channel table here matches reality ## Writes to - `projects/channels/*.md` - `decisions/` (publish rule, any channel promotion) - `WORKLOG.md`, a handoff ## Next - [33 · Command Center](./33-COMMAND-CENTER.md), [34 · Meta Social](./34-META-SOCIAL.md), [35 · Meta Ads](./35-META-ADS.md), [36 · Email Marketing](./36-EMAIL-MARKETING.md) - [29 · Control and Scoreboard](./29-CONTROL-AND-SCOREBOARD.md) # 29 · Control and Scoreboard > A short set of rules that keep the system honest, and one weekly scoreboard that shows George whether it's working. **Run it:** `Run module 29 from my framework. Set up CONTROL.md and the weekly scoreboard.` **Needs first:** 07, 16, 17, 20 **Time:** about 30 minutes · **GEORGE's part:** set the Managed Agents monthly cap and his target numbers ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{MA_MONTHLY_CAP}} | Most George will spend on Managed Agents in a month, in dollars | ask George (module 21 recorded it) | | {{EXTRA_USAGE}} | Whether extra usage credits are on for his Pro plan | module 08 | | {{CADENCE}} | What must ship and when (default: Tue video, Thu article, plus G's Plan and TOI jobs) | modules 24, 25, 26 | | {{APPROVAL_TARGET_HOURS}} | How fast items should get a decision (default 24 hours) | ask George | | {{SCOREBOARD_DAY}} | When the scoreboard goes out (default Sunday 5pm America/Chicago) | module 24 | ## Why this matters Automations fail quietly. A task stops firing, a skill drifts back into AI-sounding prose, a session ends without a handoff and the next one starts cold. Counting a few things every week catches those early. The scoreboard also proves to George that he's less hands-on than before, or shows exactly where he isn't. ## Control rows (copy into `CONTROL.md`) | ID | What's watched | Rule | Allowed misses | Who reviews | |---|---|---|---|---| | C-1 | Session start and end | every session reads the brain first and pushes a handoff to `main` | 0 a week | Sunday brief | | C-2 | Voice | nothing enters the dashboard queue without a `george-slop-check` pass | George may override with a reason, logged | monthly voice review | | C-3 | Cadence | every scheduled item is in the queue 24 hours before its publish time | 0 late items | Sunday brief | | C-4 | Publish and send | nothing publishes or sends without an approval on that exact version | 0 | weekly, queue log against receipts | | C-5 | Secrets | keys only through connectors, `op run`, or cloud network secrets; a key seen in chat is rotated and logged | 0 | monthly | | C-6 | Spend | Managed Agents spend stays under {{MA_MONTHLY_CAP}}; extra usage stays as George set it | alert at 75% of cap | weekly | | C-7 | Privacy (TOI) | no names, faces or places of people in the field without a consent entry | 0 | every TOI item | ## Weekly scoreboard (goes in the Sunday brief and on the dashboard Home) | Number | How it's counted | Target | |---|---|---| | Sessions with a handoff | handoff files on `main` divided by sessions logged in `WORKLOG.md` | 100% | | Context-lost taps | taps on the dashboard's "context lost" button this week | 0, trending down | | Slop-check pass rate on first draft | first-draft passes divided by drafts | rising; 90% by week 4 | | On-time cadence | items in the queue 24 hours early divided by items due | 100% | | Approval turnaround | median hours from item created to decision | under {{APPROVAL_TARGET_HOURS}} | | Published with receipt | items with a live URL divided by items published | 100% | | Managed Agents spend | Console usage this month against {{MA_MONTHLY_CAP}} | under cap | | Pro limit hits | times a session or task stopped at the plan limit | 0 to 1 | | George's touches | approvals, comments and pastes he did this week | falling toward the target in module 24 | ## Steps 1. **Write CONTROL.md.** Copy the control rows into `CONTROL.md` from [the CONTROL template](./templates/CONTROL.md), filled with the slots. *Check:* the file is on `main` with all seven rows. 2. **Make each number countable.** For each scoreboard number, write where the count comes from (file, dashboard table, Console page) in `CONTROL.md`. *Check:* no number says "estimate". 3. **Add the scoreboard to the brief.** Update `george-weekly-brief` to include the scoreboard table with this week and last week side by side. *Check:* a test brief shows every number. 4. **Add it to the dashboard Home.** Show the scoreboard as cards ([module 17](./17-DASHBOARD-DATA-SOURCES.md)). *Check:* the Home screen shows this week's numbers. 5. **Set alerts.** Any control row breached adds a red line at the top of the Sunday brief and a dashboard item tagged "control". Spend at 75% of cap triggers an item the same day. *Check:* a simulated breach produces the item. 6. **Monthly review.** On the first Sunday of each month, the brief adds a short section: which rules held, which slipped, one change to try. *Check:* the calendar has the monthly review. ## GEORGE does - Sets {{MA_MONTHLY_CAP}} and {{APPROVAL_TARGET_HOURS}}. - Taps "context lost" whenever he has to re-explain something. That's the most important number on the board. - Reads the Sunday brief. ## Done when - [ ] `CONTROL.md` on `main` has all seven rows, with the source for every number - [ ] The Sunday brief shows the scoreboard with last week beside it - [ ] The dashboard Home shows the scoreboard - [ ] A simulated breach produces an alert item ## Writes to - `CONTROL.md` - `skills/george-weekly-brief/SKILL.md` (his copy) - `WORKLOG.md`, a handoff ## Next - [30 · Troubleshooting](./30-TROUBLESHOOTING.md) # 30 · Troubleshooting > What to do when something in the system goes wrong, written so the agent can fix most of it without George. **Run it:** `Run module 30 from my framework. Here's what went wrong: .` **Needs first:** nothing (use it any time) **Time:** 5 to 20 minutes per problem · **GEORGE's part:** only where a fix needs his sign-in or his yes ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{SYMPTOM}} | What George or the dashboard noticed | George's message or the alert item | | {{WHEN}} | When it started | WORKLOG.md, task run history | | {{LAST_GOOD}} | The last time it worked | WORKLOG.md, receipts | ## Why this matters Every fix that gets written down is a problem George never has to solve twice. Most failures here have a known cause and a two-minute fix. Writing the fix into `WORKLOG.md` and, when it's new, into this file's local copy, is how the system learns. ## Steps 1. **Find the matching problem below.** *Check:* you can name which row it is, or say "new problem". 2. **Run the fix.** *Check:* the "Proof it's fixed" line passes. 3. **Log it.** Add a line to `WORKLOG.md`: date, symptom, cause, fix. *Check:* the line is on `main`. 4. **If it's new, add it.** Add a row to `projects/troubleshooting.md` in `george-os` so the next agent knows it. *Check:* the row exists. ### Problems and fixes **The agent forgot what we were doing.** - Likely cause: the session didn't read the brain at start, or the last session didn't push its handoff. - Fix: run `george-session-start`. If the newest handoff is missing, check `WORKLOG.md` and the job's `projects/.md` checkboxes to rebuild where things stopped, then write the missing handoff. - Proof it's fixed: the agent names the last thing done and the next step without George explaining. George taps "context lost" so it's counted. **A claude.ai Project answers from old information.** - Likely cause: Project GitHub sync is manual and read-only. - Fix: in the Project, open project knowledge and click **Sync now**. Remember Projects can't save to the brain; anything decided there ends with a handoff note for Claude Code to file. - Proof it's fixed: the Project quotes today's `NOW.md`. **A push went to a `claude/` branch instead of `main`.** - Likely cause: cloud scheduled tasks push to `claude/` branches unless unrestricted branch pushes are on for that repo. - Fix: turn on unrestricted branch pushes for `george-os` in that task's repository settings. Merge the stray branch into `main` (pull with rebase first), then delete the stray branch. - Proof it's fixed: the next run's handoff appears on `main`, and the following run reads it. **Hit the Pro usage limit.** - Likely cause: too many or too long sessions and tasks in the same window. - Fix: check whether extra usage is on (Settings > Usage) and leave it as George chose. Shorten task prompts, have tasks read only the files they need, move heavy weekly work to off-peak times, and stagger tasks. If limits keep hitting, list the options for George: trim automations, move a job to Managed Agents under its cap, or change plans. - Proof it's fixed: no limit hits in the next week's scoreboard. **A scheduled task didn't fire.** - Likely cause: the task was paused, hit the plan limit, its trigger token changed, or it's a desktop task and the computer was asleep. - Fix: open claude.ai/code/routines (or the desktop Scheduled page) and check the task's run history and status. Cloud tasks keep running with the laptop closed; desktop tasks don't. Re-run it with "Run now". If it's the publish task, confirm the dashboard's hourly poll (the backup) picked up the approved item. - Proof it's fixed: a successful run in history and a handoff on `main`. **The dashboard keeps asking people to sign in, or loops.** - Likely cause: the Access application doesn't cover the hostname they're using, the person's email isn't in the policy, or the session length is set short. - Fix: in Cloudflare Zero Trust, confirm the Access application covers both the production hostname and the preview hostnames, the person's email is in the policy (and in the dashboard's `people` table), and the session length is 30 days. Have them clear just that site's cookies and sign in again. - Proof it's fixed: they sign in once and their second visit goes straight in. **A skill didn't trigger.** - Likely cause: it isn't uploaded or switched on (claude.ai), code execution is off, it isn't installed (Claude Code), or the request didn't match its description. - Fix: in claude.ai check Customize > Skills (on) and Settings > Capabilities (code execution on). In Claude Code check `~/.claude/skills/george-/SKILL.md` exists. Try the skill's example sentence, or name it directly: "Use george-voice to…". If it still misses, improve the skill's description line in his copy. - Proof it's fixed: the example sentence triggers it in a fresh session. **Managed Agents cost jumped.** - Likely cause: a session left running, a loop that keeps starting sessions, heavy web search, or a bigger model than needed. - Fix: in the Console, look at usage by day and stop any running sessions. Pause whatever starts sessions (the Worker cron or scheduled task). Check the recipe for a missing stop condition, a missing time limit, or a search loop. Switch long drafting work to a smaller model where the output passes the slop check. Keep the monthly cap in place. - Proof it's fixed: daily spend is back under the cap's pace, and the scoreboard spend line is green. **A key or password showed up in a chat.** - Treat it as leaked. Don't keep using it. - Fix: rotate it right away in the service it belongs to (make a new one, revoke the old one). Store the new one in 1Password or as a cloud network secret, never in chat. Add a line to `WORKLOG.md` with what leaked (name only, never the value), when, and when it was rotated. Check the module 9 dummy-value test still passes. - Proof it's fixed: the old key is revoked, the new one works through `op run` or a network secret, and it appears nowhere in the transcript. **An approved item didn't publish.** - Likely cause: the publish claim failed (the item was edited after approval, so it reset to pending), the Webflow connector sign-in expired, or the trigger didn't fire. - Fix: open the item. If it says pending, someone edited it; get a fresh approval. If it says approved, run the publish task manually. If Webflow refused, have George sign in to the connector again. - Proof it's fixed: the item shows published with a receipt URL. ## GEORGE does - Signs in again where a fix needs it (Webflow, Cloudflare, Console). - Says yes to anything that changes cost or turns off an automation. ## Done when - [ ] The problem's proof line passes - [ ] A WORKLOG line records symptom, cause and fix - [ ] New problems are added to `projects/troubleshooting.md` ## Writes to - `WORKLOG.md`, `projects/troubleshooting.md`, a handoff ## Next - Back to whatever module was running, or [31 · Iteration Loop](./31-ITERATION-LOOP.md) to send the lesson to Trevor # 31 · Iteration Loop > How George and Trevor improve this framework together, round after round, without anyone's changes getting overwritten. **Run it:** `Run module 31 from my framework. Collect this round's feedback and get it ready to send Trevor.` **Needs first:** 06, 10 **Time:** about 15 minutes a round · **GEORGE's part:** add notes as things come up; decide which updates to accept ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{KIT_VERSION}} | The framework version George's copy is on (for example v1.0) | the kit's CHANGELOG.md and `upstream/VERSION` | | {{ROUND}} | Which feedback round this is | `FEEDBACK.md` | | {{SEND_TO_TREVOR}} | How George shares a round with Trevor (a shared doc, an email he sends himself, or a text) | ask George | ## Why this matters This framework is a first draft. George and Trevor will improve it many times. That only works if George's own changes are never wiped out by an update, every round's lessons are written down, and both of them always know which version they're talking about. ## How it works - **Versions.** The kit has a version number (v1.0, v1.1, v2.0) and a public CHANGELOG. George's copy records the version it came from in `upstream/VERSION`. - **George's copy is his.** Once a module, template or skill is in his repo, he can change it freely. An update never overwrites it. - **Updates arrive as proposals.** When Trevor publishes a new version, George's agent downloads it into `upstream//` and writes `upstream//PROPOSAL.md`: what changed, which of George's files it touches, and a suggested merge for each. George decides file by file. The skill installer works the same way: it skips any skill George edited and puts the new one in `upstream/`. - **Feedback goes in one file.** `FEEDBACK.md` in `george-os` (from [the FEEDBACK template](./templates/FEEDBACK.md)) collects notes as they happen: what was confusing, what broke, what George wishes it did, and what worked well. - **A round is a send.** When George is ready, the agent turns the open feedback into a short round summary for Trevor. Nothing private goes in it: no donor names, no field names, no work system details. ## Steps 1. **Set the version.** Write {{KIT_VERSION}} to `upstream/VERSION`. *Check:* the file exists on `main`. 2. **Start FEEDBACK.md.** Create it from the template if missing. *Check:* the file is on `main` with an empty "Open" section. 3. **Log as you go.** Whenever George says something like "this was annoying" or "I wish it…", or a module needed a workaround, add a line under Open with the date, the module number, and what happened. *Check:* the lines name a module. 4. **Prepare a round.** When George asks, group the open lines by module, rank them (broken, confusing, wish, worked well), and write `feedback/round-{{ROUND}}.md`: under one page, with George's words where possible, and with private details removed. *Check:* the file is on `main` and contains no names of people in the field, donors, or work clients. 5. **Send it George's way.** Hand the summary to George to send by {{SEND_TO_TREVOR}}. The agent never sends it. *Check:* George confirms he sent it; move those lines to "Sent in round {{ROUND}}". 6. **Take in an update.** When a new version is out, download it into `upstream//`, compare it to George's files, and write `PROPOSAL.md`. Change nothing yet. *Check:* the proposal lists every changed file with keep, take, or merge. 7. **Apply what George picks.** Apply only the files George approved, then commit with the version in the message. Update `upstream/VERSION`. *Check:* `git log` shows the merge commit, and no file George didn't approve changed. 8. **Close the loop.** Add a line to `WORKLOG.md` and a handoff. *Check:* the handoff names the version now running. ### What a good round summary looks like ``` Round 3 · kit v1.1 · Broken - 20 Scheduled Tasks: Thursday publish fired twice once (fixed locally; suggest a claim note in the module) Confusing - 16 Dashboard Build: unclear which hostname Access covers Wishes - A module for sermon series planning Worked well - Session ritual: no "context lost" taps for 2 weeks ``` ## GEORGE does - Mentions anything annoying or confusing as it happens. - Sends the round summary to Trevor. - Decides keep, take or merge for each file in an update. ## Done when - [ ] `upstream/VERSION` and `FEEDBACK.md` exist on `main` - [ ] A round summary can be produced in one prompt, with private details removed - [ ] Updates land in `upstream/` as proposals and never overwrite George's files ## Writes to - `FEEDBACK.md`, `feedback/round-*.md`, `upstream/` - `WORKLOG.md`, a handoff ## Next - [32 · Prompt Library](./32-PROMPT-LIBRARY.md) # 32 · Prompt Library > Every prompt George needs, ready to copy, so he never has to work out how to ask. **Run it:** `Open module 32 and give me the prompt for .` **Needs first:** nothing **Time:** none · **GEORGE's part:** copy and paste ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{FRAMEWORK_URL}} | Where this framework lives (the public page or his copy in `george-os/framework/`) | module 00 | ## Why this matters Clear prompts get clear work. These are the exact sentences that start each part of the system, so George gets the same result every time. When a prompt works better in his words, his agent should update his local copy of this file. ## Steps 1. **Save a local copy.** Copy this file into `george-os/framework/32-PROMPT-LIBRARY.md`. *Check:* the file is on `main`. 2. **Pin the daily four.** Put the Start, End, Big job and Remember prompts in each claude.ai Project's instructions, or in a note on George's phone. *Check:* George can find them without opening this page. 3. **Improve as you go.** When George rewrites a prompt and it works better, update his local copy and log it in `FEEDBACK.md`. *Check:* the change is on `main`. ## Daily **Start any session** > Read BRAIN.md, NOW.md and the three newest handoffs in george-os. Tell me in one line what you picked up, then wait. **End any session** > Wrap up: add a WORKLOG line, write a handoff (done, where we stopped, next, open questions), update NOW.md, then pull, rebase and push to main. Tell me the commit. **A big job** > Use george-coach. Make projects/.md with the goal and a checkbox per step, do the steps, and tick each box with proof as you go. Push a checkpoint every 30 minutes. If you run long, write a handoff before you stop. **Remember something** > Use george-brain: remember that . Source: . **Context got lost** > You've lost track. Run george-session-start, rebuild where we stopped from the handoffs and the project checkboxes, and tell me what you think we were doing before you do anything. **From a claude.ai Project (can't save)** > Make a handoff note of what we decided and made here, formatted for george-os, so I can paste it into Claude Code. **In Claude Code, filing that note** > File this handoff note into george-os, update NOW.md, and push to main. ## Writing **Thursday article** > Use george-weekly-article: draft Thursday's article on "". Answer it in the first two sentences, then tell it my way. Scripture as text with the reference. Run george-slop-check and put the package in the dashboard. **Tuesday video** > Use george-video-package for "": script, title, description with chapters, pinned comment and thumbnail words. Slop-check it and put it in the dashboard. **Repurpose** > Use george-repurpose on this week's article and video: Substack post, Facebook, Instagram and podcast notes, inside the same dashboard package. **Sermon to article** > Use george-sermon-to-article on this transcript: one article draft and three short pieces, in my voice. **Check for AI-sounding writing** > Use george-slop-check on this. Show me every flag, then rewrite it in my voice. **An email** > Use george-email: draft a reply to about , from my address. Draft only. ## G's Plan and TOI **G's Plan this week** > Use george-gsplan: what's due for G's Plan this week, what's ready, and what needs me? **TOI monthly update** > Use george-missions-update: draft this month's TOI update, one story, one need, one prayer, in English and Spanish. Follow the TOI privacy rule. Put it in the dashboard for the Spanish approver and me. **Donor thank-yous** > Use george-donor-thanks for this week's new gifts. Read them through the connector to , write one short personal note each for my approval, and save nothing about the donors in george-os. **Trip prep** > Use george-trip-planner for the trip: timeline from 8 weeks out, packing list, forms, and team briefing. Nothing about people in the field. ## Dashboard and automation **What needs me** > What's waiting for my approval on the dashboard, oldest first? One line each. **Weekly brief now** > Use george-weekly-brief and include the scoreboard. **Make a job automatic** > Use module 19 to decide how to automate "", then set it up at autonomy level 1 and show me the first run before anything goes live. **Brief a Managed Agent** > Use george-managed-agent-brief to write the agent brief for "", with its tools, its stop rule, its time limit and where its output lands. ## Fixing and improving **Something broke** > Run module 30. Here's what happened: . **Feedback for Trevor** > Run module 31: collect this round's feedback and write the summary for me to send Trevor. Remove anything private. **An update arrived** > Run module 31 step 6: download the new kit version into upstream/, compare it to my files, and write a proposal. Don't change anything yet. ## Running each module Every module starts the same way: > Run module from my framework. | Module | Prompt | |---|---| | 00 | Read 00-START-HERE and tell me the plan before you start. | | 01 | Run module 01 and explain how we'll work through this. | | 02 | Run module 02 and save the ground rules in my brain. | | 03 | Run module 03 and show me the system map. | | 04 | Run module 04: inventory what I already have and interview me once. | | 05 | Run module 05 and write my profile. | | 06 | Run module 06 and set up george-os. | | 07 | Run module 07 and set up the memory ritual. | | 08 | Run module 08 and set up my Claude apps. | | 09 | Run module 09 and set up passwords and secrets. | | 10 | Run module 10 and install my skills. | | 11 | Run module 11 and show me what each skill does. | | 12 | Run module 12 and build my voice guide from my own writing. | | 13 | Run module 13 and set up the anti-slop check. | | 14 | Run module 14 and set my design standard. | | 15 | Run module 15 and explain the dashboard plan. | | 16 | Run module 16 and build the dashboard. | | 17 | Run module 17 and connect my data to the dashboard. | | 18 | Run module 18 and set up team access. | | 19 | Run module 19 and sort my recurring jobs by how to automate them. | | 20 | Run module 20 and set up the scheduled tasks. | | 21 | Run module 21 and set up Managed Agents with my monthly cap. | | 22 | Run module 22 and set up the first Managed Agent recipe. | | 23 | Run module 23 and set each job's autonomy level. | | 24 | Run module 24 and set my weekly rhythm. | | 25 | Run module 25 and build the G's Plan playbook. | | 26 | Run module 26 and build the TOI playbook. | | 27 | Run module 27 and set my boundaries. | | 28 | Run module 28 and set up each publishing channel. | | 29 | Run module 29 and set up the scoreboard. | | 30 | Run module 30. Here's what went wrong: . | | 31 | Run module 31 and get this round's feedback ready. | | 32 | Open module 32 and give me the prompt for . | ## GEORGE does - Copies and pastes. Tells the agent when a prompt didn't do what he meant. ## Done when - [ ] A local copy is in `george-os/framework/` - [ ] The daily four are pinned where George can find them - [ ] Improvements George makes are saved in his copy ## Writes to - `framework/32-PROMPT-LIBRARY.md`, `FEEDBACK.md` ## Next - Back to [00 · Start Here](./00-START-HERE.md) for the run order # 33 · Command Center > George runs the whole operation from Claude Code with a few short commands, while his reviewer checks everything before it goes out. **Run it:** `Run module 33 from my framework. Set up my command center and teach me the commands.` **Needs first:** 07, 10, 16, 23, 28 **Time:** about 40 minutes · **GEORGE's part:** try each command once and rename any he'd say differently ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{REVIEWER}} | The team member who signs in to the dashboard to double check what's going out | ask George; module 18 | | {{COMMAND_WORDS}} | Any words George prefers for a command ("what's live" instead of "status") | ask George after he tries them | | {{DAILY_TIME}} | When the daily check happens (default 7:30am America/Chicago) | ask George | | {{WEEKLY_TIME}} | When the weekly run happens (default Sunday 5pm America/Chicago) | module 24 | ## Why this matters George shouldn't have to remember which app does what or which skill to name. A short set of commands, the same every day, lets him steer the ship in a sentence: see what's happening, start work, hold something back. Every command ends in the dashboard, where {{REVIEWER}} can see and check it, so nothing reaches his readers, donors or ad budget without two people: a passed review by {{REVIEWER}} (or another named reviewer) and George's final approval, on the same version. ## The commands George types these in Claude Code (the desktop Code tab or claude.ai/code). The `george-command` skill reads the sentence, runs the right skill, and puts the result in the dashboard. | Command | What happens | Skills used | Lands in | |---|---|---|---| | `status` | One screen: what's waiting for approval, what's scheduled, what published since yesterday, anything broken | george-command, george-session-start | reply in chat, read from the dashboard | | `what's going out this week` | Every item scheduled in the next 7 days by channel, with its approval state and who reviewed it | george-command, george-approval-queue | reply plus a link to the dashboard week view | | `draft Thursday` | Drafts Thursday's article package (article, Substack post, email, social captions) | george-weekly-article, george-repurpose, george-slop-check | a new dashboard item, pending | | `draft Tuesday` | Drafts Tuesday's video package | george-video-package, george-repurpose, george-slop-check | a new dashboard item, pending | | `show me what {{REVIEWER}} flagged` | Lists items the reviewer commented on or sent back, newest first, with her notes | george-command, george-approval-queue | reply in chat | | `fix what {{REVIEWER}} flagged` | Makes a new version of each flagged item that answers her notes | george-voice, george-slop-check | new versions; approval resets to pending | | `approve ` | Records George's approval on the current version, from the dashboard only | george-approval-queue | the dashboard asks him to confirm on screen (agents can't approve) | | `pause ads` | Tells George plainly that running ads keep running until a person pauses them in Ads Manager, opens the exact steps for each live ad, and records the pause on the dashboard once George confirms it's done | george-command, module 35 | an urgent dashboard item that closes only when the pause is confirmed | | `pause ` | Pauses that channel's publisher job on the dashboard (`PATCH /api/automations/:id`, which George confirms on screen) so nothing new goes out there; anything already scheduled inside the channel itself (Meta Business Suite, the email platform) must be unscheduled there by a person | george-command | the job shows paused; an item lists anything still scheduled outside | | `pause everything` | Opens the dashboard's **Pause everything** button for George to press (only George can pause all), which stops every scheduled task, Managed Agent and publisher, then gives the Ads Manager steps for any live ads (those keep running until a person pauses them) | george-command | an urgent dashboard item listing what stopped and which ads still need a person | | `run the brief` | The weekly brief and scoreboard right now | george-weekly-brief | reply plus a brief item in the dashboard | | `G's Plan` / `TOI` | What's due, ready and stuck for that brand this week | george-gsplan, george-missions-update | reply in chat | | `remember ` | Saves a fact with its source | george-brain | `BRAIN.md` or a project file | | `wrap up` | The session-end ritual | george-handoff | handoff on `main` | ## The routines - **Daily ({{DAILY_TIME}}):** George types `status`. The agent answers in under ten lines: waiting for him, waiting for {{REVIEWER}}, going out today, anything broken. One tap into the dashboard handles approvals. - **Weekly ({{WEEKLY_TIME}}):** the weekly brief arrives on its own (module 24). George reads it, then types `what's going out this week` and approves the week's packages after {{REVIEWER}} has checked them. ## Steps 1. **Install the command skill.** Confirm `george-command` is installed and lists every command above with the skill it calls. *Check:* typing `status` in a fresh Claude Code session returns the status screen. 2. **Wire every command to the dashboard.** Each command that creates work posts a dashboard item through the API, with brand, channel, destinations and the first version. *Check:* `draft Thursday` creates one pending item with a slop-check report. 3. **Two-person rule.** Every item going out needs a passed review by {{REVIEWER}} (or another named reviewer) and then George's final approval, by two different people, on the same version. The dashboard enforces it (module 16): George's approve button stays off until the review has passed, and any edit resets both. *Check:* George can't approve a test item until the reviewer passes it, and an edit after approval resets both. 4. **Make sure commands can't publish.** No command publishes, sends, launches or changes spend, and no command claims to stop live ads by itself. Those only happen through the approval flow (modules 16, 23, 28) or by a person in the platform. *Check:* asking `post this to Facebook now` produces a dashboard item, not a post. 5. **Teach George.** Show him the table, have him try `status`, `draft Thursday` and `show me what {{REVIEWER}} flagged`, and record any words he'd rather use as {{COMMAND_WORDS}}. *Check:* his preferred words work. 6. **Pin the commands.** Put the command table in each claude.ai Project's instructions and in `framework/33-COMMAND-CENTER.md` in george-os. *Check:* he can find them without this page. ## GEORGE does - Tries each command once and says what he'd rather type. - Gives the final approval from the dashboard, after {{REVIEWER}}'s review has passed. ## Done when - [ ] Every command works in a fresh session - [ ] Every command that makes work creates a dashboard item - [ ] No command can publish, send, launch or change spend - [ ] The two-person rule holds: no approval without a passed review by someone other than George, on the same version - [ ] `pause everything` stops all automations and lists any live ads still needing a person - [ ] George uses `status` daily without looking anything up ## Writes to - `skills/george-command/SKILL.md` (his copy), `framework/33-COMMAND-CENTER.md` - `decisions/` (his command words), `WORKLOG.md`, a handoff ## Next - [34 · Meta Social](./34-META-SOCIAL.md) # 34 · Meta Social (Facebook and Instagram) > George's Facebook Page and Instagram account sit in his own Meta business portfolio, posts go out on a steady plan, and his reviewer checks them first. **Run it:** `Run module 34 from my framework. Check who owns my Facebook Page and Instagram, then set up the posting flow.` **Needs first:** 09, 12, 13, 16, 18, 28 **Time:** about 60 minutes, plus any ownership transfer wait · **GEORGE's part:** sign in to Meta, accept or request ownership, add {{REVIEWER}} as a person ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{ACCOUNT_EMAIL}} | The email George uses for his own Meta business portfolio | ask George | | {{PORTFOLIO_NAME}} | The name of his Meta business portfolio (create one if none exists) | Meta Business Suite, with George signed in | | {{FACEBOOK_PAGE}} | His author Facebook Page | his site's social links | | {{INSTAGRAM}} | His Instagram professional account | his site's social links | | {{REVIEWER}} | The team member who checks posts before they go out | module 18 | | {{REVIEWER_ACCESS}} | The smallest set of permissions she needs (for example content and insights on the Page and Instagram, no admin control) | ask George | | {{POST_PLAN}} | How often and when each account posts (America/Chicago) | module 24, ask George | | {{OTHER_PAGES}} | Pages for TOI or G's Plan, if any, and who owns them | modules 25, 26 | ## Why this matters If someone else's business account owns George's Page, he can't fully control it, connect tools to it, or add his own team. So ownership comes first. After that, a predictable package (captions, images, alt text, links, a time) means posting takes minutes, and {{REVIEWER}} can catch mistakes before readers do. Insights flowing into the dashboard show what actually works. ## Steps 1. **Check ownership.** With George signed in, open Meta Business Suite, go to settings, and list who owns {{FACEBOOK_PAGE}} and {{INSTAGRAM}}, and every person and partner with access. *Check:* a table in `projects/meta/ACCESS.md` shows owner, people, partners and permissions for each asset. 2. **Get both into George's portfolio.** If they aren't owned by {{PORTFOLIO_NAME}} (created with {{ACCOUNT_EMAIL}}), George requests ownership or the current owner transfers it. George must be a full admin on the portfolio and on both assets. Write down what's pending. *Check:* the access table shows {{PORTFOLIO_NAME}} as owner and George with full control. 3. **Link Instagram to the Page.** The Instagram professional account is connected to the Facebook Page inside the portfolio. *Check:* both show in Meta Business Suite under one portfolio. 4. **Add {{REVIEWER}} as a person.** George invites her by her own email as a person in the portfolio, with only {{REVIEWER_ACCESS}}. Never a shared password, never full admin unless George decides. *Check:* she accepts and appears in the access table with those permissions only. 5. **Set the package.** Each social item in the dashboard holds: caption per platform, images or carousel plan, alt text for every image, link, first comment if any, and the scheduled time. It passes `george-slop-check`. *Check:* a test item has every field. 6. **Post at level 2.** After {{REVIEWER}}'s review passes and George gives final approval on that same version (two different people, enforced by the dashboard), a person schedules it in the Meta Business Suite Planner using the ready text, then pastes the post link back into the item as the receipt. *Check:* one real post goes through and the item shows the receipt. 7. **Pull insights read-only.** Add Page and Instagram reach, engagement and follower counts to the dashboard (module 17), read-only. *Check:* the dashboard shows last week's numbers. 8. **Level 3 later, only after four clean weeks.** Automatic posting means the Graph API with a system user token from George's portfolio, stored in 1Password or as a cloud network secret (module 9). Before building it, read Meta's current developer docs for Page and Instagram publishing, because permissions, review steps and limits change. George approves the switch in `decisions/`. *Check:* nothing posts automatically until that decision exists. ## GEORGE does - Signs in to Meta and requests or accepts ownership. - Invites {{REVIEWER}} with the smallest permissions. - Approves each package, and decides when posting moves to level 3. ## Done when - [ ] Both accounts are owned by {{PORTFOLIO_NAME}} with George as full admin - [ ] {{REVIEWER}} has her own access with only the permissions she needs - [ ] One post went through package, review, approval, Planner and receipt - [ ] Insights show on the dashboard - [ ] Posting stays at level 2 until George decides otherwise ## Writes to - `projects/meta/ACCESS.md`, `projects/channels/facebook.md`, `projects/channels/instagram.md` - `decisions/`, `WORKLOG.md`, a handoff ## Next - [35 · Meta Ads](./35-META-ADS.md) # 35 · Meta Ads > George's Meta ads run from his own ad account with a hard spending limit, his agent prepares every campaign, and a person launches it only after George approves the spend. **Run it:** `Run module 35 from my framework. Set up my ad account safely, then brief my first campaign.` **Needs first:** 09, 16, 18, 23, 34 **Time:** about 60 minutes · **GEORGE's part:** add his payment method, set the spending limit, approve every spend ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{AD_ACCOUNT}} | His ad account inside his own Meta business portfolio | Meta Business Suite, with George signed in | | {{SPEND_LIMIT}} | The account spending limit in dollars (a ceiling for all spend) | ask George | | {{MONTHLY_AD_BUDGET}} | What he plans to spend per month across campaigns | ask George | | {{REVIEWER}} | The team member who reviews ad creative | module 18 | | {{REVIEWER_CAN_APPROVE_SPEND}} | Yes or no. Default no. | ask George | | {{GOALS}} | What ads are for (book sales, newsletter sign-ups, event or trip sign-ups, video views) | modules 25, 26, ask George | | {{LANDING_PAGES}} | Pages ads send people to | his site | | {{TRACKING}} | Pixel or Conversions API events, and UTM tags | ask George; check his site | | {{PAUSE_RULES}} | When an ad gets paused (see below) | ask George to confirm | ## Why this matters Ads spend real money fast, so the order of setup is the safety plan: his own account, his own payment method, a spending limit before anything runs. After that, the agent does the slow work (briefs, audiences, three creative versions, tracking) and George makes the money decisions. Results flowing into the dashboard show what each dollar did. ## Steps 1. **Confirm the account.** {{AD_ACCOUNT}} sits in George's own portfolio (module 34), with George as admin and his own payment method. *Check:* `projects/meta/ACCESS.md` lists the ad account, its owner, the payment method owner (name only, never card details), and everyone with access. 2. **Set the spending limit first.** George sets an account spending limit of {{SPEND_LIMIT}} in billing settings before any campaign exists. *Check:* the limit shows in the account and is recorded in `decisions/`. 3. **Give {{REVIEWER}} access.** Her own login as a person in the portfolio, with access to review ads and results. She can't change budgets unless {{REVIEWER_CAN_APPROVE_SPEND}} is yes. *Check:* the access table shows her permissions. 4. **Check special categories.** If an ad touches credit, employment, housing, or social issues, elections or politics, it must use Meta's Special Ad Category and its targeting limits. Faith content that comments on public issues can fall under social issues; when unsure, flag it for George. *Check:* every brief has a line saying which category applies, or none. 5. **Brief the campaign.** For each campaign, the agent makes one dashboard item with: objective, audience, structured budget fields (total budget, daily cap, start and end dates), placements, three creative versions (image or video idea, primary text, headline, call to action), landing page, tracking events and UTM tags, and the pause rules. Creative passes `george-slop-check`. The dashboard rejects any ad brief missing the structured budget, daily cap or dates. *Check:* a test brief has every field, and one without a daily cap is refused. 6. **Review, approve, launch by a person.** {{REVIEWER}}'s review of the creative must pass, then George gives his own final approval on that exact version, including the spend (two different people, enforced by the dashboard). Every ad launch needs George's own approval. A person builds and launches it in Ads Manager from the brief, then pastes the campaign link back as the receipt. Ads always stay at level 2; no agent launches ads. *Check:* the item shows reviewer mark, George's approval and the receipt. 7. **Any spend change needs George.** Raising a budget, extending dates, or adding a campaign is a new version of the item and needs a passed review and George's own approval again, whatever {{REVIEWER_CAN_APPROVE_SPEND}} says about her access in Ads Manager. *Check:* editing a budget in a test item resets it to pending. 8. **Pull results read-only.** With read-only access (ads_read), pull daily spend, results, cost per result, and frequency into the dashboard (module 17). Store the token per module 9. *Check:* the dashboard shows yesterday's spend for each running campaign. 9. **Pause rules.** Default rules George confirms: pause an ad if cost per result is double the target after a meaningful number of impressions, if frequency climbs past 4 in a week, if spend is on pace to pass {{MONTHLY_AD_BUDGET}}, or if the ad gets a policy warning. The agent flags a breach as an urgent dashboard item with the exact Ads Manager steps; the ad keeps running until a person pauses it, and the item closes only when the pause is confirmed. `pause ads` (module 33) does the same for every live ad. *Check:* a simulated breach produces an urgent item. ## GEORGE does - Adds his payment method and sets the spending limit. - Approves every campaign and every spend change. - Decides whether {{REVIEWER}} can approve spend. ## Done when - [ ] The ad account is in George's portfolio with his payment method and a spending limit - [ ] {{REVIEWER}} has her own access with the right permissions - [ ] One campaign went through brief, review, approval, launch by a person and receipt - [ ] Spend and results show on the dashboard daily - [ ] Pause rules are confirmed and tested ## Writes to - `projects/meta/ACCESS.md`, `projects/ads/.md`, `decisions/` - `WORKLOG.md`, a handoff ## Next - [36 · Email Marketing](./36-EMAIL-MARKETING.md) # 36 · Email Marketing > George's email list grows from his site and Substack, every campaign is drafted in his voice, tested on two people, and sent only after approval. **Run it:** `Run module 36 from my framework. Find my email platform, map my lists, and set up the send flow.` **Needs first:** 04, 09, 12, 13, 16, 18, 28 **Time:** about 45 minutes · **GEORGE's part:** confirm the platform and sender details, approve every send ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{EMAIL_PLATFORM}} | Where his emails go out: his Substack newsletter, or a tool like Mailchimp or Kit | the inventory from module 04; ask George if there's more than one | | {{LISTS}} | Each list or audience, what it's for, and its size | the platform, read-only | | {{LIST_SOURCES}} | Where sign-ups come from (Webflow forms, Substack, events, TOI) | his site's forms, the platform | | {{SENDER}} | From name, from address and reply-to for each list | the platform, ask George | | {{MAILING_ADDRESS}} | The postal address that must appear in marketing email | ask George | | {{REVIEWER}} | The team member who gets every test send | module 18 | | {{SEQUENCES}} | Automated series (welcome, new reader, book launch, trip follow-up) | the platform, ask George | | {{SEND_PLAN}} | Regular sends and their days (America/Chicago) | module 24 | ## Why this matters Email is the one channel George owns outright, and his readers already said yes to hearing from him. That makes every send worth getting right: his voice, the correct list, working links, and nothing that hurts trust. A fixed flow (draft, test to two people, approve, send) keeps quality high without George doing the work himself. ## Steps 1. **Find the platform.** From the module 04 inventory, name {{EMAIL_PLATFORM}}. If he uses more than one, record which list lives where. *Check:* `projects/email/SETUP.md` names each platform and list. 2. **Map list sources.** Trace every sign-up path: Webflow forms, Substack, any event or TOI sign-up. Confirm each one lands in the right list. *Check:* a test sign-up through each form appears in its list. 3. **Set sender rules.** For each list, record {{SENDER}}, {{MAILING_ADDRESS}}, and that every marketing email has a working unsubscribe link and an honest subject line. Use the right sender identity for each role (module 27). *Check:* the rules are in `projects/email/SETUP.md`. 4. **Draft in the dashboard.** Campaigns and sequence emails are dashboard items: subject, preview text, body, list or segment, send time, and links. They pass `george-slop-check`. TOI emails come in English and Spanish (module 26). *Check:* a test campaign item has every field. 5. **Test send before every send.** Send a test to George and {{REVIEWER}}. She checks links, names, images, the subject on a phone, and the unsubscribe link. *Check:* the item shows the test date and her reviewer mark. 6. **Send at level 2.** After {{REVIEWER}}'s review passes and George gives final approval on that exact version (two different people, enforced by the dashboard), a person schedules or sends it in {{EMAIL_PLATFORM}} and pastes the campaign link back as the receipt. *Check:* one real send has its receipt. 7. **Level 3 only through the platform's API.** Automatic sends need the platform's official API, a key stored per module 9, a claim on the approved version, and a receipt for each send. Only after four clean weeks and George's decision in `decisions/`. Substack has no official publishing API, so it stays level 2. *Check:* nothing sends automatically without that decision. 8. **Bring list numbers into the dashboard.** Pull subscriber counts, new sign-ups, unsubscribes, and open and click rates for recent sends, read-only (module 17). *Check:* the dashboard shows this week's numbers. ## GEORGE does - Confirms the platform, sender details and mailing address. - Approves every send. - Decides if and when any list moves to level 3. ## Done when - [ ] Every list and sign-up path is mapped and tested - [ ] Sender and unsubscribe rules are written down - [ ] One campaign went through draft, test send, review, approval, send by a person and receipt - [ ] List numbers show on the dashboard ## Writes to - `projects/email/SETUP.md`, `projects/channels/email.md` - `decisions/`, `WORKLOG.md`, a handoff ## Next - Back to [28 · Publishing Channels](./28-PUBLISHING-CHANNELS.md) to confirm every channel row matches reality # 37 · GEO and SEO Strategy > Get George named and cited when people ask ChatGPT, Google, Claude, Perplexity and the rest a Bible question, not only when they already know his name. **Run it:** `Run module 37 from my framework. Start with the baseline, then do this week's fixes and plan the next 30 days of Tuesday videos and Thursday articles.` **Needs first:** 12, 13, 16, 28 **Time:** about 90 minutes to set up, then about 2 hours a week inside the normal rhythm · **GEORGE's part:** verify the site in Google and Bing once, record the videos, approve each package ## Fill in first | Slot | What it is | Where the agent gets it | |---|---|---| | {{RP_ACCESS}} | George's Rank Prompt access: the account, and the brand for georgeshamblin.com | ask George once; store the login in 1Password (module 09), never in a chat | | {{PROMPT_SET}} | The 50 English and 15 Spanish questions measured each month (the baseline list is below) | `projects/ai-visibility/prompts.md` (this module writes it) | | {{WEBFLOW_SITE}} | His Webflow site, the posts collection and the post template | Webflow connector (module 28) | | {{GSC_ACCESS}} | Google Search Console for georgeshamblin.com | George verifies once (Step 2) | | {{BING_ACCESS}} | Bing Webmaster Tools for the same site | George verifies once (Step 2) | | {{SPEAKING}} | Whether George takes speaking bookings and interviews, and for which audiences | ask George once in a batch | | {{MONTHLY_CREDITS}} | Rank Prompt credits he is willing to spend each month on measuring | suggested: 165 (50 prompts on 7 engines plus 15 Spanish prompts on 3 engines) | | {{BASELINE_DATE}} | Date of the first measurement | 2026-11-06 (below) | ## Why this matters George already did the hard part. Since September he has been publishing question-titled answers built for AI search. The baseline shows the engines are not using them yet: across 40 teaching questions, he was named once. When people ask his name, the engines know him well and quote his site. When they ask the question his post answers, they quote GotQuestions.org, Wikipedia, Britannica and YouTube instead. That gap is fixable, mostly by changing pages he already has, and the fixes fit inside the Tuesday video and Thursday article he already promised. This module turns the gap into a short list of page changes, a 30-day plan, and a monthly number his agent checks, so George does not have to relearn any of it. ## Steps 1. **Set up the measuring home.** Create `projects/ai-visibility/` in george-os with `BASELINE.md` (the tables in "The baseline" below), `prompts.md` (the 65 questions at the end) and `README.md` (how to re-measure). *Check:* the three files are on `main` and the baseline numbers match "The baseline" below. 2. **Verify the site with Google and Bing (GEORGE).** George adds georgeshamblin.com as a domain property in Google Search Console and in Bing Webmaster Tools, using the DNS record each one gives, then grants his agent's account read access. *Check:* both consoles show the site as verified and the sitemap as submitted. 3. **Run the indexing check.** Inspect the 12 question posts in the "loses" table below in Search Console and Bing. Record each one's status in `BASELINE.md`. *Check:* every one of the 12 has a status written down. 4. **Ship the template fixes first.** With george-site-update, make recommendations 2 and 10 (server-rendered FAQ and video schema, one H1) as Webflow drafts, then put them through the approval queue. *Check:* fetch a post with JavaScript off (for example `curl`) and find `FAQPage` in the HTML; count exactly one `

`. 5. **Fix scripture and alt text.** Recommendation 4, all seven posts. *Check:* the pearl post's HTML contains the text of Matthew 13:45-46 and no in-body image with words on it has empty alt. 6. **Load the 30-day plan into the calendar.** Add the 30-day plan table below to `calendar/` with each week's video, article and refresh. *Check:* the Saturday and Wednesday drafting jobs from module 24 pick up the right topic for week 1. 7. **Run the weekly loop.** Each week: video package Saturday, article package Wednesday, one refresh, all through voice, slop check and approval. *Check:* each shipped page is answer-first, has its question H2s, has scripture as text, and is added to `llms.txt`. 8. **Do the one-time footprint work.** Recommendations 6, 7, 8 and 9, spread over the month. *Check:* the Person schema lists every profile in `sameAs`; the Wikidata item exists; the Inerrancy page has its FAQ. 9. **Re-measure monthly** (see below) and write the result. *Check:* a new `projects/ai-visibility/YYYY-MM.md` exists with the four headline numbers and the scoreboard row is updated. ## The baseline (measured {{BASELINE_DATE}}) Measured with his Rank Prompt access: 50 English questions on 7 engines (ChatGPT, Claude, Google AI Mode, Gemini, Perplexity, Grok, Meta's Muse), United States, plus 15 Spanish questions on 3 engines (ChatGPT, Google AI Mode, Gemini), Mexico. One run, so treat every number as a starting point, not a trend. | Measure | Number | |---|---| | AI visibility score (Rank Prompt's own number) | 7.2% (25 of 346 answers named him) | | Answers to non-brand questions that named him | **6 of 307 (2.0%)**, the number that matters most | | Teaching questions where any engine named him | 1 of 40 (Claude listed the Inerrancy book sixth in a list of 11) | | Answers to "who is George" style questions that name him | 37 of 39 when you read the answers. The tool's own count says 19 of 39, because it misses answers when his name is already in the question | | His own pages cited on non-brand questions | 1 time in 307 answers (Grok cited the Gospel of John post, sixth source) | | Share of voice | 2.4%, tied with GotQuestions.org (25 mentions each), behind Crossway (30) and BibleProject (26). Nearly all of his came from questions that used his name | | Spanish | 3 of 45 answers, all three on "¿Quién es George Shamblin?". 0 of 42 on the Bible questions | **Engines that mention him (all 50 questions / non-brand only):** Gemini 4 / 0, Google AI Mode 4 / 1, Muse 4 / 2, Grok 4 / 0, Claude 4 / 2, ChatGPT 3 of 46 / 1, Perplexity 2 / 0. Perplexity is his weakest engine. **Questions he wins (non-brand):** - "Who is a Reformed pastor in Alabama who writes about the reliability of the Bible?" Muse (named first) and Claude (third). - "Christian author available for podcast or radio interviews about the Bible and the Gospels" Muse (first). - "Christian speaker in Birmingham Alabama for a men's retreat or church event" ChatGPT (second). - "Who are Christian authors and Bible teachers based in Birmingham, Alabama?" Google AI Mode (first). - "What are the best books on biblical inerrancy for a layperson?" Claude (sixth). **Questions he loses although he already has a page for them** (no engine named or cited him): | Question | His existing page | Who gets cited instead | |---|---|---| | What does the parable of the pearl of great price mean? / Who is the merchant? | two posts: `/post/what-does-the-parable-of-the-pearl-of-great-price-mean` (2026) and `/post/who-or-what-does-the-merchant-represent-who-or-what-does-the-pearl-represent` (2020) | GotQuestions.org, Wikipedia, Ligonier | | Why is the Gospel of John so different from Matthew, Mark, and Luke? | `/post/why-is-the-gospel-of-john-so-different-from-matthew-mark-and-luke` | bible.org, Wikipedia, Bible Hub | | Why are there four Gospels instead of just one? | `/post/have-you-ever-wondered-why-there-are-four-gospels-instead-of-just-one` | GotQuestions.org, BibleProject | | How does each of the four Gospels portray Jesus differently? | `/books/the-four-faces-of-christ` | Britannica (all 7 engines) | | How many Old Testament prophecies did Jesus fulfill? | `/post/how-many-old-testament-prophecies-did-jesus-actually-fulfill` | GotQuestions.org (5 of 7) | | How can old manuscripts help us trust the Bible? / How do we know the New Testament wasn't changed? | `/post/how-can-thousands-of-old-manuscripts-help-us-trust-the-bible` | Logos, C.S. Lewis Institute; Bart Ehrman named in 5 of 7 | | What does "already but not yet" mean? | `/post/already-not-yet` (2021, about 320 words, a podcast intro) | GotQuestions.org, George Eldon Ladd | | Who was John Wycliffe and why was his body dug up and burned? | `/systematic-theology-shorts/john-wycliffe-dug-up-and-burned-torchbearers-ep-2` (about 235 words, no transcript) | Wikipedia, World History Encyclopedia, Britannica | | What did Jesus look like? / Can good deeds get you to heaven? / Would alien life disprove God? | `/post/what-did-jesus-look-like`, `/post/can-good-deeds-get-you-to-god`, `/post/can-god-and-aliens-both-exist` | Bible Gateway, GotQuestions.org, Vatican Observatory | | Where can I find short videos that explain systematic theology? | the 50 Systematic Theology Shorts | YouTube (17 citations: Ligonier, The Gospel Coalition, BibleProject) | **Questions with no page yet:** how to support Christians in Cuba and which missions work there (CUBA Ministry, Proclaim Cuba, Open Doors win; 0 of 21), the state of the church in Cuba (USCIRF, Open Doors), beginner apologetics resources (Tactics, The Reason for God, Cold-Case Christianity), small-group studies on the Gospels ("Meeting Jesus" from IVP, 6 of 7), and the best websites, YouTube teachers and podcasts for Bible questions (GotQuestions.org, BibleProject, BibleThinker, Ask Pastor John). **Most-cited sources across all 50 questions:** YouTube (49 citations), GotQuestions.org (35), Wikipedia (32), georgeshamblin.com (31, almost all on questions using his name), Amazon (22), Goodreads (15), BibleProject (13), Crossway (13), Apple Podcasts (13), Bham Now (12), Bible Gateway (12), Britannica (12), Logos (12). Store pages that sell his books, on Amazon, Goodreads and one ministry bookstore, are cited more often than his own book pages. **What the engines know without searching:** with web search on, ChatGPT, Perplexity and Gemini describe him accurately from `/about/author`, the home page, the Bham Now profile and his radio interviews. With search off, ChatGPT and Claude say they don't know him, and Gemini invents two book titles he never wrote. The fix for that is a wider, consistent footprint off his own site (recommendation 7). **Technical state (checked on the live site, not only in the tool):** robots.txt allows every AI and search crawler; both sitemaps are listed and hold 305 pages; `llms.txt` already exists; home, about and book pages carry Person, Organization, Book and WebSite schema; posts carry BlogPosting with dates. The gaps: the FAQ and video schema on posts is added by JavaScript after the page loads, so most AI crawlers never see it; Systematic Theology Shorts pages have no schema and almost no text; every post has two H1 headings and category pages have none; scripture and other images inside recent posts have empty alt text (the newest pearl post shows the two verses only as an image); no x-default hreflang; mobile Largest Contentful Paint on the home page is 5.4 seconds; and the site is not yet confirmed in Google Search Console or Bing Webmaster Tools, so nobody can see whether the question posts are indexed. ## Top 10 recommendations, ranked by impact 1. **Answer-first refresh of the question posts he already has.** These pages exist and get no citations. For each post in the "loses" table in the baseline, use george-site-update to change, in this order: the first 40 to 60 words answer the exact question in plain words; the H1 and SEO title match the question as people ask it; two to four H2s are the follow-up questions (the "who is the merchant" kind); scripture appears as text with its reference; two or three named sources back any number or historical claim (the manuscripts post needs its manuscript counts sourced); one paragraph of George's own story stays, in his voice (module 12). Start with the pearl, John, four Gospels, prophecies and manuscripts posts. For the two pearl posts, keep the 2026 post as the main answer, move anything unique from the 2020 post into it, and 301-redirect the 2020 URL to it. 2. **Make the FAQ and video schema readable without JavaScript.** In the Webflow post template, move the FAQPage that the load script builds into the template's server-rendered schema box, fed from CMS fields (for example three question and answer field pairs per post), and do the same for VideoObject on posts with a video. Keep the visible FAQ text identical to the schema. Then remove the load script's FAQ part so there is one copy, not two. 3. **Verify the site with Google and Bing, then check indexing.** George verifies georgeshamblin.com in Google Search Console and Bing Webmaster Tools (domain property through the DNS record). Submit `/sitemap.xml` to both. Inspect the 12 question posts in the "loses" table below one by one; any that are "discovered, not indexed" go to the top of recommendation 1. Bing matters twice: ChatGPT search draws partly on Bing, and Microsoft Copilot answers from it. 4. **Scripture as text, and real alt text.** On `/post/what-does-the-parable-of-the-pearl-of-great-price-mean`, replace the verse image after "It's two verses long:" with Matthew 13:45-46 as text and its reference. Fill alt text on the in-body images of the Son of God, pearl, prophecies, What did Jesus look like, good deeds, manuscripts and take up your cross posts (decorative images may keep empty alt; anything with words on it may not). george-weekly-article already carries the "scripture as text, with reference" rule; this cleans up what shipped before it. 5. **Turn the Shorts and YouTube into citable text.** YouTube is the most-cited source in the whole report. For each Systematic Theology Short and Torchbearers episode, add a transcript or a 300 to 600 word written answer under the video, a question-shaped title on the page and on YouTube, server-rendered VideoObject schema, and a link from the YouTube description back to the page. Build one hub page, "Forerunners of the Reformation", that links Wycliffe, Hus and Luther in order. Start with the Wycliffe episode and "Two Camps of Apologetics". 6. **Own the book questions on his own book pages.** On `/books/the-four-faces-of-christ`, add a visible comparison block (Matthew: King; Mark: Servant; Luke: friend of the overlooked; John: God) and a "Using this book in a small group" section, and link the four-Gospels and John posts. On `/books/inerrancy`, add a short FAQ (what inerrancy means, why it matters, where to get the free PDF) like the other two book pages have, and put the free PDF link near the top. Then ask each store page that sells his books to link to the matching page on georgeshamblin.com. 7. **Widen his footprint beyond his own site.** Add every official profile to the `sameAs` list in his Person schema (YouTube, Substack, Spotify and Apple Podcasts, Amazon author page, Goodreads, LinkedIn, The Overseas Initiative, The Center for Executive Leadership's staff page). Create a Wikidata item for him and his three books with the same facts. Complete his Amazon and Goodreads author profiles with the same bio and a link home. Use one bio sentence everywhere. This is what fixes the engines that answer from memory and the one that invents books. 8. **A speaking and media page, because local is his one winning category.** If {{SPEAKING}} says yes, publish `/speaking`: topics he teaches, audiences (men's groups, churches, retreats), Birmingham and travel, and a list of past radio and podcast interviews linking the interview posts already on the site. Link it from the home page and `/about/author`. If he takes bookings, claim a profile on the GigSalad Birmingham Christian speakers directory, which engines cited seven times on the speaker question. If he does not take bookings, skip this one. 9. **A Cuba cornerstone page.** Engines answered every Cuba question without him (0 of 21) although he has years of firsthand Cuba writing. Write one long answer page, "How can I support the church in Cuba?", from his trips and The Overseas Initiative's work: what the churches need, what is legal for Americans to send, which ways to give, and what he has seen. Link the Christianity in Cuba category, the Cuba week posts and The Overseas Initiative. Its Spanish version matters as much as the English one. 10. **Fix the template headings and turn the category page into a Q&A index.** One H1 per page: remove the repeated title H1 from the post template, keep one on `/about/author`, and add one to every category page. Rewrite `/blog-categories/bible-questions-answered` into "Bible Questions Answered", a plain list of every question George has answered, each linked, with a two-line intro. GotQuestions.org won all 7 engines on "What are the best websites that answer Bible questions in plain English?"; this page is how George enters that list. ## The 30-day content plan Tied to his public promise of Tuesday videos and Thursday articles (module 24). Each week pairs one video and one article on the same losing question, so the video page and the article link to each other. Each week also gets one refresh from recommendation 1, done by the agent with no recording time from George. Weglot builds the `/es` version automatically; the agent checks the Spanish title and meta description before approval. | Week | Tuesday video (george-video-package) | Thursday article (george-weekly-article) | Refresh that week (george-site-update) | Question it targets, and who wins it now | |---|---|---|---|---| | 1 | "How does each Gospel show Jesus differently?" (Four Faces of Christ, one face per minute) | Rewrite of the four Gospels post as "Why are there four Gospels instead of just one?" | Pearl posts merged, verse as text | Four Gospels questions (Britannica, GotQuestions.org, BibleProject) | | 2 | Systematic Theology Short: "What does 'already but not yet' mean?" | New full answer at `/post/already-not-yet`, retitled to the question | Gospel of John post | Already but not yet (GotQuestions.org) | | 3 | "How do we know the New Testament wasn't changed?" | Same question as an article, linking the manuscripts post and the free Inerrancy PDF | Manuscripts post (sources added) | Bible reliability (Logos, Bart Ehrman named in 5 of 7) | | 4 | Torchbearers recap: "Who were the forerunners of the Reformation?" | "How can I support the church in Cuba?" (recommendation 9) | Prophecies post | Reformation forerunners (Wikipedia, Britannica); Cuba (CUBA Ministry, Open Doors) | | Days 29 and 30 | Pick the weakest of weeks 1 to 4 by the month-end check | Next in line: "Can you be a Christian and not believe the Bible is without error?" | Wycliffe page transcript | Inerrancy questions (Catholic Answers, The Gospel Coalition) | Every package goes through george-voice and the slop check (modules 12 and 13) before it reaches the dashboard queue (module 16). After approval, george-repurpose makes the Substack version, the YouTube description with a link back to the page, podcast notes and social captions, each linking to the one canonical page on georgeshamblin.com, so every channel points engines at the same answer. ## Technical fixes | Fix | Where | How | Skill | |---|---|---|---| | Person schema | home and `/about/author` | already present; add the full `sameAs` list and `knowsAbout` (Bible reliability, the Gospels, systematic theology, church history, missions in Cuba) | george-site-update | | Book schema | the three book pages | already present; add FAQPage to `/books/inerrancy`, keep ISBNs and publisher consistent with Amazon | george-site-update | | Article schema | post template | BlogPosting is already server-rendered with dates; keep author = George, add `about` (the question) | george-site-update | | FAQ schema | post template | move from the load script into the server-rendered schema box (recommendation 2) | george-site-update | | Video schema | posts with video, every Short | server-rendered VideoObject with name, description, upload date, thumbnail and the YouTube URL | george-site-update | | llms.txt | `/llms.txt` | already exists; add each refreshed or new answer page the week it ships, and the speaking and Cuba pages | george-site-update | | Sitemap | `/sitemap.xml` | already complete (305 pages); submit it in Search Console and Bing Webmaster Tools; 301 the retired pearl URL | george-site-update | | Spanish `/es` | site-wide (Weglot) | en and es hreflang pairs already work; add `x-default` pointing to the English page; check Spanish titles and meta descriptions on new posts (several run over 160 characters) | george-site-update | | Scripture as text | every post | never put a verse only in an image; text plus reference | george-weekly-article | | Alt text | every in-body image | describe what is in it; words in an image go in the alt text | george-weekly-article, george-site-update | | One H1 | post template, about page, category template | recommendation 10 | george-site-update | | og:url, long meta descriptions | home, several posts and `/es` pages | add og:url; keep descriptions 70 to 160 characters | george-site-update | | Mobile speed | home page | Largest Contentful Paint 5.4 seconds; compress and size the hero image, lazy-load below-the-fold video embeds | george-site-update | ## How to re-measure each month - **When:** the first Monday of each month, run by george-ai-visibility as a scheduled task (module 20). - **What:** the same 50 English questions on the same 7 engines and the same 15 Spanish questions on the same 3 engines, in the same markets, through {{RP_ACCESS}}. About {{MONTHLY_CREDITS}} credits a month. Never edit the question list between runs; add new questions as a separate group so they don't count as movement. - **The four numbers to record:** (1) non-brand answers naming him, out of about 307 (baseline 6); (2) citations of his own pages on non-brand questions (baseline 1); (3) Spanish non-brand answers naming him (baseline 0 of 42); (4) brand questions answered correctly, read from the answer text, not the tool's flag (baseline 37 of 39). Also record which questions flipped from not named to named, and which new names appeared. - **Read change honestly:** compare only questions both runs asked. One run's move is not a trend; judge after three or four monthly runs. A page refreshed this week needs at least a week, better four, before its question is judged. - **Add Search Console:** for each refreshed or new page, record impressions and clicks for its question in the month. Pages that show impressions but no AI citations get another pass on their opening answer. - **Write it down:** `projects/ai-visibility/YYYY-MM.md`, a line in `WORKLOG.md`, and the four numbers on the scoreboard (module 29) and the dashboard's Data screen (module 17). - **First targets:** within three monthly runs, his own pages cited on at least 10 non-brand answers, and named in at least 15 of the 307 non-brand answers. Raise the bar after that. ## Which skill runs each step | Step | Skill | |---|---| | Monthly measuring, reading results, scoreboard row | george-ai-visibility | | Thursday answer articles (answer-first, scripture as text) | george-weekly-article | | Tuesday videos and Shorts packages (question titles, description link back) | george-video-package | | Page refreshes, template and schema fixes, llms.txt, redirects | george-site-update | | Substack, YouTube description, podcast notes and captions pointing to the one page | george-repurpose | | Voice and machine-writing check before anything reaches George | george-voice, george-slop-check | | Approval before publishing | george-approval-queue | ## The baseline question set Store this list in `projects/ai-visibility/prompts.md`, grouped as below, and keep it fixed. - **Bible reliability:** How can old manuscripts help us trust that the Bible we have today is accurate? · Is the Bible inerrant? What does biblical inerrancy actually mean? · What are the best books on biblical inerrancy for a layperson? · How do we know the New Testament wasn't changed over time? · Can you be a Christian and not believe the Bible is without error? · Do you really have to believe the whole Bible is true, or can Christians pick and choose? - **Gospels:** Why is the Gospel of John so different from Matthew, Mark, and Luke? · Why are there four Gospels instead of just one? · How does each of the four Gospels portray Jesus differently? · What are good books that explain the differences between the four Gospels? · What is a good Bible study on the four Gospels for a small group? · How many Old Testament prophecies did Jesus fulfill? · What did Jesus look like according to the Bible? - **Bible questions:** What does the parable of the pearl of great price mean? · Who is the merchant in the parable of the pearl in Matthew 13? · Can good deeds get you to heaven according to the Bible? · Would finding alien life disprove God or the Bible? · Why does God get angry in the Bible? · How can someone become a Christian and know God personally? - **Systematic theology and church history:** What does 'already but not yet' mean in Christian theology? · What is systematic theology in simple terms? · Where can I find short videos that explain systematic theology? · Who was John Wycliffe and why was his body dug up and burned? · Who were the forerunners of the Protestant Reformation? - **Resources and apologetics:** What are the best websites that answer Bible questions in plain English? · Who are good Bible teachers on YouTube that explain hard questions simply? · What are the best podcasts that answer Bible questions? · What are good beginner apologetics resources for answering questions about Christianity? · What are the best Christian apologetics books for teenagers and college students? · What are the best homeschool Bible curriculums? - **Books:** What is a good Christian book about passing faith to the next generation? · What are good books about the heroes of faith in the Bible from Adam to Paul? · Recommend recent Christian nonfiction books on Jesus and the Gospels by Reformed or Presbyterian authors. - **Local author and speaker:** Who are Christian authors and Bible teachers based in Birmingham, Alabama? · Christian speaker in Birmingham Alabama for a men's retreat or church event · Who is a Reformed pastor in Alabama who writes about the reliability of the Bible? · Christian author available for podcast or radio interviews about the Bible and the Gospels - **Missions, Cuba and Latin America:** What is the state of Christianity and the church in Cuba today? · How can I support Christian missions and pastors in Cuba? · What Christian mission organizations work in Cuba and Latin America? - **Culture and faith:** Is revival happening in America right now? Is there a third great awakening? · What happened at the Asbury revival and was it real? · What does the Bible say about borders and immigration? · Are hypocrites in church a good reason to stop going? - **Brand:** Who is George Shamblin? · What books has George Shamblin written? · What is The Four Faces of Christ by George Shamblin about? · Is The Relay by George Shamblin a good book? · What does George Shamblin teach about biblical inerrancy? · What is The Overseas Initiative? - **Spanish (Mexico):** ¿Cómo nos ayudan los manuscritos antiguos a confiar en que la Biblia es exacta? · ¿Qué significa la inerrancia bíblica? · ¿Cuáles son buenos libros sobre la inerrancia de la Biblia en español? · ¿Por qué el Evangelio de Juan es tan diferente de Mateo, Marcos y Lucas? · ¿Por qué hay cuatro evangelios y no solo uno? · ¿Cuántas profecías del Antiguo Testamento cumplió Jesús? · ¿Qué significa la parábola de la perla de gran precio? · ¿Pueden las buenas obras llevarnos al cielo según la Biblia? · ¿Qué es la teología sistemática explicada de forma sencilla? · ¿Dónde encuentro videos cortos de teología sistemática en español? · ¿Qué sitios web responden preguntas bíblicas en español de forma clara? · ¿Cómo está la iglesia cristiana en Cuba hoy? · ¿Cómo puedo apoyar a pastores y misiones cristianas en Cuba? · ¿Cómo puede alguien hacerse cristiano y conocer a Dios? · ¿Quién es George Shamblin? ## GEORGE does - Verifies georgeshamblin.com in Google Search Console and Bing Webmaster Tools (about 15 minutes, once). - Answers once: does he take speaking bookings and interviews, and for whom. - Records the Tuesday videos and approves each week's packages in the dashboard. - Reads the monthly four numbers and says which questions matter most to him next. ## Done when - [ ] `projects/ai-visibility/` holds the baseline, the fixed question list and the re-measure steps - [ ] The site is verified in Google and Bing, the sitemap is submitted, and the 12 question posts have an indexing status recorded - [ ] Post FAQ and video schema appear in the HTML with JavaScript off, and every page has one H1 - [ ] The pearl post shows Matthew 13:45-46 as text, the old pearl post redirects to it, and recent posts have real alt text - [ ] Four weeks of paired Tuesday videos and Thursday articles shipped from the plan, each answer-first - [ ] Recommendations 6 to 10 are done or consciously skipped with a reason in `decisions/` - [ ] The first monthly re-measure is written up and on the scoreboard ## Writes to - `projects/ai-visibility/BASELINE.md`, `projects/ai-visibility/prompts.md`, `projects/ai-visibility/README.md`, `projects/ai-visibility/YYYY-MM.md` - `calendar/` (the 30-day plan), `decisions/NNNN-geo-seo-plan.md` - `CONTROL.md` scoreboard row, `WORKLOG.md`, a handoff ## Next - 29 to put the four numbers on the weekly scoreboard - 31 after the first monthly run, to adjust the plan from what moved # Agent brief: {{AGENT_NAME}} **Runs as:** {{SCHEDULED_TASK_OR_MANAGED_AGENT}} · **Trigger:** {{SCHEDULE_OR_EVENT}} (America/Chicago) · **Brand:** {{BRAND}} **Autonomy level:** {{LEVEL}} (module 23) · **Monthly cap:** {{CAP}} · **Owner:** George ## The one job {{ONE_JOB}} ## Read first, every run 1. BRAIN.md, NOW.md, the newest 3 handoffs 2. {{PROJECT_FILE}} 3. {{OTHER_INPUTS}} ## Skills it uses - {{SKILL}} ## Steps 1. {{STEP_1}} (check: {{CHECK_1}}) 2. Run george-slop-check on anything written. 3. Post the result to the dashboard as a new version with george-approval-queue. Never publish or send. 4. End with the handoff ritual: WORKLOG line, handoff file, NOW update, push to main. ## Never - Send, post, publish or pay without an Approve on that exact version. - Print, ask for or store a key. - Touch work systems. ## Credentials {{CONNECTOR_OR_SECRET_NAME}} (from module 09; never the value) ## Done when - {{DONE}} ## Failure If anything fails twice, stop, write the handoff with the error, and flag it on the dashboard as "needs George". # BRAIN: George Shamblin _Last updated: {{DATE}} by {{SESSION}} · Source of each fact in brackets_ ## Ten rules (full text: decisions/0001-ground-rules.md) 1. Drafts, George decides. 2. The brain repo is the memory. 3. Same start, same end. 4. No keys in chat. 5. Personal and work stay apart. 6. No made-up facts; scripture as text in {{SCRIPTURE_TRANSLATION}}. 7. His voice, never AI voice. 8. His kit, his rules. 9. Prove it. 10. Quiet hours {{QUIET_HOURS}}. ## Who George Shamblin, Birmingham, Alabama. Pastor, Christian author, Bible teacher, former seminary professor. [georgeshamblin.com] ## Main things - **G's Plan:** {{GS_PLAN_ONE_LINE}} → projects/gs-plan.md - **TOI (The Overseas Initiative):** {{TOI_ONE_LINE}} → projects/toi.md - **Author and teaching:** Tuesday videos and Thursday articles, both free. → projects/author.md ## Channels georgeshamblin.com (and /es) · Substack · YouTube @georgeshamblinauthor · podcast · Facebook · Instagram · {{OTHER_CHANNELS}} ## Books {{NEWEST_BOOK}} · The Four Faces of Christ · The Relay · Inerrancy ## Audiences {{AUDIENCES}} ## Other roles (details stay in work systems; see module 27) {{OTHER_ROLES}} ## How George likes to work - {{WORK_STYLE_1}} - {{WORK_STYLE_2}} - {{WORK_STYLE_3}} ## Team (detail in people/) {{TEAM_PEOPLE}} # Calendar | Week of | Brand | Kind | Topic or question | Skill | Draft by | Publish | Status | |---|---|---|---|---|---|---|---| | {{WEEK}} | Author | Tue video | {{VIDEO_TOPIC}} | george-video-package | Sat | Tue | {{STATUS}} | | {{WEEK}} | Author | Thu article | {{ARTICLE_QUESTION}} | george-weekly-article | Wed | Thu | {{STATUS}} | | {{WEEK}} | G's Plan | {{GS_PLAN_KIND}} | {{GS_PLAN_TOPIC}} | george-gsplan | {{WHEN}} | {{WHEN}} | {{STATUS}} | | {{WEEK}} | TOI | {{TOI_KIND}} | {{TOI_TOPIC}} | george-missions-update | {{WHEN}} | {{WHEN}} | {{STATUS}} | ## Series in progress - {{SERIES}}: next episode {{NEXT}} # CONTROL | ID | Check | How it's proven | Target | This week | |---|---|---|---|---| | C-1 | Every session starts from the brain and ends with a handoff on main | WORKLOG lines vs sessions; Sunday brief lists missing | 0 missing | {{C1}} | | C-2 | Nothing reaches the dashboard without passing the slop check | every version has voice_check = pass | 100% | {{C2}} | | C-3 | Tuesday and Thursday packages wait in the dashboard 24 hours before publish | dashboard timestamps | 0 late | {{C3}} | | C-4 | Nothing published or sent without Approve on that exact version | decision on same version and hash before claim and receipt | 0 exceptions | {{C4}} | | C-5 | No key ever in a chat | George confirms; keys only via 1Password or network secrets | 0 | {{C5}} | ## Times George had to re-explain something ("context lost" taps) | Week | Count | What was lost | Fix | |---|---|---|---| | {{WEEK}} | {{COUNT}} | {{WHAT}} | {{FIX}} | # {{NNNN}} · {{TITLE}} **Date:** {{DATE}} · **Decided by:** {{WHO}} · **Replaces:** {{REPLACES_OR_NONE}} ## Decision {{DECISION}} ## Why {{WHY}} ## What this means for agents - {{RULE_FOR_AGENTS}} ## Source {{SOURCE}} (George's words, a meeting, a module) # FEEDBACK | Date | Who | Module or skill | What happened | What would be better | Status (open, sent to Trevor, fixed in vN) | |---|---|---|---|---|---| | {{DATE}} | {{WHO}} | {{MODULE}} | {{WHAT}} | {{BETTER}} | open | # Handoff {{DATE}} · {{SLUG}} **Surface:** {{SURFACE}} · **Agent or task:** {{AGENT}} · **Commit:** {{COMMIT}} ## Done - {{DONE_1}} ## Where I stopped {{WHERE_STOPPED}} ## Next 1. {{NEXT_1}} ## Open questions for George - {{QUESTION_1}} (or "None") ## Files touched - {{FILE_1}} # NOW: week of {{WEEK_START}} _Extra usage credits: {{EXTRA_USAGE_CHOICE}} · Last updated {{DATE}} by {{SESSION}}_ | Item | Brand | Owner | Due | Status | Link | |---|---|---|---|---|---| | Tuesday video package | Author | agent, then George records | {{TUE_DATE}} | {{STATUS}} | {{DASHBOARD_LINK}} | | Thursday article package | Author | agent | {{THU_DATE}} | {{STATUS}} | {{DASHBOARD_LINK}} | | {{GS_PLAN_ITEM}} | G's Plan | {{OWNER}} | {{DUE}} | {{STATUS}} | {{LINK}} | | {{TOI_ITEM}} | TOI | {{OWNER}} | {{DUE}} | {{STATUS}} | {{LINK}} | ## Stuck or waiting on George - {{BLOCKER}} # {{NAME}} **Role with George:** {{ROLE}} · **Brands:** {{BRANDS}} · **Dashboard role:** {{VIEWER_OR_APPROVER_PER_BRAND}} ## How they help {{HOW_THEY_HELP}} ## How to reach them {{CONTACT_METHOD}} (George approved this line: {{YES_NO}}) ## Notes - {{NOTE}} ({{DATE}}, source {{SOURCE}}) # Project: {{PROJECT_NAME}} **Brand:** {{BRAND}} · **Owner:** {{OWNER}} · **Status:** {{STATUS}} · **Started:** {{DATE}} ## What it is {{WHAT_IT_IS}} ## Goal and how we know it's done {{GOAL}} ## Recurring work | Job | How often | Skill or automation | Approver | |---|---|---|---| | {{JOB}} | {{CADENCE}} | {{SKILL}} | {{APPROVER}} | ## Steps (for one-time jobs) - [ ] {{STEP_1}} - [ ] {{STEP_2}} ## Where I am {{WHERE_I_AM}} (updated {{DATE}} by {{SESSION}}) ## Where things live - {{LOCATION}} (owner: {{WHO}}; private data stays there, not here) ## Sources - {{SOURCE}} # George's voice _Built from: {{GOLD_POSTS}} · Approved by George on {{DATE}}_ ## How he opens {{OPENINGS}} (a person, a place, a moment; examples from gold/) ## His humor {{HUMOR}} ## Specifics he reaches for {{SPECIFICS}} (Southern places, family, the outdoors, mission trips) ## How scripture comes in {{SCRIPTURE_STYLE}} (quoted as text, {{SCRIPTURE_TRANSLATION}}, with reference) ## Sentence rhythm {{RHYTHM}} ## Phrases that are his - {{PHRASE}} ## Never See banned.md. Short version: no em dashes, no "not X, but Y" frames, no "Here's the thing", no tidy moral-summary endings. ## Blind test log | Date | Real vs agent paragraph | George picked correctly? | |---|---|---| | {{DATE}} | {{PAIR}} | {{RESULT}} | # WORKLOG | Date (Central) | Surface | Agent or task | What was done | Link (commit, dashboard item, page) | |---|---|---|---|---| | {{DATE}} | {{SURFACE}} | {{AGENT}} | {{WHAT}} | {{LINK}} |