AI and You

The ai@yoonet account is Yoonet's shared Claude workspace. It is where projects, knowledge, prompts, and institutional memory accumulate. Treat it like a shared Google Drive for thinking. It is not your personal Claude. Five rules of etiquette apply.

One, name every chat clearly. Prefix with your initials and the client code, for example YU-MFC hero copy draft 20 Apr. Nobody should have to open a chat to know whose it is. Two, do your work inside a Project, never in a loose chat at the root. Projects keep knowledge and instructions attached to the right client. Three, before you edit a Project's instructions or knowledge, flag it in the team Slack channel. Shared edits without notice are how good context rots. Four, when a chat produces something useful, promote it into Project knowledge so the next person benefits. Five, archive finished chats so the workspace stays tidy.

If you ever genuinely need a Max-level personal account for deep work, ask Em. But 95% of your work happens in the shared account so your outputs compound with everyone else's.

This is the Yoonet default. Nicole, Gaia, Cassey, and Em are expensive to interrupt. Claude is not. Asking Claude first also forces you to frame the question clearly, which improves the answer you would eventually get from a human anyway.

The test for whether Claude can help you is simple. Could Claude possibly know this from publicly available sources, or from documents that live in our Project knowledge? If yes, ask Claude. If the answer depends on internal context Claude cannot know — what Nicole told the client last Tuesday, who signs off on invoices, which vendor we actually use for stock photography — ask a human.

There are four categories where humans beat Claude every time. Internal or proprietary information about Yoonet or a specific client. Anything dependent on last week's decisions or conversations. Interpersonal or political judgement (how to raise something awkwardly with Gav, how Gaia will react to a creative call). And high stakes decisions where someone needs to be accountable.

When you do escalate to a human, bring five things. The specific question in one sentence. What you tried with Claude and what it said. The context Claude could not access. A proposed answer or two options. And what kind of help you need — a decision, a sanity check, or a full handover. This turns "got a sec?" into a two minute useful conversation, and it is the single biggest marker of a senior operator.

Anthropic's own framing is useful: treat Claude like a brilliant but brand new employee with amnesia. Clear instructions beat clever ones every time.

A weak prompt says "write something about Masterton Foot Clinic's new services." A strong prompt says: "You are drafting three service descriptions for Masterton Foot Clinic's website. Audience is patients in the Wairarapa aged 40+, warm but professional tone, plain English, UK spellings. Each description is 120 words, starts with a concrete outcome (not a feature), mentions who the service suits, and ends with a soft call to book. Services are Lunula laser for fungal nails, shockwave therapy, and EXO-bracing. Avoid the words 'revolutionary', 'cutting edge', or 'solution'. Here is the existing services page as a style reference (pasted below)."

Six habits make prompts ten times better.

Be specific about the output. Word count, format, tone, audience, channel. Tell Claude what good looks like.

Give context and motivation. Not "format as JSON" but "format as JSON because it will be parsed by our sitemap generator." Claude generalises better when it knows why.

Show, don't just tell. Paste two or three examples of the style or structure you want, wrapped in <example> tags. Three to five examples beats three paragraphs of description.

Ask for reasoning on hard tasks. Add "think step by step before answering" or wrap the response in <thinking> and <answer> tags. This genuinely improves logic-heavy work like competitor analysis or taxonomy design.

Use constraints. Banned words, hard limits, must-include elements. Constraints sharpen output.

Tell Claude what to do, not what not to do. "Write in flowing prose" beats "don't use bullet points."

One more thing worth learning early: XML tags. Claude was trained to pay extra attention to content wrapped in tags. Instead of pasting a brief as raw text, wrap it in <brief>…</brief>. Reference it in your instruction: "Using the brief in <brief> tags, produce…". For multiple documents, give each its own tag. Anthropic's own tests show queries placed at the end of long document prompts improve quality by up to 30% — so put the document first, then your ask.

Three small additions will cut hallucinations hard. Tell Claude it is allowed to say "I don't know" rather than guess. For fact work, ask it to quote verbatim from source documents before drawing conclusions. And ask for a supporting quote or source behind every factual claim — if it cannot find one, retract it.

A Project is a workspace that bundles three things together: a knowledge base (reference files everyone in the project shares), custom instructions (a pre-prompt that applies to every chat in the project), and the project's chat history. This is how we get Claude to remember Yoonet's way of doing things without you pasting context every time.

Our convention for project names is [CLIENT CODE] – [Workstream]. So Masterton Foot Clinic SEO work lives in MFC – SEO. Brand work lives in MFC – Brand. Internal work uses YNT – [Workstream]. Keep one Project per client workstream, not one giant project per client — knowledge collisions are real. If the tone and audience differ, the project differs.

What goes in Project knowledge: brand guidelines, tone of voice docs, the services taxonomy, the client's existing copy, competitor reference, SEO research, the brief you wrote, style guidance, a glossary of client-specific terms. What stays out: anything confidential we don't need Claude to see, anything that changes weekly (Claude will not auto-refresh — you have to re-upload), and anything contradictory (if your brand guide and services doc disagree, fix the source first).

A pattern worth learning: Project knowledge compounds. When Claude produces something genuinely useful in a chat — a taxonomy, a style ruling, a well-written service description — promote it into the knowledge base with one click. Over six months, a project becomes institutional memory that makes every new chat faster and better.

Start a new Project when the topic, client, or tone is meaningfully different. Continue an existing Project when the knowledge is additive. If you find yourself writing "ignore the previous knowledge about X" into your prompts, that is the signal to split.

Claude Code is the terminal tool Em's team uses to actually build sites. You will use it too, not for writing code, but for content and SEO work on real live repositories.

The quickest way to understand Claude Code is to contrast it with claude.ai. On claude.ai, you chat with Claude about files you upload. In Claude Code, Claude is an agent that sits in your project folder on your machine, reads files directly, edits them, runs commands, commits to git, and opens pull requests — with your approval at each step. It is the difference between talking about a kitchen and standing in one.

Starting a session is three lines:

cd ~/projects/mfc-site
git pull
claude

That opens the Claude Code REPL in the project. It automatically reads the CLAUDE.md file at the root, which acts as the project's standing orders for Claude. Think of CLAUDE.md as the onboarding note you would give a contractor: what the site is, where content lives, what conventions to follow, what never to touch. Em will have already written one for each client repo.

A typical Yura session looks like this: you open Claude Code in a repo, describe a task in plain English ("update the services page to add three new descriptions and their SEO metadata"), review the plan Claude proposes, approve each file edit, run pnpm build to confirm nothing is broken, commit on a feature branch, push, and open a pull request. You never edit production directly. A webbie or another teammate reviews the Vercel preview URL, approves, and merges.

Useful in-session commands to memorise: /context shows how full the context window is. /compact summarises and frees up space when it gets full. /clear wipes and starts fresh. /permissions shows what Claude is allowed to do. /cost shows tokens used so far. Exit with /exit or Ctrl+D.

You do not need to understand every line of code Claude produces. You do need to understand what files it is changing and whether those files are on the safe list (see Part 4 below).

Claude hallucinates. It makes up citations that look real, invents statistics with confident specificity, and occasionally fabricates quotes. Three signals to watch for: very specific numbers or dates that did not come from a source you gave it; citations or URLs you should verify by clicking; and "facts" about recent events past its training cutoff.

When you catch a hallucination, don't argue with the output — redo the prompt. Attach the real source, tell Claude to use only that source, and allow it to say it doesn't know. For anything going to a client, cross-check specifics against a primary source or ask a human.

Claude also gets stuck. Signals: it re-suggests approaches you already rejected; it contradicts its earlier recommendations; it keeps asking "shall I proceed?" instead of doing the work; it gives generic answers where it was previously sharp. When this happens, three moves in order. First, state the problem explicitly ("you've suggested X three times; I've rejected it because Y; propose something that respects Y"). Second, summarise the state of play in three bullets and ask for the next step. Third, if both fail, start a fresh chat with a clean brief and just the essentials. A long broken chat is almost always slower than a fresh start.

Start a fresh chat when the task has shifted meaningfully, when context feels over-stuffed (Claude starts forgetting things you told it earlier), when the UI warns you about context limits, or when Claude is repeatedly getting wrong things it previously got right. Before you close any chat that produced something worth keeping, ask Claude to summarise the decisions and outputs, and paste that summary into Project knowledge.

Escalate to a human when the stakes are high, when you have tried two distinct approaches and neither worked, when the task needs relationship or political judgement, or when accountability matters. Claude is a thinking partner, not a decision maker.

Nicole owns the client from first contact through to a signed engagement. Your entry point is the handover meeting that happens after sign off, usually within two working days of the deal closing.

At handover you receive: the signed scope document, the engagement letter (run through Ignition), any emails or notes Nicole thinks are relevant, a brief mental model of the client's expectations, and a warm introduction to whoever your main client contact will be. What you need to draw out, because Nicole will not always volunteer it: the unspoken promises made during sales, the client's pet peeves, who holds the chequebook versus who signs off on creative, and anything Nicole is worried about.

Your output from this stage is a handover note in the client's Obsidian vault as 00-handover.md, covering: who the client is, what they bought, what timeline they expect, what Nicole promised, who the stakeholders are, and what you don't yet know. Write it the same day.

For Masterton Foot Clinic: Nicole closed them on a rebuild of mastertonfootclinic.co.nz (currently built by SunRoom Web Design). Adam Philps is the senior podiatrist and co-owner, Ali Philps handles finance and ops. The sale covered a full rebuild with expanded service pages, proper SEO, and a clean funding pathways section (ACC, Southern Cross, WINZ, Zip). Nicole hinted Adam cares most about representing the clinical depth — shockwave, Lunula laser, EXO-bracing, his CMT research — without sounding salesy. Ali cares about the booking flow actually working.

Your first real act of value. The goal is to arrive at the research phase with every input the project will ever need, in one organised place, with nothing left to chase.

Create the client folder in the Obsidian vault using the standard structure: 00-handover/, 01-intake/, 02-research/, 03-briefs/, 04-taxonomy/, 05-seo/, 06-assets/, 07-ops/. Every folder contains an _index.md that lists what lives inside and its current state.

Send the client a single intake email with one attachment: the Yoonet Intake Checklist (covered in the asset gathering section of Part 3). Do not ping them five times over two weeks for different items. One ask, one follow up three working days later, one escalation to Nicole if still stuck. Keep the relationship efficient.

Your outputs: a populated 01-intake/ folder with logos, brand kit, existing copy, photos, platform access credentials (stored in 1Password, not in Obsidian), analytics access, Google Business Profile access, domain and DNS details passed to Em. And an intake-status.md tracking what arrived, what is outstanding, and what Ben or Em need to know.

For Masterton: you need the logo suite (SVG and PNG, light and dark), typography if any, the current site's copy export, clinical photography rights confirmation with AT Photography and Peter Laurenson, access to Google Business Profile and Google Analytics, Cliniko or Nookal booking widget embed details, the ACC provider number, Southern Cross Easy Claim details, and the funding partner logos (ACC, Southern Cross, WINZ, Zip).

This is where Claude earns its keep. You run research across four axes: industry, competitors, compliance, SEO.

Create a new Claude Project: MFC – Research. Upload the handover note and intake outputs as Project knowledge. Set custom instructions: "You are researching for a website rebuild of Masterton Foot Clinic, a Wairarapa podiatry clinic. Outputs must be in UK English, use plain language, cite sources, and avoid invention. If uncertain, say so."

Then run four structured chats, one per axis:

Industry research. Podiatry in New Zealand: scope of practice, common conditions, emerging therapies (Lunula, shockwave, EXO-bracing, foot mobilisation), the ACC system and how podiatrists operate inside it, how clinics differentiate.

Competitor analysis. Search "podiatrist Masterton", "podiatrist Wairarapa", "podiatrist Wellington" and review the top ten results for positioning, service range, pricing transparency, SEO strength, tone. Produce a matrix of competitor strengths and gaps MFC can exploit.

Compliance context. Podiatrists in NZ are registered through the Podiatrists Board of New Zealand under the HPCA Act 2003. The NZ Privacy Act 2020 governs patient data, with mandatory breach notification to the Privacy Commissioner. ACC has specific advertising rules around funded treatments. Relevant to note: AU clients would hit AHPRA and OAIC here instead, and AHPRA's advertising rules are stricter (no testimonials on clinical outcomes).

SEO research. Keyword landscape for local podiatry, search volumes, competitor ranking, local SEO essentials (NAP consistency — Name, Address, Phone — across Google Business Profile, Healthpoint, Facebook, the website). Core Web Vitals benchmarks for competitors. Structured data opportunities (LocalBusiness, Physician, FAQ, MedicalProcedure schemas).

Each chat produces a dense synthesis. You then convert that into an MD file (next stage).

The MD files are the artefact the rest of the lifecycle depends on. They become Project knowledge for the build phase, and they are what Claude Code reads when it builds or edits the site. If the MD files are vague, everything downstream is vague.

For MFC you produce at minimum:

03-briefs/creative-brief.md — the one page brief (Part 3 covers the template).

04-taxonomy/services-taxonomy.md — the tree of services, sub services, and associated copy slots, with URL slugs. For Masterton: /services/general-podiatry, /services/orthotics, /services/minor-surgery, /services/fungal-nails-lunula, /services/shockwave-therapy, /services/foot-mobilisation, /services/exo-bracing, /services/sports-podiatry, /services/childrens-podiatry, /services/neurological-conditions. Plus the sub brand page /wairarapa-ingrown-nail-clinic.

04-taxonomy/page-inventory.md — every page the site will have with its purpose, primary keyword, secondary keywords, target word count, and what assets it needs.

05-seo/seo-research.md — the keyword landscape, primary and secondary keywords per page, meta title and meta description drafts, structured data plan.

05-seo/local-seo-audit.md — current NAP consistency across the web, Google Business Profile audit, citation gaps.

03-briefs/content-brief-[page].md — one per major page, specifying tone, audience, what to cover, what to avoid, word count, examples.

Every MD file uses frontmatter at the top:

---
title: MFC Services Taxonomy
client: masterton-foot-clinic
status: draft
owner: yura
last-reviewed: 2026-04-20
related: [creative-brief](/w/creative-brief), [seo-research](/w/seo-research)
---

Frontmatter is how Claude Code, Obsidian, and any downstream tool knows what the file is. The wiki links in related: create the connective tissue across the vault — click through in Obsidian and you move along the knowledge graph.

The honest test of your MD files: could Gaia, Cassey, or Em walk into this project cold, read these files in order, and know exactly what to build, in what tone, for whom, ranking for what, with what assets? If yes, you have done the job. If no, keep tightening.

Once the MD files are signed off (by you, then Gaia on brand, then Em on technical feasibility), the project crosses into Claude Code. Em or Ralph usually kicks this off by creating the repo and initial CLAUDE.md.

Your involvement at this stage is to be the context provider. You copy the relevant MD files — creative brief, services taxonomy, page inventory, SEO research — into the repo's /content/briefs/ folder so Claude Code can read them when building. You ensure the CLAUDE.md references them. You answer questions from whoever is building about anything ambiguous in the briefs.

For content heavy pages (services, about, team bios), you can start drafting the actual page content in Claude Code yourself using the briefs as source material. This is where you begin to own the content surface directly rather than handing it to a webbie.

During build, the webbies (Cassey for hybrid creative/tech work, Em and her team for pure engineering) do the structural and interactive work. You hold three lanes: content production, SEO implementation checks, and asset management.

What is visible to you: the GitHub repo (read access at minimum), the list of open pull requests, the Vercel preview URL for the in progress build, and the current content files. What is not directly visible and that is fine: database schema decisions, auth implementation, deployment configuration, component internals.

Track progress in 07-ops/build-tracker.md — a simple table of pages, their status (brief / in build / in review / done), and who owns the next action. Update it weekly. This becomes the core of your upward summary to Gaia and of your status to Ben and Nicole.

Review every Vercel preview URL as pages come online. Your checks: does the copy match the brief, are meta titles and descriptions in place, do internal links go where they should, is structured data present (check with Google's Rich Results Test by pasting the preview URL in), does the page render correctly on mobile, are images compressed and alt-tagged.

You do not need to be able to explain merge conflicts. You do need to understand the pipeline so you can operate inside it with confidence.

A repo is the project's code folder on GitHub. A branch is a parallel copy of the repo where changes happen without touching the live version. main is the production branch — the site you see when you visit the real URL. A commit is a snapshot of a change. A pull request (PR) is a proposal to merge a branch into main, and it is where review happens. A merge is the acceptance. Once merged to main, Vercel builds the site and deploys it to the live domain.

The critical feature for you is the preview deployment. Every branch and every PR gets its own unique URL automatically (something like mfc-site-git-content-new-services.vercel.app). Nothing you do on a branch touches the live site until merge. This is what makes it safe for you to work in the repo.

If production ever breaks, Vercel's Instant Rollback button reverts the live site to the previous version in seconds. You then open a PR to revert the broken change in code, so the repo and the live site stay in sync. This is the safety net Em relies on, and it is what makes direct editing in Claude Code viable for you.

Launch is coordinated by Em and Nicole but you drive the content side. Your launch checklist:

Pre launch (the week before): final copy QA, all meta titles and descriptions populated, structured data validated, sitemap generated, robots.txt configured, 301 redirects from old URLs mapped, Google Search Console verified, Google Analytics or our preferred analytics installed, Google Business Profile aligned to new site (NAP, categories, hours), social previews checked (paste URLs into LinkedIn Post Inspector and Facebook Sharing Debugger).

Launch day: Em switches DNS, you check the live site against the preview, submit the sitemap to Google Search Console, trigger a re-crawl, notify the client.

Post launch first week: monitor Google Search Console for crawl errors, check Core Web Vitals, watch for 404s in analytics, fix any small copy issues directly via Claude Code.

This is the stage Ben is clearest about: you own this, not the webbies.

Post launch work includes ongoing SEO (new service pages, keyword expansion, meta refreshes, internal linking improvements), content additions (blog posts, team bios, news items), small copy tweaks, image swaps, schema additions, and local SEO hygiene. All of this runs through Claude Code on the live repo, following the safety rails in Part 4.

The next generation in your role does not file tickets with Em for "can you change the hero headline on the services page." She opens Claude Code, creates a branch, makes the edit, pushes, opens a PR, checks the Vercel preview, gets a second pair of eyes, merges. Twenty minutes start to finish. That is the autonomy we are building.

Every inbound request resolves to exactly one of five outcomes: handle it yourself, send it back for more information, redirect or delegate, defer to a scheduled slot, or escalate to Gaia. The worst outcome is a sixth — letting it sit.

Apply the logic in order. First, is the request clean? Specific, single issue, identified requester? If not, send back with the intake template (below). Second, classify using the Eisenhower lens. Urgent and important might be yours or Gaia's; important but not urgent usually goes into a scheduled queue (this is where strategic brand work lives — protect it fiercely); urgent but not important you handle fast and cheap; neither you politely decline and log the pattern. Third, apply RACI thinking: is Gaia accountable for this decision, or merely consulted, or only informed? Only escalate when she is accountable or her input materially changes the work. "Informed" items belong in the weekly summary.

Hard escalation triggers — escalate if any of these are true, don't try to absorb them: budget or scope change beyond the pre-agreed threshold, a brand critical taste call, a stakeholder above a seniority line (client principal, press, exec), cross functional conflict between you and Cassey that you cannot resolve in one exchange, reputational or legal risk, or anything that would embarrass Gaia if she heard about it second hand. That last one is the single most important rule: no surprises.

The intake template you use when sending requests back:

Requester:
Deliverable:
Why now:
Decision needed or FYI:
Deadline (hard/soft):
Budget/scope:
Success criteria:
Assets attached (Y/N):

Any blank field is an automatic "send back." This feels blunt at first. It is a kindness. It saves everyone time.

Gaia should receive decisions to make, not problems to unpack. A polished input is a brief that is tight, assets that are present, options that have been pre-thought, and an ask that is explicit.

The Yoonet creative brief is one A4 page, always. Twelve sections: project title and one line description, business objective, audience (demographics plus pain points), key message, tone of voice and brand guidelines reference, deliverables list with formats and dimensions, mandatories (legal, logos, disclaimers, accessibility), success metrics, timeline with milestones, budget envelope, stakeholders with a one line RACI, and references plus anti-references ("not this"). If the brief cannot fit on one page, the thinking is not tight enough.

Re-brief discipline is the most underused habit in agency work. After intake, write the brief back in your own words and send it to the requester to confirm before work begins. It catches 80% of misunderstandings before they cost money.

Asset gathering follows a non-negotiable checklist: brand kit (logo suite in SVG and PNG, light and dark, typography, colour tokens, current guidelines PDF); copy (approved body, headlines, CTAs, microcopy, legal footer); imagery (licensed photography with rights documentation, alt text, source files, crop variants); technical inputs (sitemap, wireframes, component inventory, CMS access, analytics, domain and DNS, hosting credentials, staging URL); reference and inspiration; legal (model releases, music licences, trademark clearances); accessibility target (WCAG level, contrast, alt text list).

File organisation is not optional. Single source of truth, one location per client. Naming convention is YYYY-MM-DD_project_asset-type_version_status.ext — for example 2026-04-20_mfc-rebuild_keyvisual_v03_approved.psd. Archive working files; surface only approved assets to Gaia. Never send her the messy folder.

When you do escalate a decision, send Gaia a Gaia-ready packet: one line ask, context in three bullets or fewer, two or three options with trade offs, your recommendation, her deadline for a response, and what will happen if she does not respond by then. That last line — the default action if she does not respond — is what separates a junior gatekeeper from a senior one. Silence should never be a blocker.

Cadence matters more than volume. Daily async one-liner to Gaia, usually in Slack: today's focus, what's blocked, what you need from her (or "nothing"). Weekly written update on Friday (pick a day and hold it), roughly this shape:

THIS WEEK
  What shipped, what was decided, what was learned (3–5 bullets)
PRIORITIES
  This week's actuals; next week's plan
METRICS
  Same format every week, don't editorialise
DECISIONS NEEDED FROM YOU
  One line per item, options, recommendation, deadline
RISKS / WATCHING
  Anything that could become a problem in 2–4 weeks
FYIs
  Short — for awareness only
WAITING-FOR
  Who owes what, by when

Weekly 1:1 with Gaia for 20 to 30 minutes, used for judgement calls and relationship intel, never for status. Status belongs in the doc.

The "no surprises" principle is not just a nice idea. It is the single most cited rule in chief of staff literature. If Gaia hears about a problem from anyone other than you first, the system has failed. Flag early; give her context; propose next steps. Escalate with a recommendation, never empty handed.

Cassey is your peer, not your report. You do not give Cassey creative direction. You relay Gaia's direction, you surface constraints, you ask clarifying questions — but you do not judge Cassey's work.

Write the lane map down on day one and share it with both Cassey and Gaia:

Rules of engagement. Protect Cassey's maker time — batch questions, use one Slack thread per topic rather than seven pokes, a weekly sync beats ad hoc pings. Present a united front upward; disagreements are resolved in private, never in front of Gaia or clients. Credit generously; your power as a coordinator comes from making others look good. Do not be a second opinion Cassey did not ask for; if you have a craft view, offer it as a question ("have you thought about X?") or not at all. Own what Cassey hates owning — timelines, status, stakeholder comms, admin, asset wrangling, meeting notes. That is where your leverage lives.

You know the lane is working when Cassey volunteers information to you without being asked, when stakeholders stop pinging Cassey directly, and when Gaia stops asking "where are we on X" because she already knows.

Becoming a bottleneck. Signals: decisions stall waiting for you, team members chase you, your inbox is the queue. Prevent by publishing your decision rights (what you approve without Gaia), setting auto defaults ("if no reply in 48 hours, proceed"), and pushing recurring decisions downward into checklists others can self serve against.

Becoming a yes person. Signals: you have stopped disagreeing with Gaia, you are relaying not advising, Cassey feels unheard. Prevent by pre-committing to bring at least one dissenting view or uncomfortable fact into every weekly update. Your job is to hold Gaia accountable, not mirror her.

Over filtering. Signals: requesters complain they cannot reach Gaia, she is missing context she needed, she is surprised by things you filtered. Prevent by erring toward inclusion in weekly FYIs. Quarterly, ask Gaia directly: "what did you not hear about that you should have?" Keep a log of what you filter and why, and review patterns monthly.

Under escalating. Signals: problems surface late, you are solving things above your pay grade alone, Gaia asks "why didn't you tell me?" Prevent by treating the hard escalation triggers above as rules, not judgement calls. When in doubt, escalate once with explicit "FYI, not asking for action" framing.

Scope creep. Signals: projects grow between brief and delivery, "just one more thing" becomes the norm, Cassey is burning out, briefs bear little resemblance to final output. Prevent by treating the written brief as the contract. Changes go through a change request step: new scope, new timeline, new budget — pick two. Surface the scope delta as a line item in the weekly.

Losing your own identity. Signals: your calendar is 100% reactive, you have no time for your own development, you catch yourself copying Gaia's phrasing. Prevent by protecting two to three hours weekly for your own priorities, and maintaining a peer network outside Yoonet (other coordinators, other chiefs of staff). Your growth is your responsibility, not Gaia's.

Becoming Cassey's project manager. Signals: you are assigning Cassey tasks, Cassey resents you, Gaia treats you as Cassey's line manager. Prevent with language discipline: "here's what's come in, how do you want to handle it?" beats "please do X." Shared planning, not top down assignment.

If a file lives under public/, content/, src/content/, app/, pages/, or src/pages/, and does not import process.env, an auth library, or a database client, it is almost certainly in your lane.

Specifically you can: edit copy and text on marketing pages, change meta titles and meta descriptions, update Open Graph and Twitter card metadata, swap images and fix alt text, add new content pages (a new service page, a blog post, a team bio), adjust internal links, update robots.txt, add or tweak structured data (JSON-LD blocks for LocalBusiness, FAQ, MedicalBusiness), change the sitemap.xml configuration to exclude a path or adjust priorities, and make simple Tailwind class tweaks (spacing, typography, colour tokens) provided you visually confirm on the preview deployment.

Ask Claude to explain, never to edit, any of the following. Authentication flows (anything importing @clerk/*, sign in/up components, middleware gating routes, webhook handlers). Database schema (schema.prisma, Drizzle schema.ts, Supabase migrations, Neon SQL files). API routes and server actions (anything under app/api/**/route.ts, pages/api/**, or files with "use server"). Deployment config (vercel.json, next.config.js, astro.config.mjs). package.json, package-lock.json, pnpm-lock.yaml. Environment variables or .env files (ever — and never paste a key into a Claude chat). middleware.ts. Anything with secrets: Stripe keys, Clerk secret keys, Supabase service-role keys, webhook signing secrets.

If Claude Code proposes changes to any of these, stop and hand the PR (unmerged) to Em.

Each Yoonet client repo ships with a .claude/settings.json that restricts what Claude Code can do. It allows standard git operations and build commands. It denies reads on .env* files and writes on the dangerous list above. This is defence in depth, not a guarantee — so the other rails matter.

Each repo has a CLAUDE.md at the root with project specific rules: framework version, deployment branch, content locations, banned edits, commit conventions. Claude reads it every session. If you ever feel the rules are too restrictive, talk to Em before editing CLAUDE.md.

GitHub branch protection on main requires a PR with one approval and passing CI checks before merge. You cannot push directly to production by accident.

Vercel preview deployments generate a unique URL for every branch. You see changes before anyone else does, and the client and team can review before merge.

Vercel Instant Rollback reverts production in seconds if something breaks post merge. You then open a revert PR on GitHub to bring code and live site back in sync.

In GitHub's "Files changed" tab on any PR, green lines are additions, red lines are removals. For copy edits you should see text inside quotes or between tags changing, and nothing else. Red flags: changes to import statements at the top of files, new process.env.* references, edits to any file on the "do not touch" list, many files changing when you asked for one. If confused, ask Claude in the same session: "explain every file in this diff in plain English and flag anything risky."

Scenario: Gaia and Adam have agreed to add three new service pages — Lunula laser for fungal nails, shockwave therapy, and EXO-bracing — each with a 120 word description and full SEO metadata. The existing site is Next.js App Router on Vercel. The service brief MD files already live in 03-briefs/content-brief-lunula.md, content-brief-shockwave.md, content-brief-exo.md.

Step 0 — one time setup, which Em will have walked you through on day one: install Git, Node.js, pnpm, the GitHub CLI (gh), and Claude Code. Run gh auth login and claude once to authenticate.

Step 1 — clone and branch.

cd ~/projects
git clone https://github.com/yoonet/mfc-site.git
cd mfc-site
pnpm install
git checkout main
git pull
git checkout -b content/new-services-apr26

Checkpoint: git status shows "On branch content/new-services-apr26, nothing to commit."

Step 2 — open Claude Code in the repo.

claude

Claude reads the project's CLAUDE.md automatically. Run /permissions to confirm the deny rules are loaded. Copy your three brief MD files into /content/briefs/ so Claude can reference them.

Step 3 — prompt Claude precisely.

"Read app/services/page.tsx, the existing service sub pages under app/services/, and the three briefs in /content/briefs/ for Lunula laser, shockwave therapy, and EXO-bracing. Create three new service pages at app/services/lunula-fungal-nails/page.tsx, app/services/shockwave-therapy/page.tsx, and app/services/exo-bracing/page.tsx. Each page has a 120 word description drawn from the brief, a metadata export with title (≤60 chars), description (≤155 chars), and Open Graph tags. Match the tone and structure of existing service pages — UK English, warm, plain language, outcome led. Update app/services/page.tsx to link to the three new pages. Do NOT touch next.config.*, middleware.ts, anything under /api, or package.json. Show me the plan first; do not write files until I approve."

Claude proposes a plan. Review it. Approve. It will ask permission per file write. Answer yes, or "yes and don't ask again for Write(app/services/**)."

Step 4 — local build check.

pnpm build

Checkpoint: ✓ Compiled successfully. If it errors, paste the error to Claude: "fix the root cause, do not edit config files."

Optionally pnpm dev and open http://localhost:3000/services to eyeball.

Step 5 — commit and push. Ask Claude to drive:

"Stage the new and modified files, write a conventional commit message, and push the branch to origin."

Claude runs roughly:

git add app/services content/briefs
git commit -m "content: add Lunula, shockwave, EXO service pages with metadata"
git push -u origin content/new-services-apr26

Step 6 — open the PR.

"Open a PR to main using gh. In the body, list each new URL, each meta title and description, and confirm no config, auth, or API files were touched."

Claude runs gh pr create. You get a PR URL.

Step 7 — Vercel preview review. Within about a minute, the Vercel bot comments on the PR with a preview URL. Visit /services, /services/lunula-fungal-nails, /services/shockwave-therapy, /services/exo-bracing. Right click → View Page Source, search for <title> and og: to confirm metadata. Check mobile viewport in DevTools. Check the console for errors. Run Google's Rich Results Test on each URL if you added schema.

Step 8 — read the diff. PR → Files changed. You should see three new files under app/services/<slug>/, a modified app/services/page.tsx with three new <Link> entries, and three brief files in /content/briefs/. No other files should appear. If they do, ask Claude why or close the PR.

Step 9 — request review, get approval, merge. Request Cassey or another teammate as reviewer via GitHub. Once they approve and CI is green: Squash and merge. Vercel kicks off a production deployment automatically.

Step 10 — verify live and tidy. Wait for the Vercel dashboard's green tick on production (1 to 3 minutes). Visit the real domain and check each new URL. Submit the updated sitemap to Google Search Console. Delete the branch:

git checkout main && git pull && git branch -d content/new-services-apr26

If something breaks live. Vercel Dashboard → Deployments → last known good → ⋮ → Instant Rollback. Then on GitHub, open the merged PR → Revert → merge the revert PR. Code and live site are back in sync.