How to Set Up Your AI Coaching Workspace (So You Stop Re-Typing Everything)

You already use AI. That's not the problem.

The problem is that every time you open a new chat, you start from zero. You re-paste the client's history. You re-explain that you program in blocks, that you don't like machine-heavy templates, that your tone with this particular client is "direct but not harsh." You go hunting for that one prompt you wrote three weeks ago that produced a genuinely good deload — and you can't find it, so you rebuild it from memory and it comes out worse. Twenty minutes later you've got an output that's fine, and you've spent half that time feeding the model things it should already know.

Here's the thing: most coaches who feel like AI is "kind of useful but not worth the hassle" don't have an AI problem. They have a setup problem. They're driving a car they never adjusted the seat in. The model is capable. The workspace around it is a mess — no saved prompts, no client context the AI can reach, no record of what worked. So every session is a cold start.

This guide is about fixing that. Not prompt technique (we've covered prompt engineering for fitness coaches separately) — the organization around the prompts. Build this once and your AI stops being a clever stranger you re-introduce yourself to every morning, and starts being something that knows your clients, your methods, and your voice.

Why a Workspace Beats a Pile of Chats

A normal AI habit looks like this: open the app, type, get an answer, close it. The next time you need something, you open a fresh chat and do it again. Every conversation is an island. Nothing carries over except what you manually re-type.

That's fine for one-off questions. It falls apart the moment you're running a roster. Because coaching at scale isn't a series of unrelated questions — it's the same handful of tasks (program a block, write a check-in, adjust for a tweak, draft an intake summary) repeated across different clients, week after week. The context and the method stay constant. Only the client changes.

A workspace flips the default. Instead of supplying everything every time, you set up the constants once — your prompts, your client files, your method notes — so the only thing you bring to a given task is what's actually new that week. The work that used to take twenty minutes of re-explaining takes five minutes of "here's this week's check-in, you already know the rest."

Four pieces make up a coaching workspace:

1. A saved prompt library — your best prompts, organized so you can find them.
2. Client context files — one per client, so the AI knows who it's writing for.
3. A method/exercise database — your coaching preferences, so it stops inventing.
4. A naming and file convention — so all of the above is findable in under ten seconds.

None of this is technical. You're not building software. You're organizing documents and using a feature most AI tools already give you for free. Let's go piece by piece.

Pick a Home: ChatGPT Projects vs Claude Projects

Both ChatGPT and Claude offer a "Projects" feature — a container that holds a set of chats plus persistent instructions and attached files that every chat inside it can see. This is the single most useful feature for a coach and most coaches don't use it. It's the difference between a workspace and a pile of chats.

Here's the honest split, having used both for coaching work:

The practical takeaway: if you only set up one, either works. If you're doing a lot of long-context work — pasting multi-week logs, iterating on a 16-week build over many turns — Claude tends to hold the thread better. For fast, familiar, everyday drafting, ChatGPT is a safe default. We went deeper on the trade-offs in ChatGPT vs Claude for fitness coaches; for setup purposes, the point is just this: pick one, make a Project, and put your constants in it. Don't run your coaching out of scattered one-off chats anymore.

A reasonable structure is one Project per function, not per client:

• "Programming" — instructions describe how you periodize; attached files hold your method notes and exercise database.
• "Check-ins & Communication" — instructions describe your tone; attached files hold client context.
• "Intake & Onboarding" — instructions and templates for new-client synthesis.

Clients move through these Projects; you don't make a new Project for each one. The client-specific detail lives in the context files you paste or attach, which we'll build next.

Build Your Saved Prompt Library

This is the highest-payoff piece, and the one almost nobody does.

Right now your best prompts live in three places: your memory (lossy), your chat history (unsearchable in practice), and nowhere (most of them). The fix is a single document — a Google Doc, a Notion page, a plain text file, whatever you'll actually open — that holds your tested prompts, organized by task.

Structure it by coaching function, not by date:

PROGRAMMING
  - Macro block structure (new client)
  - Weekly session detail
  - Deload / recovery week
  - Exercise substitution
  - Mid-block adjustment after a tweak

CHECK-INS
  - Weekly check-in response (master template)
  - Hard-week reframe
  - Plateau conversation

INTAKE
  - Intake form → client summary
  - First-program brief from intake

NUTRITION
  - Starting macro targets (method-first)
  - Weekly adjustment from check-in data

Under each entry, paste the actual prompt — the full, working version with placeholders for the parts that change:

[DELOAD WEEK]
You are programming a deload for [client name], currently in week [X]
of a [goal] block. Their recent training: [paste last 2 weeks]. They've
flagged [fatigue / joint / sleep] this week. Write a 1-week deload that
reduces volume ~40% while keeping movement patterns and one top set per
main lift. My style: [your preferences]. Output as a table.

The rule that makes this library compound: when a prompt produces something genuinely good, save it. Not "I'll remember it" — paste it in, right then, with a one-line note on why it worked. Over a couple of months you build a personal library of prompts tuned to your coaching, which is worth more than any generic prompt list you'll find online, because it's already been pressure-tested against your real clients.

(If you'd rather not build this from a blank page, it's exactly what the SCRIPT Toolkit is — a tested prompt library organized this way, by coaching function. More on that at the end. Either way, the structure above is the target.)

Build a Client Context File for Each Client

A prompt is only as good as what the model knows about the person it's writing for. The check-in reframe that lands for a self-critical client is wrong for one who needs a push. The AI can't know the difference — unless you tell it, every time, or unless you give it a file it can read.

Keep a short running doc per client. It doesn't need to be long — half a page is plenty:

• Primary goal and timeline — what they're actually here for.
• Training history and current phase — where they are in their program.
• Personality notes — how they respond to feedback, what motivates them, what derails them. ("Catastrophizes after one bad week." "Responds to direct, hates being coddled.")
• Constraints — schedule, equipment, injuries, life stuff that shapes the plan.
• Patterns you've noticed — the running thread only you would know.

Before a task, you paste the relevant client file into the prompt — or, in a Projects setup, attach the active client's file so every chat in that Project can see it. This is the same context discipline that makes AI check-ins sound human instead of generic; we walked through it in detail in writing client check-ins with AI. The file is just that context, written down once instead of retyped weekly.

One honest caution: be deliberate about what client information you put into any AI tool, and keep it to what you genuinely need for the task — goals, training notes, constraints. Skip anything sensitive that doesn't change the output. Good practice anyway, and your clients would expect it.

Build a Method and Exercise Database

Left to its own defaults, AI programs like the internet average — machine-heavy, generic, full of exercises you'd never prescribe. You fix that the same way you fix client specificity: give it a file.

Your method database is a document that captures how you coach, so you stop re-explaining it:

• Your exercise preferences — the movements you actually use, your preferred variations, the ones you avoid and why ("no upright rows — shoulder risk isn't worth it").
• Your programming defaults — set/rep schemes you favor, how you handle progression, your warm-up structure, your rules for swapping movements.
• Your coaching philosophy in one paragraph — the stuff that makes a plan recognizably yours rather than a template.

Attach this to your Programming Project, and now every program the model drafts starts from your toolbox instead of a stranger's. The output goes from "I have to rewrite half these exercises" to "I'm adjusting a couple of details." That's the whole game with AI — get it to 80% your way so your editing is light.

This is also the piece that protects your coaching identity. A common fear is that leaning on AI makes every coach's programs converge into the same beige output. The method database is the antidote: the more of your actual preferences the model can see, the more the work sounds like you and not like everyone else prompting the same tool.

Tie It Together: Naming and a Ten-Second Rule

The best workspace is the one you can navigate without thinking. Two small habits make the difference:

Name things predictably. Pick a convention and hold it. Something like Client - [Name] - Context, Prompt Library - [Function], Method - Programming Defaults. The goal: when you need a file mid-task, you find it in under ten seconds. If you're hunting, the system has failed and you'll quietly stop using it.

Designate a weekly rhythm. The workspace pays off most when paired with batching. Pick one day — Monday works for most — and run your repeating tasks in one focused session: pull up the Project, work through check-ins client by client (context files attached), then programming. Because the constants are already loaded, you're only supplying what's new. A roster that used to eat a scattered six hours across the week compresses into a couple of focused ones.

That's the payoff. Not "AI is magic" — it isn't. It's that a coach with a real workspace spends their AI time on the 20% that's actually this week's coaching, instead of re-staging the same 80% every single time.

Frequently Asked Questions

Do I need to pay for ChatGPT or Claude to do this?

The Projects feature lives on the paid tiers of both. For a coach using AI as a daily drafting layer, it's one of the easier tools to justify — it pays for itself the first week you stop re-pasting context. You can build the prompt library and client files on a free plan too; you just lose the "attached files every chat can see" convenience and do more pasting.

ChatGPT Projects or Claude Projects — which should I actually pick?

If you're undecided, start with whichever you already pay for. If you do a lot of long-context work (long training logs, multi-week iterative builds), Claude tends to hold the thread better. For fast everyday drafting, ChatGPT is a safe default. You don't need both.

How long does the initial setup take?

A focused afternoon gets you a usable v1: one or two Projects, a starter prompt library with your ten most-used prompts, a method database, and context files for your current clients. It gets better as you add to it — but you don't need it perfect to start using it.

Won't a saved prompt library make all my programs look the same?

Only if the prompts have no room for client specifics. The structure here is the opposite: reusable scaffolding (the prompt) plus per-client context (the file) plus your methods (the database). Same skeleton, different inputs, your fingerprint on all of it.

Is it worth doing this if I only have a handful of clients?

The fewer clients you have, the less the time-savings bite — but the habit is easier to build now than to retrofit at 40 clients. Set up a light version: one prompt doc, one method file, context files as you go.